LLM-Kostenmonitoring: Wie man das AI-Budget nicht verbrennt

Die AI-Rechnung explodiert selten aus einem einzigen Grund. Meist wächst sie leise: etwas längere Kontexte, ein paar Prozent Retries, Embeddings bei jeder Anfrage, ein System-Prompt, der an jeden Aufruf angehängt wird. Nach einem Quartal zahlt das Unternehmen doppelt so viel und kann nicht benennen, was genau das Budget verschlingt. FinOps für LLM beginnt mit einer Grundannahme: Was man nicht aufgeschlüsselt misst, lässt sich nicht optimieren.

Die globale Cloud-Rechnung sagt nur, dass es teuer ist – nicht, was wirklich kostet. Ein sinnvolles Monitoring zerlegt die Ausgaben in drei Achsen. Pro Token zeigt das Verhältnis von Eingabe- zu Ausgabetokens und erfasst aufgeblähte Kontexte. Pro Funktion ordnet die Kosten einer konkreten Aufgabe zu: Klassifizierung, Zusammenfassung, RAG-Antwort, Generierung von Berichten. Pro Nutzer (oder pro Kunde, pro Team) deckt auf, dass 5% der Konten 40% der Rechnung verursachen.

Erst diese drei Perspektiven zusammen ermöglichen eine Entscheidung. Wenn eine Funktion die Hälfte des Budgets verschlingt, optimierst du genau diese – nicht das gesamte System gleichmäßig. Dieselbe Logik wenden wir beim Monitoring der KI-Agenten-Qualität an – ohne Zuordnung pro Aufgabe ist die Messung Dekoration, kein Werkzeug.

Der Großteil des verbrannten Budgets stammt nicht vom „zu großen Modell“, sondern von Stellen, die niemand im Blick hat. Hier die häufigsten.

Am tückischsten sind lange Kontexte und System-Prompts, weil sie unsichtbar sind – sie wirken wie ein „normaler“ Aufruf, multiplizieren aber im Hintergrund die Eingabetokens bei jeder Anfrage. Ein kürzerer System-Prompt und ein auf das Nötigste reduzierter Kontext bringen oft größere Einsparungen als ein Modellwechsel.

Zwei Hebel bringen den schnellsten Return. Der erste ist der semantische Cache: Fragen mit ähnlicher Bedeutung werden aus dem Puffer bedient, statt an das Modell gesendet. In FAQ- und Kundenservice-Szenarien ist die Wiederholungsrate hoch, sodass die Trefferquote signifikant sein kann – statt voller Inferenz antwortest du aus dem Cache. Das Prinzip ist einfach: Zahlen einmal, mehrmals antworten.

Der zweite Hebel ist das Routing zum günstigeren, ausreichenden Modell. Nicht jede Aufgabe benötigt das größte Modell. Klassifizierung von Tickets, Extraktion von Feldern aus Formularen oder kurze Zusammenfassungen funktionieren mit kleinen, günstigen Modellen; das leistungsstarke Modell reservierst du für Aufgaben, die es wirklich erfordern. Das übernimmt der LLM-Router – eine einzige Entscheidung, die oft die variablen Kosten um 40-70% senkt, ohne spürbaren Qualitätsverlust. Wie man das Modell für die Aufgabe auswählt, zerlegen wir in einem separaten Leitfaden.

Optimierung ohne Bremsen ist nur die halbe Miete. Die andere Hälfte sind Budgets und Alerts, die die Rechnung stoppen, bevor es teuer wird. In der Praxis setzen wir einige einfache Mechanismen ein:

• Tägliches und monatliches Budget pro Funktion und pro Kunde, mit weicher Schwelle (Alert) und harter (Degradierung auf ein günstigeres Modell oder Throttling).
• Alert bei Anomalien – ein plötzlicher Kostensprung pro Nutzer deutet meist auf eine Retry-Schleife, Missbrauch oder einen undichten Kontext hin.
• Tagging jedes Aufrufs mit Funktions- und Tenant-ID, damit die Attribution automatisch erfolgt, nicht manuell.
• Kill-Switch auf Observability-Ebene, der teure Funktionen abschaltet, ohne das gesamte System lahmzulegen.

Diese Mechanismen ersetzen keine Optimierung – sie sorgen dafür, dass ein Fehler im Code oder ungewöhnlicher Traffic einen guten Monat nicht in ein verbranntes Budget verwandelt. Die Stückkosten berechnen wir genauso wie bei der Bewertung eines KI-Agenten: pro erledigte Aufgabe, nicht für einen abstrakten „AI-Monat“.

Die Frage „eigener Betrieb oder Cloud-API“ ist eine Frage des Volumens, nicht der Ideologie. Bei geringem und unregelmäßigem Traffic gewinnt die Cloud – du zahlst nach Verbrauch, keine Einstiegskosten, kein Wartungsaufwand. Bei konstant hohem Traffic beginnt Self-Hosting zu gewinnen: Die Amortisation der Hardware und die eigene Inferenz führen zu niedrigeren und – was noch wichtiger ist – vorhersehbaren Stückkosten.

Der Break-even-Punkt hängt von der Anzahl der monatlichen Aufrufe ab und davon, ob du jemanden hast, der die Infrastruktur betreibt. Wir nennen keine konkrete Zahl, weil sie erfunden wäre – die Grenze verschiebt sich mit jeder Hardware-Generation und jeder Änderung der Cloud-Preise. Deshalb wählen wir die Variante basierend auf der tatsächlichen Auslastung, indem wir die Stückkosten in beiden Varianten messen, bevor wir etwas dauerhaft umstellen.

Bei der Attribution: Jeder Aufruf wird mit Funktion, Tenant und der Anzahl der Eingabe- und Ausgabetokens getaggt. Ohne das siehst du nur die globale Rechnung und weißt nicht, was zu optimieren ist. Erst wenn du die Kosten pro Funktion und pro Nutzer hast, wird die Wahl der Hebel (Cache, Routing, kürzerer Kontext) offensichtlich.

Meistens nicht das Modell selbst, sondern lange Kontexte und System-Prompts, die an jeden Aufruf angehängt werden, fehlender Cache bei wiederholten Fragen und Retry-Schleifen. Diese Kosten sind versteckt, weil jeder einzelne Aufruf normal aussieht – sie summieren sich erst im Traffic-Maßstab.

Aus unserer Erfahrung senkt das Routing zu einem günstigeren, ausreichenden Modell die variablen Kosten meist um 40-70%, und der semantische Cache kann in Szenarien mit wiederholten Fragen zwischen 15% und über 50% der Aufrufe übernehmen. Der Gesamteffekt hängt vom Traffic-Profil ab, also betrachte diese Spanne als Orientierung, nicht als Versprechen.

Am Anfang nicht – konsequentes Logging der Kosten pro Aufruf und ein einfaches Dashboard mit Budgets und Alerts reichen aus. Dedizierte Tools machen bei vielen Modellen, vielen Teams und hohem Volumen Sinn. Entscheidend ist die Disziplin bei der Attribution, nicht die Marke des Tools.

Bei konstant hohem Volumen und dort, wo Vorhersehbarkeit der Kosten und Datenresidenz zählen. Bei geringem oder unregelmäßigem Traffic gewinnt die Cloud meist durch fehlende Einstiegskosten. Die Grenze bestimmt dein Volumen – berechne die Stückkosten in beiden Varianten, bevor du dich entscheidest.