LLM-Kosten und Latenz optimieren: Caching, Routing, Modellwahl

Im Pilotbetrieb spielt die Modellrechnung selten eine Rolle. Ein paar hundert Anfragen am Tag, die Antworten kommen schnell genug, das Thema wirkt erledigt. Mit dem Rollout dreht sich das Bild: Die Anfragen vervielfachen sich, die Prompts sind über Monate gewachsen, und plötzlich sind LLM-Kosten und Latenz ein Betriebsthema, das über die Wirtschaftlichkeit des Features entscheidet.

Die gute Nachricht: Beides ist gestaltbar, und zwar mit denselben Hebeln. Kosten und Latenz hängen an Tokenmengen, Modellwahl und Aufrufstruktur. Wer diese drei Größen versteht und misst, kann sie gezielt senken, ohne die Qualität zu opfern. Wer sie ignoriert, optimiert am Ende hektisch unter Kostendruck, und das geht fast immer zulasten der Qualität.

Kostentreiber verstehen: Tokens, Modellklasse, Retries

Die Abrechnung von Sprachmodellen folgt einem einfachen Prinzip: bezahlt wird pro Token, getrennt nach Eingabe und Ausgabe, zu einem Satz, der von der Modellklasse abhängt. Daraus ergeben sich die typischen Kostentreiber:

• Aufgeblähte Eingaben: Systemprompts, Werkzeugdefinitionen und Kontextdokumente werden bei jedem Aufruf mitgeschickt. Ein über Monate gewachsener Prompt mit toten Anweisungen und redundanten Beispielen kostet bei jeder einzelnen Anfrage mit.
• Unbegrenzte Ausgaben: Ausgabetokens sind teurer als Eingabetokens. Antworten ohne Längenvorgabe, ausschweifende Begründungen und unnötig gesprächige Formate summieren sich.
• Die Modellklasse: Der Preisunterschied zwischen der kleinsten und der größten Modellklasse eines Anbieters ist erheblich. Jede Anfrage, die ein großes Modell beantwortet, obwohl ein kleines gereicht hätte, ist verschenktes Geld.
• Retries und Agentenschleifen: Der verstecktste Treiber. Fehlgeschlagene Aufrufe, Validierungsfehler mit erneutem Versuch und Agenten, die zu viele Schritte drehen, multiplizieren alle anderen Faktoren.

Der erste Schritt ist deshalb keine Optimierung, sondern Transparenz: Kosten pro Feature und pro Vorgang erheben, nicht nur die Monatsrechnung des Anbieters lesen.

Prompt-Caching gezielt einsetzen

Die meisten Anfragen eines Features beginnen identisch: derselbe Systemprompt, dieselben Werkzeugdefinitionen, oft dieselben Referenzdokumente. Prompt-Caching nutzt das aus. Der Anbieter legt den unveränderten Anfang des Prompts zwischen und verarbeitet ihn bei Folgeaufrufen nicht erneut, was wiederholte Aufrufe deutlich günstiger und schneller macht.

Damit das greift, muss der Prompt dafür gebaut sein. Die Regel lautet: Statisches nach vorn, Variables nach hinten. Systemanweisung, Werkzeuge und feste Dokumente bilden den stabilen Anfang, die Nutzereingabe und der Gesprächsverlauf kommen ans Ende. Schon eine kleine Änderung im vorderen Teil, ein dynamischer Zeitstempel etwa oder eine pro Anfrage wechselnde Kundennummer im Systemprompt, macht den Zwischenspeicher wertlos. In der Praxis zeigt sich, dass gerade solche gut gemeinten Dynamisierungen die häufigste Ursache für wirkungsloses Caching sind.

Routing: kleines Modell zuerst, großes bei Bedarf

Nicht jede Anfrage braucht das stärkste Modell. Klassifikation, Extraktion strukturierter Daten, Umformulierungen und Routinefragen erledigt eine kleine Modellklasse zuverlässig, schneller und zu einem Bruchteil der Kosten. Das Muster dazu heißt Modell-Routing: Anfragen werden nach Schwierigkeit sortiert, das kleine Modell übernimmt den Normalfall, das große die schweren Fälle.

Die Eskalation lässt sich an harten Signalen festmachen: Die Ausgabe des kleinen Modells besteht die Formatvalidierung nicht, eine Konfidenzprüfung schlägt an, oder die Anfrage fällt in eine Kategorie, die von vornherein dem großen Modell zugeordnet ist. Wichtig ist, das Routing nicht nach Gefühl einzuführen, sondern auf Basis von Evals: Erst wenn ein Prüffall-Katalog zeigt, welche Fallklassen das kleine Modell sicher beherrscht, wird umgeleitet. Sonst tauscht man sichtbare Kosten gegen unsichtbare Qualitätsverluste.

Latenz-Budgets pro Schritt

Latenz wird meist erst behandelt, wenn sich Nutzer beschweren. Besser ist der umgekehrte Weg: ein Budget definieren, bevor gebaut wird. Wie lange darf die Interaktion aus Nutzersicht insgesamt dauern, und wie verteilt sich diese Zeit auf die Schritte, also Retrieval, Modellaufrufe, Werkzeugaufrufe, Nachbearbeitung. Ein solches Budget macht Zielkonflikte früh sichtbar: Wer drei Modellaufrufe hintereinander plant, weiß sofort, dass eine Antwort unter wenigen Sekunden nicht erreichbar ist.

Für die Einhaltung gibt es bewährte Techniken. Streaming zeigt die Antwort, während sie entsteht, und verbessert die gefühlte Wartezeit erheblich. Unabhängige Aufrufe laufen parallel statt nacheinander. Agentenläufe bekommen eine Obergrenze an Schritten. Und die Modellwahl wirkt doppelt: Kleine Modelle antworten nicht nur günstiger, sondern auch spürbar schneller, was das Routing zum Latenzhebel macht.

Messung im Betrieb

Alle genannten Hebel wirken nur, wenn ihre Wirkung sichtbar ist. Dafür braucht es je Anfrage eine kleine, konsequent erfasste Datenspur: Eingabe- und Ausgabetokens, Cache-Treffer, verwendetes Modell, Dauer je Schritt, Anzahl der Versuche, zugehöriges Feature. Aus diesen Rohdaten entstehen die Kennzahlen, die Entscheidungen tragen: Kosten pro Vorgang statt Kosten pro Monat, und bei der Latenz die Verteilung statt des Durchschnitts, denn der Durchschnitt versteckt genau die langsamen Anfragen, über die sich Nutzer beschweren.

Dazu gehören Alarmgrenzen: Wenn die Kosten pro Vorgang oder die Fehlversuchsrate über den gewohnten Bereich steigen, will man das am selben Tag wissen, nicht am Monatsende. Solche Sprünge sind fast immer ein Symptom, etwa ein Prompt, der das Caching bricht, ein Werkzeug mit erhöhter Fehlerrate oder ein Routing, das zu oft eskaliert.

Fazit

LLM-Kosten und Latenz sind keine Naturkonstanten, sondern Ergebnis von Architekturentscheidungen: schlanke Prompts mit stabilem, cachebarem Anfang, ein Routing, das die Modellklasse der Aufgabe anpasst, Latenz-Budgets, die vor dem Bau festgelegt werden, und eine Messung, die Kosten und Antwortzeiten pro Vorgang sichtbar macht. Wer diese Hebel früh verankert, betreibt AI-Features, die auch bei wachsender Last wirtschaftlich bleiben. Wer sie aufschiebt, bezahlt die Nachrüstung doppelt: in Geld und in Qualität.