Ein Pilot, der ein paar hundert Dollar im Monat kostet, sagt Ihnen so gut wie nichts darüber, was dasselbe System im Produktivbetrieb kostet. Die Demo verarbeitet eine Handvoll Anfragen pro Tag gegen einen sauberen Prompt. Der Produktivbetrieb verarbeitet Tausende, gegen einen Kontext, der unbemerkt gewachsen ist, mit Wiederholungsversuchen, die Sie längst vergessen hatten. Die Rechnung trifft zum Quartalsende ein, und jemand in der Finanzabteilung stellt die einzige Frage, auf die es ankommt: Was kostet eine einzelne Anfrage, und warum genau dieser Betrag?
Wenn Sie das nicht beantworten können, haben Sie keine LLM-Kostenkontrolle. Sie haben eine monatliche Überraschung. Und in der Finanzwelt ist ein unerklärlicher Posten nicht nur unangenehm, sondern genau die Art von Befund, der ein Projekt auf Eis legt, während alle nach der Ursache suchen.
Wohin das Geld tatsächlich fließt
Der plakative Preis pro Million Token ist der Teil, den jeder liest, und der Teil, der am wenigsten ins Gewicht fällt. Die Kosten stecken darin, wie viele Token Sie durchschleusen, wie oft, und für wie viel davon Sie doppelt bezahlen.
In der Praxis treiben einige wenige konkrete Faktoren die Rechnung:
- Überdimensionierter Kontext. Das gesamte Dokument, die gesamte Historie und ein großzügiger System-Prompt in jeden Aufruf gepackt, weil das Kürzen riskant schien. Sie bezahlen für jedes Token in jedem Aufruf, auch für die, die das Modell nie gebraucht hat.
- Zu viele Aufrufe. Ketten, die fünf Modellaufrufe machen, wo zwei genügt hätten, oder ein Agent, der dieselbe Teilfrage erneut stellt, weil sich niemand die Antwort gemerkt hat.
- Wiederholungsversuche. Ein Timeout, eine fehlerhafte JSON-Antwort, ein Backoff wegen Ratenbegrenzung. Jeder Wiederholungsversuch ist ein vollwertiger zweiter Aufruf zum vollen Preis, und solche Versuche häufen sich genau dann, wenn das System unter Last steht und Sie am wenigsten hinschauen.
- Ausgabe-Token. Üblicherweise teurer bepreist als die Eingabe und am leichtesten aus dem Ruder laufend, wenn niemand die Antwortlänge begrenzt hat.
Keiner dieser Posten taucht als eine einzelne große Zahl auf. Sie tauchen als Kosten je Anfrage auf, die zwei- oder dreimal so hoch sind, wie es das Architekturdiagramm nahegelegt hat.
Maßnahmen, die die Rechnung bewegen
Wenn Sie erst einmal wissen, wohin das Geld fließt, sind die Korrekturen konkret und größtenteils unspektakulär.
Prompt-Caching ist der erste Hebel und oft der größte. Wenn sich ein langer System-Prompt oder ein fester Anweisungsblock über mehrere Aufrufe wiederholt, bedeutet Caching, dass Sie nicht jedes Mal den vollen Eingabepreis für dieselben Token zahlen. Dieselbe Logik gilt für das Retrieval: Cachen Sie die abgerufenen Passagen für wiederkehrende Fragen, statt bei jedem Treffer neu zu embedden und neu abzurufen. Caching hilft nur dort, wo der Präfix wirklich stabil ist, daher lohnt es sich, Prompts so zu strukturieren, dass der stabile Teil vorne steht.
Batch-Verarbeitung ist der zweite Hebel. Viele Finanz-Workloads sind nicht interaktiv. Die Extraktion aus Geschäftsberichten über ein ganzes Universum, der nächtliche Abgleich, das Nachladen von Begründungscodes für eine Prüfung nachteiliger Entscheidungen. Diese Aufgaben brauchen keine Antwort im Sekundenbruchteil, also können sie über einen Batch-Pfad laufen, den die Anbieter deutlich günstiger bepreisen als den Live-Pfad. Die Arbeit in “ein Mensch wartet” und “das läuft über Nacht” zu sortieren, ist in der Regel die größte verfügbare strukturelle Einsparung.
Modell-Routing ist der dritte Hebel. Nicht jede Teilaufgabe braucht das größte Modell. Entitätsauflösung, eine Ja/Nein-Klassifikation, eine kurze Umformulierung, ein erster Filter vor dem teuren Reasoning-Schritt. Leiten Sie diese an ein kleineres, günstigeres Modell weiter und halten Sie das große für die Arbeit zurück, die es tatsächlich erfordert. Das Risiko ist eine Qualitätsabweichung bei den heruntergestuften Aufgaben, daher braucht jede Route ihr eigenes Eval-Set und eine Kontrolle, dass die Genauigkeit hält. Günstiger ist nur dann günstiger, wenn die Antwort weiterhin stimmt.
Und dann ist da der Kontext selbst. Besseres Retrieval ist eine Kostenmaßnahme, nicht nur eine Qualitätsmaßnahme. Engeres Retrieval, das drei relevante Passagen statt zwanzig zurückgibt, senkt die Eingabe-Token bei jedem Aufruf und verbessert in der Regel zugleich die Antwort. Das Beschneiden des Kontexts ist der Punkt, an dem sich gutes Retrieval doppelt auszahlt.
Kosten zur erstklassigen Kennzahl machen
Was all das zusammenhält, ist die Messung. Die Kosten je Aufruf müssen eine Kennzahl sein, die Sie neben Latenz und Genauigkeit erfassen, aufgeschlüsselt nach Route, nach Funktion und nach Token-Typ. Ohne sie ist jede oben genannte Einsparung eine Vermutung und jede Verschlechterung unsichtbar, bis die Rechnung eintrifft.
Behandeln Sie sie so, wie Sie jede Zahl behandeln würden, die am Ende vor einem Prüfer landet. Sie wollen Nachvollziehbarkeit bei den Kosten: welches Modell, wie viele Eingabe- und Ausgabe-Token, Cache-Treffer oder -Fehlversuch, wie viele Wiederholungsversuche. Wenn die Finanzabteilung fragt, warum sich die Kosten je Anfrage in diesem Quartal verändert haben, sollte die Antwort eine Datenbankabfrage sein, kein Meeting.
Das ist der Maßstab, an dem es sich lohnt, das System zu messen. Kosten je Anfrage, die Sie ablesen, erklären und verteidigen können, halten den Fragen eines CFO stand. Eine Monatssumme, die Sie nicht aufschlüsseln können, nicht.