Kapitel 15 — Serverlose APIs versus dedizierte Infrastruktur

Fünfzehnter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel legt die Break-even-Rechnung auf den Tisch und benennt dann den Posten Plattform-Engineering, der die Antwort für die meisten Teams kippt.

Warum es dieses Kapitel gibt

Kapitel 14 hat das Team mit einem klaren Bild davon zurückgelassen, woraus die API-Rechnung besteht, und einem stillen Verdacht, dass es billiger ginge. Die naheliegende nächste Frage ist, ob das Team überhaupt pro Token zahlen sollte. Die Alternative ist, Inferenz ins Haus zu holen, ein Open-Weight-Modell auf dem in früheren Kapiteln beschriebenen Stack zu betreiben und pro GPU-Stunde zu zahlen. Der Handel hat einen sauberen Break-even-Punkt. 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, der 3-Uhr-morgens-Alarm, wenn ein Knoten aus der Flotte fällt. Kapitel 15 nimmt beide Seiten ernst und leitet ab, wann Selbstbetrieb die richtige Antwort ist.

15.1 Die Break-even-Formel ist sauber und meist eine Nebelkerze

Die GPU produziert Durchsatz × Auslastung × 3.600 Output-Tokens pro Stunde. Ihre Kosten pro Million Tokens sind (gpu_hourly / tokens_per_hour) × 1.000.000. Der Break-even gegen die API liegt dort, wo diese Zahl den Millionenpreis der API erreicht. Ein 70B-Modell in FP8 auf einer H100 zu 3 Dollar pro Stunde, das aggregiert 800 Tokens pro Sekunde bei 60 Prozent Auslastung liefert, landet bei grob 1 Dollar pro Million Output-Tokens. Die Frontier-API berechnet 15. Die scheinbaren Ersparnisse betragen 14× — ein Argument für Selbstbetrieb, das der Finanzabteilung gefällt und das den zweiten, größeren Posten verpasst. Der Break-even hängt auch an der Auslastung; unter 20–30 Prozent Auslastung steigen die Selbstbetriebskosten pro Million über die API-Rate, und die GPU ist teurer als die Alternative, die sie ersetzen sollte. Die Auslastung wiederum ist eine Funktion der Traffic-Form, der Qualität des Autoscalings und der Frage, ob das Team mehr als eine Arbeitslast auf dieselbe Flotte packen kann.

15.2 Plattform-Engineering ist der Posten, der den Deal entscheidet

Die GPU-Rechnung ist die kleinere Hälfte. Die größere ist das Team, das die Flotte am Laufen hält: Engines, Treiber, Orchestrierung, Autoscaling, Observability, Sicherheit. Das API-Team zahlt diese Kosten implizit über den Preis pro Token; das Selbstbetriebs-Team zahlt sie in Köpfen. Eine nützliche Faustregel: eine einzelne Serving-GPU-Flotte — ein oder zwei Modellvarianten, Autoscaling, Observability, Bereitschaft, quartalsweise Upgrades — benötigt grob eine Vollzeit-Plattform-Ingenieurin plus einen Bruchteil eines SREs. Eine vielfältigere Flotte — mehrere Engines, mehrere Modelle, Multi-Tenant-Scheduling — benötigt zwei bis vier. Bei voll belasteten 300.000 Dollar pro Ingenieurin liegt die jährliche Plattform­rechnung bei 300.000 bis 1,2 Millionen Dollar. Der Break-even-Monatstraffic, ab dem Selbstbetrieb sich rechnet, liegt irgendwo zwischen 200 Millionen und 1 Milliarde Output-Tokens pro Monat. Darunter übersteigt der Engineering-Overhead die Token-Ersparnisse, und das Team sollte bei einer API bleiben. Darüber dominieren die Ersparnisse. Plattform-Engineering kommt zudem in Stufenfunktionen, nicht in glatten Kurven: die erste Einstellung bringt die Flotte hoch, die zweite kommt, weil die erste die Wochenend-Bereitschaft nicht abdecken kann, die dritte, wenn die Flotte auf Multi-Region wächst.

15.3 Die realistische Haltung ist hybrid, und der Router ist das tragende Stück

Die sauberste Entscheidung — alles API oder alles dediziert — ist für ein Team, das mehr als ein Jahr in Produktion ist, selten die richtige. Stationär vorhersagbare Arbeitslasten (nächtliche Batches, geplante Reports, Klassifizierungs­queues) packen sich gut auf geplante dedizierte Kapazität. Bursty Arbeitslasten (virale Peaks, Ticketfluten, Neu-Kohort-Launches) brauchen API-Elastizität. Latenz­strenge Arbeitslasten (interaktive Vervollständigung, Sprache) profitieren von einem kolokierten dedizierten Deployment. Latenz­lose Arbeitslasten (nächtliches Anreichern, Reindexing) profitieren von Batch-APIs zum halben Preis. Die Architektur, die Hybridbetrieb trägt, ist ein Router an der Anwendungsgrenze, der jede Anfrage nach Latenzbudget, Komplexität und aktueller Backend-Auslastung klassifiziert und an das günstigste Backend versendet, das ihr SLA erfüllt. Ein verfeinerter Router betreibt zusätzlich modellinternes Routing innerhalb der API (günstiges Modell für einfache Anfragen, Frontier für komplexe, Reasoning-Stufe für die, die es brauchen). Der Zweitnutzen ist Optionalität: Arbeitslasten wandern über die Grenze, indem die Router-Policy geändert wird, nicht der Anwendungscode. Und der dedizierte Fall rechnet sich häufig erst, weil eine zweite Arbeitslast — eine, die sonst zur API gegangen wäre — auf der bereits bezahlten GPU mitreitet. Ein Team, das Dediziert an einer einzelnen Arbeitslast bewertet, macht den Umstieg meist nie; ein Team, das in Arbeitslast-Portfolios denkt, tut es und spart.

Was Kapitel 15 vorbereitet

Kapitel 15 hat eine Klasse Arbeitslasten benannt, die Agenten hineingebracht haben und die weder zu „API-Aufruf" noch zu „Modell-Serving" passt: die Ausführungs­umgebung für LLM-generierten Code, die je nach Isolations- und Paketflexibilität, die der Agent braucht, auf serverlosen Funktionen, MikroVMs (Firecracker, gVisor) oder WASM-Sandboxes lebt. Kapitel 16 schließt den Band mit dem Katalog der Kostensenkungszüge ab, die auf beiden Seiten der Haltungslinie greifen: intelligentes Modell-Routing, anwendungsseitige Kontextverdichtung, Batch-APIs, semantisches Caching — die Züge, die sich zu einem Drittel oder einer Hälfte der Rechnung des letzten Monats aufschichten.

Als Nächstes — Kapitel 16: Kostenreduktion in der Produktion. Die multiplikativen Züge, die aus der Rechnung des letzten Monats die Ersparnis des nächsten machen.