LLM-Kosten: Warum die Rechnung erst nach dem Rollout kommt

Der Prototyp kostet ein paar Euro am Tag. Zehn Testnutzer, kurze Prompts, niemand schaut auf die Rechnung. Dann geht das System live, der Kontext wächst, weil jede Antwort mit mehr Hintergrund besser wird, und die Rechnung wächst schneller als die Nutzerzahl.

Das ist der Punkt, an dem FinOps für LLMs anders wird als klassisches Cloud-FinOps. Die Stellschrauben sind andere, und sie hängen direkt an der Qualität der Antworten, nicht nur an der Infrastruktur.

Wo das Geld tatsächlich hingeht

Die Kontextlänge ist der größte Hebel: Jeder zusätzliche Chunk im Prompt kostet bei jedem Call, nicht einmalig. Ein RAG-System, das zehn statt drei Chunks in den Kontext holt, weil das die Trefferquote hebt, verdreifacht damit die Eingabekosten pro Anfrage. Dazu kommen Reranking und andere Zwischen-Calls, ein Reranker-Modell, ein Validierungs-Call, ein zweiter Blick durch ein kleineres Modell. Jeder dieser Schritte ist ein eigener Posten auf der Rechnung.

Ein dritter Treiber wird oft übersehen: Modellwahl ohne Rückkopplung. Ein Team wechselt auf ein größeres, teureres Modell, weil die Texte besser klingen. Ob die Qualität wirklich steigt oder nur der Stil, sagt ohne Evaluation niemand. Und dann sind da noch Retries bei Fehlern, ein Parsing-Fehler, der einen zweiten Call auslöst. Bei niedriger Fehlerquote unauffällig. Bei 5% Fehlerquote auf hohem Volumen eine sichtbare Zeile auf der Rechnung.

Was ich als Erstes messe

Nicht die Gesamtsumme am Monatsende. Die Kosten pro Anfrage, aufgeschlüsselt nach Schritt: Retrieval, Reranking, Hauptcall, Validierung. Ohne diese Aufschlüsselung ist „die Kosten sind gestiegen" eine Beobachtung ohne Hebel.

Anfrage: "Welche Norm gilt für Zusatzstoff X?"
  Retrieval:     0,0003 €  (Embedding + Suche)
  Reranking:     0,0012 €  (Cross-Encoder, 20 Kandidaten)
  Hauptcall:     0,0180 €  (Kontext: 6 Chunks, Antwort: 200 Token)
  Validierung:   0,0040 €  (kleineres Modell, Quellencheck)
  Summe:         0,0235 €

Diese Aufschlüsselung zeigt sofort, wo eine Optimierung wirkt. Wenn der Hauptcall 75% der Kosten trägt, bringt ein günstigerer Reranker wenig. Wenn Retries 30% ausmachen, ist die Fehlerquote im Parsing das eigentliche Kostenproblem, nicht das Modell.

Der Denkfehler, der am häufigsten vorkommt

Teams optimieren das Modell, bevor sie die Pipeline optimieren. Ein günstigeres Modell für den Hauptcall spart, wenn der Kontext gleich bleibt. Bringt der Kontext aber unnötige Chunks mit, zahlt man für Ballast, egal welches Modell dahinter läuft. Die Reihenfolge sollte umgekehrt sein: erst den Kontext schlank halten, dann über das Modell nachdenken.

Ein zweiter Fehler: Kosten pro Token betrachten, statt Kosten pro Anfrage in Relation zum Wert der Antwort. Eine Anfrage, die zehn Cent kostet, aber eine Norm-Recherche ersetzt, die eine Stunde manuelle Arbeit gebraucht hätte, ist billig. Eine Anfrage für „wie ist das Wetter" zu demselben Preis ist es nicht.

Caching, bevor über das Modell geredet wird

Ein Teil der Anfragen wiederholt sich, wörtlich oder fast wörtlich. Eine Norm wird oft gefragt, eine Standardformulierung taucht in mehreren Sitzungen auf. Ein Cache auf Embedding-Ebene, der ähnliche Anfragen erkennt und die letzte Antwort mit Quelle wiederverwendet, senkt die Kosten, ohne dass ein Nutzer etwas merkt außer einer schnelleren Antwort. Der Haken: der Cache muss wissen, wann eine Quelle sich geändert hat, sonst liefert er eine alte, längst falsche Antwort schneller aus. Ohne eine Invalidierungsregel ist Caching ein neues Halluzinationsrisiko mit besserer Latenz.

Was Multi-Tenant an der Kostenfrage ändert

Bei einem Multi-Tenant-System, wie dem Lebensmitteltechnologie-Workspace, reicht eine Gesamtsumme am Monatsende nicht. Ohne Kosten pro Mandant lässt sich kein Preismodell bauen, das nicht bei jedem zusätzlichen Kunden Verlust macht. Das ist derselbe Punkt wie bei Mandantentrennung, nur auf der Kostenseite statt auf der Sicherheitsseite.

Der Tenant-Tag gehört an denselben Ort wie der Retrieval-Filter: in den Request-Kontext, nicht in eine nachträgliche Zuordnung über Zeitstempel. Wer Kosten erst im Nachhinein per Heuristik auf Mandanten verteilt, bekommt Zahlen, die in einer Preisverhandlung nicht standhalten.

Eigenes Modell oder API

Ab einer bestimmten Anfragemenge wird die Frage, ob ein selbst gehostetes Modell günstiger ist als die API eines Anbieters, ernsthaft relevant. Die Antwort hängt selten allein am Preis pro Token. Ein selbst gehostetes Modell bringt eigene Infrastrukturkosten mit, GPU-Instanzen, die auch bei niedriger Last laufen müssen, und einen Betriebsaufwand, der bei der API-Variante beim Anbieter liegt. Bei niedrigem, unregelmäßigem Volumen ist die API praktisch immer günstiger, weil niemand für eine GPU bezahlt, die die meiste Zeit leer läuft. Bei hohem, planbarem Volumen kippt die Rechnung. Ohne die Kosten-pro-Schritt-Aufschlüsselung von oben lässt sich diese Entscheidung nicht seriös treffen, man rät nur mit mehr Selbstvertrauen.

Wer die Rechnung überhaupt sieht

In vielen Teams sieht die Kostenzahl zuerst die Finanzabteilung, am Monatsende, ohne Kontext. Die technische Seite bekommt die Zahl erst, wenn sie schon unangenehm groß ist. Besser ist ein Budget-Alarm auf Ebene der Anfrage oder des Mandanten, der auslöst, bevor die Rechnung zur Überraschung wird. Das ist keine komplizierte Infrastruktur, nur ein Schwellenwert und jemand, der ihn liest.

Was der Check daraus macht

Kosten sitzen an Tag 4 des LLM-Readiness-Checks, neben Betrieb und Mandanten. Ich schaue, ob Kosten pro Anfrage überhaupt messbar sind, und ob jemand weiß, welcher Pipeline-Schritt den größten Anteil trägt, bevor er am Modell dreht.

Die Leistung dahinter sitzt unter KI-Engineering. Verwandt: Evaluation in Produktion, Antworten rekonstruieren.