Der Engpass hat sich ins Memory verlagert

Jeder zählt GPUs. Die Pressemitteilungen zählen sie, die Funding-Rounds zählen sie, die Datacenter-Ankündigungen zählen sie. Compute ist die Zahl, die headlines macht.

Ich betreibe einen kleinen GPU-Cluster. Nichts im Hyperscaler-Maßstab, aber genug, um zu spüren, wo es tatsächlich reißt. Und das, was reißt, ist fast nie das Compute. Es ist Memory. Wie viel ich habe, wie schnell ich es bewegen kann, und in letzter Zeit, was es kostet.

Das ist kein Hot Take. Das ist, was die Hardware jedem sagt, der die Zahlen eine Weile lang ansieht. Der Engpass hat sich verlagert, und die meiste Berichterstattung hat das nicht mitgekriegt.

Inference wartet auf Memory, nicht auf Mathematik

Fangen wir mit dem Teil an, der Leute überrascht. Wenn ein Modell Text generiert, Token für Token, ist der teure Schritt nicht die Arithmetik. Es ist das Auslesen der Weights aus dem Memory.

Hier ist der Grund. In der Decode-Phase produziert das Modell ein Token pro Schritt. Um dieses eine Token zu produzieren, muss es die relevanten Modell-Weights und den wachsenden KV-Cache aus High-Bandwidth-Memory in die Compute-Units streamen. Die eigentliche Mathematik pro Token ist winzig. Die Datenbewegung nicht. Also sitzen die Compute-Units da, meistens idle, und warten darauf, dass Bytes ankommen.

NVIDIA hat das in eigener Forschungplain gesagt. Ihr LIMINAL-Paper (arXiv, Juli 2025) stellt fest, dass autoregressives Decoding in diesen Modellen fundamental memory-bandwidth-bound ist, nicht compute-bound, und listet es als Hardware-Wahrheit auf: per-user Throughput wird von Memory-Bandbreite bestimmt. Ihre Messungen zeigen, dass ein state-of-the-art HBM3e-System bei etwa 750 User-Tokens pro Sekunde auf Llama-405B plateauing ist. Viermal die Bandbreite bringt dich auf grob 1500 bis 2800, nicht auf viermal so viel. Die Mauer ist Bandbreite, und sie bewegt sich nicht nur, weil du Compute dazugetan hast.

TrendForce hat den Trend auf einen Satz reduziert: Über zwei Jahre wuchs AI-Chip-Compute etwa 3x, Memory-Bandbreite etwa 1.6x und Interconnect nur 1.4x. Compute läuft den Rohren, die es füttern, davon.

Man sieht es in den Flagship-Specs. Eine H100 gibt dir 3,35 TB/s HBM3-Bandbreite. Die H200 drückt das auf 4,8 TB/s mit HBM3e. Eine B200 erreicht 8,0 TB/s. Jede Generation investiert enormen Engineering-Aufwand in die Erweiterung des Memory-Pipes, weil dieser Pipe, nicht die FLOPs, den echten Serving-Throughput begrenzt.

Quellen: NVIDIA LIMINAL-Paper (arXiv), TrendForce Memory Wall, NVIDIA H200 Specs.

Deshalb funktioniert Quantisierung überhaupt

Sobald man akzeptiert, dass Decode memory-bound ist, hört Quantisierung auf, ein cleverer Trick zu sein, und wird offensichtlich.

Wenn Throughput gleich Bandbreite durch Bytes-pro-Token ist, dann verdoppelt das Halbieren der Bytes den Throughput. Führe ein Modell in 4-Bit statt 16-Bit, und du bewegst grob ein Viertel der Daten pro Token. Auf einem bandbreitenbegrenzten Pfad ist weniger Daten keine kleine Optimierung. Es ist die Optimierung.

Das ist der Teil, den ich von meinem eigenen Hardware kenne, nicht von einem Datenblatt. Quantisierte Modelle auf Consumer-GPUs zu fahren funktioniert weit besser, als die nackten Compute-Zahlen erwarten lassen, weil die Einschränkung nie das Compute war. Eine Consumer-Karte mit moderaten FLOPs, aber anständiger Memory-Bandbreite, serviert ein 4-Bit-Modell gerne, weil du das Ding entfernt hast, das tatsächlich langsam war: den Byte-Transfer. Die Leute, die winzige quantisierte Modelle liefern, kürzen keine Ecken. Sie optimieren für den echten Engpass, während alle anderen auf FLOPs starren.

Der Memory-Preis hat die Wahrheit zuerst gesagt

Wenn Bandbreite die technische Mauer ist, dann ist der Memory-Preis der Ort, an dem der Markt dasselbe in Zahlen zeigt.

DRAM-Preise stiegen grob 171% year over year, überholt Gold. DDR5-Spot-Preise haben sich seit September 2025 etwa vervierfacht. TrendForce projizierte konventionelle DRAM-Vertragspreise um 58 bis 63% quarter over quarter für Q2 2026, mit NAND um 70 bis 75%. Der Grund ist kein Mangel an Sand. Es ist, dass die Memory-Hersteller Kapazität von Consumer-DRAM nach HBM und Server-DRAM umgelenkt haben, weil da das KI-Geld ist. Micron hat seinen HBM-Anteil der Bit-Produktion reportedly von grob 17% auf etwa die Hälfte hochgeschraubt.

Die Folgeeffekte sind schon sichtbar. Dell und Lenovo haben Hardware-Preise um 15 bis 20% angehoben. Smartphone-Hersteller haben Konfigurationen leise von 12/512GB auf 8/256GB zurückgeschraubt. DRAM ging von einer routinemäßigen 15% eines PC-Baukosten zu etwas, das Produktlinien umformt. Wenn Memory beginnt zu diktieren, was ein Telefon liefert, ist es die knappe Ressource, nicht das Compute.

Quellen: BISI RAM shortage report, TrendForce Q2 2026 pricing.

Meta hat einen Chip gebaut, nur um Memory nicht wegzuwerfen

Das klarste Signal kam von Meta, und die meiste Berichterstattung hat es als Sparsamkeits-Geschichte gelesen. Es ist mehr als das.

Meta hat einen Custom-CXL-2.0-ASIC gebaut, intern Vistara genannt, dessen einziger Job es ist, DDR4-Module aus ausrangierten Servern zu nehmen und sie an neue DDR5-only-Maschinen anzuhängen. Jeder Chip trägt bis zu 256 GB DDR4 und hängt an PCIe Gen5, präsentiert das alte Memory als separaten NUMA-Node. Ein einzelner “MemServer” paart 768 GB DDR5 mit 256 GB wiederhergestelltem DDR4. Der gemeldete Payoff: bis zu 25% weniger Server für disaggregierte Inference und ein 33%riger Rückgang von out-of-memory-Ereignissen, in Produktion auf Millionen von Maschinen. (Vorgetragen auf ISCA 2026.)

Lies das nochmal. Eine der compute-reichsten Unternehmen der Erde hat Custom-Silizium designed, nicht um Compute hinzuzufügen, sondern um zu vermeiden, Memory zu verschwenden, das es bereits besaß. So einen Engineering-Aufwand treibt man nicht für eine Ressource, die billig und plentiful ist. Der Move macht nur Sinn, wenn Memory die binding constraint ist, und Meta sagt dir, dass es sie ist.

Quellen: The Register zu Meta Vistara, Tom’s Hardware.

Was sich ändert, wenn du baust

Ich sage nicht, dass Compute keine Rolle spielt. Es spielt natürlich. Ich sage nur: Wenn du deine Systeme um die FLOPs-Zahl herum planst, optimierst du das Ding, das nicht auf dem critical path ist.

Ein paar Dinge folgen, wenn man die Memory-Perspektive ernst nimmt:

Die knappe Ressource ist Memory, also designe drumherum. Batche Requests, um die Weight-Reads zu amortisieren. Beobachte den KV-Cache, denn auf langen Kontexten frisst er deine Bandbreite und deine Kapazität. Greife nach dem kleinsten Modell und der niedrigsten Präzision, die deine echte Aufgabe noch besteht, nicht weil du billig bist, sondern weil weniger Bytes pro Token direkter Throughput-Gewinn ist.

Und wenn du die nächste Runde Buildout-Ankündigungen liest, beachte, mit welcher Zahl sie werben. Alle zitieren das Compute. Die Leute, die die Maschinen tatsächlich fahren, kämpfen leise um Memory. Der Engpass hat sich verlagert, und niemand hat dazu eine Pressemitteilung rausgegeben.