Kapitel 14 — Token-Ökonomie und API-Preise

Vierzehnter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel verbindet die Physik aus Kapitel 1 mit den Posten auf der Rechnung — und erklärt, warum die erste Monatsrechnung oft nichts mit dem zu tun hat, was das Team modelliert hat.

Warum es dieses Kapitel gibt

Frühere Kapitel behandelten die Kosten der Inferenz als physische Tatsache — Bytes über HBM bewegt, FLOPs in einem Matmul, GPU-Sekunden pro Anfrage. Diese Rahmung ist für das Team richtig, das das Silizium besitzt. Für die viel größere Population an Teams, die Inferenz von einer API kaufen, wird die Kostenfläche durch die Einheit umgeformt, die der Anbieter abrechnet: das Token. Kapitel 14 handelt davon, warum das Token so bepreist ist, wie es ist, warum Input- und Output-Seite desselben Aufrufs so unterschiedliche Preise haben und wie leise die Gesprächs­historie eines Chatbots und das unsichtbare Denken eines Reasoning-Modells auf der Rechnung landen.

14.1 Output kostet 4–8× Input, weil Dekodierung die bandbreitengebundene Phase ist

Ein Input-Token reitet den Prefill-Pfad — dicht, rechengebunden, positionsparallel über den gesamten Prompt, genau das, wofür GPUs gebaut sind. Auf einem 70B-Modell knabbert eine H100 zehntausende Input-Tokens pro Sekunde durch, weil die Operation ein breiter Matmul mit hoher Arithmetik-Intensität ist. Ein Output-Token reitet den Decode-Pfad — sequenziell, speicherbandbreitengebunden, ein Token pro Forward-Pass, in dem jeder Schritt den ganzen KV-Cache aus dem HBM liest. Dieselbe H100 produziert pro Anfrage 50–100 Output-Tokens pro Sekunde. Das Verhältnis zwischen den beiden Durchsatzraten ist das Verhältnis, das die Preisliste widerspiegelt. Frontier-Modelle berechnen 2025 zwei bis fünf Dollar pro Million Input-Tokens und zehn bis dreißig pro Million Output — eine Asymmetrie von 4:1 bis 8:1, die keine Margenwahl ist, sondern ein direktes Durchreichen der zugrunde liegenden Rechen-Asymmetrie. Gecachter Input ist noch günstiger, weil der Anbieter den Prefill bei einer früheren Anfrage bezahlt hat. Batch-APIs sind halb so teuer, weil der Anbieter die Arbeit in Fenster untätiger Kapazität schieben darf. Reasoning-Tokens sind Output-Tokens, weil sie in der Engine genau das sind.

14.2 Der Optimierungshebel hängt von der Input-/Output-Form ab

Der Fehler ist, Kosten mit einer einzigen Zahl im Kopf zu modellieren — „Tokens kosten X" — statt Input und Output getrennt zu zerlegen. Ein retrieval-lastiges Kundenservice-Triage-System, das 8.500 Input-Tokens sendet und eine 600-Token-Antwort erhält, wird bei Frontier-Preisen von den Input-Kosten dominiert (grob 255 Dollar Input zu 90 Dollar Output pro 10.000 Anfragen und Tag). Ein Langtext-Verfassungssystem auf demselben Volumen — 2.200 Input rein, 3.000 Output raus — wird von Output dominiert (66 Dollar Input zu 450 Dollar Output). Der Optimierungsrat ist in beiden Fällen entgegengesetzt: für den ersten den Prompt kürzen, für den zweiten die Antwort kürzen und auf ein Modell routen, dessen Preisprofil die dominante Achse begünstigt. Eine zweite lohnende Zerlegung ist nach Tenant oder Arbeitslast. Multi-Tenant-Systeme zeigen fast immer eine Machtgesetz-Schiefe, in der die obersten zehn Prozent der Tenants die Hälfte oder mehr der Ausgaben ausmachen, und auf diese Tenants gerichtete Kostenoptimierung zahlt sich mehrfach mehr aus als uniforme Arbeit über den langen Ausläufer.

14.3 Kontextakkumulation und unsichtbare Reasoning-Tokens vervielfachen die Rechnung

Das teuerste Token ist das, von dem das Team vergaß, dass es gesendet wurde. APIs sind zustandslos; jede Anfrage schickt die vollständige Gesprächs­historie als Input bei jedem Aufruf mit. Die kumulierten Input-Kosten über ein N-Turn-Gespräch wachsen quadratisch in N, abzüglich Präfix-Cache-Gutschrift. Ein Team, das sein System auf einer Ein-Turn-Basis bepreist hat, findet sechs Monate später, dass sein durchschnittliches Gespräch nun acht Turns umspannt und die Input-Kosten pro Gespräch grob quadratisch mitgewachsen sind. Der zweite stille Multiplikator sind Reasoning-Tokens. Modelle wie o1/o3, Anthropics Extended Thinking, DeepSeek R1 und Googles Reasoning-Varianten erzeugen vor der sichtbaren Antwort eine große Menge internen Nachdenkens — oft 4.000–8.000 Tokens hinter einer 500-Token-Antwort. Diese Tokens reiten dieselbe Output-Dekodierschleife und werden als Output abgerechnet; sie werden dem Aufrufer nicht zurückgegeben, außer der Code fragt danach. Die Minderung besteht darin, das usage-Objekt der API-Antwort korrekt zu instrumentieren — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens und jede anbieterspezifische Kategorie — und unbekannte Kategorien zu kennzeichnen, statt sie stillschweigend zu verwerfen. Jede neue abgerechnete Dimension, die der Anbieter hinzufügt, muss im Nutzungs­schema des Teams auftauchen, sonst ist die nächste Rechnung eine Überraschung.

Was Kapitel 14 vorbereitet

Sobald das Team seine eigene Rechnung mit der Input-versus-Output-, Per-Tenant- und Per-Kategorie-Zerlegung lesen kann, folgt die nächste Frage — die die Finanzabteilung stellen wird —, ob das Team überhaupt pro Token zahlen sollte. Kapitel 15 geht die Alternative ab: Inferenz ins Haus holen, GPUs mieten oder kaufen und pro GPU-Stunde zahlen. Die Break-even-Rechnung ist sauber. Weniger sauber, und von den meisten Teams unterschätzt, ist alles auf der dedizierten Seite des Ledgers, das nicht auf der GPU-Rechnung steht: das Plattform-Engineering, die Sicherheits-Patches, die Choreographie der Modell-Upgrades, die Bereitschaft, die antwortet, wenn ein Knoten aus der Flotte fällt.

Als Nächstes — Kapitel 15: Serverlose APIs versus dedizierte Infrastruktur. Die Break-even-Formel, der versteckte Posten und hybride Haltungen, in denen beides die richtige Antwort ist.