Vera Rubin NVL72: 3,7× Throughput vs. GB300 – und 99 % Scaling über 288 GPUs

Vera Rubin NVL72 debutiert in MLPerf Inference v6.1 mit bis zu 3,7× Throughput gegen GB300 NVL72 — und vier GB300-Racks skalieren mit 99 % Effizienz. Rechnen wir nach, ab welchem Gap zur Production-SLO Capex-Vergleiche kein Blindvertrauen in den Preview-Eintrag verdienen.

Rechnen wir nach: Bis 3,7× höherer Throughput als GB300 NVL72 auf Qwen3-VL — Offline, Server und Interactive, mit vLLM plus NVIDIA Dynamo. Bis 2,5× auf DeepSeek-R1 mit TensorRT-LLM. So steht es im NVIDIA-Blog vom 16. September 2026 zur ersten Preview-Submission von Vera Rubin NVL72 in MLPerf Inference v6.1. Parallel: 288 GPUs über vier GB300-NVL72-Racks, 99 % Scaling Efficiency — Throughput wächst fast linear vom Single-Rack.

Unter dem Strich sind das greifbare Submission-Zahlen. Der Haken: Preview-Submission ist kein Production-SLO. Wer Capex-Vergleiche allein dem ersten MLPerf-Eintrag überlässt, verwechselt Lab-/Closed-Division-Throughput mit dem, was Latenzbudgets, Multi-Tenancy und Mischlast in der Produktion verlangen.

Die These ist nüchtern. 3,7× und 99 % Scaling lohnen als Entscheidungsinput. Sie lohnen nicht als Einkaufsfreibrief. Wir bei digital-magazin.de rechnen den Gap vor, bevor jemand den Preview-Score für die Bilanz hält.

Was MLPerf Inference v6.1 hier konkret misst

MLPerf Inference ist ein Industriestandard der MLCommons Association. NVIDIA zitiert Closed-Division-Ergebnisse, abgerufen am 16. September 2026 von mlcommons.org, unter anderem Einträge 6.1-0106, 6.1-0074 und 6.1-0073. Die Benchmark-Namen und Logos sind Marken von MLCommons — das gehört zur Quellenhygiene.

Drei Hebel bestimmt laut Blog die Inference-Ökonomie: Systemleistung (mehr Tokens, potenziell mehr Umsatz), Scaling-Effizienz (Throughput wächst proportional zur Hardware) und Software-Velocity (mehr Nutzen aus bestehendem Capex). Dazu Platform-Fungibilität: dieselbe Infrastruktur für Training und Inference, Language und Video. Das ist Vendor-Rahmen. Die Zahlen darunter sind die Submission-Claims.

Vera Rubin NVL72 wurde auf zwei der anspruchsvollsten Benchmarks der Suite eingereicht: DeepSeek-R1 und Qwen3-VL. Nebius reichte ebenfalls Vera-Rubin-Preview-Ergebnisse ein. 19 Partner beteiligten sich am Ecosystem, acht davon auf Multi-Node-Blackwell-NVL72-Systemen — Kontext, kein eigener Partner-Pitch.

3,7× und 2,5×: die Throughput-Rechnung

Qwen3-VL: bis 3,7× Throughput gegen GB300 NVL72 über Offline, Server und Interactive. Stack: vLLM mit Dynamo. DeepSeek-R1: bis 2,5×, Stack TensorRT-LLM. „Up to“ heißt: Peak über Szenarien, nicht jeder Modus exakt 3,7. Closed Division, Preview für Vera Rubin.

Rechnen wir Capex-Logik — illustrativ, ohne erfundene Euro-Preise. Angenommen ein GB300-Rack liefert in Ihrem Workload T Tokens pro Stunde und ein Vera-Rubin-Rack 3,7 T unter denselben Lab-Bedingungen. Dann brauchen Sie für dieselbe Token-Menge grob 1/3,7 ≈ 0,27 GB300-äquivalente Racks an Rubin-Leistung — wenn der Faktor hält. Hält er unter Production-SLO nur bei 2,0×, ändert sich die Rechnung auf 0,5. Der Gap zwischen 3,7 und 2,0 ist der Ort, an dem Blindvertrauen teuer wird.

NVIDIA schreibt, jedes Vera-Rubin-Rack liefere deutlich mehr Tokens, diene mehr Nutzende und generiere mehr Revenue bei niedrigeren Kosten pro Token. Revenue und Cost-per-Token sind ökonomische Ableitung aus Throughput — Vendor-Narrativ, keine unabhängige P&L.

99 % Scaling: vier Racks, 288 GPUs

Von einem GB300 NVL72 (72 GPUs) auf vier Racks (288 GPUs) erreicht die DeepSeek-R1-Submission im Offline-Szenario 99 % Scaling Efficiency. Throughput wächst nahezu proportional zur Hardware. Ideal wären 100 %: vierfache GPUs, vierfacher Throughput. 99 % heißt: fast nichts geht an Orchestrierung und Interconnect verloren — im berichteten Offline-Setup.

Zum Vergleich: Würden doppelte GPUs nur einstellige Prozent Throughput bringen, fräße Capex die Rendite. Genau deshalb ist Scaling Efficiency laut Blog Schlüsselmetrik. Sie gilt hier für GB300-Racks untereinander, nicht automatisch für gemischte Vera-Rubin-/GB300-Flotten und nicht automatisch für Server-/Interactive-Latenzklassen.

Rechnen wir weiter — illustrativ. Ein Rack ≈ Leistung 1. Vier Racks bei 99 % ≈ 3,96. Kombinieren Sie das mit einem 3,7×-Faktor auf Rubin-Einrack-Ebene (andere Generation, anderer Benchmark-Strang): Die Multiplikation 3,7 × 3,96 ist keine NVIDIA-Zahl. Sie wäre eine unerlaubte Hochrechnung über verschiedene Submissionen. Halten Sie die Stränge getrennt: Rubin-vs-GB300-Throughput hier, GB300-Multi-Rack-Scaling dort.

https://digital-magazin.de/ki-agenten-unternehmen/

Full-Stack-Codesign: was hinter den Faktoren steht

NVIDIA führt die Ergebnisse auf Codesign zurück: verbesserte Tensor Cores und Transformer Engine für Prefill und Decode; NVFP4-Präzision gegen Memory-Footprint bei Weights, Attention und KV-Cache; disaggregiertes Serving (Prefill und Decode getrennt); Large-Scale Expert Parallelism für Mixture-of-Experts-Schichten in DeepSeek-R1 und Qwen3-VL. NVL72 Scale-up über sechste Generation NVLink und NVLink Switch: 10× höhere Packet Rates und 3× niedrigere Latenz als Off-the-Shelf-Ethernet — Vendor-Claims zur Interconnect-Basis.

Konkret heißt das: Der Throughput-Faktor ist kein reiner Silizium-Sprung. Software-Stack und Rack-Domain tragen mit. Wer nur die GPU-Folie kauft und Dynamo/vLLM/TRT-LLM-Reife ignoriert, unterschätzt den Integrationsaufwand bis Production-SLO.

Software seit v6.0: bis 1,6× auf Qwen3-VL für GB300 durch niedrigere KV-Cache-Präzision, Kernel-Fusion, bessere Kernels und Disaggregation mit vLLM und Dynamo. Post-Submission-Ergebnisse (noch nicht von MLCommons verifiziert) zu GPT-OSS-120B und DLRMv3 zeigen weitere Gains — ausdrücklich unverifiziert. Für Capex-Planung zählen verifizierte Einträge schwerer als Post-Deadline-Folien.

Preview-Submission vs. Production-SLO: der Gap

Preview heißt: frühe Plattform, erste Einreichung, oft aggressiv getunte Closed-Division-Konfiguration. Production-SLO heißt: p95/p99-Latenz, Fehlerrate, Fairness zwischen Teams, Mischlast, Patch-Fenster, Strom- und Kühlbudgets, Multi-Model-Routing.

Stellen Sie sich vor — Rahmen ohne erfundene SLO-Zahlen — Ihr Interactive-SLO verlangt 200 ms Time-to-First-Token und stabile Decode-Latenz unter Last. Der MLPerf-Interactive-Lauf maximiert Throughput unter Benchmark-Regeln. Liegt Ihr produktiver Mix aus langen Prefills und kurzen Chats ungünstiger, schrumpft der 3,7×-Faktor. Ab welchem Gap kein Blindvertrauen?

• Wenn Preview und Prod unterschiedliche Serving-Stacks nutzen (z. B. Dynamo-Labor vs. Eigenbau) — nicht blind.
• Wenn Ihr Modell nicht Qwen3-VL/DeepSeek-R1 ist und MoE-/Vision-Anteile abweichen — nicht blind.
• Wenn Multi-Tenancy und Quota den 99 %-Scaling-Pfad zerstückeln — nicht blind.
• Wenn Strom-, Kühl- und Stellflächenlimits vier Racks verhindern — Capex-Vergleich braucht Standort-Constraint, nicht nur Tokens/s.

Mal ehrlich: MLPerf ist die beste gemeinsame Sprache der Branche. Sie ist trotzdem keine Ausschreibung. Wer Enterprise-KI-Kosten schon einmal gegen Lizenz und Hardware gelegt hat, kennt den Unterschied zwischen Demo-Throughput und belastbarer Stückkostenrechnung.

Ich finde, genau dieser Unterschied wird in CFO-Runden oft übersprungen. Die Folie zeigt 3,7×. Die Betriebsabrechnung zeigt Auslastung, Ausschuss und Warteschlangen.

1,6× Software: Capex-Alternative ohne neues Rack

Bis 1,6× auf bestehendem GB300 durch Software seit v6.0 ist der leise Hebel. Rechnen wir: Liegt Ihr Engpass bei GB300 und Sie erwägen Rubin wegen 3,7×, prüfen Sie zuerst, ob 1,6× plus bessere Orchestrierung die SLO-Lücke schließt. Manchmal lohnt Software-Velocity mehr als Generationssprung — bis die Lücke größer wird als Software holen kann.

Der Haken: Software-Gains sind workload-spezifisch. Was auf Qwen3-VL 1,6× bringt, bringt auf Ihrem Fine-Tune vielleicht 1,1×. Deshalb gehören eigene Replay-Traces neben MLPerf auf die Due-Diligence-Liste.

Unter dem Strich: MLPerf zeigt Richtung. Ihr Trace zeigt Wahrheit.

Agentic Inference: 30× AgentX und der nächste Benchmark

NVIDIA nennt SemiAnalysis AgentX: Vera Rubin NVL72 mit 30× besserer Performance als GB300 in Preview-Tests. Das ist nicht der MLPerf-Closed-Eintrag, sondern ein separates Preview. MLPerf Endpoints soll agentische Workloads standardisieren. Für KI-Agenten in Unternehmen ist die Richtung klar: Throughput allein misst Mehrschritt-Reasoning schlecht.

Hand aufs Herz: Würden Sie eine Bankfiliale nur nach Schalter-Transaktionen pro Stunde bewerten und Beratungstermine ignorieren? Dann sollten Sie Inference-Capex nicht nur nach Offline-Tokens bewerten.

30× ist ein starkes Signal und ein starkes Caveat zugleich — Preview, anderer Benchmark. Legen Sie es nicht ungeprüft neben 3,7× in dieselbe Zelle.

Was Controllende und Infrastruktur-Einkauf konkret fragen sollten

Erstens: Welche MLPerf-Eintrags-IDs und welches Szenario (Offline/Server/Interactive) liegen dem 3,7× zugrunde — und welches Modell entspricht Ihrem Prod-Mix? Zweitens: Preview-Zeitplan bis GA und Software-Parity. Drittens: gemessene Scaling Efficiency unter Ihrem Orchestrator, nicht nur unter NVIDIAs Submission. Viertens: Cost per Token inkl. Strom, Kühlung, Amortisation — nicht nur Tokens/s. Fünftens: Fallback, wenn Rubin-Lieferung rutscht — hält 1,6× Software auf GB300 die SLO?

Keine Euro-Listenpreise im Blog — also keine erfundenen hier. Die Fragen verhindern Blindvertrauen.

Kennen Sie das aus Kreditentscheidungen? Sicherheiten und Cashflow getrennt prüfen. Hier: Benchmark-Peak und Production-Cashflow getrennt. Vermischen Sie die Spalten nicht, nur weil beide „Throughput“ heißen.

Fungibilität und Edge: der Rahmen drumherum

NVIDIA betont Platform-Fungibilität und reicht parallel Jetson AGX Thor auf dem neuen Edge-Agentic-Benchmark mit Qwen3.6-27B ein. Für diesen Artikel zählt das als Skalen-Kontext: von Edge bis AI Factory. Der Capex-Kern bleibt NVL72-Rack und Multi-Rack-Scaling.

Ehrlich gesagt: Edge-Zahlen lösen Ihr Datacenter-SLO nicht. Sie zeigen nur, dass dieselbe Vendor-Story über Formfaktoren gespannt wird. Bleiben Sie beim Rack, wenn Sie Rack-Capex entscheiden.

Illustrative Capex-Skizze: wann 3,7× nicht reicht

Angenommen — Skizze — Ihr Cluster braucht 10 GB300-äquivalente Rack-Leistungen unter Prod-SLO. Bei stabilem 3,7× bräuchten Sie grob 10/3,7 ≈ 2,7 Rubin-Racks. Bei effektivem 2,2× nach Latenz- und Mischlast-Abschlägen: 10/2,2 ≈ 4,5 Racks. Der Capex-Unterschied zwischen 2,7 und 4,5 ist der Preis des Preview-Gaps. Ohne eigene Abschlagsmessung wählen viele Teams optisch 2,7 und betreiben später 4,5 — oder verfehlen die SLO.

Deshalb: Preview-Score als Obergrenze der Hoffnung, Trace-Replay als Untergrenze der Planung. Dazwischen liegt Controllership.

Das Kuriose daran: Dieselbe Organisation, die 99 % Scaling feiert, akzeptiert oft 70 % Auslastung in Produktion wegen Quota und Angst vor Noisy Neighbors. Dann ist die lineare Rack-Mathematik akademisch.

Closed Division und die Versuchung der Idealbedingungen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptLab whiteboard with abstract rack scaling diagram as soft shapes not numbers, coffee and notebook, photorealistic research office, no logos, no brand names, no readable text, 16:9

Closed Division standardisiert Modell und Regeln, damit Plattformen vergleichbar bleiben. Ideal für Vendor-Vergleiche. Ungeeignet als 1:1-Proxy für Ihre Fine-Tunes, Guardrails und Tool-Calls. Je mehr Ihr Stack von der Closed-Konfiguration abweicht, desto größer der erwartbare Gap zum Preview-Faktor.

Rechnen wir qualitativ. Jede zusätzliche Sicherheitsprüfung, jedes Retrieval und jeder Agent-Schritt kostet Decode-Zeit. MLPerf-Offline maximiert Durchsatz. Ihr Agent-Pfad maximiert korrekte Mehrschritt-Ergebnisse. Verschiedene Zielfunktionen, verschiedene Capex-Logik.

Der Haken: CFOs lieben eine Zahl. 3,7× ist eine Zahl. Production-SLO ist ein Vertrag. Verträge schlagen Zahlen, wenn Incidents teurer sind als Racks.

Strom, Kühlung, Stellfläche: die vergessene Zeile

Mehr Tokens pro Rack senken oft Kosten pro Token — wenn Strom und Kühlung mithalten. Wenn Ihr Datacenter bei GB300-Dichte schon am Limit ist, ändert ein höherer Throughput pro Rack die Stellflächenrechnung, nicht automatisch die Ampère-Rechnung. Ohne Facility-Daten ist die Token-Ökonomie unvollständig.

Zum Vergleich: Eine Bankfiliale mit doppeltem Umsatz bei derselben Miete lohnt sich. Dieselbe Filiale mit doppeltem Umsatz und dreifachem Strompreis braucht eine neue Rechnung. Inference-Racks sind Filialen mit Kühlwasser.

Wir bei digital-magazin.de legen Facility-Constraints deshalb neben MLPerf, nicht darunter.

Partner-Ecosystem ohne Nebenpitch

19 Partner in der Runde, Nebius mit eigener Vera-Rubin-Preview — das zeigt Verfügbarkeit über einen Vendor hinaus. Für Einkauf: Dual-Source-Optionen prüfen, sobald GA-Zeitpläne stehen. Für diesen Text kein Katalog der Partnerfolien. Der Kern bleibt Faktor, Scaling, Preview-Gap.

Spannend wird es, wenn derselbe Workload bei zwei Integratoren unterschiedliche effektive Faktoren liefert. Dann war nicht nur Silizium der Hebel, sondern Integration. Genau das erwartet Codesign-Rhetorik — und genau das muss die Ausschreibung abfragen.

Offline, Server, Interactive: drei Uhren, ein Faktor

„Bis 3,7ד spannt Offline, Server und Interactive. Offline maximiert Durchsatz ohne strenge Latenzklassen. Server und Interactive binden Latency Constraints. Wer Capex nur auf Offline plant und Interactive verkauft, mischt Uhren. Der effektive Faktor unter Interactive-SLO kann unter dem Peak liegen — ohne dass die Submission gelogen hätte.

Rechnen wir die Disziplin vor. Legen Sie drei Zellen: Offline-Faktor, Server-Faktor, Interactive-Faktor, jeweils aus denselben Eintrags-IDs. Fehlt eine Zelle in Ihrer Folie, ist die Folie unfertig. NVIDIA nennt „across offline, server and interactive“ für Qwen3-VL — das rechtfertigt den Peak, ersetzt aber nicht Ihre Zellen.

Der Knackpunkt für Produktteams: Chat-Frontends leben und sterben mit Interactive. Batch-Pipelines leben mit Offline. Dieselbe Hardware, verschiedene Wahrheit.

Disaggregated Serving: Effizienz mit Betriebspreis

Prefill und Decode zu trennen steigert Effizienz bei MoE und langen Kontexten. Es steigert auch die Orchestrierungskomplexität: zwei Pfade, zwei Skalierungsregeln, zwei Fehlerdomänen. Preview-Submissions dürfen das aggressiv tun. Production muss Observability, Autoscaling und Failure Domains mitliefern.

Unter dem Strich: Codesign-Gewinne sind real. Integrationsschulden auch. Capex-Vergleiche ohne OpEx für Orchestrator und SRE unterschätzen Rubin ebenso wie GB300.

Zum Vergleich mit KI-Regeln in Unternehmen: Mehr Leistung ohne Betriebsmodell ist nur eine schnellere Fehlerkette.

NVFP4 und Qualität: „minimal loss“ ist kein Blankoscheck

NVIDIA schreibt, NVFP4 erhöhe Throughput bei minimalem Verlust an Output-Qualität. Minimal ist qualitativ. Für regulierte Outputs — Finanzen, Medizin, Recht — brauchen Sie eigene Qualitätsgates, nicht nur Tokens/s. Quantisierung, die Benchmarks überlebt und Compliance-Reviews nicht, ist ein teurer Capex-Irrtum.

Ich finde diese Zeile unterschätzt. Throughput-CFOs nicken. Qualitäts- und Risiko-Teams müssen nachmessen. Ohne beide Unterschriften kein Blindkauf.

Vier Racks Linearität — und die Auslastungsfalle

99 % Scaling Efficiency im Offline-DeepSeek-Lauf heißt: Die Architektur kann linear. Ihre Auslastung folgt trotzdem Quota, Team-Silos und Angst vor Noisy Neighbors. Eine Flotte, die hardwareseitig 99 % kann und organisatorisch bei 60 % steht, verschenkt den Scaling-Claim.

Rechnen wir: 4 Racks × 0,99 ≈ 3,96 ideale Leistungseinheiten. Bei 60 % organisatorischer Auslastung bleiben ~2,4. Dann war der Einkauf von vier Racks teurer als nötig — oder die Governance zu schwach. MLPerf misst das erste. Ihr FinOps misst das zweite.

Mal ehrlich: Viele AI-Factories kaufen Linearität und betreiben Fragmentierung. Beheben Sie Fragmentierung, bevor Sie den nächsten Generationssprung als Ersatztherapie buchen.

Post-Submission-Gains: Hoffnung mit Sternchen

Weitere Gains nach Deadline auf GPT-OSS-120B und DLRMv3 — noch nicht von MLCommons verifiziert. Für die Presse spannend. Für Ausschreibungen Sternchen. Verifizierte v6.1-Zahlen tragen schwerer als unverifizierte Nachreichungen. Planen Sie Software-Velocity als Option, nicht als bereits gebuchten Capex-Ersatz.

Das Kuriose daran: Dieselbe Plattform, die 1,6× seit v6.0 nachweist, lädt dazu ein, Hardwarekäufe zu verschieben. Manchmal richtig. Manchmal eine Ausrede, SLO-Schulden auszusitzen. Controllership unterscheidet beides anhand von Trace-Replays, nicht anhand von Blog-Absätzen.

Hand aufs Herz: Wenn Ihr Engpass seit zwei Quartalen gleich ist und nur die Folien neuer werden, ist nicht MLPerf das Problem.

Vier Checkfragen vor dem Capex-Freigabevermerk

Erstens: Haben Sie denselben Benchmark-Namen, dieselbe Precision und denselben Scenario-Modus gegenübergestellt — oder nur Marketing-Labels? Zweitens: Steht der Faktor unter Ihrem Interactive-SLO oder nur unter Offline? Drittens: Ist 99 % Scaling Efficiency für Ihre Flottengröße belegt oder nur für die Submission-Konfiguration? Viertens: Welche Software-Gewinne seit dem letzten Release sind bereits in Ihrer Production-Stack-Version enthalten?

Wer alle vier mit Ja beantwortet und trotzdem kauft, kauft bewusst. Wer drei mit „ungefähr“ beantwortet, kauft Storytelling. Controllership ist hier kein Misstrauen gegenüber NVIDIA — es ist Schutz vor Selbsttäuschung.

Rechnen wir die vierte Frage zu Ende. Wenn Sie noch auf einem Stack stehen, der die 1,6× Software-Gewinne seit v6.0 nicht enthält, ist der nächste Capex-Hebel oft ein Upgrade-Pfad — nicht vier neue Racks. Wenn Sie die Gewinne bereits haben und Interactive trotzdem kippt, ist Hardware der engere Engpass. Ohne diese Diagnose ist jede Generationsfolien-Entscheidung Spekulation mit sechsstelligen Folgen.

Und noch ein Punkt, der selten in MLPerf-Posts steht: Verfügbarkeit. Preview-Hardware kann in Lead-Times, Allocation und Support anders laufen als GB300-Produktion. Ein Faktor 3,7× auf Papier hilft wenig, wenn Ihr Rollout-Fenster sechs Monate später liegt und die Concurrent-User-Kurve schon nächste Woche kippt. Zeit ist Teil der Capex-Rechnung.

Der Punkt ist: Submission ist Input, kein Freibrief

Was bleibt? Vera Rubin NVL72 debutiert in MLPerf Inference v6.1 mit bis zu 3,7× Throughput gegen GB300 auf Qwen3-VL und bis 2,5× auf DeepSeek-R1. Vier GB300-Racks skalieren DeepSeek-R1 Offline mit 99 % Efficiency. Software seit v6.0 bis 1,6×. Preview-Status und Production-SLO sind verschiedene Uhren.

Unter dem Strich lohnen 3,7× und 99 % als Capex-Input. Sie ersetzen nicht die Gap-Analyse zur eigenen SLO. Rechnen Sie den Abschlag, bevor Sie den ersten MLPerf-Eintrag für die Investitionsentscheidung halten — und lassen Sie Software-Velocity auf bestehendem GB300 als Alternative auf derselben Folie stehen.

Wir bei digital-magazin.de behalten Peak und Produktion in getrennten Spalten. Bis Ihr Trace denselben Faktor zeigt, gilt: Beeindruckende Submission ja. Blindkauf nein — dieselbe Disziplin wie bei KI-Datenschutz und Vertraulichkeit, wo Peak-Features ohne Governance nichts wert sind.