OpenAI SemiAnalysis Lens: Vera Rubin NVL72 schlägt GB200, aber der TCO-Fall ist enger

NVIDIAs Vera Rubin NVL72 hat seine ersten gemessenen Siliziumergebnisse vorgelegt und beansprucht bei gleicher Interaktivität den zehnfachen GB200-NVL72-Durchsatz pro Megawatt. Die Verbindung zwischen OpenAI und SemiAnalysis entsteht über Triton, dessen Rubin-Support die Architektur für weitverbreitete KI-Software zugänglich macht.

Die Schlagzeile ist überzeugend, doch sie vergleicht Rubin mit einem GB200-Software-Baseline aus Anfang 2025. SemiAnalysis ermittelte gegenüber Blackwell-Ergebnissen vom Juli 2026 einen geringeren Vorsprung, auch wenn Rubin über den getesteten Interaktivitätsbereich hinweg weiter führte.

Diese Unterscheidung definiert den eigentlichen Wettbewerb. Rubin ist nicht einfach eine schnellere GPU, die eine ältere GPU ersetzt. Es handelt sich um ein Rack-Scale-System, das reaktionsschnelle Inferenz aufrechterhalten soll, wenn Modellgröße, Speicherverkehr und Token-Nachfrage gleichzeitig steigen.

Das Ergebnis setzt Betreiber von GB200, konkurrierende Beschleunigeranbieter und Entwickler unter Druck, die benutzerdefinierte Kernel pflegen. Zugleich bleibt eine wichtige Verifikationslücke: Der erste Test nutzte ein Rack als Engineering Sample, ein älteres Reasoning-Modell und eine Single-Turn-Workload.

Rubins erstes Ergebnis verändert den NVL72-Vergleich

Rubins früher Vorsprung wirkt real, doch der Faktor zehn ist ein Best-Case-Vergleich und kein universelles Leistungsverhältnis.

CoreWeave veröffentlichte am 21. Juli 2026 den ersten gemessenen Silizium-Benchmark für Vera Rubin NVL72. Die Ingenieure führten DeepSeek R1 auf Rubin und GB200 NVL72 aus, jeweils mit denselben wesentlichen Inferenzoptimierungen.

Der Test maß den Output-Token-Durchsatz pro Megawatt im Verhältnis zur Interaktivität, ausgedrückt in Tokens pro Sekunde für jeden Nutzer. Das ist relevant, weil ein Inferenzdienst Gesamtkapazität und akzeptable Reaktionsgeschwindigkeit ausbalancieren muss.

Bei gleicher Interaktivität zeigten die gemessenen Siliziumergebnisse bis zu zehnmal mehr Output-Token-Durchsatz pro Megawatt. Der Vergleich nutzte eine GB200-NVL72-Basislinie aus dem Jahr 2025.

CoreWeave zufolge verwendeten beide Systeme NVFP4-Präzision, spekulatives Decoding, breite Expert Parallelism sowie entkoppeltes Prefill und Decode. TensorRT-LLM und NVIDIA Dynamo stellten die Serving-Software bereit.

NVFP4 ist NVIDIAs Vier-Bit-Zahlenformat zur Verringerung von Modellspeicher und Rechenaufwand. Spekulatives Decoding erzeugt Kandidaten-Token vor der endgültigen Verifizierung und erhöht die Ausgabegeschwindigkeit, wenn seine Vorhersagen zutreffen.

Entkoppeltes Serving trennt Prefill und Decode auf verschiedene GPU-Gruppen. Prefill verarbeitet den Prompt, während Decode die Antwort Token für Token generiert.

Diese Optimierungen sind wichtig, weil Benchmark-Ergebnisse oft ebenso stark die Softwarequalität wie das Silizium messen. Ein älterer Kernel, Scheduler oder Parallelisierungsansatz kann einen großen Teil der GPU-Kapazität ungenutzt lassen.

SemiAnalysis passte seine eigenen InferenceX-Daten an die Abrechnungsmethode von CoreWeave an. Der ursprüngliche Benchmark zählte den Stromverbrauch für Prefill- und Decode-GPUs, berichtete jedoch nur Output-Token.

Gegenüber GB300-NVL72-Ergebnissen vom Juli 2026 lieferte Rubin bis 100 Tokens pro Sekunde und Nutzer nahezu den doppelten Durchsatz. Sein Vorsprung stieg bei rund 200 Tokens pro Sekunde auf etwa das Vierfache.

Bei 300 Tokens pro Sekunde erreichte das berichtete Verhältnis den Faktor 5,4. SemiAnalysis merkte jedoch an, dass GB300 am Rand seiner tragfähigen Leistungskurve arbeitete.

GB200 konnte dieses Interaktivitätsniveau in der getesteten Konfiguration nicht erreichen. Rubin setzte den Test bis 350 Tokens pro Sekunde fort und erzeugte dort 70.703 Output-Token pro Sekunde und Megawatt.

Das widerlegt die Aussage von CoreWeave nicht. Frühes Rubin hält eindeutig eine höhere Interaktivität aufrecht als die gemessenen Blackwell-Systeme. Es verändert jedoch, was Käufer aus der Schlagzeile ableiten sollten.

Ein Faktor von zehn beschreibt eine einzelne Workload, einen Betriebspunkt, eine Software-Basislinie und eine Abrechnungsmethode. Das bedeutet nicht, dass jede Rubin-Bereitstellung sofort zehn GB200-Racks ersetzt.

Die stärkere Schlussfolgerung ist enger gefasst und nützlicher. Rubin hält seine Effizienz aufrecht, wenn Serving zu kleineren Batches und schnelleren individuellen Antworten übergeht – dort, wo Blackwells Durchsatz stark einbricht.

Dieses Verhalten betrifft Coding Agents, Suchsysteme und Sicherheitsanwendungen unmittelbar. Diese Dienste erzeugen viele sequenzielle Modellaufrufe, weshalb sich Latenz nur schwer durch große Batches kaschieren lässt.

Warum Leistung pro Megawatt jetzt wichtiger sein kann als Peak-FLOPS

Die verfügbare Stromkapazität ist zu einer praktischen Obergrenze geworden, weshalb nutzbare Tokens pro Megawatt wichtiger sein können als theoretischer Rechendurchsatz.

Die Peak-FLOPS-Zahl eines Beschleunigers misst seine maximalen Gleitkommaoperationen unter bestimmten Bedingungen. Sie beschreibt nicht, wie effizient ein vollständiges Rack ein Reasoning-Modell bedient.

Inferenz bewegt Gewichte, Aktivierungen und KV-Cache-Daten zwischen Speicher- und Recheneinheiten. Der KV-Cache speichert Attention-Informationen aus früheren Tokens, damit das Modell nicht die gesamte Sequenz neu berechnen muss.

Längere Kontexte vergrößern diesen Cache. Mixture-of-Experts-Modelle senden Tokens zudem zwischen spezialisierten Teilnetzwerken hin und her und erzeugen damit Kommunikationsverkehr über GPUs hinweg.

Rubin adressiert diese Einschränkungen als vollständiges NVL72-System. Das Rack kombiniert 72 Rubin-GPUs, 36 Vera-CPUs, ConnectX-9-Netzwerk, BlueField-4-Prozessoren und NVLink-6-Switches.

NVIDIA gibt für das Rack insgesamt 20,7 Terabyte HBM4-Speicher an. Zudem spezifiziert das Unternehmen 260 Terabyte pro Sekunde aggregierte NVLink-6-Switch-Bandbreite.

Jede GPU erhält 3,6 Terabyte pro Sekunde All-to-All-Scale-up-Bandbreite. Scale-up-Networking verbindet Beschleuniger innerhalb einer großen Rechendomäne, sodass sie sich wie ein einheitliches Gerät verhalten können.

Rubin greift die Inferenz-Effizienz daher auf mehreren Ebenen an. Schnellere Tensoroperationen verarbeiten Matrixberechnungen, HBM4 liefert Gewichte und NVLink bewegt Tokens zwischen Experten.

Vera-CPUs steuern Datenbewegungen und CPU-intensive Agent-Aufgaben. Dazu können Tool-Aufrufe, Code-Kompilierung, Orchestrierung und isolierte Ausführung gehören.

NVIDIAs NVL72-Spezifikationen nennen 3.600 Petaflops Rack-Level-NVFP4-Inferenzleistung. Das Unternehmen beansprucht zudem ein Zehntel der Token-Kosten im Vergleich zu GB200 NVL72.

Diese Angaben bleiben arbeitslastabhängige Unternehmensbehauptungen. Dennoch erklärt die Rack-Architektur, warum Rubins Vorteil mit zunehmender Interaktivität wächst.

Große Batches helfen einer GPU, ausgelastet zu bleiben, weil viele Nutzer denselben Gewichtsladevorgang teilen. Schneller interaktiver Service reduziert die Batch-Möglichkeiten und erhöht den Druck auf Speicherbandbreite und Scheduling.

Rubins HBM4-Bandbreite von 22 Terabyte pro Sekunde je GPU verschafft ihm unter diesen Bedingungen mehr Spielraum. SemiAnalysis schätzt sie auf das 2,8-Fache der globalen Speicherbandbreite von Blackwell Ultra.

Höhere Bandbreite senkt die Speicherlatenz nicht automatisch. Sie bewegt mehr Daten pro Sekunde, doch ein einzelner Zugriff kann weiterhin ähnlich lange dauern.

Rubins größerer Vorteil bei hoher Interaktivität spiegelt daher mehrere zusammenwirkende Mechanismen wider. Keine einzelne Peak-Spezifikation erklärt ihn vollständig.

Die Stromkennzahl umfasst auch Infrastrukturentscheidungen. Kühlung, Netzwerk, Host-Prozessoren, Speicher und Umwandlungsverluste verbrauchen sämtlich Strom über das GPU-Paket hinaus.

NVIDIA entwickelte Rubin für Flüssigkühlmittel mit einer Eintrittstemperatur von 45 Grad Celsius. In kompatiblen Anlagen unterstützt diese Temperatur Trockenkühlung ohne traditionelle Chiller.

Das Unternehmen erklärt, sein geschlossener Kreislauf könne Wasserverbrauch und Kühlungsaufwand senken. Diese Vorteile hängen vom Anlagendesign ab und sollten nicht für jedes bestehende Rechenzentrum vorausgesetzt werden.

SemiAnalysis verwendete für alle flüssigkeitsgekühlten Systeme dieselbe Annahme zur Power Usage Effectiveness. Diese konservative Wahl verhindert, dass Rubins Anlagendesign den Siliziumvergleich aufbläht.

Das Ergebnis spricht weiterhin für Rubin. Wichtiger ist jedoch, dass es zeigt, warum Rack-Architektur untrennbar mit der Wirtschaftlichkeit von Beschleunigern verbunden ist.

Ein Käufer kann Rubin nicht bewerten, indem er allein GPU-FLOPS vergleicht. Die relevante Einheit ist das Serving-System, das eine erforderliche Reaktionsgeschwindigkeit innerhalb eines festen Strombudgets liefert.

OpenAI SemiAnalysis Software Support verschafft Rubin eine frühere Startlinie

Rubin kann wichtige Blackwell-Kernel wiederverwenden und verkürzt damit die Bereitstellungsarbeit, bevor Entwickler mit architekturspezifischem Tuning beginnen.

Der OpenAI-SemiAnalysis-Aspekt ist keine OpenAI-Hardwarepartnerschaft. Er bezieht sich darauf, dass Rubin-Support in OpenAI Triton neben PyTorch, vLLM, CUDA und anderen öffentlichen Projekten auftaucht.

Triton ist eine Open-Source-Sprache und ein Compiler zum Schreiben von GPU-Kernels mit Python-ähnlicher Syntax. Ein Kernel ist ein spezialisiertes Programm, das eine Rechenoperation auf der GPU ausführt.

OpenAI führte Triton programming ein, um die Entwicklung leistungsfähiger Kernel zugänglicher zu machen als Low-Level-CUDA-Code. PyTorch-Compiler und Inferenzprojekte setzen inzwischen bei vielen Operationen auf von Triton generierte Kernel.

NVIDIA hat eine CUDA-13.4-Developer-Preview mit Rubin-Support und aktualisierten PTX-Instruktionen veröffentlicht. PTX ist NVIDIAs Zwischenbefehlssprache zur Beschreibung von GPU-Operationen.

Die CUDA-Preview ermöglicht Entwicklern, neue Rubin-Fähigkeiten zu prüfen und mit der Portierung von Software zu beginnen. NVIDIA warnt, dass diese Preview Pre-Release-Software ist und sich nicht für Produktions-Benchmarking eignet.

SemiAnalysis berichtet, dass Rubin-Änderungen auch die Repositories von PyTorch, vLLM und OpenAI Triton erreicht haben. Diese öffentliche Sichtbarkeit gibt Framework-Entwicklern Zeit zur Anpassung, bevor die breite Cloud-Verfügbarkeit beginnt.

Rubins Streaming Multiprocessor nutzt das Ziel SM107. Noch wichtiger ist, dass er wichtige Blackwell-SM100-Familien-Kernel über Bibliotheken wie CUTLASS, DeepGEMM und FlashMLA hinweg ausführen kann.

Blackwell erbte diesen Komfort nicht in gleicher Weise von Hopper. Sein Tensor-Core-Programmiermodell erforderte umfangreiche Kernel-Neuschreibungen, bevor Entwickler sich dem Potenzial der Hardware nähern konnten.

Rubin bewahrt mehr dieser Investition. Teams können mit funktionsfähigen Blackwell-Kernels beginnen, früher bereitstellen und anschließend die wertvollsten Operationen optimieren.

Kompatibilität sollte nicht mit maximaler Leistung verwechselt werden. SemiAnalysis zufolge bleibt architekturspezifisches Tuning erforderlich, um die praktische Leistungsgrenze zu erreichen.

Rubin erhöht den Shared Memory von Blackwells 228 KiB auf einen optionalen 328-KiB-Modus. Auch Tensor Memory wächst auf 256 KiB und gibt Kernels mehr Platz für Akkumulatoren und Skalierungsinformationen.

Die Architektur ergänzt Inline-Updates für Tensor Memory Accelerator Deskriptoren. TMA ist ein Hardwaremechanismus, der mehrdimensionale Daten bewegt, ohne dass normale Ausführungseinheiten jeden Transfer steuern müssen.

In einer Mixture-of-Experts-Schicht besitzt jeder Experte eine separate Gewichtsmatrix. Blackwell muss möglicherweise einen Deskriptor neu schreiben und synchronisieren, wenn sich der aktive Experte ändert.

Rubin kann die neue Adresse mit der Transferinstruktion übergeben. Ein Deskriptor kann dann mehrere Experten ohne zwischenzeitliches Umschreiben des Speichers bedienen.

Das reduziert den Dispatch-Overhead beim Decoding mit kleinen Batches. Es zeigt auch, warum echte Inferenzgewinne aus kleinen Verbesserungen bei der Datenbewegung entstehen und nicht nur aus größeren Matrix-Engines.

Rubin verdoppelt laut NVIDIAs Architekturangaben den FP8- und FP4-Tensor-Core-Durchsatz gegenüber Blackwell. Zudem ermöglicht es eine feinere Synchronisierung zwischen abhängigen Thread-Blöcken.

Diese Funktionen helfen Entwicklern, größere fusionierte Kernel zu erstellen. Fusion kombiniert mehrere Operationen und reduziert wiederholte Starts sowie unnötige Datenbewegungen durch den Speicher.

Der Softwarevorteil reicht über die Einsatzbereitschaft zum Marktstart hinaus. Kompatible Tools ermöglichen es mehr Entwicklern, das Verhalten von Rubin zu untersuchen, Fehler zu melden und gängige Modellarchitekturen zu optimieren.

Die öffentliche Unterstützung befindet sich jedoch noch in einem frühen Stadium. Die Preview-Beschränkungen von CUDA zeigen, dass verfügbarer Code nicht mit einem ausgereiften Produktions-Stack gleichzusetzen ist.

Die Integration von PyTorch und vLLM kann grundlegende Funktionalität schaffen, während erhebliche Optimierungen noch ausstehen. Betreiber sollten zwischen „läuft auf Rubin“ und „nutzt Rubin effizient“ unterscheiden.

Das historische Muster spricht für diese Vorsicht. Die GB200-Inferenz verbesserte sich im ersten Jahr, als Kernel, Scheduler und Rezepte für verteiltes Serving ausreiften.

Rubin startet aus einer stärkeren Kompatibilitätsposition. Sein möglicher Vorsprung wird dennoch davon abhängen, ob die Maintainer der Frameworks neue Instruktionen in verlässliche Verbesserungen auf Modellebene überführen.

Der 3-Bit-LUT-Tensor-Core zielt auf den Speicherengpass

Rubins interessanteste Inferenzfunktion komprimiert Gewichte innerhalb des Tensor Core und reduziert so den Speicherverkehr ohne separaten Dequantisierungsschritt.

Rubin ergänzt seine Matrix-Multiply-Accumulate-Instruktion um einen Lookup-Table-Modus für den B-Operanden. SemiAnalysis beschreibt ihn als NVIDIAs erstes Tensor-Core-Format mit einem internen, nicht gleichmäßig verteilten Codebuch.

In diesem Modus wird jedes gespeicherte Gewicht zu einem Drei-Bit-Index. Dieser Index wählt einen von acht achtbitigen E4M3-Werten aus einer Lookup-Tabelle aus, die über einen Gewichtsblock hinweg geteilt wird.

Der Tensor Core rekonstruiert den ausgewählten Wert innerhalb der Matrixoperation. Die Software muss vor der Multiplikation keine separate dekomprimierte Gewichtsmatrix erzeugen.

Einschließlich des geteilten Codebuchs berechnet SemiAnalysis einen Speicherbedarf von 3,125 Bit pro Gewicht. Das Codebuch umfasst 64 Bit, die sich 512 Gewichte teilen.

Das Design unterscheidet sich von den Formaten NVFP4 und MXFP. Diese Formate verwenden Blockskalierung und wenden einen einheitlichen Skalierungsfaktor auf eine Gruppe niedrigpräziser Werte an.

Eine Lookup-Tabelle kann ihre acht Werte ungleichmäßig platzieren. Sie kann Einträge in der Nähe dichter Gewichtskluster konzentrieren oder asymmetrische positive und negative Verteilungen abbilden.

Diese Flexibilität kann bei einer ähnlichen Bitzahl mehr Informationen bewahren als einheitliches Runden. Sie garantiert jedoch keine bessere Modellqualität.

Ein Codebuch deckt 512 Gewichte ab, während NVFP4 seinen Skalierungsfaktor über deutlich kleinere Gruppen anpassen kann. Die Ergebnisse werden von Kalibrierungsdaten, der Anpassung des Codebuchs und der Sensitivität des Modells abhängen.

Einige Schichten benötigen möglicherweise zudem höhere Präzision. Eine aggressive Quantisierungsstrategie kann Speicher sparen, zugleich aber die Genauigkeit beim Schlussfolgern beeinträchtigen oder die Ausgabe destabilisieren.

Der Hardwaremechanismus adressiert dennoch eine zentrale Einschränkung der Inferenz. Beim Dekodieren mit kleinen Batches warten GPUs häufig darauf, dass Modellgewichte aus HBM eintreffen.

Eine geringere gespeicherte Größe pro Gewicht ermöglicht es dem Speicher, mehr Gewichte pro Sekunde bereitzustellen. Außerdem sinkt der Energieaufwand, um diese Bits durch das System zu bewegen.

SemiAnalysis nutzte ein hypothetisches Modell mit 2,8 Billionen Parametern, um den Kapazitätseffekt zu veranschaulichen. Die Berechnung veranschlagte die reinen Gewichte mit Rubins Format auf rund 1,09 Terabyte.

Der Vergleich schloss KV-Cache, Aktivierungen, Replikation und Serving-Overhead aus. Er zeigt daher die Gewichtsspeicherung, nicht den gesamten Speicherbedarf eines Deployments.

Bei 288 Gigabyte HBM4 pro Rubin-GPU würden die komprimierten Gewichte ungefähr vier Packages erfordern. Eine alternative niedrigpräzise Darstellung benötigte im Beispiel etwa sechs.

Weniger beteiligte GPUs können Kommunikation und Replikation verringern. Sie können außerdem mehr Speicher für längere Kontexte, größere Batches oder den KV-Cache freigeben.

Der LUT-Modus unterliegt jedoch Implementierungsbeschränkungen. SemiAnalysis weist darauf hin, dass er die B-Matrix nicht transponieren kann, was die Operationen einschränkt, die ihn direkt nutzen können.

Der öffentliche Benchmark scheint diese Funktion ebenfalls nicht zu verwenden. Rubins anfänglicher Vorsprung kann daher nicht der Drei-Bit-Lookup-Table-Inferenz zugeschrieben werden.

Das ist zugleich ermutigend und unsicher. Rubin verfügt über zusätzliche Siliziumfähigkeiten, die künftige Software nutzen kann, doch ihre Genauigkeit und ihr Produktionswert bleiben unbestätigt.

NVIDIA hat außerdem Laufzeit-2:4-Aktivierungssparsity ergänzt. Diese Methode behält zwei Werte in jeder Vierergruppe bei und überspringt die anderen beiden bei unterstützten Operationen.

Anders als frühere Gewichtssparsity erfordert Laufzeit-Aktivierungssparsity kein dauerhaftes Pruning und erneutes Training des Modells. Die Hardware kann Zwischenwerte komprimieren, während das Modell läuft.

NVIDIA hat jedoch keine Genauigkeitsnachweise dafür veröffentlicht, dass vor späteren Operationen die Hälfte ausgewählter Aktivierungswerte verworfen wird. Auch das CoreWeave-Ergebnis scheint diese Funktion nicht zu nutzen.

Diese ungenutzten Fähigkeiten bilden Rubins Optimierungsspielraum. Sie sollten nicht als garantierte zukünftige Gewinne in aktuelle TCO-Berechnungen einfließen.

Käufer sollten neben dem Durchsatz Tests der Modellqualität verlangen. Ein Format mit weniger Bits senkt Serving-Kosten nur, wenn das resultierende Modell dieselben Ziele bei Genauigkeit und Zuverlässigkeit erfüllt.

Rubin gewinnt den TCO-Test, doch die Ausgangsbasis verändert den Vorsprung

Rubin wirkt pro ausgeliefertem Token günstiger, obwohl die Betriebskosten höher sind; gegenüber vollständig optimierten Blackwell-Systemen schrumpft sein Vorteil jedoch.

Die Gesamtbetriebskosten umfassen Hardware, Strom, Infrastruktur, Netzwerk, Wartung und Betriebsausgaben. Sie bieten einen umfassenderen Blick als die Leistung pro Watt allein.

SemiAnalysis wandte sein Modell für Betreiberkosten auf den normierten Output-Durchsatz an. Die Analyse verzichtete auf Cloud-Mietpreise, die Knappheit, Vertragsbedingungen und Margen der Anbieter enthalten können.

Die Analyse fand Rubin bei jedem gemessenen Interaktivitätsniveau gegenüber den Ergebnissen von GB200 und GB300 aus Juli 2026 pro Output-Token günstiger. Der Vorteil wuchs mit steigender Antwortgeschwindigkeit.

Gegenüber der aktuellen GB200-Basis war Rubin bis zu 100 Token pro Sekunde und Nutzer etwa 1,5-mal günstiger. Der relative Vorteil erreichte bei rund 200 bis 250 Token ungefähr das Dreifache.

Der Vergleich von Rubin mit der GB200-Softwarebasis von 2025 ergab einen größeren Abstand. Rubin erreichte bei rund 150 Token pro Sekunde und Nutzer einen Höchstwert von nahezu dem Achtfachen.

Diese alte Ausgangsbasis erklärt einen großen Teil des Unterschieds zwischen NVIDIAs Marketing-Schlagzeile und einem praxisnahen Kaufvergleich. Ein optimierter GB200 von 2026 ist leistungsfähiger als sein früher Einsatzstand.

SemiAnalysis schätzt zudem, dass Rubin höhere Betriebskosten pro GPU verursacht als GB200 oder GB300. Sein Durchsatzgewinn muss diese höhere Systemlast ausgleichen.

Im untersuchten Workload gelingt das, insbesondere bei anspruchsvollen Interaktivitätszielen. Bei langsameren Antwortgeschwindigkeiten werden die wirtschaftlichen Vorteile weniger eindeutig, da Blackwell größere Batches effektiv nutzen kann.

Damit entsteht eine workloadspezifische Kaufentscheidung.

Für hochinteraktive Inferenz

• Rubin hält Antwortgeschwindigkeiten aufrecht, die GB200 in der getesteten Konfiguration nicht erreicht.

• Seine Speicherbandbreite und sein Rack-Fabric werden wertvoller, wenn die Batch-Größe sinkt.

• Coding Agents und Echtzeit-Suchdienste passen zu diesem Profil.

Für durchsatzorientierte Inferenz

• Ausgereifte Blackwell-Software kann Rubins relativen Gewinn verringern.

• Bestehende Infrastruktur und reservierte Kapazität können einen theoretischen Effizienzvorteil überwiegen.

• Migrationskosten sollten in das TCO-Modell des Betreibers einfließen.

Für Modelle mit langen Kontexten

• Rubins größerer Speicherpool gibt Betreibern mehr Platz für Gewichte und KV-Cache.

• Der anfängliche Single-Turn-Benchmark misst diesen Vorteil nicht direkt.

• Multi-Turn-Agent-Tests werden ein repräsentativeres Signal liefern.

Der Benchmark nutzte DeepSeek R1 671B mit einem Input von 8.000 Token und einem Output von 1.000 Token. Dieses Modell und diese Sequenzform repräsentieren nicht jeden Produktions-Workload des Jahres 2026.

SemiAnalysis argumentiert, dass neuere Modelle mit mehreren Billionen Parametern Rubins Kapazität und Bandbreite bevorzugen sollten. Diese Aussage bleibt eine technische Erwartung, bis Vergleichsergebnisse vorliegen.

CoreWeave führte den Test zudem auf einem Dell-Rack als Engineering Sample ohne Scale-out-Fabric durch. Scale-out verbindet mehrere Racks, während die interne NVLink-Backplane die Scale-up-Konnektivität bereitstellt.

Der erfolgreiche Test stützt den internen Expert-Parallel-Betrieb des Racks. Er belegt weder Leistung noch Zuverlässigkeit oder Effizienz in einem großen Deployment über mehrere Racks hinweg.

Der Wettbewerb fügt eine weitere Einschränkung hinzu. AMDs MI455X bietet 432 Gigabyte HBM4 pro Beschleuniger, verglichen mit 288 Gigabyte bei Rubin.

Über 72 Beschleuniger hinweg stellt AMDs Helios-Design 31,1 Terabyte Speicher bereit. Rubin liefert 20,7 Terabyte in seinem NVL72-Rack.

AMDs Kapazitätsvorteil kann bei großen Modellen und langen Kontexten relevant sein. NVIDIA hält mit seinem etablierten Software-Ökosystem, der NVLink-Fabric und früheren Betriebserfahrungen auf Rack-Ebene dagegen.

Googles TPU-Systeme bieten einen weiteren integrierten Ansatz. Sie kombinieren kundenspezifische Beschleuniger, Interconnects, Compiler und Cloud-Dienste unter einem Betreiber.

Der TCO-Wettbewerb beschränkt sich daher nicht auf Rubin und GB200. Käufer müssen vollständige Serving-Rezepte mit demselben Modell, Genauigkeitsziel, derselben Latenz, Kontextlänge und Strombilanz vergleichen.

Rubin hält derzeit das stärkste frühe öffentliche Ergebnis. Die Evidenz belegt noch kein festes Kostenverhältnis für Produktionsinferenz.

Was die nächsten Benchmarks beweisen müssen

Drei Signale werden bestimmen, ob Rubins frühes Engineering-Ergebnis zu einem dauerhaften Produktionsvorteil wird.

Das erste Signal ist NVIDIAs angekündigte InferenceX-Einreichung im dritten Quartal 2026. SemiAnalysis zufolge hat NVIDIA zugesagt, über diesen Benchmark unabhängig überprüfbare Rubin-Zahlen bereitzustellen.

Eine glaubwürdige Einreichung sollte aktuelle Modelle unter dokumentierten Serving-Konfigurationen testen. Sie sollte Interaktivität, Output-Durchsatz, Leistungsgrenzen und Optimierungseinstellungen gemeinsam ausweisen.

Ergebnisse gegenüber GB200- und GB300-Systemen aus Juli 2026 würden den aktuellen Vergleich stärken. Eine Wiederholung der älteren GB200-Basis würde die zentrale methodische Sorge ungelöst lassen.

Das zweite Signal ist ein Multi-Turn-Agent-Workload. Single-Turn-Inferenz kann wiederholte Tool-Aufrufe, wachsende KV-Caches und sich während einer Agent-Session ändernde Prompt-Längen nicht nachbilden.

SemiAnalysis entwickelt gemeinsam mit Infrastruktur- und Open-Source-Serving-Mitwirkenden ein AgentX-Szenario. Seine Rubin-Analyse identifiziert agentische Arbeit mit langen Kontexten als wahrscheinliche architektonische Stärke.

Rubin sollte seinen Vorsprung ausbauen, wenn Speicherkapazität und Bandbreite dominieren. Bleibt der Vorteil unverändert oder schrumpft er, wird das Argument für lange Kontexte des Racks weniger überzeugend.

Das dritte Signal ist ausgereifte öffentliche Software. Entwickler sollten Produktiv-Releases bei CUDA, PyTorch, vLLM, Triton, TensorRT-LLM und Dynamo verfolgen.

Funktionale Kompatibilität wird vor optimierter Leistung verfügbar sein. Die entscheidenden Belege werden von stabilen Kerneln kommen, die Rubin-spezifische Speicherbewegungen, Synchronisierung und niedrigpräzise Funktionen nutzen.

Die Drei-Bit-LUT-Inferenz verdient besondere Prüfung. Veröffentlichte Tests müssen Genauigkeit, Kalibrierungsmethoden, betroffene Schichten und End-to-End-Durchsatz gegenüber NVFP4 ausweisen.

Aktivierungssparsity benötigt dieselbe Behandlung. Höhere Rechenraten bedeuten wenig, wenn Qualitätsverluste Betreiber dazu zwingen, ein größeres Modell zu verwenden oder fehlgeschlagene Anfragen zu wiederholen.

Feynman wirft zudem eine längerfristige Softwarefrage auf. NVIDIA hat seine nächste Architektur als SM140 bezeichnet, während Rubin SM107 nutzt.

SemiAnalysis erwartet, dass Feynman umfassendere Kernel-Neuschreibungen erfordern wird, ähnlich dem schwierigen Übergang von Hopper zu Blackwell. Rubins Kompatibilitätsvorteil könnte daher nur eine Generation lang bestehen.

Für Infrastrukturkäufer lautet die unmittelbare Entscheidung nicht, ob Rubin bessere Spezifikationen hat. Das hat es.

Die schwierigere Frage lautet, ob ein konkreter Workload ausreichend profitiert, um Änderungen am Deployment zu rechtfertigen. Betreiber benötigen Tests, die auf ihrem Modell, ihrer Kontextverteilung, ihrem Antwortziel und ihrer vorhandenen Stromkapazität basieren.

Für Entwickler ist es jetzt sinnvoll, Kernel-Support und Benchmark-Rezepte zu verfolgen. Frühes Profiling kann zeigen, ob eine Anwendung durch Rechenleistung, HBM-Traffic, Netzwerk oder Scheduling begrenzt wird.

Für Teams, die KI-Produkte entwickeln, zählen Ergebnisse auf Nutzerebene. Schnellere Token sind nur dann relevant, wenn sie die Zeit bis zum Abschluss einer Aufgabe verkürzen, die Zuverlässigkeit von Agenten erhöhen oder mehr parallele Kunden unterstützen.

Der OpenAI-SemiAnalysis-Thread verbindet letztlich drei Ebenen: offene Kernel-Tools, unabhängige Performance-Analysen und NVIDIAs Hardware im Rack-Maßstab. Keine dieser Ebenen kann Rubin allein validieren.

Wird Rubin seinen Vorsprung bei modernen Modellen, mehrstufigen Agenten und unabhängig reproduzierbaren Tests behaupten? Diese Evidenz – und nicht ein einzelnes Schlagzeilen-Multiple – sollte über die nächste Verpflichtung für Inferenzinfrastruktur entscheiden.