NVIDIA Vera Rubin NVL72 beansprucht 67-mal bessere Leistung pro Dollar, doch der Betriebspunkt ist entscheidend
NVIDIA Vera Rubin NVL72 hat in einem frühen Test zur agentischen Inferenz einen behaupteten 67-fachen Vorteil bei der Leistung pro Dollar gegenüber GB300 NVL72 erzielt. Diese Zahl ist innerhalb des gewählten Benchmark-Vergleichs real, aber kein universeller Multiplikator. Bei gängigeren Serving-Geschwindigkeiten fiel der gemessene Vorteil deutlich geringer aus.
Die Ergebnisse vom 14. September geben Infrastrukturkäufern den ersten unabhängigen Einblick in Rubin unter einer Long-Context-Workload mit mehreren Gesprächsrunden. Sie lassen zudem die frühere Leistungsprognose von NVIDIA-CEO Jensen Huang konservativ erscheinen. Der größte Multiplikator hängt jedoch von einem anspruchsvollen Betriebspunkt ab, an dem die verglichene Blackwell-Konfiguration an ihre Leistungsgrenze stößt.
Der zentrale Wettbewerb lautet daher nicht einfach Rubin gegen Blackwell. Es geht um den Unterschied zwischen der Schlagzeilenbehauptung und der Leistung, die Betreiber über Modelle, Serving-Engines, Latenzziele und Produktionsverkehr hinweg reproduzieren können. NVIDIA scheint diese gesamte Leistungskurve verschoben zu haben, doch der Abstand variiert entlang ihr deutlich.
NVIDIA Vera Rubin NVL72 wechselt von Prognosen zu gemessener Agentenarbeit
Die entscheidende Veränderung besteht darin, dass für Rubin nun gemessene Ergebnisse zur agentischen Inferenz vorliegen, nicht nur Architekturspezifikationen oder NVIDIA-Prognosen.
SemiAnalysis veröffentlichte die ersten überprüften Rubin-Ergebnisse aus AgentX, seinem Benchmark für Long-Context-Traffic von Coding-Agenten. Die Tests nutzten produktionsähnliche Sitzungen mit angesammeltem Kontext, Tool-Pausen, Präfix-Wiederverwendung und Schüben paralleler Subagenten.
Dieser Traffic unterscheidet sich von einem herkömmlichen Chatbot-Benchmark. Eine einfache Chat-Anfrage umfasst häufig einen Prompt und eine Antwort. Ein Agent kann Hunderte Runden führen, während er Tools aufruft, Subagenten konsultiert und fortlaufend einen wachsenden Gesprächsverlauf sendet.
Diese Muster stellen andere Anforderungen an ein Inferenzsystem. Lange Verläufe verbrauchen Kapazität im Key-Value-Cache, der zuvor berechnete Attention-Daten speichert. Wiederverwendete Präfixe belohnen effizientes Caching, während Subagenten-Schübe Scheduling und Parallelität prüfen.
Die öffentliche AgentX-Methodik basiert auf 393 Opt-in-Coding-Sitzungen mit 135.282 Anfragen. Die mediane rekonstruierte Anfrage enthält 142.016 Input-Token und 444 Output-Token.
AgentX entfernt Prompts, Code, Tool-Argumente und Tool-Ergebnisse. Erhalten bleiben Anfragelängen, Zeitabläufe, Beziehungen gemeinsamer Präfixe und die Struktur von Subagenten; anschließend werden deterministische synthetische Token eingesetzt.
Dieses Design bietet realistischere Traffic-Muster, ohne die ursprünglichen Inhalte offenzulegen. AgentX prüft jedoch nicht, ob ein Modell korrekten Code erzeugt oder die Aufgabe eines Agenten erfolgreich erledigt. Gemessen wird das Serving-System, nicht die Intelligenz des Modells.
Die neuen Ergebnisse nutzten DeepSeek V4 Pro und einen frühen TensorRT-LLM-Stack. TensorRT-LLM ist NVIDIAs Inferenz-Runtime zur Optimierung der Modellausführung auf seinen Beschleunigern.
Laut der Rubin-Benchmark-Analyse erzielte Vera Rubin NVL72 bei 170 Token pro Sekunde etwa die 67-fache Gesamtdurchsatzleistung pro modellierten Betriebskosten gegenüber GB300 NVL72.
Dieser Vergleich nutzte TensorRT-LLM und NVFP4, NVIDIAs Vier-Bit-Zahlenformat für KI-Berechnungen mit geringerer Präzision. Er maß zudem die vollständige Hardware- und Softwarekonfiguration, statt theoretische Chip-Spezifikationen zu vergleichen.
Am selben Betriebspunkt erzielte Rubin einen auffälligen Vorteil, weil die ausgewählte GB300-TensorRT-LLM-Kurve nahe ihrem schnellsten gemessenen Endpunkt lag. SemiAnalysis berichtete von einem deutlich geringeren Rubin-Vorteil gegenüber GB300 mit SGLang, einem weiteren Serving-Framework.
Das Ergebnis bleibt dennoch relevant. Rubin gewann nicht allein, weil der Benchmark eine veraltete Generation oder einen einfachen Single-GPU-Server auswählte. Es übertraf NVIDIAs Blackwell-Ultra-Rack-Scale-System beim Serving desselben großen Modells und bei Einhaltung eines vergleichbaren Zielwerts für die Antwortgeschwindigkeit.
Die 67-fache Zahl beschreibt jedoch einen Punkt auf einer Leistungskurve. Sie bedeutet nicht, dass jede Rubin-Installation für dieselben Gesamtkosten 67-mal mehr Token erzeugt.
Im Bereich von 60 bis 100 Token pro Sekunde, den SemiAnalysis als repräsentativer für Anbieter dieses Workloads beschreibt, lieferte Rubin etwa 1,4- bis dreimal mehr Durchsatz pro Gesamtkosten.
Das ist weniger spektakulär als 67-mal, aber kommerziell bedeutsam. Ein nachhaltiger zweifacher Gewinn kann die Kapazitätsplanung neu gestalten, wenn Stromversorgung, Netzwerk, Kühlung und verfügbare Rechenzentrumsfläche die Expansion bereits begrenzen.
Die Ergebnisse zeigen auch eine höhere maximale Interaktivität. Rubin erreichte etwa 276 P90-Token pro Sekunde, verglichen mit rund 172 bei GB300 unter Verwendung der ausgewählten TensorRT-LLM-Konfiguration.
P90-Interaktivität misst die Streaming-Geschwindigkeit, die 90 Prozent der Antworten erreichen. Sie hilft Betreibern zu beurteilen, ob ein Durchsatzergebnis zugleich eine akzeptable Nutzererfahrung bietet.
Rubins Vorteil war nicht über alle Software-Stacks hinweg identisch. SemiAnalysis stellte fest, dass GB300 mit SGLang eine Rubin-ähnliche Interaktivität erreichen konnte, obwohl Rubin weitere Durchsatz- und Latenzvorteile behielt.
Diese Variation begründet die zentrale Spannung des Artikels. NVIDIA Vera Rubin NVL72 scheint deutlich schneller zu sein, doch sein größter berichteter Vorteil entsteht aus einer spezifischen Kombination von Modell, Runtime, Präzision und Service-Level-Ziel.
Warum agentische Inferenz Strom zur knappen Ressource macht
Rubins folgenreichster Gewinn ist nicht die Spitzenrechenleistung, sondern die Menge an nützlichem Agenten-Traffic, die innerhalb eines festen Strombudgets bedient werden kann.
Ein Agent verbraucht mehr Token als eine einfache Chat-Interaktion, weil jeder Schritt zum Kontext für den nächsten werden kann. Forschungs-, Coding- und Support-Agenten können Datenbanken durchsuchen, Tools ausführen, Ergebnisse prüfen und Aufgaben delegieren, bevor sie antworten.
NVIDIA zufolge verbrauchen agentische Anfragen auf Basis von OpenRouter-Daten etwa 15-mal mehr Token als einfache Chat-Anfragen. Diese Zahl variiert je nach Anwendung, die grundlegende Richtung ist jedoch klar.
Mit wachsendem Kontext verarbeitet oder ruft das System wiederholt Informationen aus früheren Runden ab. Mehrere Subagenten können zudem kurze, intensive Schübe gleichzeitiger Anfragen erzeugen.
Diese Eigenschaften machen Speicherkapazität, Speicherbandbreite, Interconnect-Latenz, Cache-Management und CPU-Koordination zu primären Engpässen. Rohe Tensorleistung bleibt wichtig, erklärt jedoch nicht mehr das vollständige Serving-Ergebnis.
Der Zugang zu Strom setzt eine weitere Grenze. Ein Betreiber kann möglicherweise zusätzliche Beschleuniger kaufen, verfügt aber nicht über genügend Netzkapazität, um sie zu versorgen. Neue Umspannwerke, Übertragungsanschlüsse, Kühlsysteme und Rechenzentrumshallen benötigen mehr Zeit für den Bau als Server.
Durchsatz pro Megawatt misst daher mehr als Energieeffizienz. Er nähert sich der Menge an abrechenbarer Arbeit an, die ein Betreiber aus einer knappen Anlagenressource gewinnen kann.
Bei 100 Token pro Sekunde maß SemiAnalysis für Rubin etwa 59,4 Millionen Gesamt-Token pro Sekunde je Versorger-Megawatt. Die stärkste gemessene GB300-Konfiguration erreichte beim selben Zielwert 28,5 Millionen.
Damit ist Rubin an diesem praxisnahen Betriebspunkt etwa 2,09-mal schneller als die stärkste GB300-Engine. GB300 mit TensorRT-LLM erreichte 21,1 Millionen Token pro Sekunde je Megawatt.
Die Größe des Vorsprungs änderte sich mit steigender Geschwindigkeitsanforderung. Bei 150 Token pro Sekunde behielt Rubin nahezu 37 Millionen Token pro Sekunde je Megawatt, rund 7,2-mal das gemessene GB300-SGLang-Ergebnis.
Bei 170 Token pro Sekunde lag Rubins Vorsprung beim Durchsatz pro Megawatt gegenüber GB300 TensorRT-LLM bei 62,9-mal. Gegenüber GB300 SGLang betrug der Multiplikator jedoch 5,56-mal.
Dieser Unterschied zeigt, warum jede große Leistungsbehauptung das verwendete Engine-Label benötigt. Ein Käufer, der nur Beschleunigernamen vergleicht, würde übersehen, wie stark die Runtime das Ergebnis verändert.
NVIDIAs frühere Zahlen zeigten eine weitere Perspektive auf denselben Trend. Das Unternehmen berichtete bei 160 Token pro Sekunde von bis zu 30-mal höherem Durchsatz pro Megawatt als GB300.
NVIDIA erklärte, diese Tests hätten die AgentX-DeepSeek-V4-Pro-Workload genutzt. Zum Zeitpunkt der Veröffentlichung sagte das Unternehmen zudem, dass die Ergebnisse noch von SemiAnalysis überprüft würden und die Vera-CPU-Leistung für Tool-Aufrufe nicht einschlössen.
Die anschließende Überprüfung stützt einen erheblichen Rubin-Vorteil, jedoch keinen festen Multiplikator. NVIDIAs Daten zur agentischen Leistung zeigen, dass der Vorteil von etwa dem Zweifachen bei 110 Token pro Sekunde auf das 30-Fache bei 160 steigt.
Diese Kurve ist wichtiger als ein einzelnes Balkendiagramm. Ein Inferenzanbieter wählt ein Gleichgewicht zwischen Parallelität, Antwortgeschwindigkeit, Zeit bis zum ersten Token, Gesamtlatenz und Kosten.
Eine Konfiguration, die auf maximalen Gesamtdurchsatz optimiert ist, kann einzelne Nutzer zu lange warten lassen. Ein System, das auf extreme Interaktivität optimiert ist, kann teure Kapazität unzureichend auslasten.
Agentische Produkte bringen eine weitere Komplikation mit sich. Tool-Ausführung, Code-Kompilierung, Retrieval und externe API-Aufrufe können GPUs auf CPUs oder Remote-Dienste warten lassen.
Rubin adressiert dieses Problem mit 36 Vera-CPUs neben 72 Rubin-GPUs in jedem NVL72-Rack. NVIDIA entwickelte diese CPUs für Agenten-Orchestrierung, Tool-Aufrufe, Datenverarbeitung und Sandbox-Ausführung.
Das wirtschaftliche Argument wird stärker, wenn diese Komponenten die Leerlaufzeit über einen gesamten Workflow hinweg verringern. Es wird schwächer, wenn externe Tools, Netzwerkaufrufe oder Anwendungslogik weiterhin den dominierenden Engpass bilden.
Für Cloud-Anbieter und Modelllabore ist der Druck unmittelbar. Ein großer Rubin-Vorteil würde eine fortgesetzte Blackwell-Expansion für neue, strombegrenzte Inferenzkapazität schwieriger rechtfertigen.
Bestehende Blackwell-Installationen werden nicht plötzlich unwirtschaftlich. Ihre Hardware ist bereits installiert, ihre Software ist ausgereift, und viele Workloads benötigen nicht Rubins höchste Interaktivitätsspanne.
Die notwendige Reaktion ist selektiver. Betreiber müssen entscheiden, welche Workloads zuerst Rubin verdienen, welche auf Blackwell bleiben sollten und welche auf konkurrierende Beschleuniger wechseln können.
Extremes Co-Design ist der Mechanismus hinter dem Rubin-Gewinn
NVIDIAs Ergebnis entsteht durch die Abstimmung von GPU, CPU, Speicher, Interconnect, Runtime und Anlage, nicht durch einen einzelnen schnelleren Chip allein.
NVIDIA nennt diese Strategie extremes Co-Design. Vera Rubin NVL72 integriert 72 Rubin-GPUs und 36 Vera-CPUs über NVLink der sechsten Generation innerhalb einer einzelnen Rack-Scale-Domäne.
Die Rubin-GPU umfasst 288 GB HBM4-Speicher mit 22 TB pro Sekunde Speicherbandbreite. High-Bandwidth-Memory befindet sich nahe am Prozessor und liefert Modelldaten schneller als herkömmlicher Serverspeicher.
NVLink stellt 3,6 TB pro Sekunde Bandbreite für jede GPU und 260 TB pro Sekunde über das gesamte Rack bereit. Dieses Fabric ermöglicht es den 72 GPUs, sich eher wie eine große Rechenressource zu verhalten.
Diese Architektur begünstigt Mixture-of-Experts-Modelle. Solche Modelle aktivieren für jedes Token ausgewählte Expertennetzwerke, statt bei jeder Operation sämtliche Parameter zu nutzen.
Ihre effiziente Bereitstellung erfordert schnelles Routing zwischen Prozessoren. Verzögerungen beim Verschieben von Aktivierungen zwischen Experten können die auf einem Datenblatt beeindruckend wirkende Rechenkapazität verschwenden.
Rubin verbessert zudem Synchronisationsoperationen, die während verteilter Inferenz eingesetzt werden. Weniger Kommunikations-Overhead bedeutet, dass Prozessoren mehr Zeit mit Rechnen und weniger Zeit mit dem Warten auf Koordination verbringen.
NVIDIAs Rack-Architektur kombiniert Rubin mit ConnectX-9-Netzwerken, BlueField-4-Datenverarbeitungseinheiten, NVLink-Switches und der Spectrum-6-Ethernet-Plattform.
Das Unternehmen bezeichnet das umfassendere System nach der Ergänzung um den Groq 3 LPU nun als Sieben-Chip-Architektur. Ein LPU ist ein Prozessor, der für die vorhersehbare Ausführung von Sprachmodellen mit niedriger Latenz entwickelt wurde.
Rubin übernimmt die rechenintensive Kontextverarbeitung, auch Prefill genannt. Mit Groq-3-Prozessoren ausgestattete LPX-Racks können sich auf die latenzsensitive Tokengenerierung konzentrieren, das sogenannte Decode.
Diese Trennung wird als disaggregiertes Serving bezeichnet. Sie ermöglicht Betreibern, Prefill- und Decode-Ressourcen unabhängig zu skalieren, statt beide Phasen auf identische Hardware zu zwingen.
Agent-Workloads machen diese Aufteilung attraktiv, weil ihre Anfragen lange Eingabeverläufe enthalten, aber möglicherweise schnelle interaktive Ausgaben erfordern. Prefill benötigt Speicherkapazität und parallele Rechenleistung, während Decode von niedriger Latenz profitiert.
Rate Matching gleicht anschließend aus, wie schnell die beiden Pools Arbeit austauschen. Eine schlechte Abstimmung kann dazu führen, dass eine Gruppe untätig bleibt, während die andere überlastet wird.
Die Serving-Software verbindet diese Komponenten. TensorRT-LLM stellt optimierte Kernel bereit, während NVIDIA Dynamo die Inferenz über verteilte Ressourcen hinweg koordiniert.
Die AgentX-Ergebnisse zeigen, warum Software als Teil des Produkts behandelt werden muss. Der Unterschied zwischen GB300 mit TensorRT-LLM und GB300 mit SGLang erreichte an einem Endpunkt ein Vielfaches von mehreren Zehnern.
Das bedeutet nicht, dass eine Engine universell überlegen ist. Die stärkste GB300-Engine wechselte über den getesteten Geschwindigkeitsbereich hinweg: TensorRT-LLM lag bei einem Zielwert vorn, SGLang bei höheren Zielwerten.
Rubins frühes Ergebnis wurde erzielt, bevor sein Software-Stack vollständig ausgereift war. Das schafft Raum für Verbesserungen, führt aber auch zu Unsicherheit bei der Bereitstellung.
NVIDIA zufolge befindet sich die Plattform in voller Produktion und soll in der zweiten Hälfte des Jahres 2026 ausgeliefert werden. Die frühere Plattformbehauptung des Unternehmens lautete, die Inferenzleistung pro Watt könne gegenüber Blackwell bis zu zehnmal höher sein.
SemiAnalysis stellte im Betriebsbereich einen bis zu siebenmal höheren Durchsatz pro Megawatt gegenüber Huangs früherer dreifacher GTC-Illustration fest. An einigen vergleichbaren Endpunkten fiel der gemessene Faktor deutlich höher aus.
Das stützt die „Sandbagging“-Interpretation, allerdings nur in engem Sinne. Huangs Präsentation bezog sich auf eine breite Plattform-Erwartung, während das neue Ergebnis einen agentischen Workload und bestimmte Konfigurationen abdeckt.
Rubins Design setzt auch bei der Strombereitstellung an. Rechenzentren dimensionieren elektrische Systeme üblicherweise für die maximal mögliche Leistungsaufnahme eines Racks, selbst wenn Inferenz-Workloads dieses Maximum nur selten dauerhaft erreichen.
NVIDIA DSX MaxLPS nutzt dynamische Leistungszuweisung, um ungenutzte Reserven über GPUs und Racks hinweg zurückzugewinnen. Es soll mehr Rechenleistung innerhalb derselben Standortgrenze unterbringen, ohne das Leistungsbudget der Anlage zu überschreiten.
Die MaxLPS-Dokumentation beschreibt eine beispielhafte Inferenzbereitstellung mit einem Megawatt und 400 GPUs. In diesem Beispiel erhöht dynamisches Management den Tokendurchsatz auf das 1,35-Fache der statischen Baseline bei maximaler Leistungsaufnahme.
NVIDIA zufolge können kombinierte Standortplanung und Leistungssteuerung in einem festen Leistungsrahmen bis zu 40 Prozent mehr GPUs ermöglichen. Das ist eine Planungsannahme, kein garantiertes Ergebnis für jeden Standort.
Betreiber müssen das tatsächliche Leistungsprofil ihres Workloads, die Kühlkapazität, die Sicherheitsmarge und die Auswirkungen auf die Latenz validieren. Eine Flotte, die häufig ihre Spitzenlast erreicht, bietet weniger zurückgewinnbare Reserven.
Der Mechanismus ist daher multiplikativ. Schnellere GPUs, breiterer Speicher, Verbindungen mit geringerer Latenz, besseres Scheduling, spezialisierte CPUs und dynamisches Leistungsmanagement beseitigen jeweils unterschiedliche Engpässe.
Wenn diese Ebenen zusammenwirken, kann Rubin aus demselben Gebäude mehr nützliche Tokens erzeugen. Wenn eine Ebene nicht mit skaliert, schrumpft der theoretische Gewinn, bevor er Kunden erreicht.
Der 67x-Anspruch schrumpft außerhalb seines ausgewählten Betriebspunkts
Der Benchmark stützt Rubins Vorsprung, zeigt aber auch, warum eine maximale Kennzahl für Leistung pro Dollar nicht zur Planungsannahme für eine gesamte Flotte werden sollte.
Die erste Einschränkung ist der ausgewählte Endpunkt. Bei 170 Tokens pro Sekunde lag die verglichene GB300-TensorRT-LLM-Konfiguration nahe an ihrer gemessenen Interaktivitätsgrenze.
Kleine Erhöhungen des Geschwindigkeitsziels können die Verkehrsmenge, die ein System nahe dieser Grenze bedient, stark reduzieren. Rubin verfügte weiterhin über ungenutzten Leistungsbereich, wodurch das ungewöhnlich hohe Verhältnis entstand.
Der Vergleich von Rubin mit GB300 SGLang beim selben Zielwert verringerte den Vorteil beim Durchsatz pro Megawatt von 62,9-Fach auf 5,56-Fach. Das bleibt erheblich, erzählt jedoch eine andere Beschaffungsgeschichte.
Die zweite Einschränkung ist das Gesamtkostenmodell. SemiAnalysis berechnet die Betriebskosten anhand von Hardware, Netzwerken, Strom, Finanzierung, Colocation, Nutzungsdauer und angenommenen Einkaufsbedingungen für Hyperscaler.
Ein kleinerer Anbieter wird mit anderen Finanzierungs-, Auslastungs- und Infrastrukturbedingungen konfrontiert sein. Ein Cloud-Mieter wird außerdem ein anderes Verhältnis zwischen Hardwareleistung und vertraglich zugesicherter Kapazität sehen.
Leistung pro Dollar hängt davon ab, die Ausstattung beschäftigt zu halten. Ein Beschleuniger mit exzellenter Spitzenökonomie kann enttäuschen, wenn die Nachfrage ungleichmäßig eintrifft oder Software eine hohe Auslastung verhindert.
Die dritte Einschränkung ist der Umfang des Workloads. Das veröffentlichte Rubin-Ergebnis konzentriert sich auf DeepSeek V4 Pro unter der Traffic-Charakteristik von AgentX für Coding-Agenten.
Ein Kunde, der kürzere Prompts, Bildgenerierung, Retrieval, Video, dichte Modelle oder Offline-Batch-Jobs bedient, wird auf andere Engpässe stoßen. SemiAnalysis selbst merkt an, dass Rubins vergleichbare Gewinne bei Offline-Batch-Inferenz und Training geringer sind.
AgentX nutzt zudem synthetische Nutzdaten. Es bewahrt Längen, gemeinsame Präfixe, Timing und Verzweigungen, kann jedoch den semantischen Inhalt privater Sitzungen nicht erhalten.
Spekulatives Decoding stellt eine besondere Herausforderung dar. Diese Technik nutzt ein kleineres oder schnelleres Entwurfsmodell, um mehrere künftige Tokens vorzuschlagen, und fordert dann das Hauptmodell auf, sie anzunehmen oder abzulehnen.
Synthetischer Text kann unrealistisches Annahmeverhalten erzeugen. AgentX begegnet dem, indem es Annahmelängen verwendet, die aus einem separaten Coding-Datensatz gemessen wurden, und diese Einstellungen dokumentiert.
Diese Kontrolle verbessert die Vergleichbarkeit, bleibt jedoch eine Annäherung. Der Benchmark kann proprietäre Provider-Vorlagen, verborgenes Reasoning, serverseitige Tools, Bilder oder jede Tokenizer-Transformation nicht reproduzieren.
Closed-Loop-Ausführung bringt eine weitere Nuance ein. Schnellere Systeme kommen während des Testfensters in den gesampelten Sitzungen weiter voran und können daher auf einen etwas anderen Anfrage-Mix treffen.
Keines dieser Probleme entkräftet das Ergebnis. Sie definieren, was das Ergebnis misst und wo Käufer zusätzliche Evidenz verlangen sollten.
Die vierte Einschränkung ist frühe Software. SemiAnalysis verwendete einen Vorab-Build von TensorRT-LLM, und spätere Releases sollten Rubins Effizienz verbessern.
Frühe Software kann auch Regressionen, unvollständige Funktionen und Betriebsverhalten enthalten, die in einem kontrollierten Benchmark nicht sichtbar werden. Ausgereifte Blackwell-Stacks hatten mehr Zeit, Produktionskorrekturen aufzunehmen.
Zuverlässigkeit ist auf Rack-Ebene wichtig. Ein vollständiges NVL72-Rack enthält laut NVIDIA 1,3 Millionen Komponenten und nahezu 1.300 Chips.
Ein Rechenzentrumsbetreiber benötigt dauerhaft guten Goodput, also nutzbare Ausgabe nach Berücksichtigung von Ausfällen, Wartung, Wiederholungen und nicht verfügbarer Hardware. Spitzen-Benchmarkdurchsatz misst nicht diese gesamte Betriebshistorie.
Die fünfte Einschränkung ist die Reaktion der Konkurrenz. AMD brachte im Juli 2026 seinen Instinct-MI455X-Beschleuniger für die Rack-Scale-Plattform Helios auf den Markt.
Die offiziellen MI455X-Spezifikationen nennen 40,3 Petaflops Spitzenleistung bei MXFP4 und eine CDNA5-Architektur. Spitzenwerte der Rechenleistung lassen sich nicht direkt mit AgentX-Ergebnissen vergleichen.
SemiAnalysis bezog den vorherigen MI355X in seine neuen Messungen ein. Bei 100 Tokens pro Sekunde erreichte die stärkste getestete MI355X-Konfiguration etwa 2,01 Millionen Tokens pro Sekunde und Megawatt.
Rubin erreichte an diesem Punkt 59,4 Millionen und erzielte damit einen gemeldeten Vorsprung um den Faktor 29,5. AMD hat sich laut SemiAnalysis zur Zusammenarbeit bei künftigen AgentX-Tests des MI455X verpflichtet.
Dieser künftige Vergleich wird deutlich relevanter sein als Rubin gegenüber MI355X. Er wird zwei aktuelle Rack-Scale-Plattformen unter demselben Workload, Modell, Traffic-Profil und Service-Level-Ziel testen.
Googles TPU7x Ironwood zielt ebenfalls auf große dichte Modelle und Mixture-of-Experts-Modelle ab. Die Verfügbarkeit über Google Cloud eröffnet Kunden einen weiteren Weg, der kundenspezifisches Silizium mit einer vertikal integrierten Softwareplattform verbindet.
NVIDIA behält einen Vorteil bei der Tiefe seines Ökosystems. CUDA, TensorRT-LLM, Dynamo, NVLink und das Partnernetzwerk geben dem Unternehmen Kontrolle über einen größeren Teil des Bereitstellungspfads.
Diese Kontrolle kann die Optimierung verbessern, aber auch die Abhängigkeit der Kunden von einem Anbieter vertiefen. Extreme gemeinsame Entwicklung funktioniert am besten, wenn Käufer den gesamten Stack akzeptieren.
Die glaubwürdige Interpretation lautet nicht, dass Rubin überall 67-mal besser ist. Sie lautet, dass Rubin die nutzbare Inferenzgrenze erweitert, insbesondere für große agentische Workloads mit strengen Interaktivitätsanforderungen.
Mehr Tokens pro Gigawatt bedeuten nicht automatisch mehr Gewinn
Rubin kann die Wirtschaftlichkeit von Rechenzentren verbessern, doch Gewinn hängt von Auslastung, Nachfrage, Zuverlässigkeit und Verkaufspreisen ab, die der Benchmark nicht feststellen kann.
SemiAnalysis schätzt, dass Rubin pro Gigawatt mehr als doppelt so viel Jahresgewinn wie Blackwell generieren kann. Das Unternehmen erwartet, dass sich dieser Unterschied mit der Reifung von Kerneln und Serving-Software vergrößert.
Diese Schätzung folgt einem plausiblen Mechanismus. Wenn ein Megawatt mehr abrechenbare Tokens erzeugt, steigt die Umsatzkapazität, während die Netzzuteilung der Anlage unverändert bleibt.
Niedrigere Stückkosten können außerdem Margen erhöhen oder niedrigere Kundentarife ermöglichen. Anbieter können zwischen dem Behalten des Effizienzgewinns und dessen Einsatz zur Gewinnung zusätzlicher Nachfrage wählen.
Durchsatz steht jedoch für Kapazität, nicht für Verkäufe. Ein Anbieter verdient nur dann mehr, wenn Kunden diese zusätzliche Kapazität zu nachhaltigen Preisen nutzen.
Das Nachfrageprofil muss zur Hardware passen. Rubins stärkste Vorteile zeigen sich bei interaktiven Agent-Workloads mit langem Kontext, nicht bei jeder Form von KI-Berechnung.
Dadurch entsteht ein Allokationsproblem. Anbieter benötigen ausreichend agentischen Traffic, um die neuen Racks auszulasten, ohne Workloads umzuleiten, die anderswo wirtschaftlicher laufen.
Modelleffizienz kann zudem den Infrastrukturbedarf pro Aufgabe senken. Bessere Architekturen, kürzere Reasoning-Traces, verbessertes Caching und kleinere spezialisierte Modelle können den Tokenverbrauch reduzieren.
Der gegenteilige Effekt ist ebenso plausibel. Günstigere Tokens können Entwickler dazu veranlassen, länger laufende Agenten zu bauen, mehr Subagenten einzusetzen und zuvor unwirtschaftliche Aufgaben zu automatisieren.
Dies ist der bekannte Rebound-Effekt der Datenverarbeitung. Effizienz senkt die Kosten eines Vorgangs, anschließend wächst die Software, um die neue Kapazität zu verbrauchen.
NVIDIA setzt stark auf dieses Ergebnis. Die Darstellung des Unternehmens behandelt Rechenzentren als KI-Fabriken, deren Output Tokens statt konventioneller Computing-Dienste sind.
Die Metapher hat Grenzen. Tokens unterscheiden sich stark im Wert. Ein Token, das zu einer abgeschlossenen Coding-Aufgabe beiträgt, ist mehr wert als eines, das während einer gescheiterten Reasoning-Schleife erzeugt wurde.
Agent-Benchmarks haben weiterhin Schwierigkeiten, Infrastruktureffizienz mit erledigter Arbeit zu verknüpfen. AgentX hält das Modellverhalten bewusst außerhalb seines Umfangs und bewertet nicht die Ausgabequalität.
Ein vollständiger ökonomischer Test würde die Kosten pro erfolgreich erledigter Aufgabe messen, nicht nur die Kosten pro einer Million Tokens. Er würde Modellgenauigkeit, Wiederholungen, Tool-Ausfälle und den menschlichen Aufwand zur Überprüfung der Ergebnisse einbeziehen.
Latenz beeinflusst den Umsatz auch indirekt. Ein schnellerer Agent kann mehr Aufgaben abschließen und Nutzer stärker binden, aber nur, wenn die Anwendung und externe Tools mit vergleichbarer Geschwindigkeit reagieren.
Rubins gemeldete End-to-End-Latenzergebnisse sind ermutigend. Bei einem vergleichbaren Punkt der Ownership-Effizienz maß SemiAnalysis für Rubin etwa 20 Sekunden und für B200 oder B300 60 Sekunden.
Bei einem höheren Durchsatz-pro-Kosten-Punkt meldete das Unternehmen rund 20 Sekunden für Rubin und 120 Sekunden für die verglichenen Blackwell-Systeme.
Diese Messungen stärken Rubins Argumentation, weil sie höheren Durchsatz mit kürzeren Abschlusszeiten verbinden. Dennoch bleiben sie konfigurationsspezifische Benchmark-Ergebnisse.
Der Gewinn hängt auch von der Bereitstellungsgeschwindigkeit ab. Ein verspätetes Rack erzeugt keine Tokens, unabhängig von seiner prognostizierten Effizienz.
NVIDIA hat Rubin rund um das MGX-Rackformat der dritten Generation entwickelt, um Installation und Wartung zu erleichtern. Das Compute-Tray verwendet ein kabelloses, schlauchloses und lüfterloses internes Design.
Laut Unternehmen sank die Montage- und Wartungszeit eines Trays von fast zwei Stunden auf fünf Minuten. Die Praxiserfahrung muss zeigen, ob diese Designänderungen die Verfügbarkeit der Flotte verbessern.
Kühlung und Leistungsdichte bleiben wichtige Anforderungen an die Rechenzentrumsinfrastruktur. Rubin bündelt einen erheblichen elektrischen Bedarf in einem einzelnen Rack und erfordert kompatible Flüssigkeitskühlung sowie Stromverteilung.
Betreiber älterer Anlagen können den Vorteil nicht allein durch den Austausch von Servern realisieren. Möglicherweise benötigen sie neue elektrische Ausrüstung, Kühlmittelverteilung, Netzwerke und Betriebsverfahren.
Das macht Rubin besonders attraktiv für Hyperscaler, Modelllabore und spezialisierte Cloud-Anbieter, die bereits neue KI-Campusse bauen. Kleinere Käufer können effizienter über Cloud-Dienste darauf zugreifen.
„Je mehr Sie kaufen, desto mehr verdienen Sie“ ist eine einprägsame Zusammenfassung von NVIDIAs Verkaufsargument. Es ist kein ökonomisches Gesetz.
Die präzisere Fassung ist bedingt: Je mehr effiziente Kapazität ein Betreiber bereitstellt, auslastet, mit Strom versorgt und verfügbar hält, desto mehr Umsatz kann dieser feste Standort unterstützen.
Worauf Käufer nach dem NVIDIA Vera Rubin NVL72-Ergebnis achten sollten
Drei Signale werden bestimmen, ob Rubins früher Benchmark-Vorsprung zu einem nachhaltigen Produktionsvorteil wird.
Das erste Signal sind unabhängig reproduzierbare AgentX-Daten über verschiedene Serving-Engines hinweg. Rubin benötigt öffentliche Ergebnisse von TensorRT-LLM, SGLang und vLLM mit identischen Modellen und Service-Level-Zielen.
Dieser Vergleich wird zeigen, wie viel des aktuellen Vorsprungs von der Rubin-Hardware stammt und wie viel von einer ungewöhnlich vorteilhaften Software-Kombination.
Historische Ergebnisse sollten sichtbar bleiben, während sich Runtimes verbessern. Andernfalls können Käufer echte Hardwaregewinne nicht von Softwareänderungen unterscheiden, die auch älteren Systemen zugutekommen.
Eine Reproduktion durch Cloud-Anbieter würde die Argumentation zusätzlich stärken. Ihre Deployments umfassen Scheduling, Networking, Monitoring, Mandantenfähigkeit und Zuverlässigkeitsanforderungen, die in kontrollierten Testumgebungen fehlen.
Behält Rubin über Engines und Betreiber hinweg einen großen Vorsprung, wird der 67x-Endpunkt wie ein extremes Beispiel eines breiteren Wandels wirken. Verringert sich die Lücke deutlich, war die Softwareauswahl der dominierende Faktor.
Das zweite Signal ist die Leistung von MI455X und TPU7x auf derselben AgentX-Workload. Aktuelle Vergleiche vermischen Rubin mit Beschleunigern aus unterschiedlichen Produktzyklen oder mit verschiedenen Benchmark-Methodiken.
AMDs Helios-Plattform ist der direkteste Herausforderer, weil sie aktuelle GPUs, CPUs, Networking und Rack-Integration kombiniert. Ein vergleichbarer Test wird zeigen, ob NVIDIAs Software-Stack weiterhin sein entscheidender Vorteil bleibt.
TPU7x bietet einen anderen Wettbewerbsweg. Google kontrolliert den Beschleuniger, den Compiler, den Cloud-Dienst und Teile des Modell-Stacks und verfügt damit über eine eigene Form des Co-Designs.
Nähert sich einer der Wettbewerber Rubins Leistung pro Megawatt bei sinnvoller Interaktivität, gewinnen Käufer Verhandlungsspielraum und mehr architektonische Auswahlmöglichkeiten. Ein großer Rubin-Vorsprung würde NVIDIAs Kontrolle über agentische Infrastruktur festigen.
Das dritte Signal sind die Produktionsökonomien nach Berücksichtigung von Auslastung und Zuverlässigkeit. Käufer sollten nachhaltigen Goodput, Zeit bis zum ersten Token, End-to-End-Latenz, Leistungsaufnahme, Ausfallraten und Kosten pro abgeschlossener Aufgabe verfolgen.
Sie sollten außerdem Spitzeninteraktivität von dem Bereich trennen, den reale Kunden nutzen. Der Bereich von 60 bis 100 Tokens pro Sekunde könnte kommerziell wichtiger sein als ein beeindruckender Endpunkt.
DSX MaxLPS verdient eine ähnlich genaue Prüfung. Mehr GPUs innerhalb eines festen Strombudgets zu betreiben, ist nur wertvoll, wenn das System Standortgrenzen einhält, ohne Latenz oder Lebensdauer der Ausrüstung zu beeinträchtigen.
Ein verifizierter Dichtegewinn von 40 Prozent würde Rubins Hardwarevorteil vervielfachen. Ein kleineres Ergebnis im Feld würde die prognostizierte Verbesserung des Gewinns pro Gigawatt verringern.
Entwickler sollten sich dafür interessieren, weil Infrastrukturökonomien letztlich das Produktdesign prägen. Niedrigere Kosten für Agent-Serving können längere Sitzungen, mehr Retrieval und mehr parallele Subagents ermöglichen.
Wissensarbeiter werden die Veränderung indirekt spüren. Schnellere und günstigere Agents können größere Projekthistorien verarbeiten, doch wertvolle Ergebnisse hängen weiterhin von vertrauenswürdigem Quellenmaterial ab.
Eine gut gepflegte persönliche Wissensbasis kann diesen Kontext liefern, ohne mehr generierte Tokens als Ersatz für bessere Belege zu behandeln.
Das frühe Urteil ist klar, aber begrenzt. NVIDIA Vera Rubin NVL72 hat einen erheblichen Vorsprung bei agentischer Inferenz erzielt, und Jensen Huangs frühere Prognose scheint konservativ.
Die 67x-Zahl liegt am Rand der Kurve, nicht bei ihrem Durchschnitt. Der praktische Gewinn liegt in üblichen Betriebsbereichen näher beim Zwei- oder Dreifachen, mit größeren Vorteilen unter strengeren Interaktivitätszielen.
Das reicht dennoch aus, um jeden großen Anbieter von KI-Infrastruktur unter Druck zu setzen. Die nächste Frage ist, ob Rubin diese Ökonomie bewahren kann, wenn Benchmarks zu Deployments werden und Tokens zu abgeschlossener Arbeit werden müssen.
