Hosting af Qwen på Blackwell

NVIDIA GB200 NVL72-racks med NVIDIA Blackwell-GPU'er forbundet via 72-vejs NVLink er unikt egnet til implementering af store MoE-modeller (mixture-of-experts). I dette blogindlæg beskriver vi inferensopsætningen, der leverer eftertrænede Qwen3 235B-modeller, som understøtter en del af Perplexitys trafik. Vi viser, hvordan vi tilpassede vores interne inferensmotor til at udnytte de avancerede tensor-kerner og højhastigheds-interconnectet i NVIDIA Blackwell-GPU'er. Med denne hardware håndterer vi mere trafik til en lavere pris uden at gå på kompromis med nøjagtigheden af de underliggende modeller.

Implementering på GB200 NVL72

GB200 NVL72-racks består af 18 noder med 2 ARM-baserede NVIDIA Grace-CPU'er og 4 Blackwell-baserede GPU'er, som hver er udstyret med 180 GB HBM. De 72 GPU'er er forbundet via NVLink og 18 NVLink Switch ASIC'er, hvilket leverer en båndbredde på 1800 GB/s mellem to vilkårlige par og deler tilstrækkelig hukommelse til at hoste modeller med billioner af parametre. Derudover leverer ConnectX-7 InfiniBand-adaptere yderligere 400 GB/s i båndbredde både internt i et racks noder og på tværs af naboracks.

For at håndtere trafikken valgte vi at eftertræne og hoste Qwen-modeller. I dette blogindlæg fokuserer vi på Qwen3 235B, men mange af de diskuterede hostningsteknikker og ydeevneegenskaber ligner dem i de nyere Qwen3.5 397B- og 122B-modeller, som vi migrerer til. Med hensyn til parallelisme ligner lineær attention fuld selv-attention, og den eksisterende MoE-lagimplementering kan let tilpasses til at rumme de nye gate-termer. For at opretholde en konsekvent dekodningshastighed og samtidig maksimere gennemløbet har vi valgt at adskille prefill fra dekodning ved at implementere forskellige parallelismestrategier for de to typer noder. Kommunikationen mellem prefiller og decoder håndteres via InfiniBand, hvorimod NVLink-båndbredde er reserveret til kommunikation inden for prefillere og decodere. Ydeevneegenskaberne for Blackwell-enheder ved udførelse af matrixmultiplikation og enhed-til-enhed-kommunikation, som udforskes i dette blogindlæg, bestemmer de anvendte sharding-strategier. Sammenlignet med NVIDIA Hopper-GPU'er ser vi kerne-for-kerne-forbedringer på grund af det højere antal streaming-multiprocessorer, øget hukommelsesbåndbredde og lavere peer-to-peer-latenser.

Udvid

Vores TransferEngine, som implementerer disaggregerede prefill, håndterede vilkårlig og potentielt uoverensstemmende sharding på tværs af prefillere og decodere. KV-cachen er lagt ud i hukommelsen i HND-rækkefølge med hoveder i den ledende dimension og tokens holdt kontiguelle, for at tillade en shardet KV-cache på en prefiller at blive yderligere opdelt eller konkateneret undervejs under overførslen til decoder-noden.

Prefillere

Prefiller-noder modtager input-tokens for en anmodning, udfylder KV-cacher og overfører dem til decoderne for at fortsætte tekstgenereringen. Prefill er beregningsmæssigt intensivt, da tusindvis af tokens, der hører til en sekvens, behandles på samme tid.

Derfor fandt vi ud af, at en tensor-parallel implementering er egnet, hvor modellen er shardet på tværs af 4 GPU'er i en enkelt GB200-node, og projektioner og eksperter er shardet (TP=4, EP=4). Da både attention og MLP'er er beregningsbundne, drager begge fordel af parallelisme ved at fordele eksperter og attention-hoveder på tværs af separate rangordener. Yderligere parallelisme ville have givet aftagende afkast, da gennemløbsforbedringen ved at hoste færre eksperter på hver rangorden (16 versus 32) ikke ville have opvejet de ekstra omkostninger ved en 8-vejs all-reduce og overheadet ved at opdele værts-sidekoden på tværs af to noder, hvilket kræver kommunikation over Ethernet.

Qwen3 235B har kun 4 nøgle-værdi-hoveder, hvilket kræver, at k- og v-projektionerne replikeres på tværs af par af rangordener, hvis der bruges 8 enheder. Vi kunne have overvejet mere aggressiv sharding for at reducere den mængde hukommelse, der kræves for at lagre vægte på hver rangorden, hvilket frigør plads til flere tokens i KV-cachen. Vi fandt dog ud af, at en bredere implementering ikke var det værd.

Under forudsætning af en inputlængde på omkring 6000 tokens har hver af de 128 eksperter omkring 6000 * 8 / 128 = 375 tokens routet til sig, hvilket sikrer et tæt problem for MoE GEMM. Da dette allerede mætter enhedens beregningsgennemløb, er dataparallelisme ikke nødvendig til prefill.

På trods af den kvadratisk voksende pris for attention leverer prefillere et konsistent gennemløb, hvilket tillader et groft anslået overslag over antallet af input-tokens, der kan behandles af en node på et sekund. Ved at stole på metrikker, der sporer det samlede antal input-tokens fra anmodninger, kan antallet af prefiller-noder skaleres op for at sikre, at det samlede prefill-gennemløb er dimensioneret derefter. For at undgå kødannelse matches antallet af prefiller-replikaer med det samlede antal modtagne input-tokens.

Decodere

Decoder-noder modtager KV-cacherne fra prefillerne og genererer tokens ét for ét. Dekodning er generelt hukommelsesbundet: med få input-tokens er matrixmultiplikation fuldstændig bundet af omkostningerne ved at indlæse vægte fra HBM ind i tensor-kerner. Ud over at anvende en anden sharding-strategi skal flere kerner finjusteres for bedre at parallelisere beregninger og hukommelsesadgange.

I modsætning til prefill er sharding af attention ikke længere fordelagtigt: at opdele attention-hoveder på tværs af flere enheder ville betyde, at der er færre muligheder for parallelisme inden for en enkelt enhed. Derfor anvendes kun dataparallelisme og ekspertparallelisme: eksperter er shardet på tværs af flere enheder, men hver enhed administrerer sine egne KV-cacher og anmodninger. Uden tensor-parallelisme er pr. token-KV-cachenstørrelsen på en enhed større. Plads frigøres dog i hukommelsen ved at placere færre eksperter på en enkelt node. I modsætning til Hopper, hvor vi begrænsede tensor-parallelisme inden for et enkelt NVLink-domæne i en 8-GPU-node, fandt vi på Blackwell ud af, at det er fordelagtigt at udvide på tværs af flere noder inden for et domæne ved at bruge op til 16 enheder.

For at maksimere gennemløbet behandler decodere et større antal anmodninger samtidigt. Selvom yderligere anmodninger medfører et minimalt overhead i MoE-lag og andre projektioner, øger de uforholdsmæssigt omkostningerne ved attention. For at opretholde en rimelig minimumsdekodningshastighed skaleres antallet af decoder-noder for at holde pr. decoder-batchstørrelser under en vis tærskel.

I lighed med tidligere Hopper-implementeringer bruger vi spekulativ dekodning med MTP-lag trænede internt for at øge dekodningshastighederne. Heldigvis ligner den underliggende hardware og programmeringsrammer hinanden tilstrækkeligt til fuldt ud at dele implementeringen mellem de to arkitekturer.

Inter-node- og intranode-kommunikation

Hovedforskellen mellem GB200 NVL72 og tidligere Hopper-noder er det store NVLink-domæne, som muliggør peer-to-peer-kommunikation ud over den tidligere grænse på 8 enheder. Selvom Blackwell-enheder er blevet implementeret i 8-GPU-noder, er der stor værdi i at skalere på tværs af flere noder over NVLink sammenlignet med det langsommere InfiniBand-netværk.

På prefiller-noderne stoler vi på all-reduce-kommunikation inden for attention-lag og på en ekspertparallel reduktion, der ligner all-reduce meget. På tværs af 4 GPU'er udnytter vi både NVLink og NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): ud over peer-to-peer-båndbredde udnytter vi også reduktioner i NVLink Switches for yderligere at reducere latenser og implementere hurtige broadcaste. På decoder-noder bruges en tilpasset all-to-all-dispatch- og combine-implementering over NVLink. Kernerne er blevet implementeret internt ved hjælp af CuTeDSL og cuMem-tilordninger eller multicast-tilordninger.

All-Reduce

Prefillerne udfører en all-reduce-operation i attention-lagets outputprojektion og summerer bidragene fra de hoveder, der er shardet på tværs af de deltagende rangordener. Tensor-parallelisme er kun effektiv, når omkostningerne ved all-reduce-overheadet opvejes af den reducerede latens for de mindre matrixmultiplikationsproblemer. Denne antagelse holder normalt for prefill.

På datacenter-grad NVIDIA HGX H200- og GB200 NVL72-systemer er GPU'er normalt forbundet via NVLink Switches. Ud over routing kan switchene udføre reduktionsoperationer på tværs af tilsluttede enheder via SHARP. Efter oprettelse af hukommelsestilordninger og registrering af dem i en multicast-gruppe ved hjælp af CUDA API'erne kan kerner bruge multicast.ld_reduce og multicast.st til at aggregere og broadcast værdier gennem switchene. For at skabe et fundament og genbrugelige komponenter, der kan fuses ind i andre kerner, vedligeholder vi internt en CuTeDSL all-reduce-kerne ved hjælp af disse primitiver.

I et system med N GPU'er, der reducerer B byte, ville en triviel implementering få en peer til at indlæse værdier fra alle andre peers for i alt N * (N - 1) * B byte læsetrafik. En mere effektiv implementering ville opdele de data, der skal reduceres, på tværs af peers, hvor hver reducerer et udsnit af inputtet og derefter broadcaster det til resten. Dette resulterer i (N - 1) * (B / N) byte læst ind i en peer og broadcastet til resten, for i alt (N - 1) * B * 2 læsninger og skrivninger, hvilket reducerer trafikken over switchene.

Udvid

Med SHARP kan reduktionen og broadcastet udføres mere effektivt: i stedet for at indlæse (N - 1) * (B / N) byte i en enhed til lokal akkumulering flyttes der kun B / N fra switchen, da den udfører selve reduktionen ved hjælp af data fra peers. For broadcast er der en lignende forbeholdelse, da antallet af transaktioner mellem en GPU og switchen over NVLink-kanaler reduceres kraftigt. Uden SHARP ville den akkumulerende enhed udføre (N - 1) * (B / N) transaktioner over NVLink med switchen, hvor switchen læser den samme mængde data fra peers, for i alt 2 * (N - 1) * (B / N) transaktioner. Med SHARP udføres B / N transaktioner mellem GPU'en og switchen og yderligere (N - 1) * (B / N) med peers, for i alt B transaktioner.

På grund af sin enkelthed er SHARP et værdifuldt værktøj, da det giver en ligetil hardwareimplementering for en algoritme. Selvom overførslerne reduceres med en teoretisk N / (2 * (N - 1))-brøk (som svarer til 33% med 4 peers), observerer vi i praksis en forbedring på 10% i både prefill- og dekodningslatenser på både H200- og GB200 NVL72-systemer.

Udvid

MoE Dispatch - Combine

For MoE-modeller flytter og grupperer dispatch- og combine-kerner tokens for de efterfølgende MoE GEMM-problemer mellem peers, hvorefter der udføres en vægtet akkumulering i combine. Vi har tilpasset vores eksisterende Dispatch- og Combine-kerner til Blackwell ved at porte dem til CuTeDSL, finjustere bloktildelingerne og aggressivt specialisere dem mellem prefill og dekodning.

Ekspertparallel

Den ekspertparallelle (EP) kerne bruges i prefillere. Da dens inputs replikeres på tværs af alle rangordener, skal dispatch-kernen blot vælge de tokens, der routes til eksperter på den aktuelle rangorden. Den aggregerer routinginformation og forbereder tokens i buffere, der bruges som inputs til MoE GEMM. Combine-kernen udfører først en lokal akkumulering mellem bidragene fra tokens routet til eksperter på den aktuelle rangorden, hvorefter den udfører en all-reduce på tværs af alle rangordener.

For dekodning fuses hele kernen sammen til én. Prefiller-kernen er opdelt i flere kerner, da routing og all-reduce kræver færre blokke end det lokale combine-trin. Med CuTeDSL kunne vi bygge et generisk bibliotek til både SHARP- og NVLink-all-reduce- og peer-to-peer-synkronisering ved at sammensætte det i både all-reduce- og de ekspertparallelle kerner.

Udvid

Mæssigt i forhold til ydeevne observerer vi, at Blackwell er væsentligt hurtigere end Hopper på grund af forbedrede overførselshastigheder, højere hukommelsesbåndbredde og bedre beregningsgennemløb. Shardet på tværs af 8 enheder og flere noder på GB200'er (EP=8) bliver kernerne hurtigere, da den lokale akkumulering kører på meget færre tokens på hver enhed, og med SHARP skalerer omkostningerne ved reduktion på tværs af flere rangordener bedre. I praksis begrænser vi dog parallelismen til 4 enheder, da disse hastighedsforgørelser ikke er universelle på tværs af alle kerner.

Dataparallel og ekspertparallel

Den dataparallelle og ekspertparallelle (DP-EP) kerne bruges i de dataparallelle decodere. Den broadcaster forskellige tokens fra alle rangordener til eksperter, overfører resultaterne til de oprindelige rangordener og akkumulerer dem. Da den implementerer et sparsomt all-to-all-problem, stoler den udelukkende på NVLink.

På Hopper er denne kerne begrænset til 8 enheder inden for et enkelt nods NVLink-domæne. På GB200-systemer kan vi dog skalere den på tværs af et helt rack. Det meste af koden genbruges. Den eneste forskel er brugen af fabric-håndtag til at udveksle peer-information over IMEX til den oprindelige opsætning.

Udvid

Da overførselsstørrelserne, der opstår under dekodning, er små, er de langt fra at mætte NVLink-båndbredden og er i stedet latensbegrænsede. Latenser er i ti-sekunderne af mikrosekunder og forbliver relativt stabile, efterhånden som antallet af peers stiger, hvilket gør det muligt for os at sprede en implementering på tværs af et større antal enheder uden at pådrage os væsentlig yderligere latens.

MoE GEMM

MoE-modeller drager fordel af ekspertparallelisme, da omkostningerne ved at multiplicere alle tokens med alle eksperter let kan paralleliseres på tværs af flere enheder. Med tensor-parallelisme på prefillere ved tætte problemer er fordelen ret ligetil, da hver rangorden nu skal udføre færre beregninger. I dekodningstilfældet giver dataparallelisme en ekstra fordel oven i ekspertparallelisme, da det større antal parallelle anmodninger routes flere tokens til hver ekspert, hvilket gør problemerne tættere.

I vores implementering stoler vi i øjeblikket på CUTLASS CUDA/C++-kerner til matrixmultiplikation. Vi benchmarkede dem på sparsomme dekodnings-inputs med forskellige kvantiseringsskemaer og niveauer af parallelisme for at beslutte den optimale sharding-strategi for decodere. I benchmarks nedenfor aktiveres alle eksperter med et enkelt token.

Udvid

Vi fandt ud af, at skalering af 128 eksperter på tværs af mere end 16 rangordener giver aftagende afkast med CUTLASS, da omkostningerne ved at multiplicere 2 eksperter ikke er væsentligt lavere end at multiplicere 4. Der er en tydelig forbedring på Blackwell over Hopper, selv på den suboptimale blokskaleringsstrategi. Da latensstigningen på omkring 5 us mellem EP=8 og EP=16 for dispatch/combine overvejes af et fald på mere end 10 us i omkostningerne ved GEMM, er det på GB200-systemer berettiget at sharde decodere på tværs af 16 rangordener, hvilket også bekræftes af end-to-end-benchmarks.

Kvantisering

Blackwell introducerer hardwareunderstøttelse af nye 8-bit- og 4-bit-kvantiseringsskemaer. I modsætning til Hopper, som var afhængig af pr. tensor- eller pr. blokskaleringsskaleringsfaktorer, kræver Blackwell mikroskalering for at opnå det bedste prefill- og dekodningsgennemløb. Selvom det blokskaleringsskema, der bruges til modeller som DeepSeek eller Kimi, er tilgængeligt, er mikroskalering mere effektivt.

Vi har implementeret Qwen3 235B med MXFP8-kvantiseringsskemaet og konverteret vægtene statisk efter finjustering af modellen. Nøjagtighedspåvirkningen svarede til påvirkningen af blokskalering med stokastisk kvantisering, men den leverede ydeevne var meget forbedret, hvilket illustreres af MoE GEMM-mikrobenchmarks. Vi har også overvejet MXFP4- og NVFP4-kvantiseringsskemaerne, selvom nøjagtighedspåvirkningen uden Quantization-Aware Training var for væsentlig til den første overgang fra Hopper til Blackwell. Vi planlægger at udforske disse formater grundigere i fremtidigt arbejde.

End-to-end-ydeevne

Vi benchmarkede decodere for Blackwell Qwen3 235B-implementeringer og sammenlignede dem med vores tidligere Hopper-implementeringer. I denne opsætning overvejede vi blokskalering på tværs af begge implementeringer for at fokusere på virkningen af parallelisme. TP=4-prefillere blev adskilt for begge arkitekturer for at isolere dekodningsydeevnen. Figuren nedenfor illustrerer dekodningsgennemløb under forudsætning af en realistisk udkastacceptrate leveret af vores MTP-lag.

Udvid

På Hopper er det ikke levedygtigt at sharde implementeringen på tværs af mere end 8 GPU'er, da latenserne på tværs af InfiniBand, især på EFA-adaptere, er væsentligt langsommere. På Blackwell opnår vi dog væsentligt højere gennemløb takket være de større NVLink-domæner.

Vi opnåede en første Blackwell-implementering ved at generalisere eksisterende Hopper-kerner og presse ydeevnen af de NVLink-baserede kerner. Vi vil yderligere reducere omkostningerne ved at hoste Qwen ved at forbedre kvantisering og finjustere dekodningsydeevnen og prefill-gennemløbet for de andre kerner i pipelinen.

Referencer

Transfer Engine-blogindlæg

CuTeDSL-blogindlæg

Prefill-Disagg-blogindlæg

Blogindlæg om spekulativ dekodning

CUTLASS

NVLink

Citation

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}