Vertskap for Qwen på Blackwell

NVIDIA GB200 NVL72-rack med NVIDIA Blackwell-GPU-er koblet sammen via 72-veis NVLink egner seg utmerket til distribusjon av store mixture-of-experts-modeller (MoE-modeller). I dette innlegget beskriver vi inferensoppsettet som betjener ettertrenede Qwen3 235B-modeller som støtter en del av trafikken til Perplexity. Vi viser hvordan vi tilpasset vår egne inferensmotor for å utnytte de avanserte tensorkjernene og høyhastighetsforbindelsene i NVIDIA Blackwell-GPU-ene. Med denne maskinvaren håndterer vi mer trafikk til en lavere kostnad uten at det går ut over nøyaktigheten til de underliggende modellene.

Distribusjon på GB200 NVL72

GB200 NVL72-rack består av 18 noder med 2 ARM-baserte NVIDIA Grace-CPU-er og 4 Blackwell-baserte GPU-er, hver utstyrt med 180 GB HBM. De 72 GPU-ene er koblet sammen via NVLink og 18 NVLink Switch ASIC-er, noe som gir 1800 GB/s i båndbredde mellom hvilke som helst to par og deler tilstrekkelig minne til å være vert for modeller med billioner av parametere. I tillegg gir ConnectX-7 InfiniBand-adaptere ytterligere 400 Gb/s i båndbredde både innenfor nodene i et rack og på tvers av omliggende rack.

For å håndtere trafikken valgte vi å ettertrene og betjene Qwen-modeller. I dette innlegget fokuserer vi på Qwen3 235B, men mange av de diskuterte betjeningsteknikkene og ytelsesegenskapene ligner på de nyere Qwen3.5 397B- og 122B-modellene som vi migrerer til. Når det gjelder parallellisme, ligner lineær oppmerksomhet (attention) på full selv-oppmerksomhet, og den eksisterende MoE-lagimplementeringen kan enkelt tilpasses for å imøtekomme de nye porttermene. For å opprettholde en konsekvent dekodingsrate samtidig som gjennomstrømningen maksimeres, har vi valgt å desaggregere prefill fra dekoding, og distribuere ulike parallellismestrategier for de to typene noder. Kommunikasjon mellom prefiller og dekoder håndteres over InfiniBand, mens NVLink-båndbredde er reservert for kommunikasjon innenfor prefillere og dekodere. Ytelsesegenskapene til Blackwell-enheter ved utførelse av matrisemultiplikasjon og kommunikasjon mellom enheter, utforsket i dette innlegget, avgjør de sharding-strategiene som brukes. Sammenlignet med NVIDIA Hopper-GPU-er ser vi kjerne-for-kjerne-forbedringer på grunn av det høyere antallet strømmende multiprosessorer, økt minnebåndbredde og lavere peer-to-peer-forsinkelser.

Forstørr

Vår TransferEngine, som implementerer desaggregert prefill, håndterte vilkårlig og potensielt uoverensstemmende sharding på tvers av prefillere og dekodere. KV-mellomlagrene er plassert i minnet i HND-rekkefølge, med hoder i ledende dimensjon og tokens holdt sammenhengende, for å tillate at et sharded KV-mellomlagre på en prefiller kan deles ytterligere eller settes sammen underveis under overføringen til dekodernoden.

Prefillere

Prefillernoder mottar inndatatokens for en forespørsel, fyller opp KV-mellomlagre og overfører dem til dekoderne for å fortsette tekstdannelsen. Prefill er beregningsintensivt, da tusenvis av tokens som tilhører en sekvens, behandles samtidig.

Følgelig fant vi ut at en tensorparallell distribusjon er egnet, med modellen sharded på tvers av 4 GPU-er i en enkelt GB200-noden og projeksjoner og eksperter sharded (TP=4, EP=4). Siden både oppmerksomhet og MLP-er er beregningsbundet, drar begge fordel av parallellisme, der eksperter og oppmerksomhetshoder distribueres på tvers av separate ranger. Ytterligere parallellisme ville ha gitt avtakende avkastning, siden gjennomstrømningsforbedringen ved å være vert for færre eksperter på hver rang (16 versus 32) ikke ville ha oppveid ekstra kostnad for en 8-veis all-reduce og overheaden ved å dele kodesiden på verten på tvers av to noder, noe som krever kommunikasjon over Ethernet.

Qwen3 235B har bare 4 nøkkel-verdi-hoder, noe som krever at k- og v-projeksjonene repliseres på tvers av par av ranger hvis 8 enheter brukes. Vi kunne ha vurdert mer aggressiv sharding for å redusere mengden minne som kreves for å lagre vekter på hver rang, og frigjort rom for flere tokens i KV-mellomlagret. Vi fant imidlertid ut at en bredere distribusjon ikke var verdt det.

Forutsatt en inndatalengde på rundt 6000 tokens, har hver av de 128 ekspertene rundt 6000 * 8 / 128 = 375 tokens ruttet til seg, noe som sikrer et tett problem for MoE GEMM. Siden dette allerede metter enhetens beregningsgjennomstrømning, er dataparallellisme ikke nødvendig for prefill.

Til tross for den kvadratisk økende kostnaden for oppmerksomhet, leverer prefillere jevn gjennomstrømning, noe som gir et grovt estimat for antall inndatatokens som kan behandles av en node på et sekund. Ved å stole på metrikker som sporer det totale antallet inndatatokens fra forespørsler, kan antall prefillernoder skaleres opp for å sikre at den generelle prefill-gjennomstrømningen er riktig dimensjonert. For å unngå køer tilpasses antall prefillerreplikaer til det totale antallet mottatte inndatatokens.

Dekodere

Dekodernoder mottar KV-mellomlagrene fra prefillerne og genererer tokens ett etter ett. Dekoding er generelt minnebundet: med få inndatatokens er matrisemultiplikasjon fullstendig bundet av kostnaden ved å laste vekter fra HBM til tensorkjerner. I tillegg til å bruke en annen sharding-strategi, må flere kjerner finjusteres for å parallelisere beregninger og minnetilganger bedre.

I motsetning til prefill er det ikke lenger gunstig å sharde oppmerksomhet: å dele opp oppmerksomhetshoder på tvers av flere enheter vil bety at det er færre muligheter for parallellisme innenfor en enkelt enhet. Følgelig brukes bare dataparallellisme og ekspertparallellisme: eksperter sharded på tvers av flere enheter, men hver enhet administrerer sine egne KV-mellomlagre og forespørsler. Uten tensorparallellisme er KV-mellomlagrets størrelse per token på en enhet større. Imidlertid frigjøres rom i minnet ved å plassere færre eksperter på en enkelt node. I motsetning til Hopper, der vi begrenset tensorparallellisme innenfor et enkelt NVLink-domene i en 8-GPU-node, fant vi på Blackwell at det er gunstig å utvide på tvers av flere noder innenfor et domene ved hjelp av opptil 16 enheter.

For å maksimere gjennomstrømningen behandler dekodere et større antall forespørsler samtidig. Selv om ekstra forespørsler medfører en minimal overhead i MoE-lag og andre projeksjoner, øker de kostnaden for oppmerksomhet uforholdsmessig mye. For å opprettholde en rimelig minimumsdekodingshastighet skaleres antall dekodernoder for å holde batchstørrelsene per dekoder under en viss terskel.

I likhet med tidligere Hopper-distribusjoner bruker vi spekulativ dekoding med MTP-lag som er trent internt for å øke dekodingshastigheten. Heldigvis er den underliggende maskinvaren og programmeringsrammeverkene like nok til å dele implementeringen fullt ut mellom de to arkitekturene.

Kommunikasjon innenfor noder og på tvers av noder

Hovedforskjellen mellom GB200 NVL72 og tidligere Hopper-noder er det store NVLink-domenet, som muliggjør peer-to-peer-kommunikasjon utover den forrige grensen på 8 enheter. Selv om Blackwell-enheter er distribuert i 8-GPU-noder, er det stor verdi i å skalere på tvers av flere noder over NVLink sammenlignet med det tregere InfiniBand-nettverket.

På prefillernodene baserer vi oss på all-reduce-kommunikasjon innenfor oppmerksomhetslag og på en ekspertparallell reduksjon som ligner sterkt på all-reduce. På tvers av 4 GPU-er utnytter vi både NVLink og NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): i tillegg til peer-to-peer-båndbredde utnytter vi også reduksjoner i NVLink Switches for ytterligere å redusere forsinkelser og implementere raske kringkastinger. På dekodernoder brukes en tilpasset all-to-all-utsendings- og kombineringsimplementering over NVLink. Kjernene er implementert internt ved hjelp av CuTeDSL og cuMem-tilordninger eller multicast-tilordninger.

All-Reduce

Prefillerne utfører en all-reduce-operasjon i utdata-projeksjonen til oppmerksomhetslaget, og summerer bidragene fra hodene sharded på tvers av de deltakende rangene. Tensorparallellisme er bare effektiv når kostnaden for all-reduce-overheaden oppveies av den reduserte forsinkelsen til de mindre matrisemultiplikasjonsproblemene. Denne antagelsen gjelder vanligvis for prefill.

På datasentersystemer av type NVIDIA HGX H200 og GB200 NVL72 er GPU-er vanligvis koblet sammen via NVLink Switches. I tillegg til ruting kan svitsjene utføre reduksjonsoperasjoner på tvers av tilkoblede enheter via SHARP. Etter å ha opprettet minnetilordninger og registrert dem i en multicast-gruppe ved hjelp av CUDA API-ene, kan kjernene bruke multicast.ld_reduce og multicast.st til å aggregere og kringkaste verdier gjennom svitsjene. For å opprette et fundament og gjenbrukbare komponenter som kan fusjoneres inn i andre kjernere, vedlikeholder vi internt en CuTeDSL all-reduce-kjerne ved hjelp av disse primitivene.

I et system med N GPU-er som reduserer B byte, vil en triviell implementering ha en peer som laster verdier fra alle andre peers, for totalt N * (N - 1) * B byte med lesetrafikk. En mer effektiv implementering vil dele dataene som skal reduseres på tvers av peers, der hver reduserer en del av inndataene, og deretter kringkaster den til resten. Dette resulterer i (N - 1) * (B / N) byte lest inn i en peer og kringkastet til resten, for totalt (N - 1) * B * 2 lesinger og skrivinger, noe som reduserer trafikk over svitsjene.

Forstørr

Med SHARP kan reduksjonen og kringkastingen utføres mer effektivt: i stedet for å lese inn (N - 1) * (B / N) byte i en enhet for lokal akkumulering, flyttes bare B / N fra svitsjen, siden den utfører selve reduksjonen ved hjelp av data fra peers. For kringkasting er det en lignende forbedring, siden antallet transaksjoner mellom en GPU og svitsjen over NVLink-kanaler er sterkt redusert. Uten SHARP vil den akkumulerende enheten utføre (N - 1) * (B / N) transaksjoner over NVLink med svitsjen, der svitsjen leser den samme mengden data fra peers, for totalt 2 * (N - 1) * (B / N) transaksjoner. Med SHARP utføres B / N transaksjoner mellom GPU-en og svitsjen, og ytterligere (N - 1) * (B / N) med peers, for totalt B transaksjoner.

På grunn av sin enkelhet er SHARP et verdig verktøy, siden det gir en rett fram maskinvareimplementering for en algoritme. Selv om overføringene reduseres med en teoretisk N / (2 * (N - 1))-brøk (som tilsvarer 33 % med 4 peers), observerer vi i praksis en 10 % forbedring i både prefill- og dekodingsforsinkelser på både H200- og GB200 NVL72-systemer.

Forstørr

MoE Dispatch – Combine

For MoE-modeller flytter og grupperer dispatch- og combine-kjernene tokens for de etterfølgende MoE GEMM-problemene mellom peers, og utfører en vektet akkumulering etterpå i combine. Vi har tilpasset våre eksisterende Dispatch- og Combine-kjernere til Blackwell ved å overføre dem til CuTeDSL, finjustere blokktildelingene og spesialisere dem aggressivt mellom prefill og dekoding.

Ekspertparallell

Den ekspertparallelle (EP) kjernen brukes i prefillere. Siden inndataene repliseres på tvers av alle ranger, trenger dispatch-kjernen ganske enkelt å velge tokens som rutes til eksperter på gjeldende rang. Den aggregerer rutinginformasjon og forbereder tokens i buffer som brukes som inndata til MoE GEMM. Combine-kjernen utfører først en lokal akkumulering mellom bidragene fra tokens ruttet til eksperter på gjeldende rang, og deretter utfører den en all-reduce på tvers av alle ranger.

For dekoding er hele kjernen fusjonert til én. Prefill-kjernen er delt inn i flere kjernere, siden ruting og all-reduce krever færre blokker enn det lokale combine-trinnet. Med CuTeDSL kunne vi bygge et generisk bibliotek for både SHARP- og NVLink all-reduce og peer-to-peer-synkronisering, og komponere det inn i både all-reduce- og de ekspertparallelle kjernene.

Forstørr

Ytelsesmessig observerer vi at Blackwell er vesentlig raskere enn Hopper på grunn av forbedrede overføringshastigheter, høyere minnebåndbredde og bedre beregningsgjennomstrømning. Sharded på tvers av 8 enheter og flere noder på GB200 (EP=8) blir kjernene raskere ettersom den lokale akkumuleringen kjører på mye færre tokens på hver enhet, og med SHARP skalerer kostnaden for reduksjon på tvers av flere ranger bedre. I praksis begrenser vi imidlertid parallellismen til 4 enheter, siden disse hastighetsøkningene ikke er universelle på tvers av alle kjernere.

Dataparallell og ekspertparallell

Den dataparallelle og ekspertparallelle (DP-EP) kjernen brukes i de dataparallelle dekoderne. Den kringkaster forskjellige tokens fra alle ranger til eksperter, overfører resultatene til opprinnelsesrangene og akkumulerer dem. Siden den implementerer et sparsomt all-to-all-problem, stoler den utelukkende på NVLink.

På Hopper er denne kjernen begrenset til 8 enheter innenfor NVLink-domenet til en enkelt node. På GB200-systemer kan vi imidlertid skalere den på tvers av et hele rack. Mesteparten av koden gjenbrukes. Den eneste forskjellen er bruken av fabric-håndtak for å utveksle peer-informasjon over IMEX for det opprinnelige oppsettet.

Forstørr

Siden overføringsstørrelsene som pådras under dekoding er små, er de langt fra å mette NVLink-båndbredden og er i stedet forsinkelsesbegrensede. Forsinkelser er på titalls mikrosekunder og forblir relativt stabile når antall peers øker, slik at vi kan spre en distribusjon over et større antall enheter uten å pådra oss betydelig ekstra forsinkelse.

MoE GEMM

MoE-modeller drar nytte av ekspertparallellisme, siden kostnaden ved å multiplisere alle tokens med alle eksperter enkelt kan paralleliseres på tvers av flere enheter. Med tensorparallellisme på prefillere er fordelen ganske rett fram ved tette problemer, siden hver rang nå må utføre færre beregninger. I dekodingstilfellet gir dataparallellisme en ekstra fordelt på toppen av ekspertparallellisme, ettersom det større antallet parallelle forespørsler ruter flere tokens til hver ekspert, noe som gjør problemene tettere.

I vår implementering baserer vi oss for tiden på CUTLASS CUDA/C++-kjernere for matrisemultiplikasjon. Vi benchmarkede dem på sparsomme inndata for dekoding med ulike kvantiseringsordninger og parallellismenivåer for å bestemme den optimale sharding-strategien for dekodere. I benchmarkene nedenfor aktiveres alle eksperter med et enkelt token.

Forstørr

Vi fant ut at skalering av 128 eksperter på tvers av mer enn 16 ranger gir avtakende avkastning med CUTLASS, siden kostnaden ved å multiplisere 2 eksperter ikke er vesentlig lavere enn å multiplisere 4. Det er en tydelig forbedring på Blackwell over Hopper, selv på den suboptimale blokkskaleringsstrategien. Siden forsinkelsesøkningen på omtrent 5 us mellom EP=8 og EP=16 for dispatch/combine oppveies av en reduksjon på mer enn 10 us i kostnaden for GEMM, er det på GB200-systemer berettiget å sharde dekodere på tvers av 16 ranger, noe som også bekreftes av end-to-end-benchmarker.

Kvantisering

Blackwell introduserer maskinvarestøtte for nye 8-biters og 4-biters kvantiseringsordninger. I motsetning til Hopper, som stolte på skaleringsfaktorer per tensor eller per blokk, krever Blackwell mikroskalering for å oppnå best mulig prefill- og dekodingsgjennomstrømning. Selv om blokksaleringsordningen som brukes for modeller som DeepSeek eller Kimi er tilgjengelig, er mikroskalering mer effektivt.

Vi har distribuert Qwen3 235B med MXFP8-kvantiseringsordningen, og konvertert vektene statisk etter finjustering av modellen. Nøyaktighetspåvirkningen lignet på påvirkningen av blokkskalering med stokastisk kvantisering, men ytelsen som ble levert, var mye bedre, som illustrert av MoE GEMM-mikrobenchmarkene. Vi har også vurdert MXFP4- og NVFP4-kvantiseringsordningene, selv om nøyaktighetspåvirkningen uten Quantization-Aware Training var for betydelig for den første overgangen fra Hopper til Blackwell. Vi planlegger å utforske disse formatene grundigere i fremtidig arbeid.

End-to-end-ytelse

Vi benchmarkede dekoderne for Blackwell Qwen3 235B-distribusjoner og sammenlignede dem med våre tidligere Hopper-distribusjoner. I dette oppsettet vurderte vi blokkskalering på tvers av begge distribusjoner for å fokusere på påvirkningen av parallellisme. TP=4-prefillere ble separert for begge arkitekturer for å isolere dekodingsytelsen. Figuren nedenfor illustrerer dekodingsgjennomstrømning under antagelse om en realistisk utkastakseptrate levert av våre MTP-lag.

Forstørr

På Hopper er det ikke levedyktig å sharde distribusjonen på tvers av mer enn 8 GPU-er, siden forsinkelsene på tvers av InfiniBand, spesielt på EFA-adaptere, er vesentlig tregere. På Blackwell oppnår vi imidlertid vesentlig høyere gjennomstrømning takket være de større NVLink-domenene.

Vi oppnådde en første Blackwell-implementering ved å generalisere eksisterende Hopper-kjernere og presse ytelsen til de NVLink-baserte kjernene. Vi vil redusere kostnaden for å betjene Qwen ytterligere ved å forbedre kvantisering og finjustere dekodingsytelsen og prefill-gjennomstrømningen for de andre kjernene i pipelinen.

Referanser

Blogginnlegg om Transfer Engine

Blogginnlegg om CuTeDSL

Blogginnlegg om Prefill-Disagg

Blogginnlegg om spekulativ dekoding

CUTLASS

NVLink

Sitat

@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}
}