Am 1. April 2026 veröffentlichte MLCommons die MLPerf-Inference-v6.0-Ergebnisse1. Zwischen den üblichen Rekordmeldungen stand eine Zahl, die die Lektüre dieses Benchmarks verändern sollte: Derselbe GB300-NVL72-Rack, den NVIDIA ein halbes Jahr zuvor eingereicht hatte — identische Beschleuniger, identischer Speicher, identisches Strombudget — lieferte 2,77x höheren DeepSeek-R1-Server-Durchsatz, von 2.907 auf 8.064 Tokens pro Sekunde und GPU zwischen v5.1 und v6.02. Kein Silizium hat sich geändert. Der gesamte Gewinn kam aus dem Software-Stack.
Dieser eine Datenpunkt ist das sauberste natürlich entstandene Experiment, das die Inference-Branche bisher hervorgebracht hat: Er beziffert, was allein Software-Reifung auf fester Hardware wert ist. Und er erzwingt die Frage, die dieser Artikel beantwortet: Wenn ein Benchmark-Ergebnis Silizium, Interconnect und einen optimierten Software-Stack zu einer Zahl bündelt — was wird da eigentlich gemessen, und wie liest man es, ohne sich vereinnahmen zu lassen? |
1. Der Anker: 2,7x auf unveränderter Hardware
Das v6.0-Ergebnis präzise rekapituliert, denn jedes Wort zählt: In der Closed Division stieg der DeepSeek-R1-Server-Score pro GPU des GB300 NVL72 von 2.907 tok/s (v5.1-Debüt) auf 8.064 tok/s (v6.0) — Faktor 2,77x2. NVIDIA rechnet daraus über 60 % geringere Token-Kosten bei gleichem Rack und Stromverbrauch. Im DeepSeek-R1-Offline-Szenario liegt der Faktor bei 1,68x, beim älteren dichten Llama 3.1 405B nur bei 1,52x — die Gewinne sind szenario- und modellabhängig, was für sich genommen aufschlussreich ist: Mixture-of-Experts-Reasoning-Modelle haben am meisten Spielraum für Serving-Tricks.
Die genannten Techniken sind nicht exotisch: disaggregiertes Prefill/Decode-Serving über NVIDIA Dynamo, Multi-Token-Prediction (bis zu drei Tokens pro Forward-Pass), breiteres Expert-Parallel für MoE-Schichten, Kernel-Fusion und KV-bewusstes Routing2. Einige der stärksten Zahlen lieferte der Partner Nebius auf derselben Hardware — selbst schon ein Beleg dafür, dass ein reifes Ökosystem, nicht nur ein Hersteller-Kernel-Team, diese Kurven bewegt.
Die Konsequenz für Benchmark-Kompetenz ist knapp formuliert: Ein „Hardware-Benchmark"-Ergebnis ist ein Produkt aus (Silizium × Stack-Generation), und 2025–2026 hat der Stack-Term das Produkt stärker bewegt als es ein kompletter GPU-Generationssprung typischerweise tut. Wer ein NVIDIA-Ergebnis aus Runde N mit einem AMD-Ergebnis aus Runde N-1 vergleicht, sieht im Wesentlichen den Kalender, nicht die Architektur. |
2. v6.1: Eine Ergebnistabelle, zwei Marketing-Geschichten
Die Runde v6.1 (veröffentlicht am 16. September 2026; 30 Organisationen, 486 Datacenter- und Edge-Ergebnisse) machte die Skalierungsfrage unumgänglich3. AMD und der Partner Crusoe reichten das größte System der MLPerf-Inference-Geschichte ein — 512 Instinct MI355X GPUs über 64 Nodes — und es führt die Aggregat-Durchsatztabellen an45:
- GPT-OSS-120B, Offline: rund 5,75 Millionen tok/s (5,39M Server)
- DeepSeek-R1, Offline: rund 2,90 Millionen tok/s (2,41M Server)
- Crusoe meldet lineare Skalierung von 8 bis 512 GPUs mit über 90 % des Idealfalls4
NVIDIAs Geschichte in derselben Runde ist pro GPU und pro Segment: GB300 NVL72 führt GPT-OSS-120B sowohl bei 72 GPUs (ca. 1,20M tok/s Offline) als auch bei 8 GPUs, und CoreWeaves GB300-Submission erzielte den höchsten Pro-GPU-Durchsatz im Datacenter-Closed-Bereich auf GPT-OSS-120B aller Silizium — 16.635 tok/s pro GPU offline6.
Beide Geschichten sind gleichzeitig wahr. Normalisiert (Durchsatz ÷ Beschleunigerzahl):
Das ist ein Pro-GPU-Vorsprung von rund 48 % für GB300 bei GPT-OSS-120B Offline (16.670 vs 11.230 tok/s/GPU). Bei DeepSeek-R1 Offline ist der Abstand größer: 9.441 vs 5.668 tok/s/GPU (1,67x). Urteil nach Skalierung, alle v6.1 Closed Division:
| Skalierung | GPT-OSS-120B-Offline-Führender | Abstand |
|---|---|---|
| 8 GPUs | GB300 | GB300 ca. 9 % vor dem besten MI355X-System (132.236 vs 121.818 tok/s Offline)7 |
| 72 GPUs | GB300 (1,20M) vs MI355X (1,04M) | ~15 % aggregiert, ~48 % pro GPU gegen den 512-GPU-Cluster5 |
| 512 GPUs | AMD MI355X (5,75M) | keine GB300-Submission in dieser Größe4 |
Die ehrliche Aussage lautet: AMD gewinnt die größte existierende Cluster-Zeile; NVIDIA gewinnt jede kleinere Zeile und liegt in dieser Runde bei GPT-OSS-120B und DeepSeek-R1 pro GPU vorn. Keine der beiden Schlagzeilen lügt; jede ist ein Rahmen. AMDs Rahmen (Aggregat-Rekorde) schmeichelt dem, der 512 GPUs nebst Interconnect besitzt oder kaufen will. NVIDIAs Rahmen (Pro-GPU- und Segment-Führung) schmeichelt dem dichten Token-Kosten-Käufer. Aggregat-Zahlen sind über Clustergrößen hinweg nicht vergleichbar, weil nahezu lineare Skalierung (AMD meldet 95 % Effizienz von 8 auf 72 GPUs; NVIDIAs 288-GPU-GB300-Submission meldet 99 %58) bedeutet, dass ungefähr jeder Hersteller „gewinnt“, der sein Cluster einfach groß genug macht — eine Lineare-Skalierungs-Illusion, kein Silizium-Urteil. Was Clusterwachstum tatsächlich begrenzt, ist das Fabric — dafür gibt es bei uns die Detailanalyse in Scale-Up vs Scale-Out: Die Netzwerk-Mathematik hinter LLM-Clustern: Bisektions-Bandbreite, Oversubscription und Scale-out-Linkbudgets entscheiden, ob die 512. GPU Durchsatz oder Stau bringt.
Der Symmetrie halber der Skalierungsrekord der v6.0-Runde selbst: NVIDIAs größtes v6.0-System waren 4× GB300-NVL72-Racks (288 GPUs) über Quantum-X800 InfiniBand — damals die größte je eingereichte Submission mit 2.494.310 tok/s DeepSeek-R1 Offline2. Den Rekord übernahm eine Runde später ein Cluster mit der 1,8-fachen GPU-Anzahl. Rekorde bei Maximal-Skalierung messen vor allem, wer in der Saison die meisten GPUs verkabelt hat. |
3. Vera Rubins Preview: Fast 2x — unter anderem Etikett
v6.1 brachte außerdem NVIDIAs Vera-Rubin-NVL72-Debüt — in der Preview-Kategorie, nicht in der Available-Kategorie. Nach den MLCommons-Regeln werden Ergebnisse in Verfügbarkeitskategorien eingeteilt: Available (alle Komponenten heute kauf- oder mietbar), Preview (System muss bis zur nächsten Runde Available werden) und RDI (Forschungs-/Interneinsatz)19. Preview-Einträge sind verifizierte Ergebnisse, aber die Plattform ist pre-production, der Software-Stack dafür ist seine Version 1.0, und Audits zielen in jeder Runde auf Available-Submissionen der Closed Division9.
Die verifizierten Preview-Zahlen, auf beiden Seiten gleiche 72-GPU-Systemgröße8: Vera Rubin NVL72 liefert 1.175.890 vs 596.944 tok/s bei DeepSeek-R1 Server — etwa 1,97x pro GPU, offline nur ~1,74x (1.183.327 vs 679.740 tok/s). NVIDIAs Schlagzeile ist „bis zu 2,5x" bei DeepSeek-R1 (der Best-Case im Interactive-Szenario) und „bis zu 3,7x" bei Qwen3-VL — ein Verhältnis aus einem einzigen Interactive-Vergleich (1.306,6 vs 349,3 queries/s), jeweils nach der Herstellerlesart der MLCommons-Tabellen10.
Zwei Kategorienfehler gilt es zurückzuweisen. Erstens: einen Preview-Vera-Rubin-Delta (Früh-Silizium, Erstgenerierungs-Stack) gegen geprüfte Available-GB300-Zahlen zu stellen und das Verhältnis als stabilen Generationssprung zu lesen. Rubins Software ist heute dort, wo Blackwells Stack vor zwei Jahren war — am Anfang seiner Optimierungskurve. Zweitens: „3,7x" als allgemeinen Vera-Rubin-Speedup zu zitieren, wenn knapp 2x pro GPU auf einem Frontier-Reasoning-Modell die ehrliche Zahl ist und der größere Quotient zu einem Vision-Language-Modell in genau einem latenzbeschränkten Szenario gehört. Rubin mit ~2x pro GPU ist ein starker Generationsschritt — nur eben kein 3,7x, und das Preview-Etikett bedeutet, dass noch nichts davon ein lieferbares Produkt ist. |
4. Methodik: Eine Ergebnistabelle in drei Minuten lesen
Was eine Submission laut MLCommons-Regeln tatsächlich ist91:
- Divisions. Closed fixiert Modell, Pre- und Postprocessing sowie Genauigkeitsziele — der Apfel-mit-Apfel-Hardwarevergleich. Open erlaubt Modellersatz und Retraining und misst stattdessen entfesselte Kreativität.
- Szenarien. Datacenter-Submissionen laufen als Offline (reiner Batch-Durchsatz ohne Latenzbedingung), Server (Durchsatz unter Latenz-SLA) und Interactive (schärfere Token-Raten- und Time-to-First-Token-Anforderungen). Wer ein Szenario anführt, kann im anderen zurückliegen — die 2,7x aus v6.0 galten spezifisch für Server.
- Fixiert: Modellgewichte, Datensatz, Qualitätsziel, Load-Generator und Regeln. Frei: der gesamte Serving-Stack — Framework, Parallelitätsschema, Quantisierung (Kalibrierung erlaubt, Retraining nicht), Batch-Politik und die Clustergröße.
Ein skeptischer Drei-Minuten-Blick über jede Ergebnistabelle:
- Pro Beschleuniger normalisieren, bevor irgendetwas verglichen wird (die Tabelle oben brauchte diesen einen Divisionsschritt, um die v6.1-Schlagzeilen umzudrehen).
- Skalierung angleichen. 8-GPU-Zeilen mit 8-GPU-Zeilen vergleichen, 72 mit 72. Aggregate sind per Konstruktion marketinggeformt.
- Runde und Kategorie angleichen. Nur Zeilen derselben Ergebnisrunde, Kategorie (Available vs Preview) und Division. Rundenübergreifende Vergleiche beantworten eine andere Frage — siehe unten.
- Szenario und Softwarespalte prüfen. Die Tabelle nennt das eingesetzte Framework; „Führender" im Offline-Batchdurchsatz sagt nichts über das latenzkritische Produkt aus, und vLLM/TensorRT-LLM-Unterschiede sind Teil des gemessenen Systems (wie viel allein die Serving-Schicht bewegt, zeigt unser vLLM-vs-SGLang-Vergleich). |
5. Rundenübergreifende Deltas: Das Signal, das niemand etikettiert
Wenn ein rundenübergreifender Vergleich auf fester Hardware genau eine Variable isoliert — den Stack —, dann sind Round-over-Round-Deltas ein Benchmark, der im Verborgenen liegt. Das Fenster v6.0→v6.1 (rund fünf Monate) brachte, alles auf unverändertem Silizium und von den Submittern selbst gemeldet:
- Lambda: +8,85 % Server- und +8,79 % Offline-GPT-OSS-Durchsatz auf identischer Hardware — eine Zahl aus Lambdas eigenem Blog, keine MLCommons-Statistik11
- AMD (ROCm): +28 % Offline / +38 % Server bei 8× MI355X-GPT-OSS-120B in einem Zyklus; 72 v6.1-GPUs liefern mehr Durchsatz als 94 v6.0-GPUs5
- Intel: +36 % Server / +27 % Offline auf denselben vier Arc Pro B70, der Software-Reifung zugeschrieben12
- CoreWeave: ~19,8 % Pro-GPU-Zugewinn bei DeepSeek-R1 über GB200-NVL72-Submissionen hinweg6
Über Hersteller und Silizien hinweg haben diese 9–38-%-Deltas aus fünf Monaten dieselbe Gestalt wie NVIDIAs 170 % aus sechs Monaten — nur bei anderer Stack-Reife. Round-over-Round auf fester Hardware misst Stack-Reife — eine wirklich nützliche Zahl für Käufer (sie prognostiziert, wie viel Gratis-Performance die eigene Flotte vor dem nächsten Hardware-Refresh bekommt). Zur Fehlinformation wird sie erst, wenn der Zugewinn in einem Atemzug als Hardware-Eigenschaft berichtet wird, während die Baseline-Hardware im nächsten Atemzug mit den Zahlen der Vorrunderung verkauft wird. |
6. Der ehrliche Etikettenschwindel — und die Heuristik für Käufer
Zur Legitimität, um nichts misszuverstehen: Auf einen Benchmark zu optimieren ist in der Closed Division ganz normales Engineering. Disaggregiertes Serving, Kernel-Fusion, Expert-Parallel — das sind dieselben Techniken, die realen Verkehr beschleunigen; ein 2,7x auf MLPerfs festem Datensatz ist kein Betrug, sondern der Stack, der bei genau der Arbeit besser wird, die Käufer betreiben. Die Closed Division existiert genau dafür: dass Hersteller auf festen Modellen um Stack-Qualität konkurrieren; dass dieser Wettbewerb jedermanns Token-Kosten senkt, ist das System wie ausgestaltet9.
Der Täuschungsanteil ist rein semantisch: aus (Silizium × Stack-Generation)-Produkten Siliziumvergleiche machen. „GB300 schlägt MI355X um 48 %" und „MI355X liefert den höchsten je gemessenen Durchsatz" sind beides reale v6.1-Fakten, die einander gegenseitig verbergen. Das Gegenmittel ist Lesedisziplin, nicht Misstrauen gegen den Benchmark:
- Gleiche Skalierung, gleiche Runde, gleiche Kategorie, gleiche Division vergleichen — nur dort kürzen sich Stack-Generation und Clustergröße heraus.
- Schlagzeilen-Vielfache misstrauen, die sich nicht auf Systemebene nachrechnen lassen. Übersteht ein Quotient aus einer Pressemitteilung die Division beider Seiten durch die Beschleunigerzahl samt Szenario- und Modell-Check, ist er Daten; sonst ist er ein Rahmen.
- Preview-Deltas als Richtungsangabe lesen, nicht als Vergleich — Früh-Silizium plus Erstgenerierungs-Stack bleiben nicht stehen.
- Rundenübergreifende Deltas auf fester Hardware gezielt nutzen als das Stack-Reife-Signal, das sie sind — und den Refresh-Zyklus entsprechend kalkulieren: Die heute gekaufte Hardware hat historisch 9 % bis 170 % messbaren Durchsatzgewinn innerhalb eines halben Jahres gelegt, ohne dass ein Rack angefasst wird.
Die unbequeme Zwischenbilanz von MLPerf 2026 für Hardware-Leute: Die beeindruckendsten Zahlen des Jahres — 2,7x auf Blackwell, +38 % auf Instinct in fünf Monaten — stammten aus Compilern, Schedulern und Serving-Frameworks, auf Hardware, die alle schon besaßen. Silizium bleibt der Rahmen des Möglichen. Der Benchmark misst zunehmend, wie nah der eigene Software-Stack diesem Rahmen gekommen ist. Wer jede Submission als Software-Ergebnis auf Hardware liest, für den hört die Tabelle auf, eine Anzeigetafel zu sein — und wird das, was sie tatsächlich ist: ein Quartalsbericht zur Stack-Reife, pro Hersteller, pro Skalierung. |
Verwandte Artikel
- Scale-Up vs Scale-Out: Die Netzwerk-Mathematik hinter LLM-Clustern — warum Cluster-Durchsatzrekorde Fabric-Fragen (Bisektionsbandbreite, Oversubscription) sind, keine GPU-Fragen.
- NVIDIA B200 vs GB200: Effizienz-Benchmark — dieselbe Skalierungs-Verzerrungsfalle in den MLPerf-Training-v5.0-Daten.
- vLLM vs SGLang — zwei der Serving-Stacks hinter diesen Zahlen, im direkten Vergleich.
Quellen
Autor: flozi00 | Veröffentlicht: 24. September 2026
Footnotes
-
MLCommons, „MLPerf Inference: Datacenter" — Divisions, Verfügbarkeitskategorien, Ergebnistabellen: https://mlcommons.org/en/inference-datacenter ↩ ↩2 ↩3
-
NVIDIA Technical Blog (Hersteller), „NVIDIA Platform Delivers Lowest Token Cost Enabled by Extreme Co-Design", MLPerf Inference v6.0, April 2026: https://developer.nvidia.com/blog/nvidia-extreme-co-design-delivers-new-mlperf-inference-records ↩ ↩2 ↩3 ↩4
-
MLCommons chairs' blog, MLPerf Inference v6.1: Rekorde und die ersten Preview-Submissionen über 30 Organisationen und 486 Ergebnisse. https://mlcommons.org/2026/09/chairs-mlperf-inference-v6-1 ↩
-
Crusoe (Submitter), „Serving 5.75 million tokens per second: Crusoe's MLPerf Inference v6.1 results on AMD MI355X", September 2026: https://crusoe.ai/resources/blog/serving-5-75-million-tokens-per-second-crusoes-mlperf-inference-v6-1-results-on-amd-mi355x ↩ ↩2 ↩3
-
AMD Blog (Hersteller), „AMD Delivers Its Broadest MLPerf Inference 6.1 Submission", 16. September 2026: https://www.amd.com/en/blogs/2026/amd-delivers-its-broadest-mlperf-inference-6-1-submission.html ↩ ↩2 ↩3 ↩4
-
CoreWeave (Submitter), „MLPerf Inference v6.1 Results", September 2026: https://www.coreweave.com/blog/coreweave-leads-cloud-providers-in-mlperf-r-inference-v6-1-performance-with-nvidia-blackwell-ultra ↩ ↩2
-
WindowsForum-News-Zusammenfassung der veröffentlichten MLCommons-v6.1-Tabellen, GPT-OSS-120B nach Skalierung: https://windowsforum.com/news/nvidia-vera-rubin-is-preview-not-a-gb300-replacement.444700 ↩
-
MLCommons, „Supplemental — MLPerf Inference v6.1", September 2026: https://mlcommons.org/wp-content/uploads/2026/09/Supplemental-MLCommons-MLPerf-Inference-v6.1.pdf ↩ ↩2
-
MLCommons, „MLPerf Inference Rules" (inference_policies/inference_rules.adoc): https://github.com/mlcommons/inference_policies/blob/master/inference_rules.adoc ↩ ↩2 ↩3 ↩4
-
NVIDIA Blog (Hersteller), „NVIDIA Vera Rubin NVL72 Delivers Leading Performance in MLPerf Inference v6.1 Debut", 16. September 2026: https://blogs.nvidia.com/blog/vera-rubin-nvl72-mlperf-inference/ ↩
-
Lambda (Submitter), „MLPerf Inference v6.1: pioneering agent, VLM benchmarks", 16. September 2026: https://lambda.ai/blog/mlperf-inference-v6.1 ↩
-
Intel Newsroom (Hersteller), „Intel Software Optimizations Boost AI Inference in MLPerf v6.1", September 2026: https://www.intel.com/content/www/us/en/newsroom/news/data-center/intel-software-optimizations-boost-ai-inference-in-mlperf-v6-1.html ↩