LLM-Kosten im Griff: Monitoring und Budgetierung pro Feature und Kunde

Die Monatsrechnung des Modellanbieters ist deutlich höher als im Vormonat, und niemand kann sagen, warum. War es das neue Feature aus dem letzten Release, ein einzelner Großkunde, ein Bug, der still Anfragen wiederholt? In vielen Unternehmen existieren die Kosten für AI-Features nur als eine einzige Zahl: der Gesamtbetrag auf der Rechnung. Alles darunter ist Spekulation.

Das eigentliche Problem sind dabei selten die LLM-Kosten selbst, sondern die fehlende Sichtbarkeit. Klassische Infrastrukturkosten sind weitgehend planbar: Ein Server kostet, was er kostet, ob er ausgelastet ist oder nicht. Token-basierte Kosten dagegen skalieren mit jedem Request, mit der Kontextlänge und mit dem Verhalten der Nutzer. Ohne Zuordnung lässt sich weder budgetieren noch bepreisen. Wer nicht weiß, was ein Feature pro Kunde kostet, kann auch nicht beurteilen, ob das Geschäftsmodell dahinter trägt.

Die gute Nachricht: Die nötigen Daten fallen bei jedem API-Aufruf ohnehin an. Man muss sie nur erfassen, anreichern und auswerten.

Token-Tracking pro Request: die Datenbasis

Jede Antwort einer Modell-API enthält Verbrauchsdaten: Eingabe-Token, Ausgabe-Token, bei manchen Anbietern auch Cache-Treffer. Der erste Schritt ist, diese Werte bei jedem einzelnen Request zu persistieren, zusammen mit den Metadaten, die spätere Auswertungen erst möglich machen: Zeitstempel, Modellname, Feature-Kennung, Mandant, Nutzer und eine Request-ID für die Verknüpfung mit Logs und Traces.

Die Umrechnung in Geld gehört ebenfalls in diesen Schritt. Da Anbieter ihre Preise ändern, speichert man neben den Token-Zahlen auch die zum Zeitpunkt gültige Preistabelle oder deren Version. Sonst stimmen historische Auswertungen später nicht mehr. Aggregationen, Dashboards und Berichte bauen alle auf dieser Rohdatenebene auf. Wer sie sauber anlegt, kann jede spätere Frage beantworten. Wer nur Monatssummen speichert, kann es nicht.

Attribution: Feature, Mandant, Kunde

Damit die Zuordnung funktioniert, muss jede Aufrufstelle im Code ihre Herkunft mitgeben. Das erzwingt man am besten strukturell: Alle Modell-Aufrufe laufen durch einen zentralen Client oder ein internes Gateway, das eine Feature-Kennung und eine Mandanten-Kennung als Pflichtfelder verlangt. Ein Aufruf ohne diese Angaben schlägt fehl. Damit ist Attribution keine Frage der Disziplin einzelner Entwickler mehr, sondern eine Eigenschaft der Architektur.

Die Kundendimension ist dabei die wertvollste. Erst sie erlaubt die Fragen, die geschäftlich zählen: Was kostet uns Kunde A pro Monat im Verhältnis zu seinem Umsatz? Welche Kunden nutzen das teuerste Feature am intensivsten? Gibt es Accounts, die dauerhaft mehr kosten als sie einbringen? Wer später nutzungsbasiert bepreisen oder Kontingente einführen will, hat mit dieser Datenbasis bereits alles Nötige in der Hand.

Budgets und Alerts statt Überraschung am Monatsende

Sichtbarkeit allein verhindert keine Kostenexplosion. Dafür braucht es Budgets mit Konsequenzen. Bewährt hat sich ein zweistufiges Modell:

• Weiche Schwellen: Bei einem definierten Anteil des Monatsbudgets pro Feature oder Mandant geht eine Benachrichtigung an das verantwortliche Team. Niemand wird blockiert, aber jemand schaut hin.
• Harte Grenzen: Bei Überschreitung greift eine definierte Reaktion. Das muss kein Totalausfall sein: Oft genügt es, auf ein kleineres Modell umzuschalten, Anfragen zu verzögern oder nicht kritische Hintergrundjobs zu pausieren.

Ergänzend lohnen Anomalie-Alerts unabhängig vom Budget: Wenn die Tageskosten eines Features plötzlich ein Mehrfaches des gewohnten Werts erreichen, ist das fast immer ein Fehler in der Anwendung und kein organisches Wachstum. Je früher der Alert kommt, desto billiger der Vorfall.

Versteckte Kostentreiber aufspüren

Die auffälligsten Kostentreiber sind selten die geplanten. In der Praxis tauchen immer wieder dieselben Muster auf. Retries sind der Klassiker: Eine Retry-Logik, die bei Timeouts stumpf wiederholt, verdoppelt oder verdreifacht die Kosten eines Requests, ohne dass es irgendwo sichtbar wird. Aufgeblähte Kontexte sind der zweite: Chat-Verläufe, die ungekürzt mitwachsen, oder Retrieval-Schritte, die großzügig Dokumente in den Prompt laden, treiben die Eingabe-Token pro Request stetig nach oben. Dazu kommen Agenten-Schleifen, die mehr Iterationen drehen als nötig, und Eval- oder Testläufe, die versehentlich gegen das teuerste Modell laufen.

Ein einfaches Ritual hilft: regelmäßig die teuersten Einzel-Requests und die Features mit dem stärksten Kostenwachstum ansehen. Ein Blick auf die zehn teuersten Requests der Woche erklärt oft mehr als jedes Dashboard.

Reporting, das die Geschäftsführung versteht

Token-Zahlen interessieren außerhalb des Entwicklungsteams niemanden. Ein brauchbarer Monatsbericht übersetzt sie in Geschäftsgrößen und passt auf eine Seite: Kosten pro Feature mit Trend zum Vormonat, Kosten pro aktivem Kunden, und wo verfügbar eine Gegenüberstellung mit einer Wertgröße, etwa bearbeiteten Vorgängen oder eingesparten Bearbeitungsminuten. Erst dieser Vergleich macht aus einer Kostenzahl eine Entscheidungsgrundlage: Ein Feature, das viel kostet und viel Arbeit ersetzt, ist ein anderes Thema als eines, das viel kostet und kaum genutzt wird.

Wichtig ist auch die Sprache: nicht Token und Modellversionen, sondern Stückkosten und Trends. Die Frage, die der Bericht beantworten muss, lautet: Entwickeln sich die Kosten proportional zum Nutzen, und wo nicht?

Fazit

Kostenkontrolle für AI-Features beginnt nicht bei Optimierungstricks, sondern bei Sichtbarkeit. Die Reihenfolge ist klar: Verbrauchsdaten pro Request mit Feature- und Kundenkennung erfassen, die Attribution architektonisch erzwingen, Budgets mit weichen und harten Schwellen hinterlegen und die üblichen Verdächtigen wie Retries und wachsende Kontexte regelmäßig prüfen. Das Reporting übersetzt am Ende alles in Stückkosten, die auch ohne technisches Vorwissen verständlich sind. Wer das etabliert hat, diskutiert am Monatsende nicht mehr über eine überraschende Rechnung, sondern über gezielte Entscheidungen.