Zum Inhalt springen
Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.

MLPerf 2026: Wenn die Software 2,7x wert ist — was misst der Benchmark dann überhaupt?

Zerlegung der MLPerf-Inference-v6.0/v6.1-Ergebnisse in Silizium und Software-Stack: der 2,7x-Sprung auf identischer GB300-Hardware, AMDs 512-GPU-Rekord gegen die Pro-GPU-Realität, die Vera-Rubin-Preview-Regeln — und so liest man eine Ergebnistabelle wie ein Ingenieur.

9 Min. Lesezeitflozi00
mlperfbenchmarknvidiaamdinferencegb300mi355xvera rubinmethodik

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):

tok/s pro GPU=GesamtdurchsatzBeschleuniger,5,749,440512≈11,230  vs.  1,200,00072≈16,670\text{tok/s pro GPU} = \frac{\text{Gesamtdurchsatz}}{\text{Beschleuniger}}, \quad \frac{5{,}749{,}440}{512} \approx 11{,}230 \; \text{vs.} \; \frac{1{,}200{,}000}{72} \approx 16{,}670

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:

SkalierungGPT-OSS-120B-Offline-FührenderAbstand
8 GPUsGB300GB300 ca. 9 % vor dem besten MI355X-System (132.236 vs 121.818 tok/s Offline)7
72 GPUsGB300 (1,20M) vs MI355X (1,04M)~15 % aggregiert, ~48 % pro GPU gegen den 512-GPU-Cluster5
512 GPUsAMD 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:

  1. Pro Beschleuniger normalisieren, bevor irgendetwas verglichen wird (die Tabelle oben brauchte diesen einen Divisionsschritt, um die v6.1-Schlagzeilen umzudrehen).
  2. Skalierung angleichen. 8-GPU-Zeilen mit 8-GPU-Zeilen vergleichen, 72 mit 72. Aggregate sind per Konstruktion marketinggeformt.
  3. Runde und Kategorie angleichen. Nur Zeilen derselben Ergebnisrunde, Kategorie (Available vs Preview) und Division. Rundenübergreifende Vergleiche beantworten eine andere Frage — siehe unten.
  4. 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

Quellen

Autor: flozi00 | Veröffentlicht: 24. September 2026

Footnotes

  1. MLCommons, „MLPerf Inference: Datacenter" — Divisions, Verfügbarkeitskategorien, Ergebnistabellen: https://mlcommons.org/en/inference-datacenter ↩ ↩2 ↩3

  2. 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

  3. 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 ↩

  4. 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

  5. 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

  6. 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

  7. 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 ↩

  8. MLCommons, „Supplemental — MLPerf Inference v6.1", September 2026: https://mlcommons.org/wp-content/uploads/2026/09/Supplemental-MLCommons-MLPerf-Inference-v6.1.pdf ↩ ↩2

  9. MLCommons, „MLPerf Inference Rules" (inference_policies/inference_rules.adoc): https://github.com/mlcommons/inference_policies/blob/master/inference_rules.adoc ↩ ↩2 ↩3 ↩4

  10. 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/ ↩

  11. Lambda (Submitter), „MLPerf Inference v6.1: pioneering agent, VLM benchmarks", 16. September 2026: https://lambda.ai/blog/mlperf-inference-v6.1 ↩

  12. 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 ↩