Kapitel 1 — Die Mechanik der Token-Erzeugung

Erster Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel argumentiert, dass fast jede schwere Frage im LLM-Serving auf eine einzige Tatsache zurückgeht — die Schleife, die jedes Token erzeugt, ist speicherbandbreitengebunden, und die teure Rechenleistung, für die man bezahlt hat, liegt zu 99,7 Prozent der Zeit brach.

Warum es dieses Kapitel gibt

Ein LLM ist im Betrieb ein Next-Token-Prädiktor, eingewickelt in eine Schleife. Tokens gehen hinein, eine Wahrscheinlichkeitsverteilung über das nächste Token kommt heraus, eines wird gewählt und angehängt, und die Schleife läuft erneut. Jede interessante Eigenschaft eines Inferenz-Stacks — Batching, Quantisierung, KV-Caching, spekulatives Dekodieren, disaggregiertes Serving — leitet sich aus einem genauen Blick in diese Schleife ab. Die Schleife verbirgt zwei Arbeitslasten, die einen gemeinsamen Code-Pfad teilen, die Hardware aber auf gegensätzliche Weise belasten. Die eine ist rechengebunden. Die andere ist bandbreitengebunden. Auf derselben H100. Im selben Forward-Pass. Diese Trennung präzise zu benennen ist der erste Zug des Buches, und es ist die Rahmung, auf die sich jedes spätere Kapitel bezieht.

1.1 Die autoregressive Schleife ist sequenziell durch Zwang

Token t+1 ist eine Funktion aller Tokens bis einschließlich t. Das Modell kann t+2 nicht vorhersagen, bevor t+1 nicht gesampelt ist, denn die Vorhersage von t+2 benötigt t+1 als Bestandteil der Eingabe. Es gibt keinen klugen Kernel, der die Erzeugung zweier aufeinanderfolgender Tokens für eine einzelne Sequenz parallelisiert; die Sequenzialität wird durch die Abhängigkeitsstruktur der Berechnung erzwungen. Die Wall-Clock-Kosten einer N-Token-Vervollständigung betragen daher N-mal die Kosten eines Schrittes plus fixen Overhead. Jede spätere Optimierung im Buch — größere Batches, Spekulation entlang der Trajektorie, günstigere Arithmetik pro Schritt — ist eine Teilantwort auf die Frage: „Angesichts dessen, dass die Schleife Token für Token gehen muss, wie machen wir jeden Schritt schneller oder jeden Batch größer?" Das Modell hat auch keinen externen Notizblock: es denkt, indem es Tokens ausgibt. Die Schleife ist der einzige Mechanismus, mit dem das Modell länger denken darf, und deshalb leben Chain-of-Thought und spekulatives Dekodieren in derselben Buchhaltung.

1.2 Prefill und Dekodierung belasten den Chip gegensätzlich

Die Schleife verbirgt zwei Phasen. Prefill ist der erste Forward-Pass, der den Prompt des Nutzers in Form [batch, sequence_length, hidden_dim] verarbeitet. Jede Matrix­multiplikation läuft über alle Sequenzpositionen gleichzeitig; die Arithmetik skaliert mit der Sequenzlänge; die Gewichte werden einmal aus dem HBM gelesen und auf viele Zeilen von Arbeit angewendet. Die Arithmetik-Intensität ist hoch. Prefill ist rechengebunden und kann die 989 BF16-TFLOP/s der H100 nutzen. Dekodierung ist jeder spätere Forward-Pass. Die Eingangsform kollabiert auf [batch, 1, hidden_dim]. Die Gewichte jeder Schicht müssen weiterhin aus dem HBM gestreamt werden, aber es wird nur eine einzige Zeile Arithmetik dagegen ausgeführt. Die Arithmetik-Intensität stürzt um drei Größenordnungen ab. Dekodierung ist speicherbandbreitengebunden. Auf einem 70B-Modell in BF16 läuft Prefill auf einem 2.000-Token-Prompt nahe an der Rechenobergrenze des Chips; der unmittelbar folgende Forward-Pass — der erste Dekodierschritt — läuft gegen dieselben 140 GB Gewichte, um ein einziges Token zu erzeugen. Der Chip hat sich nicht verändert. Die Arbeitslast schon.

1.3 Ein einzelner Nutzer lässt 99,7 Prozent der H100 brachliegen

Die Konsequenz ist, dass Echtzeit-Erzeugung für einen einzelnen Nutzer der schlechteste Fall für einen Frontier-Beschleuniger ist. Ein 70B-Modell in BF16 auf einer H100 SXM dekodiert mit etwa 24 Tokens pro Sekunde — flüssige Lesegeschwindigkeit für den Nutzer —, und die HBM3-Bandbreite des Chips von 3,35 TB/s ist voll gesättigt, während sie 140 GB Gewichte pro Token bewegt. Bei dieser Rate leisten die Recheneinheiten aber nur etwa 3,36 TFLOP/s von den 989, zu denen sie fähig sind. Die Rechenauslastung liegt bei 0,34 Prozent. Der physische Chip ist nicht falsch konfiguriert; jeder SM liest und multipliziert mit voller Geschwindigkeit, aber die Tensor Cores sind darauf ausgelegt, Kacheln vieler Zeilen gegen dieselbe Gewichts­kachel zu verrechnen, und ein Ein-Token-Forward-Pass liefert ihnen genau eine Zeile. Die Rechenkapazität ist in einer Einheit (Operationen pro geladenem Byte) bepreist, die die Arbeitslast nicht produziert. Für den ganzen Chip zahlt trotzdem jemand vier bis acht Dollar pro Stunde. Die Ökonomie des LLM-Servings ist deshalb die Ökonomie der Frage, wie man Arbeit für die geparkte Rechenleistung findet — über Batching, über günstigere Bandbreite pro Token, über Spekulation, über Hardware, deren Balancepunkt zur Arbeitslast passt.

Was Kapitel 1 vorbereitet

Der Rest des Buches ist die Antwort auf die hier benannte Asymmetrie. Kapitel 2 nimmt den KV-Cache auseinander — die Datenstruktur, die es der Dekodierung erlaubt, quadratische Neuberechnung zu vermeiden, und die dabei zum größten einzelnen VRAM-Verbraucher in einem Serving-Cluster wird. Die Kapitel 3 und 4 gehen das Hardware-Substrat mit der Bandbreiten-versus-Rechenleistung-Brille ab. Die Kapitel 5 und 6 verringern die Bandbreitenlast pro Token, indem sie die Gewichte schrumpfen. Kapitel 7 behandelt Batching als systemseitigen Hebel, der bandbreitengebundene Verschwendung in Durchsatz verwandelt. Die Kapitel 8 und 9 verändern die Form der Arbeit mit paged KV-Management und spekulativem Dekodieren. Jeder Zug ist lesbar als Versuch, jenen Leerlauf zu füllen, den dieses Kapitel gerade vermessen hat.

Als Nächstes — Kapitel 2: Die KV-Cache-Herausforderung. Der Arbeitsspeicher, der Dekodierung bezahlbar macht, und die Speicherformel, die erklärt, warum Serving-Cluster eher am VRAM als an der Rechenleistung scheitern.