Köra Qwen på Blackwell

NVIDIA GB200 NVL72-rackar med NVIDIA Blackwell-GPU:er som är sammankopplade via 72-vägs NVLink lämpar sig utmärkt för att köra stora MoE-modeller (mixture-of-experts). I det här blogginlägget beskriver vi den inferensmiljö som kör tränade Qwen3 235B-modeller vilka hanterar en del av Perplexity-trafiken. Vi visar hur vi anpassade vår egna inferensmotor för att utnyttja de avancerade tensorkärnorna och höghastighetssammankopplingen hos NVIDIA Blackwell-GPU:er. Med denna hårdvara hanterar vi mer trafik till en lägre kostnad utan att kompromissa med noggrannheten hos de underliggande modellerna.

Driftsättning på GB200 NVL72

GB200 NVL72-rack består av 18 noder med 2 ARM-baserade NVIDIA Grace-CPU:er och 4 Blackwell-baserade GPU:er, var och en utrustad med 180 GB HBM. De 72 GPU:erna är sammankopplade via NVLink och 18 NVLink Switch ASIC:ar, vilket ger en bandbredd på 1800 GB/s mellan valfritt par av enheter och delar tillräckligt med minne för att rymma modeller med biljoner parametrar. Dessutom ger ConnectX-7 InfiniBand-adaptrar ytterligare 400 Gb/s i bandbredd både inom noderna i ett rack och mellan närliggande rack.

För att hantera trafiken valde vi att vidareutbilda och köra Qwen-modeller. I det här blogginlägget fokuserar vi på Qwen3 235B, men många av de omskrivna teknikerna för exekvering och prestandaegenskaper liknar dem för de nyare Qwen3.5 397B- och 122B-modellerna som vi migrerar till. När det gäller parallellism liknar linjär attention full self attention, och den befintliga implementering av MoE-lager kan enkelt anpassas för att rymma de nya gate-villkoren. För att upprätthålla en konsekvent avkodningshastighet samtidigt som vi maximerar dataflödet har vi valt att separera förfyllning (prefill) från avkodning och tillämpa olika strategier för parallellism för de två typerna av noder. Kommunikationen mellan prefiller och avkodare hanteras via InfiniBand, medan NVLink-bandbredden är reserverad för kommunikation inom prefillers och avkodare. Prestandaegenskaperna hos Blackwell-enheter vid matrismultiplikation och enhetsöverskridande kommunikation, som utforskas i det här blogginlägget, avgör vilka sharding-strategier som används. Jämfört med NVIDIA Hopper-GPU:er ser vi förbättringar kärna för kärna tack vare ett högre antal streaming-multiprocessorer, ökad minnesbandbredd och lägre latenser för peer-to-peer.

Förstora

Vår TransferEngine, som implementerar separerad prefill, hanterade godtycklig och eventuellt matchande sharding över prefillers och avkodare. KV-cacher är placerade i minnet i HND-ordning, med huvuden i den ledande dimensionen och tokens hållna kontinuerliga, för att tillåta att en shardad KV-cache på en prefiller delas upp ytterligare eller sammanfogas under överföringen till avkodarnoden.

Prefillers

Prefiller-noder tar emot indatatokens för en begäran, fyller i KV-cacher och överför dem till avkodarna för att fortsätta textgenereringen. Prefill är beräkningsintensivt eftersom tusentals tokens som tillhör en sekvens bearbetas samtidigt.

Följaktligen fann vi att en tensorparallell driftsättning är lämplig, där modellen shardas över 4 GPU:er inom en enda GB200-nod och projektioner och experter shardas (TP=4, EP=4). Eftersom både attention och MLP är beräkningsbundna drar båda nytta av parallellism genom att fördela experter och attention-huvuden över separata rangordningar. Ytterligare parallellism skulle ha gett avtagande avkastning, eftersom dataflödesförbättringen från att ha färre experter på varje rang (16 jämfört med 32) inte skulle ha vägt upp den extra kostnaden för en 8-vägs all-reduce och overheaden med att dela upp koden på värdsidan över två noder, vilket kräver kommunikation via Ethernet.

Qwen3 235B har endast 4 key-value-huvuden, vilket kräver att k- och v-projektionerna replikeras över par av rangordningar om 8 enheter används. Vi kunde ha övervägt en mer aggressiv sharding för att minska den mängd minne som krävs för att lagra vikter på varje rang, vilket frigör utrymme för fler tokens i KV-cachen. Vi fann dock att en bredare driftsättning inte var värd besväret.

Förutsatt en indatalängd på cirka 6 000 tokens har var och en av de 128 experterna cirka 6000 * 8 / 128 = 375 tokens som dirigeras till sig, vilket säkerställer ett tätt problem för MoE GEMM. Eftersom detta redan mättar enhetens beräkningsdataflöde behövs inte dataparallellism för prefill.

Trots den kvadratiskt ökande kostnaden för attention levererar prefillers ett konsekvent dataflöde, vilket möjliggör en grov uppskattning av antalet indatatokens som kan bearbetas av en nod på en sekund. Genom att förlita sig på mätvärden som spårar det totala antalet indatatokens från begäranden kan antalet prefiller-noder skalas upp för att säkerställa att det totala prefill-dataflödet är dimensionerat därefter. För att undvika köbildning matchas antalet prefiller-repliker med det totala antalet mottagna indatatokens.

Avkodare

Avkodarnoder tar emot KV-cacharna från prefillers och genererar tokens en i taget. Avkodning är i allmänhet minnesbunden: med få indatatokens är matrismultiplikation helt bunden av kostnaden för att ladda vikter från HBM till tensorkärnor. Förutom att använda en annan sharding-strategi måste flera kärnor finjusteras för att bättre parallellisera beräkningar och minnesåtkomster.

Till skillnad från prefill är det inte längre fördelaktigt att sharda attention: att dela upp attention-huvuden över flera enheter skulle innebära färre möjligheter till parallellism inom en enskild enhet. Följaktligen används endast dataparallellism och expertparallellism: experter shardas över flera enheter, men varje enhet hanterar sina egna KV-cacher och begäranden. Utan tensorparallellism är KV-cache-storleken per token på en enhet större. Utrymme i minnet frigörs dock genom att färre experter placeras på en enda nod. Till skillnad från Hopper, där vi begränsade tensorparallellism inom en enda NVLink-domän i en nod med 8 GPU:er, fann vi att det på Blackwell är fördelaktigt att expandera över flera noder inom en domän och använda upp till 16 enheter.

För att maximera dataflödet bearbetar avkodare ett större antal begäranden samtidigt. Även om ytterligare begäranden medför en minimal overhead i MoE-lager och andra projektioner, ökar de oproportionerligt mycket kostnaden för attention. För att bibehålla en rimlig lägsta avkodningshastighet skalas antalet avkodarnoder för att hålla batchstorlekarna per avkodare under ett visst tröskelvärde.

På samma sätt som vid tidigare Hopper-driftsättningar använder vi spekulativ avkodning med internt tränade MTP-lager för att öka avkodningshastigheterna. Lyckligtvis är den underliggande hårdvaran och programmeringsramverken tillräckligt lika för att implementeringen ska kunna delas helt mellan de två arkitekturerna.

Kommunikation inom och mellan noder

Den stora skillnaden mellan GB200 NVL72 och tidigare Hopper-noder är den stora NVLink-domänen, som möjliggör peer-to-peer-kommunikation bortom den tidigare gränsen på 8 enheter. Även om Blackwell-enheter har driftsatts i noder med 8 GPU:er finns det ett stort värde i att skala över flera noder via NVLink jämfört med det långsammare InfiniBand-nätverket.

På prefiller-noderna förlitar vi oss på all-reduce-kommunikation inom attention-lager och på en expertparallell reduktion som starkt liknar all-reduce. Över 4 GPU:er utnyttjar vi både NVLink och NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): utöver peer-to-peer-bandbredd utnyttjar vi även reduktioner i NVLink-switchar för att ytterligare minska latenser och implementera snabba sändningar (broadcasts). På avkodarnoder används en anpassad implementering för all-to-all-dirigering och sammanslagning över NVLink. Kärnorna har implementerats internt med CuTeDSL och cuMem-mappningar eller multicast-mappningar.

All-Reduce

Prefillers utför en all-reduce-operation i attention-lagrets utdatarespektive projektion och summerar bidragen från de huvuden som shardats över de deltagande rangordningarna. Tensorparallellism är endast effektiv när kostnaden för all-reduce-overheaden uppvägs av den minskade latensen för de mindre matrismultiplikationsproblemen. Detta antagande gäller vanligtvis för prefill.

På NVIDIA HGX H200- och GB200 NVL72-system av datacenterklass är GPU:er vanligtvis anslutna via NVLink-switchar. Utöver routning kan switcharna utföra reduktionsoperationer över anslutna enheter via SHARP. Efter att ha skapat minnesmappningar och registrerat dem i en multicast-grupp med hjälp av CUDA-API:erna kan kärnor använda multicast.ld_reduce och multicast.st för att aggregera och skicka ut värden genom switcharna. För att skapa en grund och återanvändbara komponenter som kan slås samman till andra kärnor underhåller vi internt en CuTeDSL all-reduce-kärna med dessa primitiver.

I ett system med N GPU:er som reducerar B byte skulle en trivial implementering innebära att en peer läser in värden från alla andra peers, vilket ger totalt N * (N - 1) * B byte i lästrafik. En mer effektiv implementering skulle dela upp data som ska reduceras mellan peers, där var och en reducerar en del av indata och sedan sända ut det till resten. Detta resulterar i att (N - 1) * (B / N) byte läses in i en peer och sänds ut till resten, för totalt (N - 1) * B * 2 läsningar och skrivningar, vilket minskar trafiken över switcharna.

Förstora

Med SHARP kan reduktionen och utsändningen utföras mer effektivt: i stället för att läsa in (N - 1) * (B / N) byte i en enhet för lokal akkumulering flyttas endast B / N från switchen, eftersom den utför själva reduktionen med data från de andra enheterna. För utsändning finns en liknande förbättring, eftersom antalet transaktioner mellan en GPU och switchen över NVLink-kanaler minskas avsevärt. Utan SHARP skulle den ackumulerande enheten utföra (N - 1) * (B / N) transaktioner över NVLink med switchen, där switchen läser samma mängd data från de andra enheterna, för totalt 2 * (N - 1) * (B / N) transaktioner. Med SHARP utförs B / N transaktioner mellan GPU:n och switchen, och ytterligare (N - 1) * (B / N) med de andra enheterna, för totalt B transaktioner.

På grund av sin enkelhet är SHARP ett värdefullt verktyg eftersom det ger en okomplicerad hårdvaruimplementering för en algoritm. Även om överföringarna reduceras med en teoretisk bråkdel på N / (2 * (N - 1)) (vilket motsvarar 33 % med 4 peers) observerar vi i praktiken en förbättring på 10 % i både prefill- och avkodningslatenser på både H200- och GB200 NVL72-system.

Förstora

MoE Dispatch - Combine

För MoE-modeller flyttar och grupperar dispatch- och combine-kärnor tokens för de efterföljande MoE GEMM-problemen mellan peers, och utför därefter en viktad ackumulering i combine. Vi har anpassat våra befintliga Dispatch- och Combine-kärnor till Blackwell genom att porta dem till CuTeDSL, finjustera blockallokeringarna och specialisera dem aggressivt mellan prefill och avkodning.

Expert Parallel

Den expertparallella (EP) kärnan används i prefillers. Eftersom dess indata replikeras över alla rangordningar behöver dispatch-kärnan helt enkelt välja ut de tokens som dirigeras till experter på den aktuella rangordningen. Den aggregerar routningsinformation och förbereder tokens till buffertar som används som indata för MoE GEMM. Combine-kärnan utför först en lokal ackumulering mellan bidragen från tokens som dirigeras till experter på den aktuella rangordningen, och utför sedan en all-reduce över alla rangordningar.

För avkodning slås hela kärnan ihop till en. Prefill-kärnan delas upp i flera kärnor, eftersom routning och all-reduce kräver färre block än det lokala combine-steget. Med CuTeDSL kunde vi bygga ett generiskt bibliotek för både SHARP- och NVLink-all-reduce samt peer-to-peer-synkronisering, och integrera det i både all-reduce- och de expertparallella kärnorna.

Förstora

Prestandamässigt ser vi att Blackwell är avsevärt snabbare än Hopper, tack vare förbättrade överföringshastigheter, högre minnesbandbredd och bättre beräkningsdataflöde. Shardat över 8 enheter och flera noder på GB200 (EP=8) blir kärnorna snabbare eftersom den lokala ackumuleringen körs på mycket färre tokens på varje enhet och, med SHARP, skalas kostnaden för reduktion över fler rangordningar bättre. I praktiken begränsar vi dock parallellismen till 4 enheter, eftersom dessa hastighetsökningar inte är universella för alla kärnor.

Data Parallel och Expert Parallel

Den dataparallella och expertparallella (DP-EP) kärnan används i de dataparallella avkodarna. Den sänder ut olika tokens från alla rangordningar till experter, överför resultaten till de ursprungliga rangordningarna och ackumulerar dem. Eftersom den implementerar ett glest all-to-all-problem förlitar den sig enbart på NVLink.

På Hopper är denna kärna begränsad till 8 enheter inom NVLink-domänen för en enskild nod. På GB200-system kan vi dock skala den över ett helt rack. Mestadels återanvänds koden. Den enda skillnaden är användningen av fabric-handtag för att utbyta peer-information över IMEX för den ursprungliga konfigurationen.

Förstora

Eftersom de överföringsstorlekar som uppstår under avkodning är små är de långt ifrån att mätta NVLink-bandbredden och är istället latensbegränsade. Latenserna ligger på tiotals mikrosekunder och förblir relativt stabila i takt med att antalet peers ökar, vilket gör att vi kan sprida ut en driftsättning över ett större antal enheter utan att det medför någon betydande extra latens.

MoE GEMM

MoE-modeller drar nytta av expertparallellism, eftersom kostnaden för att multiplicera alla tokens med alla experter enkelt kan parallelliseras över flera enheter. Med tensorparallellism på prefillers är fördelen ganska okomplicerad vid täta problem, eftersom varje rang nu måste utföra färre beräkningar. Vid avkodning ger dataparallellism en extra fördel utöver expertparallellism, eftersom det större antalet parallella begäranden dirigerar fler tokens till varje expert, vilket gör problemen tätare.

I vår implementering förlitar vi oss för närvarande på CUTLASS CUDA/C++-kärnor för matrismultiplikation. Vi körde prestandatester på glesa avkodningsindata med olika kvantiseringsscheman och nivåer av parallellism för att fastställa den optimala sharding-strategin för avkodare. I testerna nedan aktiveras alla experter med en enda token.

Förstora

Vi fann att skalning av 128 experter över mer än 16 rangordningar ger avtagande avkastning med CUTLASS, eftersom kostnaden för att multiplicera 2 experter inte är väsentligt lägre än att multiplicera 4. Det finns en tydlig förbättring på Blackwell jämfört med Hopper, även på den suboptimala blockskalningsstrategin. Eftersom ökningen av latens på cirka 5 us mellan EP=8 och EP=16 för dispatch/combine uppvägs av en minskning på mer än 10 us i kostnaden för GEMM, är det motiverat att sharda avkodare över 16 rangordningar på GB200-system, vilket även bekräftas av ende-till-ende-tester.

Kvantisering

Blackwell introducerar hårdvarustöd för nya 8-bitars- och 4-bitarskvantiseringsscheman. Till skillnad från Hopper, som förlitade sig på skalningsfaktorer per tensor eller per block, kräver Blackwell mikroskalning för att uppnå bästa dataflöde för prefill och avkodning. Även om det blockskalningsschema som används för modeller som DeepSeek eller Kimi är tillgängligt, är mikroskalning mer effektivt.

Vi har driftsatt Qwen3 235B med MXFP8-kvantiseringsschemat och konverterat vikterna statiskt efter finjustering av modellen. Noggrannhetspåverkan liknade effekten av blockskalning med stokastisk kvantisering, men den levererade prestandan var mycket bättre, vilket illustreras av mikrotesterna för MoE GEMM. Vi har också övervägt MXFP4- och NVFP4-kvantiseringsschemana, även om noggrannhetspåverkan utan Quantization-Aware Training var för stor för övergången från Hopper till Blackwell. Vi planerar att utforska dessa format mer noggrant i framtida arbeten.

Prestanda från ende till ende

Vi testade avkodarna i Blackwell Qwen3 235B-driftsättningar och jämförde dem med våra tidigare Hopper-driftsättningar. I den här konfigurationen övervägde vi blockskalning för båda driftsättningarna för att fokusera på effekten av parallellism. TP=4-prefillers separerades för båda arkitekturerna för att isolera avkodningsprestandan. Figuren nedan illustrerar avkodningsdataflöde under antagande om en realistisk acceptansgrad för utkast som levereras av våra MTP-lager.

Förstora

På Hopper är det inte hållbart att sharda driftsättningen över mer än 8 GPU:er, eftersom latenserna över InfiniBand, särskilt på EFA-adaptrar, är väsentligt långsammare. På Blackwell uppnår vi dock ett väsentligt högre dataflöde tack vare de större NVLink-domänema.

Vi uppnådde en första Blackwell-implementering genom att generalisera befintliga Hopper-kärnor och driva prestandan för de NVLink-baserade kärnorna. Vi kommer att ytterligare minska kostnaden för att köra Qwen genom att förbättra kvantiseringen och finjustera avkodningsprestandan och prefill-dataflödet för de andra kärnorna i pipelinen.

Referenser

Blogginlägg om Transfer Engine

Blogginlägg om CuTeDSL

Blogginlägg om Prefill-Disagg

Blogginlägg om spekulativ avkodning

CUTLASS

NVLink

Citering

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