Qwen hosten op Blackwell

NVIDIA GB200 NVL72-racks met NVIDIA Blackwell-GPU's die via 72-weg NVLink met elkaar verbonden zijn, zijn bij uitstek geschikt voor het inzetten van grote mixture-of-experts (MoE)-modellen. In deze blogpost beschrijven we de inferentie-opstelling voor het serveren van post-trained Qwen3 235B-modellen die een deel van het verkeer van Perplexity ondersteunen. We laten zien hoe we onze in-house inferentie-engine hebben aangepast om gebruik te maken van de geavanceerde tensor-cores en de hogesnelheids-interconnect van NVIDIA Blackwell-GPU's. Met deze hardware verwerken we meer verkeer tegen lagere kosten zonder in te boeten op de nauwkeurigheid van de onderliggende modellen.

Inzet op GB200 NVL72

GB200 NVL72-racks bestaan uit 18 nodes met 2 op ARM gebaseerde NVIDIA Grace-CPU's en 4 op Blackwell gebaseerde GPU's, elk uitgerust met 180 GB HBM. De 72 GPU's zijn onderling verbonden via NVLink en 18 NVLink Switch ASIC's, wat zorgt voor een bandbreedte van 1800 GB/s tussen elke twee peers en voldoende gedeeld geheugen om modellen met biljoenen parameters te hosten. Daarnaast leveren ConnectX-7 InfiniBand-adapters een extra 400 Gb/s bandbreedte, zowel binnen de nodes van een rack als tussen aangrenzende racks.

Om het verkeer af te handelen, hebben we ervoor gekozen om Qwen-modellen te post-trainen en te serveren. In deze blogpost richten we ons op Qwen3 235B, maar veel van de besproken serveertechnieken en prestatiekenmerken zijn vergelijkbaar met die van de nieuwere Qwen3.5 397B- en 122B-modellen waar we naar migreren. Wat parallellisme betreft is lineaire aandacht vergelijkbaar met volledige zelfaandacht, en de bestaande implementatie van de MoE-laag kan eenvoudig worden aangepast om de nieuwe gate-termen te accommoderen. Om een consistente decodeersnelheid te behouden en tegelijkertijd de doorvoer te maximaliseren, hebben we ervoor gekozen om prefill van decode te scheiden en verschillende parallellismestrategieën in te zetten voor de twee soorten nodes. Communicatie tussen prefiller en decoder verloopt via InfiniBand, terwijl NVLink-bandbreedte is gereserveerd voor communicatie binnen prefillers en decoders. De prestatiekenmerken van Blackwell-apparaten bij het uitvoeren van matrixvermenigvuldiging en communicatie tussen apparaten, die in deze blogpost worden onderzocht, bepalen de gebruikte sharding-strategieën. Vergeleken met NVIDIA Hopper-GPU's zien we verbeteringen per kernel dankzij het grotere aantal streaming multiprocessors, de toegenomen geheugenbandbreedte en de lagere peer-to-peer-latentie.

Vergroten

Onze TransferEngine, die gedesaggregeerde prefill implementeert, verwerkte willekeurige en mogelijk niet-overeenkomende sharding tussen prefillers en decoders. De KV-caches zijn in het geheugen gerangschikt in HND-volgorde, met de koppen in de leidende dimensie en tokens aaneengesloten, zodat een gesharde KV-cache op een prefiller tijdens de overdracht naar de decoder-node verder kan worden gesplitst of samengevoegd.

Prefillers

Prefiller-nodes ontvangen de invoertokens van een verzoek, vullen KV-caches en dragen deze over naar de decoders om het genereren van tekst voort te zetten. Prefill is rekenintensief, omdat duizenden tokens die tot een reeks behoren tegelijkertijd worden verwerkt.

Bijgevolg ontdekten we dat een tensor-parallelle inzet geschikt is, waarbij het model wordt geshard over 4 GPU's binnen een enkele GB200-node en projecties en experts worden geshard (TP=4, EP=4). Aangezien zowel aandacht als MLP's rekenintensief zijn, profiteren beide van parallellisme door experts en aandachtskoppen over afzonderlijke ranks te verdelen. Verder parallellisme zou minder resultaat hebben opgeleverd, omdat de doorvoerverbetering door minder experts op elke rank te hosten (16 in plaats van 32) de extra kosten van een 8-weg all-reduce en de overhead van het splitsen van de host-side code over twee nodes, die communicatie via Ethernet vereist, niet zou compenseren.

Qwen3 235B heeft slechts 4 key-value-koppen, waardoor de k- en v-projecties over paren ranks moeten worden gerepliceerd als er 8 apparaten worden gebruikt. We hadden agressievere sharding kunnen overwegen om de hoeveelheid geheugen te verminderen die nodig is om gewichten op elke rank op te slaan, waardoor Ruimte vrijkomt voor meer tokens in de KV-cache. We ontdekten echter dat een bredere inzet niet de moeite waard was.

Uitgaande van een invoerlengte van ongeveer 6000 tokens, heeft elk van de 128 experts ongeveer 6000 * 8 / 128 = 375 tokens die ernaar worden gerouteerd, wat zorgt voor een dicht probleem voor MoE GEMM. Omdat dit de rekenkracht van het apparaat al verzadigt, is datapara-llellisme niet nodig voor prefill.

Ondanks de kwadratisch toenemende kosten van aandacht leveren prefillers een consistente doorvoer, wat een ruwe schatting mogelijk maakt van het aantal invoertokens dat door een node per seconde kan worden verwerkt. Door te vertrouwen op statistieken die het totale aantal invoertokens van verzoeken bijhouden, kan het aantal prefiller-nodes worden geschaald om ervoor te zorgen dat de algehele prefill-doorvoer dienovereenkomstig wordt gedimensioneerd. Om wachttijden te voorkomen, wordt het aantal prefiller-replica's afgestemd op het totale aantal ontvangen invoertokens.

Decoders

Decoder-nodes ontvangen de KV-caches van de prefillers en genereren tokens één voor één. Decode is over het algemeen geheugenintensief: met weinig invoertokens wordt matrixvermenigvuldiging volledig beperkt door de kosten van het laden van gewichten van HBM naar Tensor Cores. Naast het gebruik van een andere sharding-strategie, moeten verschillende kernels worden aangepast om berekeningen en geheugentoegang beter te parallelliseren.

In tegenstelling tot prefill is sharding van aandacht niet langer voordelig: het splitsen van aandachtskoppen over meerdere apparaten zou betekenen dat er minder mogelijkheden voor parallellisme binnen één apparaat zijn. Bijgevolg worden alleen datapara-llellisme en expert-parallellisme gebruikt: experts worden over meerdere apparaten geshard, maar elk apparaat beheert zijn eigen KV-caches en verzoeken. Zonder tensor-parallellisme is de KV-cachegrootte per token op een apparaat groter. Er komt echter Ruimte vrij in het geheugen door minder experts op een enkele node te plaatsen. In tegenstelling tot Hopper, waar we tensor-parallellisme binnen een enkel NVLink-domein in een node met 8 GPU's beperkten, ontdekten we op Blackwell dat uitbreiding over meerdere nodes binnen een domein, met gebruik van maximaal 16 apparaten, voordelig is.

Om de doorvoer te maximaliseren, verwerken decoders tegelijkertijd een groter aantal verzoeken. Hoewel extra verzoeken een minimale overhead met zich meebrengen in MoE-lagen en andere projecties, verhogen ze de kosten van aandacht onevenredig. Om een redelijke minimale decodeersnelheid te behouden, wordt het aantal decoder-nodes geschaald om de batchgroottes per decoder onder een bepaalde drempel te houden.

Net als bij eerdere Hopper-implementaties gebruiken we speculatief decoderen met in-house getrainde MTP-lagen om de decodeersnelheden te verhogen. Gelukkig zijn de onderliggende hardware en programmeerframeworks vergelijkbaar genoeg om de implementatie volledig te delen tussen de twee architecturen.

Intra-node en inter-node communicatie

Het belangrijkste verschil tussen GB200 NVL72 en eerdere Hopper-nodes is het grote NVLink-domein, dat peer-to-peer-communicatie mogelijk maakt die verder gaat dan de eerdere limiet van 8 apparaten. Hoewel Blackwell-apparaten zijn ingezet in nodes met 8 GPU's, is er veel waarde in het schalen over meerdere nodes via NVLink in vergelijking met het tragere InfiniBand-netwerk.

Op de prefiller-nodes vertrouwen we op all-reduce-communicatie binnen aandachts-lagen en op een expert-parallelle reductie die sterk lijkt op all-reduce. Over 4 GPU's maken we gebruik van zowel NVLink als NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): naast peer-to-peer-bandbreedte exploiteren we ook reducties in NVLink-switches om latentie verder te verminderen en snelle broadcasts te implementeren. Op decoder-nodes wordt een aangepaste all-to-all dispatch- en combine-implementatie via NVLink gebruikt. De kernels zijn in-house geïmplementeerd met behulp van CuTeDSL en cuMem-mappings of multicast-mappings.

All-Reduce

De prefillers voeren een all-reduce-bewerking uit in de outputprojectie van de aandachts-laag, waarbij de bijdragen van de koppen die over de deelnemende ranks zijn geshard, worden opgeteld. Tensor-parallellisme is alleen effectief wanneer de kosten van de all-reduce-overhead worden gecompenseerd door de verminderde latentie van de kleinere matrixvermenigvuldigingsproblemen. Deze aanname is meestal geldig voor prefill.

Op datacenter-grade NVIDIA HGX H200- en GB200 NVL72-systemen zijn GPU's meestal verbonden via NVLink-switches. Naast routering kunnen de switches reductiebewerkingen uitvoeren over verbonden apparaten via SHARP. Na het maken van geheugenmappings en het registreren ervan in een multicast-groep met behulp van de CUDA API's, kunnen kernels de multicast.ld_reduce en multicast.st gebruiken om waarden via de switches te aggregeren en uit te zenden. Om een basis en herbruikbare componenten te creëren die in andere kernels kunnen worden gefuseerd, onderhouden we intern een CuTeDSL all-reduce-kernel die deze primitieven gebruikt.

In een systeem met N GPU's die B bytes reduceren, zou een triviale implementatie een peer waarden van alle andere peers laten laden, voor een totaal van N * (N - 1) * B bytes aan leestraffiek. Een efficiëntere implementatie zou de te reduceren gegevens over peers verdelen, waarbij elke peer een schijf van de invoer reduceert en deze vervolgens uitzendt naar de rest. Dit resulteert in (N - 1) * (B / N) bytes gelezen in een peer en uitgezonden naar de rest, voor een totaal van (N - 1) * B * 2 lees- en schrijfbewerkingen, wat het verkeer over de switches vermindert.

Vergroten

Met SHARP kunnen de reductie en de broadcast efficiënter worden uitgevoerd: in plaats van (N - 1) * (B / N) bytes naar een apparaat te lezen voor lokale accumulatie, wordt slechts B / N verplaatst vanaf de switch, omdat deze de reductie zelf uitvoert met gegevens van de peers. Voor broadcast is er een vergelijkbare verbetering, aangezien het aantal transacties tussen een GPU en de switch over NVLink-kanalen aanzienlijk wordt verminderd. Zonder SHARP zou het accumulerende apparaat (N - 1) * (B / N) transacties over NVLink met de switch uitvoeren, waarbij de switch dezelfde hoeveelheid gegevens van de peers leest, voor een totaal van 2 * (N - 1) * (B / N) transacties. Met SHARP worden B / N transacties uitgevoerd tussen de GPU en de switch, en nog eens (N - 1) * (B / N) met de peers, voor een totaal van B transacties.

Vanwege de eenvoud is SHARP een waardevol hulpmiddel, omdat het een eenvoudige hardware-implementatie biedt voor een algoritme. Hoewel de overdrachten worden verminderd met een theoretische N / (2 * (N - 1)) fractie (wat neerkomt op 33% bij 4 peers), zien we in de praktijk een verbetering van 10% in zowel prefill- als decode-latentie op zowel H200- als GB200 NVL72-systemen.

Vergroten

MoE Dispatch - Combine

Voor MoE-modellen verplaatsen en groeperen dispatch- en combine-kernels tokens voor de daaropvolgende MoE GEMM-problemen tussen peers, waarbij daarna een gewogen accumulatie wordt uitgevoerd in combine. We hebben onze bestaande Dispatch- en Combine-kernels aangepast aan Blackwell door ze naar CuTeDSL te porten, de bloktoewijzingen aan te passen en ze agressief te specialiseren tussen prefill en decode.

Expert Parallel

De expert-parallelle (EP) kernel wordt gebruikt in prefillers. Omdat de invoer ervan over alle ranks wordt gerepliceerd, hoeft de dispatch-kernel eenvoudigweg de tokens te selecteren die naar experts op de huidige rank worden gerouteerd. Het aggregeert routeringsinformatie en bereidt tokens voor in buffers die als invoer voor MoE GEMM worden gebruikt. De combine-kernel voert eerst een lokale accumulatie uit tussen de bijdragen van tokens die naar experts op de huidige rank zijn gerouteerd, en voert vervolgens een all-reduce uit over alle ranks.

Voor decode wordt de gehele kernel tot één geheel gefuseerd. De prefill-kernel is opgesplitst in meerdere kernels, aangezien routering en all-reduce minder blokken vereisen dan de lokale combine-stap. Met CuTeDSL konden we een generieke bibliotheek bouwen voor zowel SHARP als NVLink all-reduce en peer-to-peer-synchronisatie, en deze samenstellen in zowel de all-reduce- als de expert-parallelle kernels.

Vergroten

Wat de prestaties betreft, zien we dat Blackwell aanzienlijk sneller is dan Hopper, dankzij verbeterde overdrachtsnelheden, hogere geheugenbandbreedte en betere rekenkracht. Geshard over 8 apparaten en meerdere nodes op GB200's (EP=8) worden de kernels sneller omdat de lokale accumulatie op veel minder tokens op elk apparaat draait en, met SHARP, de kosten van reductie over meer ranks beter schalen. In de praktijk beperken we het parallellisme echter tot 4 apparaten, omdat deze versnellingen niet universeel zijn voor alle kernels.

Data Parallel en Expert Parallel

De data-parallelle en expert-parallelle (DP-EP) kernel wordt gebruikt in de data-parallelle decoders. Het zendt verschillende tokens van alle ranks uit naar experts, brengt de resultaten over naar de oorspronkelijke ranks en accumuleert ze. Aangezien het een schaars all-to-all-probleem implementeert, vertrouwt het uitsluitend op NVLink.

Op Hopper is deze kernel beperkt tot 8 apparaten binnen het NVLink-domein van een enkele node. Op GB200-systemen kunnen we deze echter over een heel rack schalen. Het grootste deel van de code wordt hergebruikt. Het enige verschil is het gebruik van fabric-handles om peer-informatie uit te wisselen via IMEX voor de initiële setup.

Vergroten

Aangezien de overdrachtsgroottes die tijdens decode worden opgelopen klein zijn, zijn ze verre van verzadigend voor de NVLink-bandbreedte en worden ze in plaats daarvan beperkt door latentie. De latentie ligt in de tientallen microseconden en blijft relatief stabiel naarmate het aantal peers toeneemt, waardoor we een inzet over een groter aantal apparaten kunnen verspreiden zonder significante extra latentie op te lopen.

MoE GEMM

MoE-modellen profiteren van expert-parallellisme, aangezien de kosten van het vermenigvuldigen van alle tokens met alle experts eenvoudig over meerdere apparaten kunnen worden geparallelliseerd. Met tensor-parallellisme op prefillers is het voordeel bij dichte problemen vrij eenvoudig, aangezien elke rank nu minder berekeningen hoeft uit te voeren. In het decode-geval biedt datapara-llellisme een extra voordeel bovenop expert-parallellisme, omdat het grotere aantal parallelle verzoeken meer tokens naar elke expert routeert, wat de problemen verdicht.

In onze implementatie vertrouwen we momenteel op CUTLASS CUDA/C++ kernels voor matrixvermenigvuldiging. We hebben ze gebenchmarkt op schaarse decode-invoer met verschillende kwantiseringsschema's en niveaus van parallellisme om de optimale sharding-strategie voor decoders te bepalen. In de onderstaande benchmarks worden alle experts geactiveerd met een enkel token.

Vergroten

We ontdekten dat het schalen van 128 experts over meer dan 16 ranks met CUTLASS minder resultaat oplevert, aangezien de kosten van het vermenigvuldigen van 2 experts niet aanzienlijk lager zijn dan die van 4. Er is een duidelijke verbetering op Blackwell ten opzichte van Hopper, zelfs bij de suboptimale blokschalingsstrategie. Omdat de latentietoename van ongeveer 5 us tussen EP=8 en EP=16 van dispatch/combine wordt gecompenseerd door een afname van meer dan 10 us in de kosten van GEMM, is het op GB200-systemen gerechtvaardigd om decoders over 16 ranks te sharden, zoals ook bevestigd door end-to-end benchmarks.

Kwantisering

Blackwell introduceert hardware-ondersteuning voor nieuwe 8-bit en 4-bit kwantiseringsschema's. In tegenstelling tot Hopper, dat vertrouwde op schalingsfactoren per tensor of per blok, vereist Blackwell microscaling om de beste prefill- en decode-doorvoer te bereiken. Hoewel het blokschalingsschema dat wordt gebruikt voor modellen zoals DeepSeek of Kimi beschikbaar is, is microscaling efficiënter.

We hebben Qwen3 235B ingezet met het MXFP8-kwantiseringsschema, waarbij de gewichten statisch worden geconverteerd na het fine-tunen van het model. De invloed op de nauwkeurigheid was vergelijkbaar met de invloed van blokschaling met stochastische kwantisering, maar de geleverde prestaties waren veel beter, zoals geïllustreerd door de MoE GEMM-microbenchmarks. We hebben ook de MXFP4- en NVFP4-kwantiseringsschema's overwogen, hoewel de invloed op de nauwkeurigheid zonder Quantization-Aware Training te significant was voor de initiële overgang van Hopper naar Blackwell. We zijn van plan deze formaten in toekomstig werk grondiger te onderzoeken.

End-to-end prestaties

We hebben de decoders van Blackwell Qwen3 235B-inzettingen gebenchmarkt en vergeleken met onze eerdere Hopper-inzettingen. In deze opstelling hebben we blokschaling over beide inzettingen overwogen om ons te concentreren op de impact van parallellisme. TP=4 prefillers werden gescheiden voor beide architecturen om de decode-prestaties te isoleren. De onderstaande afbeelding illustreert de decodeer-doorvoer, uitgaande van een realistische acceptatiegraad voor concepten zoals geleverd door onze MTP-lagen.

Vergroten

Op Hopper is het sharden van de inzet over meer dan 8 GPU's niet levensvatbaar, aangezien de latentie via InfiniBand, met name op EFA-adapters, aanzienlijk trager is. Op Blackwell bereiken we echter aanzienlijk hogere doorvoer, dankzij de grotere NVLink-domeinen.

We hebben een initiële Blackwell-implementatie bereikt door bestaande Hopper-kernels te generaliseren en de prestaties van de op NVLink gebaseerde kernels te verhogen. We zullen de kosten van het serveren van Qwen verder verlagen door de kwantisering te verbeteren en de decode-prestaties en prefill-doorvoer van de andere kernels in de pijplijn fijn te tunen.

Referenties

Transfer Engine blogpost

CuTeDSL blogpost

Prefill-Disagg blogpost

Speculative Decoding blogpost

CUTLASS

NVLink

Citaat

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