Kapitel 16 — Kostenreduktion in der Produktion

Veröffentlicht am: 2026-05-08 Zuletzt aktualisiert am: 2026-07-07 Version: 1
Kapitel 16 — Kostenreduktion in der Produktion

Kapitel 16 — Kostenreduktion in der Produktion

Letzter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Der Katalog orthogonaler Züge, die sich zu einem Drittel oder einer Hälfte der Rechnung des letzten Monats aufschichten.


Warum es dieses Kapitel gibt

Die beiden vorherigen Kapitel haben dem Team gezeigt, wohin das Geld fließt, und einen Rahmen gegeben, um zu entscheiden, auf welcher Seite der API-versus-Dediziert-Linie es sitzen soll. Dieses Kapitel ist der Katalog der Züge, die das Team machen kann, sobald diese Entscheidungen gefallen sind. Die Züge sind weitgehend haltungsunabhängig — sie sparen Geld auf einer API, sie sparen Geld auf dedizierter Hardware, sie sparen Geld in einer Hybridanordnung — und sie schichten sich auf. Teams, die sie der Reihe nach übernehmen, finden sechs Monate in eine gezielte Kosten­anstrengung regelmäßig, dass ihre Inferenzrechnung ein Drittel bis eine Hälfte dessen ist, was sie vorher war. Keiner der Züge ist exotisch; alle erfordern bewusste Ingenieursarbeit; die Kosten, sie zu bauen, sind klein im Vergleich zu dem, was sie sparen.

In einem Satz: Routing, Verdichtung, Batch, Cache, Prompt-Audit, Output-Budget — vier bis sechs unabhängige Züge, die sich zu einer 80-Prozent-Reduktion vervielfachen, ohne dass sich für den Nutzer etwas ändert.

16.1 Intelligentes Modell-Routing ist der größte einzelne Hebel

Produktions-Traffic ist nicht gleich schwer. Die Hälfte oder mehr der Anfragen ist einfach genug für ein Budget-Modell, das eine Größenordnung günstiger als das Frontier-Modell ist; ein kleinerer Anteil braucht wirklich das Frontier. Ein Team, das alles zum Top-Modell schickt, überbezahlt die einfachen Fälle um das 10- bis 20-Fache. Die richtige Architektur ist ein Router, der jede Anfrage klassifiziert und an die günstigste Stufe versendet, die sie bewältigt. Der Kostengradient liegt zum Zeitpunkt der Niederschrift bei etwa 30:1 auf Input und 20:1 auf Output zwischen Frontier (15–30 Dollar/M Output) und Budget (0,10–1 Dollar/M). Die Router-Optionen reichen von einer Heuristik auf Anfrageform (Länge, Format, Tool-Use-Marker) über einen kleinen Budget-Tier-Klassifikator, der ein Stufenlabel ausgibt, bis zu einem gelernten Router, der auf historischen Daten trainiert ist, welches Modell tatsächlich funktioniert hat. Design-Vorgaben: günstig und schnell (unter 100 ms, ein Zehntel Cent), beobachtbar (jede Entscheidung mit Features und Ergebnis geloggt), sicher als Standard (bei Unsicherheit nach oben routen — die Kosten von zu hohem Routing ist ein zusätzlicher Dollar, die Kosten von zu niedrigem Routing eine sichtbare Qualitätsregression).

16.2 Verdichtung, Batch-APIs und semantisches Caching holen jeweils große Stücke zurück

Kontextverdichtung greift das quadratische Input-Wachstum an, das Kapitel 14 benannt hat. Die einfachste Form ist ein rollendes Fenster: die letzten K Turns wortgetreu behalten, alles davor durch eine Budget-Tier-Zusammenfassung ersetzen; der Zusammenfassungs­aufruf kostet einen Bruchteil eines Cents und schrumpft den Input auf jedem folgenden Turn von tausenden wortgetreuen Historie-Tokens auf hunderte Zusammenfassungs­tokens. Ein raffinierter Verdichter bewahrt bestimmte Arten wortgetreu (Code, Tool-Ausgaben, vom Nutzer bereitgestellte Daten) und fasst den Rest zusammen. Asynchrone Batch-APIs zum halben Preis handhaben jede Arbeitslast ohne synchrones Latenzbudget — nächtliche Zusammenfassungen, Neuklassifizierung, Vorab-Erzeugung für einen A/B-Test, Embedding-Refresh —; die Kategorie ist größer, als Teams anfangs erkennen, und die Ingenieursarbeit, eine Arbeitslast auf Batch umzuziehen, ist trivial. Semantisches Caching antwortet, bevor das Modell aufgerufen wird: jede Anfrage einbetten, in einem Vektor­index früherer Anfrage-Antwort-Paare nachschlagen, die gecachte Antwort zurückgeben, wenn die Ähnlichkeit eine Schwelle überschreitet. Zwei Nutzer, die „was ist die Rückgabepolitik" und „wie schicke ich einen Artikel zurück" fragen, treffen denselben Eintrag. Auf FAQ-artigem Traffic sind Cache-Trefferraten von 30–50 Prozent Routine, und das günstigste Token ist das, das nie erzeugt wurde.

16.3 Die Züge multiplizieren sich, sie addieren sich nicht

Nimm einen Agenten, dessen Rechnung bei 1.000 Anfragen pro Tag auf 4.000 Dollar/Monat gewachsen ist. Routing: 60 Prozent Budget, 30 Prozent Mitte, 10 Prozent Frontier → gemischte Kosten fallen auf 28 Prozent der Frontier-Rate, die Rechnung sinkt auf 1.100 Dollar. Verdichtung: Input-Aufblähung halbiert, die Rechnung sinkt auf 770 Dollar. 20 Prozent auf Batch verschoben: 720 Dollar. Semantisches Caching mit 25 Prozent Trefferrate: 540 Dollar. Von 4.000 auf 540 Dollar — eine Reduktion um 86 Prozent — ohne dass sich für den Nutzer etwas ändert. Zwei weitere Züge verdienen ihren Platz auch ohne eigenen Abschnitt. Ein Prompt-Audit — jeden Prompt mit frischem Blick zu lesen und alles zu löschen, was seine Tokens nicht rechtfertigen kann — findet typisch 10–20 Prozent Ausgaben, die ohne Verhaltensänderung zu streichen sind. Ein expliziter max_tokens-Deckel verhindert, dass eine Antwort auf 2.000 Tokens ausrollt, wenn die Anwendung nur 300 brauchte — fast eine 7-fache Überzahlung auf dieser Anfrage. Das mentale Modell ist das von Band IV: jede Anfrage hat Stückkosten, und die Ingenieuraufgabe ist, jede Anfrage durch die günstigen Schichten zuerst zu leiten und die teure Schicht nur dann zu erreichen, wenn es nötig ist.

Wert, das festzuhalten: Kosten sind eine Ingenieurskennzahl. Die Teams, die ihre Rechnung um eine Größenordnung senken, haben die Kosten so ernst genommen wie die Latenz — sie zerlegt, instrumentiert, die Routing-, Caching- und Verdichtungs­schichten gebaut und gemessen. Die anderen warteten, bis die Finanzabteilung es bemerkt.

Was Kapitel 16 abschließt

Der Band öffnete mit dem autoregressiven Engpass — der unaufhebbaren Tatsache, dass LLM-Erzeugung sequenziell ist und dass die Hardware, die so gut in paralleler Arithmetik ist, den größten Teil ihrer Zeit damit verbringt, auf Speicher zu warten. Jedes Kapitel danach war eine Antwort auf diese zentrale Tatsache auf einer anderen Ebene des Stacks. Hardware-Kapitel bauten das physische Substrat auf. Modellseitige Kapitel schrumpften das Modell. Systemseitige Kapitel holten maximale nützliche Arbeit aus jedem Taktzyklus. Engine- und Orchestrierungs-Kapitel brachten das in Produktion. Ökonomie-Kapitel beschrieben, wie das Team, das das System betreibt, dafür zahlt. Jede Schicht ist eine Antwort auf die vorhergehende, und die Disziplin, LLMs im Maßstab zu betreiben, besteht darin, alle Schichten von denselben Menschen integrieren zu lassen — oder zumindest von Menschen, die sich im selben Vokabular unterhalten können.

Das Buch endet hier. Die Reihe setzt sich mit Band VII — KI-Sicherheit fort, dem abschließenden Band, der die Produktions-Engineering-Disziplin dieses Bandes auf Bedrohungsmodellierung, Guardrails, das Sandboxing modell-erzeugten Codes, die Minderung von Prompt-Injektionen, Ausgabefilterung und die Regulierung erweitert, die inzwischen mitentscheidet, wie all das eingesetzt werden darf. Die in diesem Band aufgebaute Infrastruktur — die Inferenzflotte, die Routing-Schicht, die Sandboxes, die Agenten-Ausführungs­umgebungen — ist genau die Infrastruktur, auf der die Sicherheitsanliegen von Band VII sich abspielen. Skalierung und Sicherheit sind zwei Seiten desselben Problems: die eine ist die Ingenieursarbeit des Wachsens, die andere die der Widerstandsfähigkeit gegen die Angriffe, die dieses Wachstum einlädt.

Möchtest du das ganze Bild? Das Buchkapitel enthält die lauffähigen ModelRouter-, ConversationCompactor-, BatchJobBuilder- und SemanticCache-Klassen, die vollständig durchgerechnete Spur von 4.000 auf 540 Dollar, die Prompt-Audit-Checkliste und die abschließende Reflexion über die Trajektorie der Inferenzkosten, die dieser Artikel nur zusammenfassen kann. LLM Primer VI auf Amazon →

SHO
SHO