NVIDIA Rubin CPX: Die neue GPU-Klasse für Million-Token-Kontext

NVIDIA Rubin CPX: Warum eine neue GPU-Klasse für Million-Token-Kontexte?

Im September 2026 hat NVIDIA mit Rubin CPX eine Beschleunigerkarte vorgestellt, die es in dieser Form vorher nicht gab: keine Trainings-GPU, keine klassische Inferenz-GPU, sondern eine Karte, die ausschließlich für das Einlesen extrem langer Prompts gebaut ist. Der Anlass ist nicht abstrakt. Codeassistenten, die eine komplette Repository im Kontext halten sollen, Rechtsabteilungen, die hunderte Vertragsseiten gleichzeitig einlesen, und agentische Systeme, die über tausende Arbeitsschritte hinweg ein Gedächtnis brauchen, drücken Kontextfenster in Größenordnungen, für die bisherige GPU-Architekturen schlicht nicht ausgelegt waren.

Der technische Grund dafür ist ein Detail der LLM-Inferenz, das lange als reine Implementierungsfrage galt und jetzt zur Hardware-Entscheidung wird: der Unterschied zwischen der Prefill-Phase (das einmalige Verarbeiten des gesamten Eingabe-Prompts) und der Decode-Phase (die sequenzielle Erzeugung der Antwort, Token für Token). Beide Phasen stellen fundamental unterschiedliche Anforderungen an Rechenleistung und Speicher – und genau diese Trennung strukturiert den Rest dieses Artikels.

Für Entscheider im deutschen Mittelstand klingt das zunächst nach reiner Hyperscaler-Technik, die mit der eigenen IT-Landschaft wenig zu tun hat. Das stimmt auf den ersten Blick auch: Ein NVL72-Rack kauft niemand für eine 200-Personen-Firma. Trotzdem ist die Ankündigung relevant, weil sie zeigt, wohin sich die Inferenz-Landschaft insgesamt bewegt, welche Anbieter in Zukunft welche Kontextgrößen zu welchen Preisen anbieten können – und weil sie hilft, die eigene Bedarfsermittlung nüchterner zu führen, statt sich von Schlagzeilen über Millionen-Token-Modelle zu Fehlinvestitionen treiben zu lassen.

Bereits heute zeigt sich die Prefill/Decode-Trennung indirekt in der Preisgestaltung kommerzieller Inferenz-APIs: Eingabe-Token werden pro Anfrage in der Regel deutlich günstiger abgerechnet als Ausgabe-Token, weil die zugrundeliegende Hardware unterschiedlich stark ausgelastet wird. Mit dedizierter Hardware für beide Phasen dürfte sich dieser Preisunterschied in den kommenden Jahren eher vergrößern als einebnen – ein Aspekt, der bei der Kalkulation eigener oder eingekaufter Million-Token-Anwendungen von Anfang an mit eingeplant werden sollte.

Rubin CPX im Detail: 128 GB GDDR7 statt HBM4

Die zentrale Designentscheidung bei Rubin CPX fällt beim Speicher auf, noch bevor man über Rechenleistung spricht: NVIDIA verbaut 128 GB GDDR7-Speicher – nicht das teurere und bandbreitenstärkere HBM4, das in den regulären Rubin-GPUs zum Einsatz kommt. Das wirkt auf den ersten Blick wie ein Sparmodell, ist aber eine bewusste Architekturentscheidung, die sich aus der Natur der Prefill-Phase ergibt (dazu im nächsten Abschnitt mehr).

Die Kernspezifikationen von Rubin CPX laut NVIDIA-Newsroom:

Spezifikation	Rubin CPX	Einordnung
Speicher	128 GB GDDR7	bewusst kein HBM4 – kosteneffizienter
Rechenleistung	bis zu 30 PFLOPS NVFP4	für rechengebundene Prefill-Last ausgelegt
Attention-Speedup	ca. 3× ggü. GB300 NVL72	wirkt sich direkt auf Time-to-First-Token aus
Verfügbarkeit	laut NVIDIA Ende 2026	reale Kunden-Systeme eher Anfang/Mitte 2027

Warum GDDR7 statt HBM4 hier sinnvoll ist, erschließt sich aus dem NVFP4-Zahlenformat, mit dem Rubin CPX rechnet: Es handelt sich um ein 4-Bit-Gleitkommaformat, das speziell für Inferenz mit reduzierter Präzision entwickelt wurde und deutlich mehr Rechenoperationen pro Speicherzugriff ermöglicht als klassische FP16-Berechnungen. Damit verschiebt sich der Flaschenhals in der Prefill-Phase weg von der Speicherbandbreite hin zur reinen Rechenkapazität – und genau dort punktet GDDR7 pro investiertem Dollar deutlich besser als HBM4, weil es zwar weniger Bandbreite, aber ausreichend Kapazität bei niedrigeren Kosten liefert. NVIDIA nennt Rubin CPX konsequenterweise nicht schlechter, sondern anders spezialisiert.

Prefill und Decode: Die zwei Phasen der LLM-Inferenz erklärt

Um zu verstehen, warum NVIDIA für eine einzige Nutzeranfrage plötzlich zwei unterschiedliche GPU-Klassen einsetzt, lohnt sich ein Blick auf das, was bei einer Anfrage an ein Sprachmodell technisch tatsächlich passiert. Man kann sich das als zwei klar getrennte Arbeitsschritte vorstellen:

• Prefill: Das Modell liest den kompletten Eingabe-Prompt – also alles, was der Nutzer oder das System als Kontext mitgibt, von der einzelnen Frage bis zur kompletten Codebasis – in einem Durchgang ein und berechnet daraus die internen Zustände für jedes einzelne Token. Dieser Schritt lässt sich stark parallelisieren, weil alle Token des Prompts gleichzeitig verarbeitet werden können. Er ist dafür sehr rechenintensiv: Je länger der Prompt, desto quadratisch aufwendiger wird die Attention-Berechnung.
• Decode: Nach dem Prefill generiert das Modell die Antwort Token für Token, wobei jedes neue Token von allen vorherigen abhängt. Dieser Schritt lässt sich nicht parallelisieren – er ist von Natur aus sequenziell. Entscheidend ist hier nicht die Rechenleistung, sondern wie schnell die GPU die bereits berechneten Zwischenzustände wieder aus dem Speicher lesen kann.

Genau diese wiederverwendeten Zwischenzustände werden im sogenannten KV-Cache gehalten – einer wachsenden Datenstruktur, die für jedes bereits verarbeitete Token die zugehörigen Key- und Value-Vektoren speichert. Bei einem langen Kontextfenster wird dieser Cache selbst bei mittelgroßen Modellen mehrere hundert Gigabyte groß, und jeder einzelne Decode-Schritt muss diesen kompletten Cache durchsuchen. Genau deshalb ist die Decode-Phase in erster Linie speicherbandbreitengebunden, nicht rechengebunden – hier zahlt sich HBM4 mit seinen 22 TB/s pro GPU aus.

NVIDIA zieht daraus die logische Konsequenz und trennt die Hardware nach diesem Muster: Rubin CPX übernimmt die rechengebundene Prefill-Phase mit günstigerem, aber rechenstarkem GDDR7-Speicher, während reguläre Rubin-GPUs mit teurem, bandbreitenstarkem HBM4 die bandbreitengebundene Decode-Phase übernehmen. Dieses Muster nennt die Branche disaggregiertes Serving: Statt eine einzelne GPU-Klasse für beide, gegenläufige Anforderungsprofile zu kompromittieren, bekommt jede Phase die für sie optimale Hardware. Für einen Betreiber bedeutet das in der Theorie eine bessere Kosten-Nutzen-Bilanz pro verarbeitetem Token – vorausgesetzt, die Orchestrierung zwischen den beiden GPU-Klassen funktioniert reibungslos, was in der Praxis zusätzliche Softwarekomplexität in der Inferenz-Pipeline bedeutet.

Vera Rubin VR200: Die neue Basis-GPU seit Juni 2026 in Vollproduktion

Während Rubin CPX noch auf ihre Markteinführung wartet, ist die reguläre Rubin-GPU der Vera-Rubin-Plattform – intern als VR200 bezeichnet – bereits Realität. NVIDIA hat am 1. Juni 2026 auf der GTC Taipei den offiziellen Start der Vollproduktion verkündet, mit Kunden-Rollout im zweiten Halbjahr 2026. Das ist keine bloße Ankündigung mehr, sondern ein belastbarer Produktionsstatus, der auch durch unabhängige Berichte zu ersten Kundenauslieferungen bestätigt wird.

Die Kernspezifikationen einer einzelnen VR200-GPU:

Kennzahl	Vera Rubin VR200	Blackwell Ultra B300
Dichte FP4-Rechenleistung	50 PFLOPS	ca. 15 PFLOPS
Speicher	288 GB HBM4	288 GB HBM3e
Speicherbandbreite	22 TB/s	niedriger (HBM3e-Generation)

Der oft zitierte Wert, VR200 liefere die 3,3-fache Rechenleistung pro Chip gegenüber der Vorgängergeneration, ergibt sich rechnerisch aus 50 PFLOPS gegenüber rund 15 PFLOPS bei B300. Wichtig für die Einordnung: Das ist eine Herstellerangabe unter Idealbedingungen, gemessen an dichter FP4-Rechenkapazität pro Chip. Sobald eine Anwendung netzwerk- oder speicherbandbreitenlimitiert ist – was bei den meisten praxisnahen Workloads mit langem Kontext der Fall ist – fällt der reale Geschwindigkeitsgewinn spürbar geringer aus als der Rechenwert suggeriert. Für die eigene Planung sollte diese Zahl daher als oberes Limit gelesen werden, nicht als realistische Alltagsleistung.

Das NVL72-Rack: 72 GPUs, 36 CPUs und 260 TB/s NVLink-Bandbreite

Einzelne GPUs verkauft NVIDIA im Rechenzentrumsgeschäft ohnehin kaum – die eigentliche Verkaufseinheit ist das Rack. Ein NVL72-Rack der Vera-Rubin-Generation bündelt 72 Rubin-GPUs mit 36 Vera-CPUs zu einem einzigen, über NVLink-6 verbundenen System. Die Fabric-Bandbreite liegt bei 260 TB/s über das gesamte Rack, der gepoolte HBM4-Speicher bei 20,7 TB. In Summe kommt ein Rack laut NVIDIA auf 3,6 EFLOPS NVFP4-Inferenzleistung, zusätzlich rund 2,5 EFLOPS Trainingsleistung.

Praktisch bedeutet dieser gepoolte Speicher, dass sehr große Modelle und gleichzeitig sehr viele lange Kontexte im schnellen GPU-Speicher gehalten werden können, ohne ständig auf langsamere Speicherebenen ausweichen zu müssen. Für einen Anbieter, der mehreren tausend Nutzern gleichzeitig Million-Token-Kontexte anbieten will, ist genau das der limitierende Faktor – nicht die reine Rechenleistung einer einzelnen GPU.

Eine ergänzende Rack-Variante, die im Kontext von Rubin CPX besonders relevant ist, ist das Vera Rubin NVL144 CPX. Es kombiniert reguläre Rubin-GPUs mit Rubin-CPX-GPUs im selben Rack und kommt laut NVIDIA auf 8 EFLOPS NVFP4-Rechenleistung, 100 TB Speicher und 1,7 PB/s Bandbreite – nach Herstellerangabe rund das 7,5-Fache eines GB300-NVL72-Racks. Das ordnet Rubin CPX korrekt ein: Sie ist kein eigenständiges Produkt, sondern ein Baustein, der im Rack-Verbund mit regulären Rubin-GPUs seine Wirkung entfaltet.

Rack-Variante	Bestückung	NVFP4-Leistung	Speicher / Bandbreite
NVL72	72 Rubin-GPUs + 36 Vera-CPUs	3,6 EFLOPS	20,7 TB HBM4 / 260 TB/s NVLink
NVL144 CPX	Rubin-GPUs + Rubin-CPX kombiniert	8 EFLOPS	100 TB / 1,7 PB/s

Ein Rack dieser Klasse benötigt konsequente Flüssigkühlung und liegt im Strombedarf im hohen zweistelligen bis niedrigen dreistelligen Kilowatt-Bereich – Werte, die für die Planung eines eigenen Rechenzentrumsraums relevant sind, für die allermeisten Mittelstandsbetriebe aber schlicht außerhalb der realistischen Beschaffungsgröße liegen. Zum Vergleich: Ein typischer On-Premise-KI-Server, wie er für RAG- oder Chat-Anwendungen im Mittelstand ausreicht, kommt mit ein bis vier GPUs und wenigen Kilowatt Anschlussleistung aus – ein Unterschied um zwei Größenordnungen, der die Kaufentscheidung in der Praxis meist schon vorwegnimmt.

Für wen Million-Token-Kontexte tatsächlich relevant werden

Bevor man in Hardware dieser Größenordnung investiert oder investieren lässt, lohnt sich die ehrliche Frage, wer ein Kontextfenster im Millionen-Token-Bereich überhaupt braucht. Konkrete Anwendungsfälle, bei denen das tatsächlich einen Unterschied macht:

• Vollständige Codebasen analysieren. Ein Codeassistent, der nicht nur einzelne Dateien, sondern ein komplettes Repository mit allen Abhängigkeiten im Kontext hält, kann Refactorings und Bugfixes vorschlagen, die den Gesamtzusammenhang berücksichtigen – nicht nur den geöffneten Tab.
• Sehr lange Dokumentenkonvolute. Vertragswerke mit hunderten Anlagen, technische Dokumentationen über mehrere tausend Seiten oder komplette Aktenbestände, die in einem einzigen Durchgang und ohne Chunking-Verluste durchsucht werden sollen.
• Video-Generierung mit langem zeitlichen Kontext. Modelle, die konsistente, mehrminütige Videos erzeugen, müssen sich über sehr viele Frames hinweg an vorherige Inhalte erinnern – das erzeugt ähnliche Kontextlängen wie Text, nur in einer anderen Modalität.
• Agentic-AI-Systeme mit langem Gedächtnis. Ein Agent, der über hunderte Arbeitsschritte hinweg eigenständig plant, Tools aufruft und Zwischenergebnisse bewertet, akkumuliert Kontext mit jedem Schritt – ohne ausreichendes Kontextfenster verliert er frühere Entscheidungen aus dem Blick.

Ebenso wichtig ist die Abgrenzung: Die überwiegende Mehrheit produktiver KI-Anwendungen im Mittelstand – klassisches RAG, interne Chatbots, Dokumentenzusammenfassung, Support-Assistenten – funktioniert mit deutlich kleineren Kontextfenstern zwischen 8.000 und 128.000 Token einwandfrei. Wer sein Anwendungsproblem mit gezielter Informationsauswahl statt mit roher Kontextgröße löst, braucht keine Million-Token-Hardware, sondern eine gut gebaute Suchschicht.

Was das für Kaufentscheidungen im Mittelstand bedeutet

Die nüchterne Einordnung vorweg: NVL72-Racks, und erst recht kombinierte NVL144-CPX-Systeme, sind auf der Ebene von Hyperscalern und großen KI-Fabriken konzipiert – nicht für den direkten Einkauf durch ein mittelständisches Unternehmen. Weder der Strom- und Kühlungsbedarf noch die siebenstelligen Anschaffungskosten eines vollbestückten Racks passen zu den Beschaffungsvolumen, mit denen ein typischer Mittelständler plant.

Für die meisten Unternehmen ergeben sich daraus zwei realistische Wege, an die Vorteile dieser Architektur heranzukommen:

1. Nutzung über Cloud- oder API-Anbieter. Sobald Hyperscaler und spezialisierte Inferenz-Anbieter VR200- und später CPX-Racks in Betrieb nehmen, wird Million-Token-Inferenz als Dienstleistung verfügbar – ohne eigene Hardwarebeschaffung, dafür mit den bekannten Abwägungen bei Datenübermittlung an einen externen Anbieter.
2. Fokus auf passend dimensionierte On-Premise-Hardware. Für die tatsächlichen, meist deutlich kleineren Kontext-Anforderungen im eigenen Haus reichen aktuell verfügbare GPU-Klassen aus dem Blackwell-Umfeld in der Regel vollständig aus – bei erheblich geringerem Investitions- und Betriebsaufwand.

Ein pragmatischer erster Schritt für die eigene Bewertung ist, die tatsächlich genutzten Kontextlängen aus den vergangenen drei bis sechs Monaten der bestehenden Systeme auszuwerten, statt von hypothetischen Zukunftsszenarien auszugehen. Wer feststellt, dass 95 Prozent der Anfragen unter 64.000 Token liegen, hat damit eine belastbare Datengrundlage für die Ablehnung – oder Bestätigung – einer teuren Hardware-Investition, statt auf Marketingversprechen zu reagieren.

Wichtig für die Zeitplanung: Selbst wenn Rubin CPX Ende 2026 wie angekündigt verfügbar wird, bedeutet das für ein eigenes System realistischerweise Lieferzeiten bis Anfang oder Mitte 2027, inklusive Integration in bestehende Rechenzentrumsinfrastruktur. Wer heute mit konkretem Bedarf plant, sollte dieses Zeitfenster in die Budget- und Projektplanung einrechnen, statt von einer sofortigen Verfügbarkeit auszugehen.

On-Premise-Einordnung: Souveränität auch ohne eigenes NVL72-Rack

Als Anbieter von On-Premise-KI-Lösungen ist uns an dieser Stelle eine ehrliche Einordnung wichtiger als das Anpreisen der neuesten Hardware-Generation: Datensouveränität und Kontrolle über die eigenen Daten hängen nicht von der größten verfügbaren GPU-Klasse ab, sondern von einer zum tatsächlichen Bedarf passenden, selbst betriebenen Infrastruktur. Ein Unternehmen, das seine Dokumentenanalyse mit einem sauber dimensionierten, on-premise betriebenen Modell mit 128.000 Token Kontextfenster löst, ist regulatorisch und datenschutzrechtlich nicht schlechter gestellt als eines, das theoretisch Zugriff auf Millionen-Token-Hardware hätte.

Für die Praxis heißt das: Die Total-Cost-of-Ownership-Betrachtung sollte immer mit der realen Kontextanforderung beginnen, nicht mit der neuesten NVIDIA-Ankündigung. Wer feststellt, dass 90 Prozent der eigenen Anwendungsfälle mit deutlich kleineren Kontextfenstern zuverlässig funktionieren, spart nicht nur bei der Anschaffung, sondern auch bei Strom, Kühlung und Wartung – ohne auf Souveränität zu verzichten. Rubin-CPX-Technik für Mittelstandsgrößen anzupreisen, wäre in den allermeisten Fällen Overselling. Eine fundierte Bedarfsanalyse und Beratung zur passenden Hardwaregröße bringt in der Regel mehr als jede Spezifikationstabelle.

Ein oft übersehener Hebel ist zudem die Modellseite selbst: Durch gezielte Quantisierung, effizientere Attention-Implementierungen und Retrieval-Verfahren, die nur die tatsächlich relevanten Dokumentabschnitte in den Kontext laden, lässt sich der reale Speicher- und Rechenbedarf pro Anfrage oft um den Faktor fünf bis zehn senken, ohne die Antwortqualität für den jeweiligen Anwendungsfall spürbar zu verschlechtern. Diese softwareseitigen Optimierungen sind in aller Regel die wirtschaftlichere erste Investition, bevor überhaupt über neue Hardware-Generationen nachgedacht werden muss.

Fazit: Neue Referenzarchitektur, aber kein sofortiger Handlungsdruck für die meisten Unternehmen

Die Fakten in der Zusammenfassung: Die Vera-Rubin-VR200-Plattform ist seit dem 1. Juni 2026 offiziell in Vollproduktion, mit 50 PFLOPS dichter FP4-Rechenleistung, 288 GB HBM4 und 22 TB/s Bandbreite pro GPU. Rubin CPX ergänzt diese Plattform ab Ende 2026 um eine spezialisierte GPU mit 128 GB GDDR7 für die rechenintensive Prefill-Phase bei Million-Token-Kontexten. Gebündelt in NVL72- beziehungsweise NVL144-CPX-Racks entstehen daraus Systeme mit bis zu 8 EFLOPS NVFP4-Rechenleistung – eine Referenzarchitektur für die nächste Generation von Long-Context-Anwendungen.

Für die überwiegende Mehrheit der Unternehmen im deutschen Mittelstand lautet die realistische Handlungsempfehlung: beobachten statt sofort kaufen. Wer ernsthaft über Million-Token-Anwendungen nachdenkt, sollte zunächst die eigenen Kontextfenster-Anforderungen sauber ermitteln – anhand tatsächlicher Dokumentlängen, Codebase-Größen oder Agentic-Workflows – und erst danach eine Hardware- oder Anbieter-Entscheidung treffen. In den meisten Fällen wird sich zeigen, dass deutlich kleinere, bereits verfügbare und wirtschaftlich sinnvollere Systeme ausreichen.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. NVIDIA Newsroom: NVIDIA Unveils Rubin CPX Primärquelle bestätigt, existiert und deckt Rubin-CPX-Spezifikationen (128 GB GDDR7, 30 PFLOPS NVFP4, 3x Attention-Speedup, Verfügbarkeit Ende 2026) korrekt ab.
2. NVIDIA Developer Blog: Inside the NVIDIA Rubin Platform Primärquelle bestätigt, existiert und beschreibt die sechs neuen Rubin-Plattform-Chips (Vera-CPU, Rubin-GPU, NVLink-6-Switch, ConnectX-9, BlueField-4, Spectrum-6) inkl. Architekturdetails.
3. Hashrate Index: NVIDIA Vera Rubin NVL72 Specs Breakdown Quelle bestätigt und existiert; enthält die geprüften NVL72-Rack-Spezifikationen (72 GPUs, 36 CPUs, 260 TB/s NVLink, 20,7 TB HBM4).
4. NVIDIA Newsroom: Vera Rubin Ramps Into Full Production Zusätzliche Primärquelle zur Bestätigung des Vollproduktionsstarts am 1. Juni 2026 auf der GTC Taipei.
5. TechPowerUp: NVIDIA Ships First Vera Rubin VR200 Samples Ergänzende, unabhängige Quelle zur Historie/Timeline der VR200-Auslieferung an Kunden vor der Vollproduktion.

Häufig gestellte Fragen zu NVIDIA Rubin CPX

Was macht die Rubin CPX anders als eine normale GPU für KI-Training?

Rubin CPX ist keine Trainings-GPU, sondern spezialisiert auf die rechenintensive Prefill-Phase der Inferenz – also das erstmalige Einlesen und Verarbeiten sehr langer Prompts (bis in den Millionen-Token-Bereich). Statt teurem HBM4 setzt NVIDIA auf 128 GB kosteneffizientes GDDR7-Speicher, weil in der Prefill-Phase Rechenleistung wichtiger ist als Speicherbandbreite. Die eigentliche Token-Generierung (Decode-Phase) übernehmen weiterhin klassische Rubin-GPUs mit HBM4.

Ab wann ist die Vera-Rubin-Plattform tatsächlich verfügbar?

Die Vera-Rubin-VR200-Plattform (NVL72-Racks) ist seit dem 1. Juni 2026 offiziell in Vollproduktion, erste Kunden-Deployments folgen im zweiten Halbjahr 2026. Rubin CPX als separate GPU-Klasse für Massive-Context-Workloads wird laut NVIDIA erst Ende 2026 verfügbar sein – Unternehmen sollten also mit Lieferzeiten bis Anfang/Mitte 2027 für eigene Systeme rechnen.

Lohnt sich Rubin CPX schon für den deutschen Mittelstand?

Praktisch kaum. Die NVL72-Racks und erst recht kombinierte CPX-Systeme sind auf Hyperscaler und große KI-Fabriken ausgelegt, mit entsprechendem Strom-, Kühlungs- und Investitionsbedarf. Für Mittelstandsanforderungen mit On-Premise-KI reichen aktuell deutlich kleinere GPU-Klassen (z. B. Blackwell-basierte Workstations) für die meisten Million-Token-Anwendungsfälle wie Dokumentenanalyse oder RAG-Systeme aus.

Was bedeutet die 3,3-fache Rechenleistung gegenüber B300 konkret?

NVIDIA gibt für eine einzelne Rubin-GPU 50 PFLOPS dichte FP4-Inferenzleistung an, gegenüber rund 15 PFLOPS bei einer B300-GPU (Blackwell Ultra) – das entspricht etwa dem 3,3-fachen Wert. Das ist eine reine Rechenkapazitäts-Kennzahl pro Chip; bei speicherbandbreiten- oder netzwerklimitierten Workloads fällt der reale Geschwindigkeitsgewinn in der Praxis oft geringer aus.