Hosting von Qwen auf Blackwell

NVIDIA GB200 NVL72-Racks mit NVIDIA Blackwell-GPUs, die über 72-Wege-NVLink miteinander verbunden sind, eignen sich hervorragend für den Einsatz großer Mixture-of-Experts (MoE)-Modelle. In diesem Blogbeitrag beschreiben wir die Inferenz-Einrichtung für das Hosting von nachtrainierten Qwen3 235B-Modellen, die einen Teil des Datenverkehrs von Perplexity unterstützen. Wir zeigen, wie wir unsere interne Inferenz-Engine angepasst haben, um die fortschrittlichen Tensor-Cores und die Hochgeschwindigkeits-Verbindung der NVIDIA Blackwell-GPUs zu nutzen. Mit dieser Hardware bewältigen wir mehr Datenverkehr bei geringeren Kosten, ohne die Genauigkeit der zugrunde liegenden Modelle zu beeinträchtigen.

Einsatz auf GB200 NVL72

GB200 NVL72-Racks bestehen aus 18 Knoten mit je 2 ARM-basierten NVIDIA Grace-CPUs und 4 Blackwell-basierten GPUs, die jeweils mit 180 GB HBM ausgestattet sind. Die 72 GPUs sind über NVLink und 18 NVLink Switch-ASICs miteinander verbunden, was eine Bandbreite von 1800 GB/s zwischen zwei beliebigen Peers ermöglicht und ausreichend Speicher für Modelle mit Billionen von Parametern bietet. Zusätzlich liefern ConnectX-7 InfiniBand-Adapter weitere 400 GB/s Bandbreite sowohl innerhalb der Knoten eines Racks als auch zwischen benachbarten Racks.

Um den Datenverkehr zu bewältigen, haben wir uns entschieden, Qwen-Modelle nachträglich zu trainieren und bereitzustellen. In diesem Blogbeitrag konzentrieren wir uns auf Qwen3 235B, aber viele der diskutierten Bereitstellungstechniken und Leistungsmerkmale ähneln denen der neueren Qwen3.5 397B- und 122B-Modelle, auf die wir gerade migrieren. Hinsichtlich der Parallelisierung ist die lineare Attention ähnlich wie die vollständige Self-Attention, und die bestehende MoE-Layer-Implementierung kann leicht angepasst werden, um die neuen Gate-Terme zu berücksichtigen. Um eine konsistente Dekodierungsrate bei maximalem Durchsatz aufrechtzuerhalten, haben wir uns für eine Trennung von Prefill und Decode entschieden und setzen für die beiden Knotentypen unterschiedliche Parallelisierungsstrategien ein. Die Kommunikation zwischen Prefiller und Decoder erfolgt über InfiniBand, während die NVLink-Bandbreite für die Kommunikation innerhalb der Prefiller und Decoder reserviert ist. Die Leistungsmerkmale der Blackwell-Geräte bei der Durchführung von Matrixmultiplikationen und der Kommunikation zwischen den Geräten, die in diesem Blogbeitrag untersucht werden, bestimmen die verwendeten Sharding-Strategien. Im Vergleich zu NVIDIA Hopper-GPUs stellen wir aufgrund der höheren Anzahl an Streaming-Multiprozessoren, der gesteigerten Speicherbandbreite und der geringeren Peer-to-Peer-Latenzen Verbesserungen bei jedem Kernel fest.

Vergrößern

Unser TransferEngine, der ein disaggregiertes Prefill implementiert, verarbeitete beliebiges und möglicherweise nicht übereinstimmendes Sharding über Prefiller und Decoder hinweg. Die KV-Caches sind im Speicher in HND-Reihenfolge angeordnet, wobei die Heads in der führenden Dimension liegen und die Tokens zusammenhängend gehalten werden, damit ein geshardeter KV-Cache auf einem Prefiller während des Transfers zum Decoder-Knoten weiter aufgeteilt oder verkettet werden kann.

Prefiller

Prefiller-Knoten empfangen die Eingabe-Tokens einer Anfrage, füllen KV-Caches und übertragen diese an die Decoder, um die Textgenerierung fortzusetzen. Prefill ist rechenintensiv, da Tausende von Tokens, die zu einer Sequenz gehören, gleichzeitig verarbeitet werden.

Folglich haben wir festgestellt, dass ein Tensor-paralleler Einsatz geeignet ist, bei dem das Modell über 4 GPUs innerhalb eines einzigen GB200-Knotens geshardet wird und Projektionen sowie Experten geshardet sind (TP=4, EP=4). Da sowohl Attention als auch MLPs rechengebunden sind, profitieren beide von der Parallelisierung, indem Experten und Attention-Heads über separate Ranks verteilt werden. Eine weitere Parallelisierung hätte zu abnehmenden Erträgen geführt, da der Durchsatzvorteil durch das Hosting von weniger Experten auf jedem Rank (16 statt 32) die zusätzlichen Kosten für ein 8-Wege-All-Reduce und den Overhead der Aufteilung des hostseitigen Codes über zwei Knoten hinweg, was Kommunikation über Ethernet erfordert, nicht ausgeglichen hätte.

Qwen3 235B verfügt nur über 4 Key-Value-Heads, was erfordert, dass die k- und v-Projektionen über Rank-Paare repliziert werden müssen, wenn 8 Geräte verwendet werden. Wir hätten ein aggressiveres Sharding in Betracht ziehen können, um den erforderlichen Speicherplatz für das Speichern von Gewichten auf jedem Rank zu reduzieren und so Speicherplatz für mehr Tokens im KV-Cache freizugeben. Wir haben jedoch festgestellt, dass ein breiterer Einsatz nicht lohnenswert war.

Unter der Annahme einer Eingabelänge von etwa 6000 Tokens werden jedem der 128 Experten etwa 6000 * 8 / 128 = 375 Tokens zugewiesen, was ein dichtes Problem für MoE GEMM sicherstellt. Da dies den Rechen-Durchsatz des Geräts bereits sättigt, ist für Prefill keine Datenparallelität erforderlich.

Trotz der quadratisch steigenden Kosten für Attention liefern Prefiller einen konsistenten Durchsatz, was eine grobe Schätzung der Anzahl der Eingabe-Tokens ermöglicht, die von einem Knoten in einer Sekunde verarbeitet werden können. Durch die Nutzung von Metriken, die die Gesamtzahl der Eingabe-Tokens von Anfragen verfolgen, kann die Anzahl der Prefiller-Knoten skaliert werden, um sicherzustellen, dass der gesamte Prefill-Durchsatz entsprechend dimensioniert ist. Um Warteschlangen zu vermeiden, wird die Anzahl der Prefiller-Replikate an die Gesamtzahl der empfangenen Eingabe-Tokens angepasst.

Decoder

Decoder-Knoten empfangen die KV-Caches von den Prefillern und generieren Tokens einzeln. Decode ist im Allgemeinen speichergebunden: Bei wenigen Eingabe-Tokens ist die Matrixmultiplikation vollständig durch die Kosten für das Laden von Gewichten aus dem HBM in die Tensor Cores gebunden. Neben dem Einsatz einer anderen Sharding-Strategie müssen mehrere Kernel angepasst werden, um Berechnungen und Speicherzugriffe besser zu parallelisieren.

Im Gegensatz zu Prefill ist das Sharding von Attention nicht mehr vorteilhaft: Das Aufteilen von Attention-Heads auf mehrere Geräte würde bedeuten, dass weniger Möglichkeiten für Parallelität innerhalb eines einzelnen Geräts bestehen. Folglich werden nur Datenparallelität und Expertenparallelität verwendet: Experten werden über mehrere Geräte geshardet, aber jedes Gerät verwaltet seine eigenen KV-Caches und Anfragen. Ohne Tensor-Parallelität ist die KV-Cache-Größe pro Token auf einem Gerät größer. Speicherplatz wird jedoch dadurch frei, dass weniger Experten auf einem einzelnen Knoten untergebracht werden. Im Gegensatz zu Hopper, wo wir die Tensor-Parallelität innerhalb einer einzigen NVLink-Domäne in einem 8-GPU-Knoten begrenzt haben, haben wir auf Blackwell festgestellt, dass die Expansion über mehrere Knoten innerhalb einer Domäne mit bis zu 16 Geräten vorteilhaft ist.

Um den Durchsatz zu maximieren, verarbeiten Decoder eine größere Anzahl von Anfragen gleichzeitig. Auch wenn zusätzliche Anfragen einen minimalen Overhead in MoE-Layern und anderen Projektionen verursachen, erhöhen sie die Kosten für Attention überproportional. Um eine vernünftige Mindest-Dekodierungsgeschwindigkeit aufrechtzuerhalten, wird die Anzahl der Decoder-Knoten so skaliert, dass die Batch-Größen pro Decoder unter einem bestimmten Schwellenwert bleiben.

Ähnlich wie bei früheren Hopper-Implementierungen verwenden wir spekulative Dekodierung mit intern trainierten MTP-Layern, um die Dekodierungsraten zu steigern. Glücklicherweise sind die zugrunde liegende Hardware und die Programmier-Frameworks ähnlich genug, um die Implementierung vollständig zwischen den beiden Architekturen teilen zu können.

Intra-Knoten- und Inter-Knoten-Kommunikation

Der Hauptunterschied zwischen GB200 NVL72 und früheren Hopper-Knoten ist die große NVLink-Domäne, die eine Peer-to-Peer-Kommunikation über das bisherige Limit von 8 Geräten hinaus ermöglicht. Auch wenn Blackwell-Geräte in 8-GPU-Knoten eingesetzt wurden, ist die Skalierung über mehrere Knoten hinweg via NVLink im Vergleich zum langsameren InfiniBand-Netzwerk sehr wertvoll.

Auf den Prefiller-Knoten verlassen wir uns auf eine All-Reduce-Kommunikation innerhalb der Attention-Layer und auf eine Experten-parallele Reduktion, die stark an All-Reduce erinnert. Über 4 GPUs hinweg nutzen wir sowohl NVLink als auch NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): Zusätzlich zur Peer-to-Peer-Bandbreite nutzen wir Reduktionen in NVLink-Switches, um Latenzen weiter zu reduzieren und schnelle Broadcasts zu implementieren. Auf Decoder-Knoten wird eine benutzerdefinierte All-to-All-Dispatch- und Combine-Implementierung über NVLink verwendet. Die Kernel wurden intern unter Verwendung von CuTeDSL und cuMem-Mappings oder Multicast-Mappings implementiert.

All-Reduce

Die Prefiller führen eine All-Reduce-Operation in der Output-Projektion des Attention-Layers durch und summieren die Beiträge der Heads, die über die teilnehmenden Ranks geshardet sind. Tensor-Parallelität ist nur dann effektiv, wenn die Kosten des All-Reduce-Overheads durch die verringerte Latenz der kleineren Matrixmultiplikationsprobleme ausgeglichen werden. Diese Annahme gilt normalerweise für Prefill.

Auf NVIDIA HGX H200- und GB200 NVL72-Systemen in Rechenzentrumsqualität sind GPUs normalerweise über NVLink-Switches verbunden. Neben dem Routing können die Switches Reduktionsoperationen über angeschlossene Geräte mittels SHARP durchführen. Nach dem Erstellen von Speicher-Mappings und deren Registrierung in einer Multicast-Gruppe über die CUDA-APIs können Kernel multicast.ld_reduce und multicast.st verwenden, um Werte durch die Switches zu aggregieren und zu übertragen. Um eine Grundlage und wiederverwendbare Komponenten zu schaffen, die in andere Kernel integriert werden können, pflegen wir intern einen CuTeDSL All-Reduce-Kernel, der diese Primitive verwendet.

In einem System mit N GPUs, die B Bytes reduzieren, würde eine triviale Implementierung Werte von allen anderen Peers laden, was insgesamt N * (N - 1) * B Bytes an Leseverkehr bedeuten würde. Eine effizientere Implementierung würde die zu reduzierenden Daten über die Peers aufteilen, wobei jeder einen Teil des Inputs reduziert und dann an die anderen überträgt. Dies führt zu (N - 1) * (B / N) Bytes, die in einen Peer gelesen und an die anderen übertragen werden, für insgesamt (N - 1) * B * 2 Lese- und Schreibvorgänge, was den Verkehr über die Switches reduziert.

Vergrößern

Mit SHARP können die Reduktion und der Broadcast effizienter durchgeführt werden: Anstatt (N - 1) * (B / N) Bytes zur lokalen Akkumulation in ein Gerät zu laden, werden nur B / N Bytes vom Switch verschoben, da dieser die Reduktion selbst unter Verwendung von Daten der Peers durchführt. Für den Broadcast gibt es eine ähnliche Verbesserung, da die Anzahl der Transaktionen zwischen einer GPU und dem Switch über NVLink-Kanäle stark reduziert wird. Ohne SHARP würde das akkumulierende Gerät (N - 1) * (B / N) Transaktionen über NVLink mit dem Switch durchführen, wobei der Switch die gleiche Datenmenge von den Peers liest, was insgesamt 2 * (N - 1) * (B / N) Transaktionen entspricht. Mit SHARP werden B / N Transaktionen zwischen der GPU und dem Switch durchgeführt und weitere (N - 1) * (B / N) mit den Peers, was insgesamt B Transaktionen ergibt.

Aufgrund seiner Einfachheit ist SHARP ein wertvolles Werkzeug, da es eine unkomplizierte Hardware-Implementierung für einen Algorithmus bereitstellt. Auch wenn die Transfers rechnerisch um einen Faktor von N / (2 * (N - 1)) (was bei 4 Peers 33% entspricht) reduziert werden, beobachten wir in der Praxis eine 10-prozentige Verbesserung sowohl bei der Prefill- als auch bei der Decode-Latenz auf H200- und GB200 NVL72-Systemen.

Vergrößern

MoE Dispatch - Combine

Bei MoE-Modellen verschieben und gruppieren Dispatch- und Combine-Kernel Tokens für die anschließenden MoE GEMM-Probleme zwischen den Peers und führen danach eine gewichtete Akkumulation im Combine durch. Wir haben unsere bestehenden Dispatch- und Combine-Kernel an Blackwell angepasst, indem wir sie auf CuTeDSL portiert, die Blockzuweisungen optimiert und sie aggressiv zwischen Prefill und Decode spezialisiert haben.

Experten-Parallel

Der Experten-parallele (EP) Kernel wird in Prefillern verwendet. Da seine Eingaben über alle Ranks repliziert werden, muss der Dispatch-Kernel lediglich die Tokens auswählen, die an Experten auf dem aktuellen Rank weitergeleitet werden. Er aggregiert Routing-Informationen und bereitet Tokens in Puffern vor, die als Eingaben für MoE GEMM dienen. Der Combine-Kernel führt zunächst eine lokale Akkumulation zwischen den Beiträgen der Tokens durch, die an Experten auf dem aktuellen Rank weitergeleitet wurden, und führt dann ein All-Reduce über alle Ranks durch.

Für das Dekodieren wird der gesamte Kernel in einem verschmolzen. Der Prefill-Kernel ist in mehrere Kernel aufgeteilt, da Routing und All-Reduce weniger Blöcke erfordern als der lokale Combine-Schritt. Mit CuTeDSL konnten wir eine generische Bibliothek sowohl für SHARP- als auch für NVLink-All-Reduce und Peer-to-Peer-Synchronisation erstellen und diese sowohl in die All-Reduce- als auch in die Experten-parallelen Kernel integrieren.

Vergrößern

In Bezug auf die Leistung stellen wir fest, dass Blackwell aufgrund verbesserter Transfergeschwindigkeiten, höherer Speicherbandbreite und besserem Rechen-Durchsatz wesentlich schneller als Hopper ist. Geshardet über 8 Geräte und mehrere Knoten auf GB200s (EP=8) werden die Kernel schneller, da die lokale Akkumulation auf wesentlich weniger Tokens auf jedem Gerät läuft und mit SHARP die Kosten für die Reduktion über mehr Ranks hinweg besser skalieren. In der Praxis begrenzen wir die Parallelität jedoch auf 4 Geräte, da diese Geschwindigkeitsvorteile nicht für alle Kernel universell sind.

Datenparallel und Experten-Parallel

Der datenparallele und experten-parallele (DP-EP) Kernel wird in datenparallelen Decodern verwendet. Er überträgt verschiedene Tokens von allen Ranks an Experten, leitet die Ergebnisse an die ursprünglichen Ranks weiter und akkumuliert sie. Da er ein spärliches All-to-All-Problem implementiert, basiert er ausschließlich auf NVLink.

Auf Hopper ist dieser Kernel auf 8 Geräte innerhalb der NVLink-Domäne eines einzelnen Knotens beschränkt. Auf GB200-Systemen können wir ihn jedoch über ein gesamtes Rack skalieren. Der Großteil des Codes wird wiederverwendet. Der einzige Unterschied ist die Verwendung von fabric-Handles zum Austausch von Peer-Informationen über IMEX für das anfängliche Setup.

Vergrößern

Da die während des Dekodierens anfallenden Transfergrößen klein sind, sind sie weit davon entfernt, die NVLink-Bandbreite zu sättigen, und sind stattdessen latenzbegrenzt. Die Latenzen liegen im Bereich von zweistelligen Mikrosekunden und bleiben relativ stabil, wenn die Anzahl der Peers steigt, was es uns ermöglicht, einen Einsatz auf eine größere Anzahl von Geräten zu verteilen, ohne signifikante zusätzliche Latenz zu verursachen.

MoE GEMM

MoE-Modelle profitieren von Experten-Parallelität, da die Kosten für das Multiplizieren aller Tokens mit allen Experten leicht über mehrere Geräte hinweg parallelisiert werden können. Bei der Tensor-Parallelität auf Prefillern ist der Vorteil bei dichten Problemen ziemlich direkt, da jeder Rank nun weniger Berechnungen durchführen muss. Im Decode-Fall bietet die Datenparallelität einen zusätzlichen Vorteil gegenüber der Experten-Parallelität, da die größere Anzahl paralleler Anfragen mehr Tokens an jeden Experten weiterleitet, was die Probleme verdichtet.

In unserer Implementierung verlassen wir uns derzeit auf CUTLASS CUDA/C++-Kernel für die Matrixmultiplikation. Wir haben diese auf spärlichen Decode-Inputs mit verschiedenen Quantisierungsschemata und Parallelitätsgraden gebenchmarkt, um die optimale Sharding-Strategie für Decoder zu bestimmen. In den unten aufgeführten Benchmarks sind alle Experten mit einem einzelnen Token aktiviert.

Vergrößern

Wir haben festgestellt, dass das Skalieren von 128 Experten über mehr als 16 Ranks bei CUTLASS zu abnehmenden Erträgen führt, da die Kosten für die Multiplikation von 2 Experten nicht wesentlich niedriger sind als die von 4. Es gibt eine klare Verbesserung auf Blackwell gegenüber Hopper, selbst bei der suboptimalen Block-Scaling-Strategie. Da der Latenzanstieg von etwa 5 us zwischen EP=8 und EP=16 bei Dispatch/Combine durch eine Senkung der Kosten für GEMM um mehr als 10 us aufgewogen wird, ist das Sharding von Decodern über 16 Ranks auf GB200-Systemen gerechtfertigt, was auch durch End-to-End-Benchmarks bestätigt wird.

Quantisierung

Blackwell führt Hardware-Unterstützung für neue 8-Bit- und 4-Bit-Quantisierungsschemata ein. Im Gegensatz zu Hopper, das sich auf pro-Tensor- oder pro-Block-Skalierungsfaktoren stützte, erfordert Blackwell Mikro-Skalierung, um den besten Prefill- und Decode-Durchsatz zu erzielen. Während das für Modelle wie DeepSeek oder Kimi verwendete Block-Scaling-Schema verfügbar ist, ist Mikro-Skalierung effizienter.

Wir haben Qwen3 235B mit dem MXFP8-Quantisierungsschema bereitgestellt und die Gewichte nach dem Fine-Tuning des Modells statisch konvertiert. Die Auswirkungen auf die Genauigkeit waren ähnlich wie beim Block-Scaling mit stochastischer Quantisierung, aber die erzielte Leistung war wesentlich verbessert, wie die MoE GEMM-Mikrobenchmarks zeigen. Wir haben auch die MXFP4- und NVFP4-Quantisierungsschemata in Betracht gezogen, obwohl die Auswirkungen auf die Genauigkeit ohne Quantization-Aware Training für den anfänglichen Übergang von Hopper zu Blackwell zu signifikant waren. Wir planen, diese Formate in zukünftigen Arbeiten gründlicher zu untersuchen.

End-to-End-Leistung

Wir haben die Decoder von Blackwell Qwen3 235B-Implementierungen gebenchmarkt und mit unseren früheren Hopper-Implementierungen verglichen. In diesem Setup haben wir das Block-Scaling über beide Implementierungen hinweg berücksichtigt, um uns auf die Auswirkungen der Parallelität zu konzentrieren. TP=4-Prefiller wurden für beide Architekturen getrennt, um die Decode-Leistung zu isolieren. Die Abbildung unten zeigt den Dekodierungsdurchsatz unter der Annahme einer realistischen Draft-Akzeptanzrate, die von unseren MTP-Layern geliefert wird.

Vergrößern

Auf Hopper ist ein Sharding des Einsatzes über mehr als 8 GPUs nicht praktikabel, da die Latenzen über InfiniBand, insbesondere bei EFA-Adaptern, wesentlich höher sind. Auf Blackwell erreichen wir jedoch einen wesentlich höheren Durchsatz dank der größeren NVLink-Domänen.

Wir haben eine erste Blackwell-Implementierung erreicht, indem wir bestehende Hopper-Kernel verallgemeinert und die Leistung der NVLink-basierten Kernel gesteigert haben. Wir werden die Kosten für die Bereitstellung von Qwen weiter senken, indem wir die Quantisierung verbessern und die Decode-Leistung sowie den Prefill-Durchsatz der anderen Kernel in der Pipeline weiter optimieren.

Referenzen

Blogbeitrag zur Transfer Engine

Blogbeitrag zu CuTeDSL

Blogbeitrag zu Prefill-Disagg

Blogbeitrag zur spekulativen Dekodierung

CUTLASS

NVLink

Zitierweise

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