Ein Score gehört zu einem eingereichten System
Prüfe Workload-Regeln, Software, Größe und Verfügbarkeit, bevor du eine Änderung des MLPerf-Durchsatzes zuordnest.
KI-gestützte Lernvisualisierung · schematische Erklärung zum Artikel
Öffne den Einreichungsdatensatz und gleiche Modell, Szenario und Qualitätsanforderungen ab. Ein Server-Ergebnis mit Latenzvorgaben beantwortet eine andere Frage als maximaler Offline-Durchsatz.
MLPerf Inference misst eingereichte Gesamtsysteme einschließlich Beschleunigern, Netzwerk und Software. Die Ergebnisse erlauben Vergleiche von Installationen unter den Benchmarkregeln. Der Beitrag des Chips lässt sich daraus allein nicht vom Serving-Stack trennen. Zu jeder Aussage anhand der Rangliste gehören die Ergebnisse und Regeln von MLCommons.
Deutlicher Zuwachs bei derselben Beschleunigerfamilie
Laut NVIDIAs Auswertung von MLPerf Inference v6.0 stieg der Server-Durchsatz für DeepSeek-R1 auf GB300 NVL72 zwischen den v5.1- und v6.0-Einreichungen von 2.907 auf 8.064 Token/s je GPU. Der Quotient beträgt etwa 2,77. Dieselbe Herstellertabelle nennt 1,68× für DeepSeek-R1 Offline und 1,52× für Llama 3.1 405B Server. Die GPU-Werte wurden aus Ergebnissen vollständiger Systeme errechnet; NVIDIA weist ausdrücklich darauf hin, dass der Durchsatz je Chip keine primäre MLPerf-Metrik ist.
Der Vergleich zeigt deutlich, dass ein Benchmarkwert keine dauerhafte Eigenschaft eines GPU-Modells ist. NVIDIA schreibt den Fortschritt in v6.0 seiner Serving-Software zu, unter anderem Kernelverbesserungen und optimierter Attention-Datenparallelität. Es handelt sich jedoch nicht um eine kontrollierte Software-Ablationsstudie: Die Einreichungen stammen aus verschiedenen Runden, und im öffentlichen Vergleich sind nicht alle Konfigurationsvariablen konstant. Der Anteil einzelner Änderungen lässt sich aus den beiden Werten nicht bestimmen. NVIDIAs Aussage zu niedrigeren Kosten je Token hängt zudem von Annahmen zu Infrastruktur und Strombedarf ab; das Durchsatzverhältnis misst weder Energie noch Kosten.
Die Clustergröße beeinflusst die Schlagzeile
Der v6.1-Bericht von MLCommons nennt eine Einreichung mit 512 Beschleunigern (IDs 6.1-0026 und 6.1-0027) und für eine davon knapp 5,8 Millionen Token/s bei GPT-OSS-120B Offline. Das ist der Durchsatz eines Gesamtsystems. Daraus ergibt sich keine Rangfolge einzelner Beschleuniger gegenüber kleineren Systemen anderer Anbieter.
Gesamtdurchsatz geteilt durch Beschleunigeranzahl ist eine nützliche beschreibende Kennzahl. Unterschiede bei Aufgabe, Szenario, Latenzgrenze, Quantisierung, Interconnect und Größe verschwinden dadurch aber nicht. Selbst der Durchsatz je GPU kann wegen anderer Batchgrößen und Kommunikationskosten abweichen. Für einen Systemvergleich müssen zunächst Modell, Szenario, Qualitätsziel, Benchmarkrunde, Verfügbarkeitskategorie und ungefähr die Beschleunigeranzahl übereinstimmen. Danach sind die Systembeschreibung und Latenzvorgaben zu prüfen. Der Quotient je Beschleuniger ist eine zusätzliche Rechnung, kein isolierter Hardwarebenchmark.
Preview ist eine eigene Kategorie
Laut MLCommons zum v6.1-Ergebnis stammen manche Spitzenwerte von einem Vera-Rubin-System der Kategorie Preview. Das v6.1-Zusatzdokument beschreibt eine Preview-Einreichung von Nebius mit 36 Rubin-GPUs sowie verfügbare GB300-Systeme in verschiedenen Größen. Kategorie und Konfiguration müssen beim Zitieren eines Preview-Werts erhalten bleiben. Von Anbietern genannte Beschleunigungen „bis zu“ einem Faktor in einzelnen Szenarien sind kein universeller Rubin-zu-GB300-Faktor.
Checkliste zum Lesen der Ergebnisse
- Im Ergebnis-Dashboard von MLCommons die Einreichungsnummern ermitteln.
- Benchmarkversion, Closed/Open Division, Modell, Szenario, Genauigkeitsziel und Verfügbarkeitskategorie abgleichen.
- Gesamtdurchsatz, Beschleunigeranzahl, Systemtopologie und Latenzgrenzen notieren. Möglichst ähnlich große Systeme vergleichen.
- Für Leistung pro Watt oder Kosten je Token gemessene Systemleistung und tatsächliche Betriebskosten verwenden. Der Durchsatz allein reicht dafür nicht.
- Wer einen Leistungszuwachs der Software zuschreibt, braucht einen kontrollierten Vergleich oder eine Ablationsstudie. Ergebnisse aus verschiedenen Runden zeigen die gesamte Änderung des eingereichten Systems.
Die Runden von 2026 zeigen, dass sowohl Softwareänderungen als auch die Größe der Installation einen Wert stark verschieben können. Für eine Beschaffungsentscheidung ist ein Ergebnis erst dann hilfreich, wenn die vollständige Konfiguration der geplanten Aufgabe hinreichend ähnelt.