LLM Primer VI — Serieneinführung und Index

Ein Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren — dem Band, der LLM-Inferenz als Ingenieursdisziplin behandelt, in der Speicherbandbreite, Scheduling und Kosten aufeinandertreffen.

Warum es diese Reihe gibt

Eine H100, für vier bis acht Dollar pro Stunde gemietet, liefert 989 TFLOP/s BF16-Rechenleistung. Ein einzelner Nutzer, der in Echtzeit eine einzige Antwort gegen ein 70B-Modell auf diesem Chip erzeugt, verbraucht davon rund 0,34 Prozent. Der Chip liegt zu 99,7 Prozent brach — nicht weil die Arbeitslast klein wäre, sondern weil sie speicherbandbreitengebunden ist und die Recheneinheiten des Chips nichts zu tun haben, während der HBM die Gewichte durch sie hindurchströmt. Inferenz-Engineering ist die Disziplin, Arbeit für diese untätigen Einheiten zu finden. Es ist eine Disziplin des Batchings, der KV-Cache-Buchhaltung, der Quantisierung, des spekulativen Dekodierens, des Schedulings und schließlich der Plattform, der Orchestrierung und der Kosten. Jede Technik in diesem Band ist eine Variation desselben Zugs: bandbreitengebundene Verschwendung in Durchsatz zu verwandeln, ohne die Latenz zu zerstören, die der Nutzer tatsächlich spürt.

In einem Satz: LLM-Serving ist ein Systemproblem, bei dem eine bandbreitengebundene Dekodierschleife, ein KV-Cache in der Größenordnung einer kleinen Datenbank und eine Rechnung pro Token gemeinsam darüber entscheiden, ob ein Produkt echten Traffic übersteht.

Für wen dieses Buch geschrieben ist

Für Platform-Engineers, SREs und Infrastruktur-Architekten, die LLM-Inferenz in großem Maßstab verantworten — also die Menschen, die geweckt werden, wenn die Latenz ausschlägt, deren Budgetzeile der GPU-Pool ist und die der Finanzabteilung erklären müssen, warum die Rechnung vom letzten Monat doppelt so hoch ausfiel wie im Monat davor. Es richtet sich ebenso an ML-Engineers, die das Modell trainiert haben und es nun ausliefern müssen, und an Backend-Engineers, die sich plötzlich als die versierteste Person ihres Teams für Inferenzfragen wiederfinden. Vertrautheit mit verteilten Systemen und Containern setzt das Buch voraus; Vorkenntnisse über GPU-Interna oder das Speichermuster des Transformers nicht. Beides baut es aus ersten Prinzipien auf.

Wie man es liest

Die sechzehn Kapitel teilen sich in sechs Teile. Kapitel 1–2 benennen die Arbeitslast — die autoregressive Schleife und den KV-Cache. Kapitel 3–4 gehen das Silizium ab, das sie ausführt, von H100 bis zur Groq LPU. Kapitel 5–6 gehen die modellseitigen Kompressionen ab — Quantisierung, Pruning, Distillation —, die die Bandbreitenlast verringern. Kapitel 7–9 gehen die Laufzeittechniken ab — Batching, paged KV, spekulatives Dekodieren —, die Leerlaufzeit verstecken. Kapitel 10–13 gehen den Serving-Stack ab — Engines, Plattformen, Disaggregation, Autoscaling —, der aus diesen Techniken einen Dienst macht. Kapitel 14–16 gehen dem Geld nach: Token-Ökonomie, Selbstbetrieb versus API und die Kostensenkungen, die sich multiplikativ aufschichten. Die Kapitel lassen sich in der Reihenfolge lesen oder thematisch anspringen, aber die mechanismusorientierte Rahmung hängt an Kapitel 1 und 2.

Der Walkthrough über sechzehn Kapitel

Zwischen dem 23. April und dem 8. Mai erscheint täglich ein Kapitel. Jeder Beitrag verdichtet die drei Kernideen des jeweiligen Kapitels zu einer Lektüre von etwa fünf Minuten; das Buchkapitel liefert die durchgerechneten Beispiele, den Code und die „In Plain English"-Kästen.

23. April — Kapitel 1 — Die Mechanik der Token-Erzeugung. Die autoregressive Schleife, Prefill versus Dekodierung und warum ein einzelner Nutzer eine H100 zu 99,7 Prozent leerlaufen lässt.
24. April — Kapitel 2 — Die KV-Cache-Herausforderung. Die Speicherformel, die Kompromisse zwischen MHA, GQA und MQA und warum naive Allokation die Nebenläufigkeit zerstört.
25. April — Kapitel 3 — Rechenzentrums-GPUs für generative KI. H100, H200, B200, L40S, MI300X — gelesen als Bandbreiten- und VRAM-Profile, nicht als FLOPs.
26. April — Kapitel 4 — Spezialisiertes KI-Silizium und ASICs. Groqs LPU, Inferentia2, TPU v5p/v6 und Gaudi 3 — wo ASICs gewinnen und wo sie verlieren.
27. April — Kapitel 5 — Quantisierung entmystifiziert. Warum FP16 → INT4 den Durchsatz vervierfacht und was AWQ, GPTQ, SmoothQuant und GGUF tatsächlich tun.
28. April — Kapitel 6 — Pruning und Knowledge Distillation. 2:4-Sparsity auf Hopper und wie aus den weichen Labels eines Lehrers ein kleineres Schülermodell entsteht.
29. April — Kapitel 7 — Fortgeschrittene Batching-Strategien. Vom statischen Batching zum iterationsweisen Continuous Batching und die Schulden, die Continuous Batching aufmacht.
30. April — Kapitel 8 — KV-Cache-Management der nächsten Generation. PagedAttention, H2O-Eviction, InfiniGen und die Ökonomie des Präfix-Caches.
1. Mai — Kapitel 9 — Spekulatives Dekodieren. Entwurf, Verifikation und die Arithmetik, wann Spekulation sich lohnt — EAGLE, Medusa, MTP.
2. Mai — Kapitel 10 — Die LLM-Engine-Schicht. vLLM, TensorRT-LLM, SGLang, TGI, Ollama — und wie man eine Engine nach Mechanismus statt nach Benchmark wählt.
3. Mai — Kapitel 11 — Die Plattform- und Orchestrierungsschicht. Ray Serve, KServe, BentoML, Triton — welche Plattform zu welcher Ops-Kultur passt.
4. Mai — Kapitel 12 — Disaggregiertes Serving und Kubernetes. Prefill und Decode auf getrennte GPU-Pools aufteilen und die Kubernetes-Primitive, die das ausdrücken.
5. Mai — Kapitel 13 — Autoscaling und Cold-Start-Minderung. Warum HPA für LLMs falsch ist und wie KEDA, Knative und CRIU Cold Starts unter fünf Sekunden zusammensetzen.
6. Mai — Kapitel 14 — Token-Ökonomie und API-Preise. Warum Output teurer bepreist ist als Input und wie unsichtbare Reasoning-Tokens die Rechnung überraschen.
7. Mai — Kapitel 15 — Serverlose APIs versus dedizierte Infrastruktur. Die Break-even-Rechnung und der Posten Plattform-Engineering, den die meisten Teams unterschätzen.
8. Mai — Kapitel 16 — Kostenreduktion in der Produktion. Routing, Kontextverdichtung, Batch-APIs und semantisches Caching — die Züge, die sich aufaddieren.

Wo dies in der Reihe steht: Die Bände I–IV bauten Transformer-Mechanik, RAG, Agenten und Modalität auf. Band V ging Application-Engineering ab — die deterministische Hülle um den probabilistischen Kern. Band VI ist die Schicht unter dieser Hülle: wie der Modellaufruf selbst schnell und günstig genug ausgeliefert wird, damit die Hülle wirtschaftlich bleibt. Band VII schließt die Reihe mit KI-Sicherheit — Bedrohungsmodellierung, Guardrails und der Regulierung, die inzwischen mitentscheidet, wie all das eingesetzt werden darf.

Über dieses Buch und die Reihe

Die Reihe LLM Primer umfasst sieben Bände von Sho Shimoda, veröffentlicht auf Amazon KDP und Kapitel für Kapitel hier im ReceiptRoller-Blog begleitet. Die Reihe vertritt die Auffassung, dass Bauen mit LLMs eine Systemdisziplin ist und dass diese Disziplin am besten Schicht für Schicht in mechanismusorientierter Prosa gelernt wird — nicht in Checklistenform. Band VI ist der Infrastrukturband: der, der Schicht für Schicht die Frage beantwortet, was für Hardware, Laufzeit und Plattform wahr sein muss, damit ein LLM-Feature echten Traffic und eine Finanzprüfung übersteht.

Hol dir ein Exemplar. Das Buch enthält die vollständigen durchgerechneten Beispiele, den lauffähigen Python-Code für Kalibrierung und Continuous Batching, die YAML-Manifeste für KServe und Grove sowie die „In Plain English"-Kästen, die die Walkthrough-Artikel nur zusammenfassen. LLM Primer VI auf Amazon →