LLM-Kosten im Griff behalten: was im Betrieb wirklich teuer wird — und was nicht

Wo LLM-Kosten im Betrieb tatsächlich entstehen

In der Pitchphase wird die Modellrechnung gerne auf eine Tabelle reduziert: Preis pro tausend Tokens mal erwartete Anfragen pro Monat. Im laufenden Betrieb sieht die Rechnung anders aus, weil die eigentlichen Kostentreiber nicht der Tokenpreis sind, sondern wie viele Tokens pro Anfrage tatsächlich fließen — und wie oft.

Vier Quellen tauchen in fast jeder LLM-Anwendung auf. Erstens die Eingabe- Tokens: System-Prompt, Beispiele, eingeblendete Wissensquellen, Konversationshistorie. In RAG-basierten Anwendungen ist das fast immer der größere Block, nicht die Antwort. Zweitens die Ausgabe-Tokens: bei ausführlichen Antworten, ungewollt langer Begründung oder „Reasoning"-Modi schnell mehrfach so groß wie geplant. Drittens die Embedding-Kosten für Indexierung und Anfrage-Vektoren — pro Aufruf gering, in Summe je nach Datenmenge spürbar. Viertens die Vector-Datenbank- und Infrastruktur-Kosten, die meist nicht pro Aufruf, sondern pro reservierter Kapazität abgerechnet werden.

Hinzu kommt eine fünfte, oft übersehene Quelle: Mehrfach-Aufrufe pro Nutzeranfrage. Eine einzelne Frage löst bei Tool-Use, agentischen Schritten oder mehrstufiger Reasoning-Logik schnell drei bis zehn Modellaufrufe aus. Was im Demo wie ein Aufruf aussieht, ist im Betrieb eine Kette — und in der Rechnung entsprechend.

Modell-Tiering: das richtige Modell für die richtige Aufgabe

Der wirksamste Kostenhebel ist fast immer die Frage, ob für jede einzelne Aufgabe wirklich das größte Modell nötig ist. In den meisten produktiven Anwendungen lassen sich Aufgaben in zwei oder drei Klassen unterteilen, für die unterschiedliche Modelle sinnvoll sind.

Klassifizierung von Anfragen, Routing-Entscheidungen, einfache Extraktionen oder Formatumwandlungen sind Aufgaben, die ein kleineres Modell zuverlässig löst — schneller, günstiger und mit weniger Tokens. Tiefere Recherche, mehrstufige Argumentation oder die Antwortformulierung in einer kundennahen Anwendung gehören zum großen Modell. Wer beides bewusst trennt, senkt seine Kosten typischerweise um einen substanziellen Faktor, ohne die wahrgenommene Qualität zu beeinflussen.

Diese Trennung ist eng mit der allgemeineren Frage verbunden, welches Modell für welchen Use Case überhaupt das richtige ist — wir haben sie im Beitrag zur LLM-Auswahl für Unternehmen ausführlich aufgeschlüsselt. Im Kostenkontext gilt zusätzlich: kleinere Modelle, die sich gut an eine eng definierte Teilaufgabe anpassen lassen, schlagen langfristig das größere Modell mit langem Prompt — was direkt in das Spannungsfeld Fine-Tuning, RAG oder Prompting führt.

Prompt-Disziplin und Caching

Der zweite große Hebel liegt in der Eingabe. Lange System-Prompts, viele Beispiele und ausführliche Wissensblöcke wirken oft wie Qualitätsversicherung — und sind in Wahrheit der größte Einzelkostentreiber pro Aufruf. Disziplin im Prompt-Design hat damit eine direkte Kostenwirkung, lange bevor das Modell überhaupt antwortet.

Wo der Prompt aus guten Gründen lang sein muss, lohnt sich Prompt-Caching. Stabile Teile des Prompts — System-Prompt, Few-Shot-Beispiele, statische Wissensblöcke — werden anbieterseitig zwischengespeichert und müssen nicht bei jedem Aufruf neu verarbeitet werden. Bei wiederkehrenden Konstellationen kann das die Eingabekosten spürbar reduzieren, ohne an Qualität zu verlieren. Voraussetzung ist, dass der stabile Teil sauber vom variablen Teil getrennt ist — eine Disziplin, die sich auch unabhängig von Caching auszahlt und im Beitrag zum Prompt Engineering im Unternehmen beschrieben ist.

Auf der Ausgabeseite hilft eine bewusste Antwortlänge. Klare Anweisungen zum Antwortformat, harte Längenlimits und das Erzwingen kompakter Strukturen verhindern, dass Modelle aus Höflichkeit oder eingebauten Reflexen längere Antworten geben als nötig.

Retrieval-Disziplin in RAG-Anwendungen

In Anwendungen rund um RAG-Systeme entscheidet das Retrieval mehr über die Kosten als das Modell. Wer pro Anfrage zehn Dokumentenausschnitte einblendet, bezahlt diese zehn Ausschnitte als Eingabe-Tokens. In den allermeisten Fällen reichen drei bis fünf — wenn Retrieval und Ranking gut sind. Schlechtes Retrieval kompensiert man oft mit mehr Kontext; gutes Retrieval erlaubt weniger Kontext.

Konkret hilft eine bewusste Begrenzung der Top-K-Treffer, ein zweistufiges Verfahren mit grober Vorauswahl und feinem Re-Ranking, sowie konsequentes Trimmen der zurückgegebenen Ausschnitte auf das tatsächlich relevante Fenster. Diese drei Schritte zusammen reduzieren die Eingabe-Tokens in vielen Anwendungen um die Hälfte oder mehr.

Eine weitere oft übersehene Stellschraube ist die Embeddings-Strategie. Re-Indexierungen jedes geänderten Dokuments können sich summieren. Inkrementelles Embedding nur für tatsächlich veränderte Abschnitte, sinnvoll dimensionierte Embedding-Modelle und ein bewusster Umgang mit Aktualisierungs-Intervallen sind unspektakulär — und in der Summe ein realer Kostenposten.

Aufrufmuster: synchron, batch, asynchron

Nicht jede LLM-Aufgabe muss in Echtzeit beantwortet werden. Anwendungen, die interaktiv genutzt werden, brauchen niedrige Latenz und damit synchrone Aufrufe. Anwendungen, die im Hintergrund laufen — Klassifikation eingehender Mails, Extraktion aus Dokumenten, periodische Analysen — vertragen häufig Batch- oder asynchrone Verarbeitung.

Der Unterschied ist nicht nur architektonisch, sondern auch finanziell. Viele Anbieter bieten Batch-Verarbeitung zu deutlich reduzierten Preisen an, weil sie Last besser planen können. Wer geeignete Aufgaben dafür identifiziert, senkt die Kosten erheblich, ohne dass Nutzer einen Unterschied spüren.

Auch die Aggregation von Anfragen lohnt sich. Statt für jede einzelne Zeile in einem Datensatz einen separaten Aufruf zu machen, lassen sich häufig fünf bis zwanzig Einträge in einem Aufruf bündeln, mit klarer Output-Struktur. Das spart Tokens für wiederholte System-Prompts und reduziert die Latenz pro Datensatz.

Sichtbarkeit als Voraussetzung jeder Optimierung

Kosten lassen sich nicht steuern, was man nicht sieht. Eine LLM-Anwendung im Betrieb ohne saubere Aufrufprotokollierung, ohne Token-Buchhaltung pro Use Case oder pro Nutzergruppe und ohne Auswertung typischer Aufrufmuster ist ein Blindflug.

Praktisch gehört das in dieselbe Schicht wie das fachliche Monitoring der Anwendung — in unserem Beitrag zu LLM-Monitoring und Observability ausführlich beschrieben. Aus Kostensicht zählen vor allem: Tokens pro Anfrage nach Use Case, Verteilung der Antwortlängen, Verhältnis von Cache-Treffern zu kalten Anfragen, durchschnittliche Anzahl von Modellaufrufen pro Nutzeranfrage und Top-N- Anwender oder Pfade nach Verbrauch.

Mit diesen Zahlen wird die Optimierungsdiskussion sachlich. Ohne sie bleibt sie eine Bauchgefühlsdebatte, in der die laute Vermutung gewinnt — und nicht die wirksamste Maßnahme.

Typische Kostenfallen, die spät auffallen

Drei Kostenfallen tauchen in unseren Projekten besonders oft auf — meistens, weil sie im Pilot keine Rolle spielten und erst bei mehr Last sichtbar werden.

Erstens: Stille Schleifen. Eine ungeschickte Prompt- oder Tool- Logik führt dazu, dass das Modell sich selbst rekursiv aufruft, mehrfach dieselbe Wissensabfrage macht oder sich in Korrekturschleifen verfängt. Das passiert selten sichtbar — aber sehr zuverlässig auf der Rechnung. Klare Schritt-Limits und Logging pro Anfrage entdecken solche Muster früh.

Zweitens: Test- und Debug-Verbrauch. In Entwicklungs- und Testumgebungen entstehen mehr Aufrufe, als man denkt — automatisierte Tests, manuelle Versuche, fehlgeschlagene CI-Läufe. Ohne separate Schlüssel oder Quoten landet das alles in derselben Rechnung wie die Produktion und wird schwer zuzuordnen.

Drittens: Agenten ohne Begrenzung. Ein echter Agent, der ohne harte Schritt- oder Token-Limits arbeitet, kann pro Nutzerinteraktion ein Vielfaches dessen kosten, was ursprünglich kalkuliert war. Bewusste Limits — sowohl an Schritten als auch an Token-Budget pro Anfrage — gehören in die erste Version jedes agentischen Systems, nicht in eine spätere Härtungsphase.

Wie sich Kostenoptimierung sauber in den Betrieb einfügt

Kostenoptimierung ist keine einmalige Aufräumaktion, sondern ein wiederkehrender Termin. In produktiv betriebenen LLM-Anwendungen lohnt sich ein leichtgewichtiger Quartals-Review, der wenige Fragen ehrlich beantwortet: Welche Use Cases haben sich in Volumen und Verbrauch wie entwickelt? Welche Aufrufmuster haben sich verschoben? Welche Modelle und Caches werden tatsächlich genutzt? Wo entstehen Ausgaben, die nicht zu erklärten Use Cases passen?

Aus dieser Routine ergeben sich kleine, klar wirkende Maßnahmen — viel besser als ein großes Optimierungsprojekt nach einem Schreckmoment auf der Rechnung. Sie verlangen keine eigene FinOps-Abteilung, aber eine bewusst zugeordnete Verantwortung — typischerweise im Schnittbereich von AI Engineering und Plattformbetrieb.

Wann externe Unterstützung sinnvoll ist

Für eine kleine Anwendung mit überschaubarem Volumen reichen interne Disziplin und ein paar bewusste Architekturentscheidungen. Sobald aber mehrere Anwendungen, hohe Last und ein wachsendes Portfolio zusammenkommen, lohnt sich ein gezielter Blick von außen — bevor sich Kosten- und Architekturmuster verfestigen, die später nur schwer zu drehen sind.

Wir arbeiten mit Unternehmen, die LLM-Kosten als Teil ihrer KI-Reife verstehen, nicht als Sparübung. Wenn das zu Ihrer Situation passt, sprechen Sie uns an, am besten bevor das nächste Modellupgrade ins Haus steht — denn jede Modellgeneration verschiebt das Verhältnis aus Qualität, Latenz und Kosten neu. Den passenden Rahmen dafür bieten wir über AI Engineering und unser LLM-QA.