Software für RTX PRO Blackwell (SM120): vLLM, SGLang, TensorRT-LLM, NVFP4 im Oktober 2026

Welche Software heute auf SM120 läuft

Die Karten der NVIDIA RTX PRO Blackwell, von der RTX PRO 6000 Blackwell Server Edition, der Max-Q und der Workstation Edition bis zur RTX PRO 5000, 4500, 4000 und 2000, melden alle Compute Capability 12.0, in den Engines SM120 genannt. Stand 24. Oktober 2026 unterstützen vLLM 0.32.0, SGLang 0.5.22 und TensorRT-LLM diese Karten mit nativer FP4- und FP8-Arithmetik; die Lücken liegen bei einigen Attention- und Mixture-of-Experts-Kerneln, bei der FP8-Block-Skalierung in TensorRT-LLM und bei der Kommunikation mehrerer GPUs ohne NVLink. Legen Sie Versionen je Modell fest und prüfen Sie das Start-Log auf Fallback-Warnungen, bevor Sie einen Server abnehmen.

SM120 ist nicht dieselbe Zielarchitektur wie B200 und B300, die Compute Capability 10.0 und 10.3 haben. Ein Kernel für SM100 läuft nicht auf SM120, nur weil beide Blackwell heißen: vLLM nennt seine trtllm-gen-Attention-Kernel nur für 10.x, und Release Notes führen SM100, SM120 und SM12x getrennt auf. DGX Spark mit dem GB10-Chip hat 12.1, eine Zeile zu SM121 oder SM12x schließt ihn also meist ein. Alle Versionen und Daten unten stammen aus Release Notes und Dokumentation, gelesen am 24. Oktober 2026. Die Projekte entwickeln sich schnell: vLLM hat 0.30.0, 0.31.0 und 0.32.0 innerhalb von vier Wochen veröffentlicht.

Versionen und Daten im Oktober 2026

Release Notes von vLLM v0.30.0 (22. September), v0.31.0 (5. Oktober) und v0.32.0 (18. Oktober 2026); Release-Seiten von SGLang v0.5.20 (18. September) und v0.5.22 (19. Oktober); Release-Seiten von TensorRT-LLM v1.2.1 (als „Latest“ markiert) und v1.4.0rc1 sowie seine Quantisierungsseite, Dokumentation 1.4.0rc1, zuletzt aktualisiert am 19. Oktober 2026; README von FlashInfer; CUDA und Treiber wie in unserem Treiber-Leitfaden. Alles gelesen am 24. Oktober 2026.

Die CUDA-Version ist wichtiger als früher. pip install vllm und das Standard-Image von vLLM 0.32.0 sind auf CUDA 13.0 gebaut, das NVIDIA dem Treiberzweig R580 zuordnet; daneben veröffentlicht vLLM Wheels für CUDA 12.9. SGLang ist noch weiter gegangen: Die Release Notes von 0.5.20 schreiben „The CUDA 12 lane is retired“, und 0.5.19 war das letzte Release mit Wheels und Images für CUDA 12. Ein Host auf einem Zweig vor R580 braucht also ein Treiber-Update, bevor er das Standard-Image von vLLM oder ein aktuelles Image von SGLang betreiben kann. Auf Blackwell unterstützt NVIDIA nur die offenen GPU-Kernelmodule. Unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen stellt R580 und R595 gegenüber und erklärt die Kompatibilitätsregeln für Container mit neueren CUDA-Versionen.

NVFP4, MXFP4 und FP8 je Engine

Blackwell-Tensor-Cores rechnen FP4 nativ. Von den Karten, die wir liefern, können das die Karten der RTX PRO Blackwell und DGX Spark; H200 NVL, L40S und L4 rechnen FP8, aber nicht FP4. Native Unterstützung in der Hardware braucht trotzdem für jedes Format und jeden Schichttyp einen Kernel in der Engine, und hier unterscheiden sich die drei Engines.

Release Notes von vLLM v0.30.0 (Pull-Request 55170 und der Eintrag zu Blockwise-FP8 auf SM12x für DGX Spark) und v0.32.0 (46963, 58877), FP8 ab Compute Capability 8.9 laut vLLM-Dokumentation; Quantisierungsleitfaden von SGLang (Seite ohne Datum); Quantisierungsmatrix von TensorRT-LLM, Dokumentation 1.4.0rc1, 19. Oktober 2026; Blogbeitrag von LMSYS zum NVFP4-KV-Cache in SGLang, 16. September 2026. Alles gelesen am 24. Oktober 2026.

vLLM. Die Release Notes von 0.30.0 führen „W4A4 NVFP4 over weight-only kernels on SM120/121“ unter den neuen Standards; NVFP4-Checkpoints rechnen auf diesen Karten also in FP4, statt auf 16 Bit entpackt zu werden. Release 0.32.0 ergänzt „NVFP4 KV cache now runs on SM8x and SM12x“ und „OAI Triton MXFP4 MoE on SM12x“, den Pfad für die MXFP4-Experten von gpt-oss. Es ändert auch einen Standard, der im Log auftaucht: MXFP4-Checkpoints mit W4A4 fallen mit einer Warnung auf W4A16 zurück, wenn kein W4A4-Kernel existiert. Die vLLM-Dokumentation beschreibt dasselbe Muster für NVFP4 auf GPUs ohne nativen FP4-Kernel, einen Weight-only-Fallback über Marlin mit Warnung. Der Checkpoint spart dann weiterhin Speicher, aber das Tempo ist das eines 16-Bit-Kernels.

SGLang. Sein Quantisierungsleitfaden enthält eine Tabelle der NVFP4-GEMM-Backends: auto wählt flashinfer_cutedsl auf SM100, Marlin auf SM80 bis SM90 und flashinfer_cutlass „otherwise (including SM120)“, und ein cuDNN-Backend für SM100 und SM120 braucht CUDA 13 und cuDNN 9.15 oder neuer. NVFP4-GEMM setzt laut Leitfaden ein installiertes FlashInfer voraus. Für FP8 mit Block-Skalierung nennt der Leitfaden ein cutlass-Backend für SM120 und flashinfer_cutlass für SM100 und SM120. Ein Feature-Request auf GitHub hatte Block-FP8 auf SM120 für RTX 5090 und RTX PRO 6000 verlangt; der aktuelle Leitfaden nennt dafür ein Backend. Die Methode nvfp4_online, die beim Laden quantisiert, ist nur für SM100 und SM103 gelistet.

TensorRT-LLM. NVIDIAs Matrix gibt sm120 eine eigene Zeile: NVFP4, MXFP4, FP8 per Tensor und der FP8-KV-Cache werden unterstützt, FP8-Block-Skalierung, FP8 rowwise, der NVFP4-KV-Cache und die Modi W4A8 und W4A16 mit AWQ und GPTQ nicht, während die Zeile sm100/103 die meisten davon hat. Ein FP8-Checkpoint im Stil von DeepSeek mit Block-Skalen von 128 × 128 gehört auf diesen Karten also in SGLang oder vLLM, dessen Notes zu 0.30.0 einen Blockwise-FP8-Kernel auf SM12x für DGX Spark abstimmen, und ein INT4-AWQ-Checkpoint läuft dort in TensorRT-LLM gar nicht. Unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama nennt den Release-Stand von TensorRT-LLM, und unser Leitfaden zu FP8, NVFP4, MXFP4 und INT4 erklärt die Formate.

Attention-Kernel: was vLLM auf 12.x wählt

Die Seite zu den Attention-Backends von vLLM, datiert auf den 24. Oktober 2026, nennt die Compute Capabilities je Backend. FlashAttention 2 ist ab 8.0 gelistet, FlashAttention 3 nur für 9.x. FlashAttention 4 steht ab 10.0, und die Seite sagt nicht, ob das 12.x einschließt. Das native FlashInfer-Backend ist für 8.x bis 9.x gelistet, seine Variante trtllm-gen für 10.x, Triton-Attention für jede GPU. Für die MLA-Attention der DeepSeek-Modelle stehen FlashMLA und FlashMLA sparse für 9.x bis 10.x, und ein eigenes Backend FLASHINFER_MLA_SPARSE_SM120 für 12.x. Die Seite gibt Prioritätslisten für SM 8.x bis 9.x und für SM 10.x an; vLLM wählt daraus das erste kompatible Backend.

SM120 hat außerdem eigene Kernel bekommen. Release 0.30.0 brachte „B12X causal paged attention for SM120/SM121“, ein optionales Backend, das laut Dokumentation mit dem Extra vllm[b12x] installiert und mit --attention-backend b12x ausgewählt wird. Es deckt kausale Decoder-Attention in BF16 mit Head-Größen von 64 bis 256 ab, Decode Context Parallelism nicht. Release 0.31.0 brachte „NoPE sparse MLA on the FlashInfer SM120 backend“, und 0.32.0 nennt „SM120 split-K attention“ sowie den NVFP4-KV-Cache „with XQA decode on SM12x“. Für ein dichtes Modell mit Standard-Attention braucht das keine Einstellung; bei MLA-Modellen und langen Kontexten prüfen Sie im Log, welches Backend vLLM gewählt hat.

Wir liefern Server mit RTX PRO 6000 Server Edition auf Wunsch mit Betriebssystem, NVIDIA-Treiber, CUDA und Container-Runtime; schicken Sie uns Modell, Checkpoint-Format und Engine, und unser Team antwortet mit einer Konfiguration und dem Treiberzweig, auf dem sie läuft.

MoE-Modelle der DeepSeek-Klasse auf SM120: vom Workaround zum Release

Große Mixture-of-Experts-Modelle mit Sparse-MLA-Attention, darunter DeepSeek-V4-Flash, waren 2026 der Bereich, in dem SM120 am längsten hinterherhing. Der Verlauf nach Datum:

Beitrag im vLLM-Forum „SM120 (RTX PRO 6000) NVFP4 MoE Performance Report“ (WSL2, Nightly-Builds, Edition nicht genannt); Engineering-Blog von Helix „Running DS4 on RTX PRO 6000“ (Server Edition, Treiber 595.84); Release Notes von SGLang v0.5.20 (Pull-Request 29927, optionale Umgebungsvariablen, Batch 1); Release Notes von vLLM v0.30.0 (56876) und v0.31.0 (57218). Alles gelesen am 24. Oktober 2026.

Im April berichtete ein Nutzer, dass auf vier RTX PRO 6000 alle 80 TMA-Warp-Specialized-Grouped-GEMM-Taktiken des nativen CUTLASS-NVFP4-MoE-Kernels bei der Initialisierung scheiterten und das beste Ergebnis vom Marlin-W4A16-Fallback bei TP=4 kam, 50,5 Token pro Sekunde für einen Nutzer mit Qwen3.5-397B. Das System lief unter WSL2 mit abgeschaltetem P2P; lesen Sie es als Hinweis auf den damaligen Stand der Kernel, nicht als Geschwindigkeitswert. Im August betrieb Helix DeepSeek-V4-Flash auf acht Karten der Server Edition und nannte den fehlenden FlashMLA-Sparse-Decode-Kernel auf SM120 und Asserts mit NVFP4 auf SM120 beim KV-Cache; für das erste Problem lud es eine von der Community gebaute CUDA-Erweiterung, für das zweite stellte es den KV-Cache auf fp8_ds_mla um, und sein Rezept setzte einen Treiber ab Zweig 590 voraus.

SGLang 0.5.20 verlegte dann den SM120-Sparse-MLA-Indexer auf den Paged-MQA-Kernel von DeepGEMM und schaltete das FP4-MoE-Backend von DeepGEMM frei, als Ersatz für den Torch-Fallback, der laut Notes der einzige funktionierende Pfad war. Die Notes melden eine Decode-Zeit je Ausgabetoken, die auf vier RTX PRO 6000 bei Batch 1 von 36,1 auf 10,5 ms fiel, per Umgebungsvariablen zuschaltbar. vLLM band in 0.30.0 einen DeepGEMM-Fork mit SM120-Paged-MQA ein und hob ihn in 0.31.0 auf einen Stand mit SM120-Fixes. Für ein Modell dieser Klasse gehen Sie vom aktuellen Rezept der Engine aus, nicht von einer Anleitung aus dem Frühjahr.

Mehrere GPUs auf SM120 ohne NVLink

Keine Karte der RTX PRO Blackwell hat NVLink; Tensor-Parallelismus führt seine All-Reduces daher über PCIe aus. Standardmäßig nutzt vLLM seinen eigenen Custom-All-Reduce für zwei reine PCIe-GPUs und überlässt vier oder acht der Bibliothek NCCL: Der Quellcode schaltet den eigenen Kernel ab, wenn die GPUs auf einem Knoten liegen, die World Size, also die Zahl der Prozesse, über zwei liegt und sie nicht voll verbunden sind. Die Release Notes von 0.30.0 nennen „an opt-in FlashInfer PCIe IPC all-reduce for NVLink-less boxes“ (Pull-Request 53576), eingeschaltet mit VLLM_ALLREDUCE_USE_FLASHINFER_PCIE_IPC=1. Der Pull-Request nennt die RTX PRO 6000 und SM120 als Anlass.

Das Backend unterstützt Tensor-Parallel-Größen von 2, 4 und 8, Tensoren in BF16 und FP16 und einen Knoten, und es fällt mit einer Warnung zurück, wenn dem installierten FlashInfer die Klasse PcieIpcAllReduceWorkspace fehlt. vLLM 0.31.0 führt FlashInfer 0.7.0.post1 unter seinen Abhängigkeiten, und die Klasse steht in der Dokumentation von FlashInfer 0.7.2.post1; eine Angabe, mit welchem FlashInfer-Release sie zuerst kam, haben wir nicht gefunden, prüfen Sie also nach dem Einschalten das Log. Die veröffentlichten Gewinne sind klein und auf TP=2 beschränkt, wie unser Leitfaden zur RTX PRO 6000 ohne NVLink zeigt. P2P zwischen den Karten und die IOMMU- und ACS-Einstellungen, die es stören, behandelt unser Leitfaden zu P2P mit der RTX PRO 6000 unter Linux.

Ein Software-Stand für den Produktionsserver

Für einen Server mit Karten der RTX PRO 6000 Server Edition, der über Monate ein oder wenige Modelle betreibt, folgen aus den Release Notes oben diese Entscheidungen.

1. Treiber. R580, der Zweig mit Langzeitsupport, oder R595, der Produktionszweig. Beide nennen jede Edition der RTX PRO 6000, und beide liegen über 575.51.03, der Untergrenze, die NVIDIAs MIG-Leitfaden für MIG auf der RTX PRO 6000 setzt. Bleiben Sie auf oder über den behobenen Versionen aus NVIDIAs Sicherheitsbulletin vom 30. September 2026, 580.178.04 oder 595.91.07.
2. Engine-Release. vLLM 0.31.0 oder neuer im gemeinsam genutzten Netz, weil 0.31.0 eine als „High“ eingestufte Lücke zur entfernten Codeausführung geschlossen hat, die Server mit --trust-remote-code betrifft (GitHub-Advisory GHSA-h3rc-6mm3-gc2m vom 6. Oktober 2026); 0.32.0 für den NVFP4-KV-Cache und den MXFP4-MoE-Pfad auf SM12x. SGLang 0.5.20 oder neuer für Sparse-MLA-Modelle der DeepSeek-Klasse.
3. Checkpoint-Format. NVFP4 und FP8 per Tensor laufen in allen drei Engines nativ. FP8 mit Block-Skalen läuft laut Leitfaden in SGLang und hat in vLLM einen SM12x-Kernel; TensorRT-LLM nennt für sm120 keine Block-Skalierung. INT4 AWQ oder GPTQ läuft in vLLM und SGLang über Marlin, in TensorRT-LLM auf diesen Karten nicht.
4. Start-Log. Durchsuchen Sie es nach fallback, Marlin, W4A16 und weight-only, nach dem Attention-Backend, das vLLM gewählt hat, und mit dem optionalen All-Reduce nach dessen Fallback-Warnung.
5. Genauigkeit. Ein NVFP4-KV-Cache braucht etwa 56 Prozent des Speichers eines FP8-Caches, 4,5 gegenüber 8 Bit je Wert nach unserer Rechnung aus dem Format. LMSYS hat am 16. September 2026 Genauigkeitswerte für SGLang veröffentlicht, die Leistungsmessungen liefen auf der RTX PRO 6000 Blackwell Server Edition: Bei Qwen3.8-27B lag ein NVFP4-Cache auf GSM8K 0,31 Prozentpunkte und auf GPQA-Diamond 1,01 Prozentpunkte unter einem FP8-Cache und löste 76,20 gegenüber 77,80 Prozent von SWE-bench Verified. Der Beitrag nennt die Unterstützung in SGLang experimentell und umfasst zwei Modelle; vergleichen Sie die Antworten also zuerst auf Ihrem eigenen Evaluationsdatensatz mit einem FP8-Cache. Unsere Seite zum NVFP4-KV-Cache auf der RTX PRO 6000 Server Edition nennt die Werte und die Flags.
6. Reproduzierbarkeit. Legen Sie das Engine-Image per Digest fest, mit den FlashInfer- und DeepGEMM-Versionen darin, und wiederholen Sie den Lasttest nach jeder Änderung.

Unser Engineering-Partner Vixen.UNO betreibt offene Modelle mit vLLM auf diesen Servern im Rahmen unseres Service Private AI/ML; nennen Sie uns die Modelle und das Format, in dem Sie sie betreiben wollen, und wir prüfen sie vor der Bestellung gegen die Release Notes.

Was sich bei der H200 NVL ändert

Die H200 NVL hat Compute Capability 9.0, Hopper, und liegt bei den meisten dieser Punkte auf der anderen Seite. vLLM nennt FlashAttention 3 und FlashMLA für 9.x, und die Matrix von TensorRT-LLM nennt FP8-Block-Skalierung und INT4 AWQ für Hopper. FP4-Tensor-Cores gibt es nicht: NVFP4- und MXFP4-Checkpoints laden über Weight-only-Kernel und rechnen in 16 Bit, wie unser Leitfaden zu FP4-Modellen auf der H200 NVL erklärt. Für ein FP8-Modell, das auf Hopper-Kernel angewiesen ist, ist die H200 NVL mit NVLink-Brücken die vorsichtige Wahl; für NVFP4-Checkpoints und 96 GB je Karte mit nativem FP4 die RTX PRO 6000 Server Edition, mit den Prüfungen oben. Unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz wägt die beiden Karten ab, und unsere Seite zum Kauf eines GPU-Servers für LLMs listet die Konfigurationen, die wir bauen.

FAQ