Kapitel 3 — Rechenzentrums-GPUs für generative KI
Dritter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel argumentiert, dass man eine Serving-GPU nach HBM-Bandbreite und VRAM-Kapazität kaufen sollte, nicht nach der FLOP/s-Zahl vorne auf dem Datenblatt.
Warum es dieses Kapitel gibt
Die Kapitel 1 und 2 haben die Arbeitslast benannt: Prefill will die Matrixeinheiten gesättigt sehen, Dekodierung will Gewichte und KV-Cache so schnell wie möglich gestreamt bekommen, und der KV-Cache-Fußabdruck skaliert multiplikativ. Die Siliziumauswahl ist der Ort, an dem diese beiden Profile auf den Markt treffen. Der Rechenzentrums-GPU-Katalog von 2026 besteht aus einer kleinen Menge Karten, die oberflächlich ähnlich aussehen — ein Beschleuniger, ein paar tausend Kerne, ein Block On-Package-Speicher — und in den zwei Dimensionen, die die Dekodierkosten tatsächlich bestimmen, scharf auseinanderlaufen: HBM-Bandbreite und VRAM-Kapazität. Kapitel 3 geht die Aufstellung ab, die heute die Produktion beherrscht — H100, H200, B200, L40S, MI300X — und gibt Ingenieurinnen genug Mechanismus in die Hand, um für eine bestimmte Arbeitslast eine Karte auszuwählen, statt einem Benchmark-Diagramm zu vertrauen.
3.1 Die H100 ist der sichere Standard, die H200 ist der Bandbreiten-Patch
Die H100 bleibt die Arbeitspferd-Karte fast jeder Produktions-Inferenzflotte, solange nichts Bestimmtes für etwas anderes spricht. 80 GB HBM3, 3,35 TB/s Bandbreite auf der SXM-Variante (2,04 TB/s auf PCIe), 989 BF16-TFLOPs und — entscheidend — natives FP8 in den Tensor Cores, was den Gewichts-Datenverkehr pro Token halbiert und einem 70B-Modell erlaubt, in 70 GB statt 140 zu passen. Der Software-Stack ist reif; die Preise sind eingespielt. Wo die H100 an ihre Grenzen kommt, ist die Kapazität: 80 GB deckeln ein 70B-FP8-Modell plus Serving-Batch-KV-Cache und erzwingen jenseits davon Tensor-Parallelismus. Die H200 ist der chirurgische Eingriff — dieselbe Hopper-Rechenleistung, dasselbe 700-W-Budget, aber 141 GB HBM3e und 4,80 TB/s Bandbreite. Für jede Arbeitslast, die auf der H100 HBM-limitiert war (also fast jede Dekodier-Arbeitslast), ist die H200 ein reiner Bandbreiten-Durchsatzschub von rund 40 Prozent plus Kopffreiheit für den KV-Cache, den die H100 nicht halten konnte.
3.2 Blackwell bringt FP4 und verdoppelt die Bandbreiten-Obergrenze
Die B200 ist kein Hopper-Refresh. 192 GB HBM3e, 8,00 TB/s Bandbreite, 2250 BF16-TFLOPs und eine Transformer-Engine der zweiten Generation, die FP4 in den Tensor Cores nativ unterstützt. FP4 halbiert den Gewichts-Datenverkehr pro Token noch einmal gegenüber FP8; kombiniert mit der rohen Bandbreiten-Verdopplung dekodiert ein 70B-Modell, das auf H100 bei ~24 Tokens/s liegt, auf B200 für einen einzelnen Nutzer bequem mehr als 100 Tokens/s und skaliert mit dem Batch nahezu linear. Die 192-GB-Kapazität hält ein 180B-Modell in FP8 auf einer Karte und ein 70B in FP16 mit reichlich KV-Reserve, was den Tensor-Parallelismus aus vielen Deployments herausnimmt. Die Kosten sind der Preis und die 1000-W-Thermik; die Arbeitslasten, bei denen Blackwell am offensichtlichsten zurückzahlt, sind die, bei denen die H100 in jeder Anfrage gegen eine Bandbreiten- oder Kapazitätsgrenze kämpfte.
3.3 L40S und MI300X sind die Formentscheidungen der Arbeitslast
Die L40S ist die Ada-Generations-Karte für Arbeitslasten, die kein Rechenzentrumsteil brauchen. 48 GB GDDR6, 0,86 TB/s Bandbreite und rund ein Viertel des HBM-Durchsatzes der H100 — aber ein Drittel des Preises und ein Standard-PCIe-Formfaktor. Für kleine Modelle (bis etwa 13B), für asynchrone Batch-Arbeitslasten oder für Edge-Deployments, in denen ein HGX-Chassis nicht verfügbar ist, ist die L40S die richtige Antwort; eine H100 dafür zu kaufen ist Verschwendung. Die AMD MI300X markiert das andere Ende: 192 GB HBM3, 5,30 TB/s Bandbreite und 1307 BF16-TFLOPs auf OAM. In reinen Serving-Kennzahlen ist sie konkurrenzfähig zur H200 oder besser in der Kapazität, ähnlich in der bandbreitenlimitierten Dekodierung und liefert zu deutlich niedrigeren Stückkosten. Der Kompromiss ist der Software-Stack — ROCm hat den größten Teil der Lücke zu CUDA geschlossen, aber nicht die ganze, und die reifen Engines (vLLM, TensorRT-LLM, SGLang) sind auf NVIDIA kampferprobter. Für Teams mit ROCm-Kompetenz ist die MI300X der Kostenhebel; für Teams ohne ist die H200 der sicherere Kauf.
Was Kapitel 3 vorbereitet
Sobald das GPU-Datenblatt durch die Brille von Bandbreite und VRAM neu gelesen ist, stellt sich die naheliegende nächste Frage, ob Allzweck-GPUs überhaupt das richtige Substrat sind. Kapitel 4 geht die spezialisierten Silizium-Alternativen ab — Groqs LPU, AWS Inferentia2, Googles TPU v5p und v6, Intels Gaudi 3 —, jede davon ein Argument dafür, dass LLM-Inferenz regelmäßig genug ist, um einen Zweckchip zu rechtfertigen. Kapitel 5 geht dann den softwareseitigen Zug ab, der den Bandbreitenbedarf pro Token direkt schrumpft: Quantisierung von FP16 hinunter zu FP8 und FP4, die eine bandbreitengebundene Arbeitslast in eine mit verschobenem Engpass verwandelt.
Als Nächstes — Kapitel 4: Spezialisiertes KI-Silizium und ASICs. Die zweckgebauten Beschleuniger — Groq, Inferentia2, TPU, Gaudi 3 — und die Bereiche, in denen sie GPUs bei Latenz oder Kosten pro Token schlagen.
