LLM-Kosten senken: Caching, Modell-Routing und schlankere Prompts

Ein Prototyp mit einem LLM dahinter kostet selten viel. Dann kommt der Traffic, und ein System, das in der Entwicklung billig wirkte, wird tausend- oder millionenfach im Monat aufgerufen. Spätestens jetzt wird die Inferenzrechnung zu einem Posten, nach dem in Meetings gefragt wird. Überall ein kleineres Modell einzusetzen ist der naheliegende Reflex, und oft der falsche. Der Großteil der Einsparungen hängt an drei Entscheidungen: wie Modelle aufgerufen werden, was man ihnen schickt und welches Modell welche Anfrage bearbeitet. Im Folgenden geht es um Caching-, Routing- und Prompt-Strategien, die die Ausgaben senken, ohne die Qualität zu beschädigen, die Nutzer tatsächlich bemerken.

Was die Rechnung treibt

Mehrere Faktoren bestimmen die LLM-Kosten:

• wie viele Anfragen eingehen
• Input- und Output-Tokens
• welches Modell jeden Aufruf bedient
• die Größe des Kontextfensters
• wie oft sich dieselbe Frage wiederholt
• Agenten- und Tool-Aufrufe
• Wiederholungen nach Fehlern
• Embedding- und Retrieval-Last
• Bedarf an Batch-Verarbeitung

Ein einfacher Chatbot macht einen Modellaufruf pro Frage. Ein Agent kann für eine einzige Aufgabe eine ganze Kette auslösen: Nutzer, Agent, Retrieval, Tool, Modell, Tool, Modell, finale Antwort. Läuft jedes Glied dieser Kette auf einem teuren Modell, steigt die Summe rasant. Deshalb gehört Kostenkontrolle von Anfang an in die Architektur. Sie nachträglich anzuflanschen, nachdem die Rechnung jemanden geschockt hat, ist deutlich schwieriger.

Erst messen, dann ändern

Blind zu optimieren ist Raten. Erfassen Sie zuerst:

• Anfragen pro Tag und Tokens pro Anfrage
• Input-Tokens im Vergleich zu Output-Tokens
• Kosten pro Anfrage, pro Nutzer, pro Feature und pro Modell
• Cache-Trefferquote
• Latenz, Fehlerquote und Wiederholungsquote
• Tool-Aufrufe von Agenten

Echte Daten halten oft Überraschungen bereit. Vielleicht verursachen 20 % der Nutzer 70 % der Kosten, oder ein einzelner RAG-Workflow stopft riesige Mengen nutzlosen Kontext in jeden Aufruf. Beides fällt erst auf, wenn jemand hinschaut.

Wiederkehrende Arbeit cachen

Caching ist einer der einfachsten Wege, Inferenz ganz zu vermeiden. Nehmen wir einen Support-Assistenten. Tausende Kunden fragen in irgendeiner Form: „Wie sind Ihre Rückgabebedingungen?“ Wenn sich die Antwort kaum ändert, ist es sinnlos, sie jedes Mal neu zu generieren.

Der Ablauf ist kurz. Eine Anfrage kommt an, der Cache wird geprüft. Bei einem Treffer geht die gespeicherte Antwort an den Nutzer zurück. Bei einem Fehlschlag wird das Modell aufgerufen, das Ergebnis gespeichert und die Antwort ausgeliefert. Wiederholte Modellaufrufe gehen deutlich zurück.

Semantisches Caching

Klassisches Caching braucht eine exakte Zeichenkette, und „Wie sind Ihre Rückgabebedingungen?“ und „Kann ich mein Geld zurückbekommen?“ sind verschiedene Zeichenketten. Ein semantischer Cache vergleicht stattdessen die Bedeutung. Jede Anfrage wird als Embedding dargestellt, und überschreitet die Ähnlichkeit einen festgelegten Schwellenwert, verwendet das System eine vorhandene Antwort wieder. Das funktioniert gut für:

• FAQs
• Kundensupport
• interne Wissensassistenten
• Produktdokumentation
• repetitive Unternehmensabläufe

Den Schwellenwert sollte man sorgfältig wählen. Zu locker, und unterschiedliche Fragen bekommen dieselbe Antwort; zu streng, und der Cache greift kaum.

Nach Schwierigkeit routen

Ein häufiger Architekturfehler ist, jede Anfrage an das stärkste verfügbare Modell zu schicken. Vergleichen Sie drei Anfragen: „Wann ist Ihr Support erreichbar?“, „Fasse diese Kundenbeschwerde zusammen“ und „Analysiere diese Finanzdokumente und identifiziere mögliche Risiken.“ Ein Premium-Reasoning-Modell schafft alle drei, aber bei der ersten dafür zu bezahlen, ist Verschwendung.

Modell-Routing löst das. Einfache Aufgaben gehen an ein kleines, effizientes Modell, mittlere an ein Modell der Mittelklasse, schwierige an ein besonders leistungsfähiges. Ein Klassifikator am Eingang prüft jede Anfrage und wählt das Ziel. Ein Router in Produktion kann Komplexität der Anfrage, geforderte Genauigkeit, Kontextlänge, Nutzerpriorität, Aufgabentyp, Latenzanforderungen und Kostengrenzen abwägen. Die Ausgaben sinken spürbar, und niemand zwingt den gesamten Traffic durch ein schwaches Modell.

Den Prompt entschlacken

Lange Prompts kosten Geld, besonders wenn ein großer System-Prompt bei jedem Aufruf mitfährt. Stellen Sie sich pro Anfrage 3.000 Tokens Anweisungen, 5.000 Tokens abgerufenen Kontext und 500 Tokens Nutzereingabe vor. Selbst bei einer winzigen Frage verarbeitet das Modell rund 8.500 Tokens.

Prüfen Sie Prompts auf:

• wiederholte Anweisungen
• Beispiele, die nichts beitragen
• doppelten Kontext
• überladene Formatierungsregeln
• irrelevante Details
• veraltete Anweisungen
• Tool-Beschreibungen, die niemand nutzt

Ein kürzerer Prompt mit klar formulierter Aufgabe leistet oft genauso viel wie ein längerer. Ziel ist nicht der kürzestmögliche Prompt, sondern der kleinste, der das gewünschte Ergebnis noch zuverlässig liefert.

Im RAG weniger, aber bessere Chunks schicken

RAG-Pipelines werden teuer, wenn dem Modell zu viele abgerufene Dokumente übergeben werden. Angenommen, das Retrieval liefert 20 Chunks à 1.000 Tokens. Das sind 20.000 Tokens Kontext für eine einzige Anfrage, und das Modell braucht den Großteil davon vermutlich nicht.

Besser ist: Anfrage, Retrieval, Reranking und dann nur die relevantesten Chunks ins LLM. Tokenverbrauch, Latenz und Rauschen sinken, und die Antworten können sogar besser werden.

Den Rest komprimieren

Auch relevante Dokumente enthalten viel irrelevanten Text. Kontextkompression zieht die nützlichen Teile heraus, bevor das Modell sie sieht. Ein Dokument mit 10.000 Tokens kann auf 1.500 Tokens relevanten Inhalt schrumpfen. Das lohnt sich bei:

• juristischen Dokumenten
• Finanzberichten
• technischer Dokumentation
• Wissensdatenbanken in Unternehmen
• langen Kundenhistorien

Die Ausgabe begrenzen

Modelle können weit mehr schreiben, als ein Nutzer lesen will. Für eine Frage wie „Wie ist der Status meiner Bestellung?“ braucht es keine Antwort mit 1.000 Tokens. Legen Sie sinnvolle Ausgabelimits und Antwortformate fest. Bei strukturierten Aufgaben funktioniert ein kompaktes Format besser als Fließtext:

Status: Shipped
Expected Delivery: Friday
Tracking Available: Yes

Weniger Output-Tokens bedeuten eine niedrigere Rechnung und meist auch eine schnellere Antwort.

Normalen Code nutzen, wo er reicht

Das ist vielleicht die wichtigste Regel im AI-Engineering: Manche Aufgaben brauchen gar kein LLM. Zu prüfen, ob eine Bestellung über 1.000 $ liegt, ist eine Zeile: if order_value > 1000. Gewöhnliche Software erledigt bereits Berechnungen, Sortieren, Filtern, Validierung, Datumsrechnungen, Datenbankabfragen und deterministische Geschäftsregeln. Setzen Sie das Modell dort ein, wo Sprachverständnis oder Reasoning echten Mehrwert bringt.

Agenten an der kurzen Leine halten

Agentensysteme können überraschend hohe Inferenzkosten anhäufen. Eine einzige Aufgabe kann einen Planungsaufruf, einen Tool-Auswahl-Aufruf, einen Retrieval-Aufruf, einen Analyseaufruf, einen Prüfaufruf und einen Aufruf für die finale Antwort auslösen. Laufen alle sechs auf einem großen Modell, vervielfacht sich der Preis.

Ein besseres Design kann:

• unnötige Agentenschleifen streichen
• wo möglich deterministische Tools verwenden
• die maximale Zahl der Iterationen begrenzen
• Routineschritte an kleinere Modelle abgeben
• Zwischenergebnisse cachen
• wiederholtes Retrieval vermeiden
• kompatible Operationen zusammenlegen

Es geht nicht um weniger sinnvolle Aktionen, sondern darum, die überflüssigen loszuwerden.

Was nicht eilt, im Batch erledigen

Nicht alles braucht eine Antwort in Echtzeit. Dokumentklassifikation, Datenanreicherung, Content-Verarbeitung, Berichtserstellung, Zusammenfassungen im großen Stil und das Labeln von Datensätzen lassen sich meist asynchron oder in Batches ausführen. Je nach Anbieter und Aufbau der Last verbessert Batching die Auslastung und senkt den Preis großer Jobs.

Das Modell wie ein Engineer auswählen

Die Modellwahl ist eine technische Entscheidung, die man anhand mehrerer Fragen bewertet:

• Qualität: Wie genau muss das Ergebnis sein?
• Kosten: Welcher Preis pro Anfrage ist akzeptabel?
• Latenz: Wie schnell muss die Antwort kommen?
• Kontext: Wie viele Informationen muss das Modell aufnehmen?
• Reasoning: Wie schwierig ist die Aufgabe?
• Zuverlässigkeit: Wie konsistent müssen die Ergebnisse sein?

Ersetzen Sie „Welches Modell ist das beste?“ durch „Welches Modell reicht für diese Aufgabe?“ Diese kleine Änderung kann die Wirtschaftlichkeit in Produktion grundlegend verschieben.

Belegen, dass nichts kaputtgegangen ist

Kostensenkungen dürfen die Qualität nicht schleichend aushöhlen, also messen Sie jede Änderung. Bauen Sie ein Evaluationsset aus echten Anfragen und vergleichen Sie Ausgangs- und optimiertes System bei Genauigkeit, Relevanz, Faktentreue, Aufgabenerfüllung, Nutzerzufriedenheit, Latenz und Kosten.

Ein ausgedachtes Beispiel: Die Ausgangsversion erreicht 92 % bei 0,020 $ pro Anfrage, die optimierte 91 % bei 0,009 $. Akzeptiert das Business einen Punkt weniger Qualität, ist die zweite Variante im Betrieb deutlich günstiger.

Die Schichten zusammensetzen

Eine Produktionsanwendung kann diese Ideen hintereinanderschalten: Anfrage klassifizieren, Cache prüfen, Daten abrufen oder verarbeiten, Kontext filtern, an ein Modell routen, das gewählte LLM aufrufen, die Ausgabe validieren, sie im Antwort-Cache ablegen und an den Nutzer zurückgeben. Das teure Modell läuft nur, wenn nichts weiter vorne in der Kette antworten konnte.

Welche Einsparungen realistisch sind

Verstehen Sie „60 % günstiger“ nicht als Versprechen. Das Ergebnis hängt stark von der Last ab. Mehrere Optimierungen zusammen können trotzdem große Reduktionen bringen. Nehmen wir eine hypothetische Monatsrechnung von 10.000 $ und schauen, wo sie schrumpfen könnte:

• wiederholte Anfragen um 20 % reduzieren
• geeignete Lasten auf günstigere Modelle verlagern
• unnötige Input-Tokens abbauen
• nur relevanten Kontext abrufen und senden
• überflüssige Tool- und Modellaufrufe streichen
• überlange Antworten unterbinden

Zusammen kann das einen großen Teil der Gesamtsumme abschneiden. Entscheidend ist, dass Einsparungen meist aus vielen kleinen Architekturverbesserungen entstehen und nicht aus einem Zaubertrick.

Checkliste vor dem Launch

Bevor eine LLM-Anwendung unter echte Last geht, sollten Sie diese Fragen stellen.

• Notwendigkeit: Braucht jeder Schritt ein LLM? Könnte deterministischer Code einen Teil übernehmen? Sind Agentenschleifen begrenzt?
• Prompts: Sind die Systemanweisungen aufgebläht? Sind die Beispiele nötig? Schleicht sich irrelevanter Kontext ein?
• Retrieval: Werden zu viele Chunks abgerufen? Gibt es Reranking? Lässt sich der Kontext komprimieren?
• Modelle: Wird das teuerste Modell dort eingesetzt, wo es nicht nötig ist? Lassen sich Anfragen nach Komplexität routen?
• Caching: Werden wiederholte Anfragen gecacht? Würde semantisches Caching passen?
• Ausgabe: Wird die Antwortlänge kontrolliert? Sind strukturierte Ausgaben sinnvoll?
• Monitoring: Wird der Tokenverbrauch erfasst? Sind die Kosten pro Feature bekannt? Werden Qualitätsmetriken neben den Kosten beobachtet?

Nachhaltig statt billigst

„Die AI so billig wie möglich machen“ ist das falsche Ziel. Besser ist, die geforderte Geschäftsqualität zu den niedrigsten nachhaltigen Kosten zu erreichen. Eine Support-App kann einfache FAQs mit einem kleinen Modell beantworten und verzwickte Beschwerden an ein stärkeres geben. Ein Coding-Assistent braucht für schwierige Programmieraufgaben womöglich viel Reasoning. Eine Dokumenten-Pipeline setzt vielleicht auf Durchsatz und Konsistenz. Ein Universalrezept gibt es nicht, die richtige Architektur hängt von der Last ab.

LLM-Ausgaben müssen nicht im Gleichschritt mit der Nutzung steigen. Caching, Routing, straffere Prompts, schlankeres RAG, Kompression, effiziente Agenten, Ausgabelimits und fortlaufende Evaluation helfen jeweils, und der größte Gewinn liegt meist schlicht darin, Aufrufe zu vermeiden, die nie nötig waren. Wird eine AI-Anwendung im Betrieb teuer, ist weniger Nutzung womöglich nicht die Lösung. Sorgfältigeres Engineering des Systems ist es oft schon.