Mitte 2026 ist der häufigste Architekturfehler, den wir im Produktiveinsatz beobachten, eine zu teure Inferenz. Teams führen LLM-Funktionen ein, sehen sie funktionieren und werden anschließend mit fünfstelligen Monatsrechnungen konfrontiert, die mit der Nutzung steigen. Manche Funktionen werden unrentabel. Einige Unternehmen stellen Funktionen ein, die mit besserer Kostendisziplin tragfähig gewesen wären.
Die meisten LLM-Rechnungen sind wesentlich höher als nötig. Die Einsparungen entstehen nicht durch eine einzelne Wundertechnik, sondern durch mehrere Optimierungen, von denen jede für sich einen moderaten Beitrag leistet.
Dieser Artikel behandelt die Techniken, Zahlen und betriebliche Disziplin. Wir setzen voraus, dass Sie das grundlegende Modell-Routing, das ein anderer Artikel behandelt, bereits umgesetzt haben, und gehen hier tiefer.
Die Kostenstruktur
LLM-Kosten entstehen aus:
- Eingabetoken. Was Sie dem Modell senden. Enthält System-Prompt, Kontext, Benutzeranfrage.
- Ausgabetoken. Was das Modell zurückgibt. Sie sind typischerweise vier- bis sechsmal teurer als Eingabetoken (Anthropic 5x, OpenAI ~6x zu aktuellen Listenpreisen – siehe Modell- und Preisreferenz, verifiziert am 2026-07-07).
- Reasoning-Token. Bei Reasoning-Modellen sind dies interne „Denk“-Token. Sie sind häufig so teuer wie Ausgabetoken.
- Werkzeugaufrufe. Beim Tool Calling zählt jede Werkzeugdefinition zu den Eingabetoken.
- Wiederholungsversuche. Auch fehlgeschlagene Aufrufe verursachen Kosten.
Optimierung funktioniert auf jeder Ebene.
Technik 1: Prompt-Caching
Dies ist der größte einzelne Hebel. Die meisten modernen Anbieter cachen wiederkehrende Eingabepräfixe: Beim ersten Mal zahlen Sie den vollen Preis, bei späteren Aufrufen mit demselben Präfix deutlich weniger.
Preise (typisch):
- Anthropic: gecachte Eingabe ~10 % des normalen Preises.
- OpenAI: Automatisch bei Präfixübereinstimmung, ~50 % des normalen Preises (variiert je nach Modell).
- Google: explizit gecachte Inhalte, Preis variiert.
So funktioniert es: Der erste Aufruf eines Modells mit einem bestimmten Eingabepräfix kostet den normalen Preis. Weitere Aufrufe innerhalb des Cache-Fensters – typischerweise 5–60 Minuten, abhängig vom Anbieter – verwenden die gecachte Darstellung.
Praktische Umsetzung:
Strukturieren Sie Ihre Prompts so, dass statischer Inhalt zuerst kommt, dynamischer Inhalt später:
[CACHED: 10K tokens]
- System prompt
- Tool descriptions
- User's static profile
- Knowledge base snippets unlikely to change per call
[NOT CACHED: 1K tokens]
- Conversation history (changes each turn)
- Current user query
Die ersten 10.000 Token werden nach dem ersten Aufruf gecacht. Bei späteren Aufrufen zahlen Sie für sie ~10 % und für die übrigen 1.000 Token den vollen Preis.
Einsparungsbeispiel:
Ohne Caching:
- 11.000 Eingabetoken × €3/Million = €0,033 pro Aufruf.
- 100.000 Aufrufe/Tag = €3.300/Tag.
Mit Caching (90 % der Eingabe ist gecacht):
- 1.000 Vollpreis + 10.000 gecacht bei 10 %:
- 1.000 × €3/Million + 10.000 × €0,30/Million = €0,003 + €0,003 = €0,006 pro Aufruf.
- 100.000 Aufrufe/Tag = €600/Tag.
82 % Einsparung. Reale Zahlen, reale Systeme.
Umsetzungsdisziplin:
- Identifizieren Sie statische vs. dynamische Teile der Prompts.
- Platzieren Sie statische Teile zuerst.
- Verwenden Sie Cache-Marker zur expliziten Steuerung, sofern der Anbieter sie unterstützt, etwa Anthropic.
- Prüfen Sie Cache-Treffer. Ihre Observability sollte die Cache-Trefferrate ausweisen. Ist sie niedrig, passt Ihre Promptstruktur nicht.
Diese Optimierung bietet den höchsten ROI. Setzen Sie sie vor allen anderen Maßnahmen um.
Technik 2: Modell-Routing
Ein anderer Artikel behandelt dies ausführlich. Kurz gesagt: Leiten Sie Anfragen je nach Komplexität an unterschiedliche Modelle weiter.
- 60 % der Anfragen an kleine Modelle.
- 30 % an mittelgroße.
- 10 % an Spitzenmodelle.
Typische Einsparung: 60–80 % gegenüber dem Einsatz eines Spitzenmodells für alle Anfragen.
Kombiniert mit Caching sind Sie bei 90 %+ Einsparungen im Vergleich zur naiven Baseline.
Technik 3: Steuerung der Ausgabelänge
Ausgabetoken dominieren die Kosten für die meisten Anwendungsfälle. Sie sind typischerweise 4–6-mal teurer als Eingabe; sie werden vom Modell und Prompt bestimmt; sie sind oft länger als nötig.
Strategien:
Explizite Längenangaben.
Respond in at most 100 words.
Modelle befolgen diese Anweisung meist recht gut. Das senkt die Ausgabekosten erheblich.
Strukturierte Ausgabe.
Besteht die sichtbare Antwort aus kurzen strukturierten Daten, etwa JSON mit festgelegten Feldern, ist die Ausgabe begrenzt. Unnötige Ausführlichkeit entfällt.
max_tokens-Parameter.
Legen Sie ihn fest, statt den Standardwert zu übernehmen. Wenn 200 Token genügen, setzen Sie den Höchstwert mit einem kleinen Puffer auf 250. Das Modell kann ihn nicht überschreiten.
Formatbeschränkungen.
„Nur Aufzählungspunkte“ oder „ein Absatz“ erzeugen kürzere Ausgaben als freie Form.
Aufzählungspunkte statt Prosa.
Aufzählungspunkte sind typischerweise die Hälfte der Token von Prosa, die dieselbe Information vermittelt.
Keine Einleitung.
„Überspringen Sie einleitende Floskeln. Kommen Sie direkt zur Antwort.“ Modelle beginnen häufig mit „Gute Frage …“ oder „Lassen Sie mich erklären …“ – das sind verschwendete Token.
Einsparungsbeispiel:
Ein Zusammenfassungsworkflow. Standardausgabe: 500 Token. Begrenzt: 200 Token.
- 500 Token × €10/Million = €0,005 pro Aufruf.
- 200 Token × €10/Million = €0,002 pro Aufruf.
60 % Einsparung bei der Ausgabe. Das wirkt weniger eindrucksvoll als 90 % durch Caching, betrifft aber den größten Kostenposten.
Technik 4: Ausgabesampling und frühzeitiger Abbruch
Für einige Anwendungsfälle benötigen Sie keine vollständige LLM-Ausgabe – Sie benötigen eine Entscheidung oder eine Klassifizierung.
Logprobs für Klassifizierung.
# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject logprobs/logit_bias.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Sie fordern das Modell auf, genau ein Token – die Kategorie – auszugeben. Die Kosten bestehen aus einem Eingabedurchlauf und einem Ausgabetoken. Das ist schneller, günstiger und häufig ebenso gut wie eine längere Antwort.
Logit-Bias.
Bei einer bekannten Menge möglicher Ausgaben können Sie die Logits zugunsten gültiger Optionen gewichten.
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
Das lenkt das Modell zur gewünschten Ausgabeart. Für Klassifizierungen ist es günstig und zuverlässig.
Technik 5: Batching
Wenn Sie viele Elemente verarbeiten, bündeln Sie sie.
Asynchrones Batching auf API-Ebene.
Die meisten Anbieter unterstützen asynchrone oder Batch-APIs, die mehrere Anfragen zu geringeren Kosten verarbeiten.
- OpenAI Batch API: 50 % Rabatt, 24-Stunden-SLA.
- Anthropic Message Batches: 50 % Rabatt, 24-Stunden-SLA.
Verarbeiten Sie Hintergrundaufgaben ohne Echtzeitanforderung per Batch. Das halbiert die Kosten.
Prompt-basiertes Batching.
Verarbeiten Sie mehrere Elemente in einem LLM-Aufruf, wenn möglich.
Statt:
[10 separate calls, each classifying one ticket]
Tun Sie:
[1 call, classifying 10 tickets in one prompt]
Der einzelne Aufruf enthält mehr Eingabe – zehn Elemente –, aber nur einmal den festen Overhead aus System-Prompt und Werkzeugbeschreibungen. Insgesamt benötigt er weniger Token als zehn separate Aufrufe.
Hinweis: Qualität kann mit zu vielen Elementen pro Prompt sinken. Testen Sie den Sweet Spot für Ihre Anwendung. Typischerweise sind 5–20 Elemente pro Prompt in Ordnung.
Technik 6: Kleinere Modelle für spezifische Aufgaben
Überlegen Sie über das Standard-Routing hinaus, ob eine Aufgabe tatsächlich ein großes Modell benötigt.
Klassifizierung: Für einfache Klassifizierungen ist ein kleineres Modell häufig ebenso gut wie ein Spitzenmodell. Zu aktuellen Listenpreisen (verifiziert am 2026-07-07) bedeutet Claude Haiku 4.5 mit $1/$5 pro Million gegenüber Claude Opus 4.8 mit $5/$25 eine glatte fünffache Einsparung; bei OpenAIs kleiner Modellklasse gegenüber GPT-5.5 ist der Faktor ähnlich.
Extraktion: Mittelgroße Modelle eignen sich für strukturierte Extraktion. Reservieren Sie das Spitzenmodell für fehlgeschlagene Fälle.
Übersetzung: Spezialisierte Übersetzungsmodelle oder kleinere LLMs bewältigen die meisten Fälle.
Embedding: Verwenden Sie spezialisierte Embedding-Modelle, nicht allgemeine LLMs für Embedding.
Das Muster: Identifizieren Sie Ihre einfachen, eng umrissenen Workloads. Leiten Sie sie an das kleinste Modell weiter, das die Aufgabe ausreichend gut erledigt. Reservieren Sie Spitzenmodelle für komplexe Aufgaben, die Urteilsvermögen erfordern.
Technik 7: Fine-Tuning kleiner Modelle
Bei sehr hohem Volumen und eng umrissenen Aufgaben können Sie ein kleines Modell feinabstimmen.
Beispiel: 100.000 Klassifizierungsanfragen/Tag.
- GPT-5 unverändert: €30/Tag in API-Kosten.
- Feinabgestimmtes 8B-Modell auf dedizierter Inferenzinfrastruktur: €5–10/Tag für die Inferenz, zuzüglich einmaliger Fine-Tuning-Kosten.
Bei ausreichendem Volumen amortisieren sich feinabgestimmte kleine Modelle schnell. Die konkrete Rechnung hängt von Ihrem Volumen ab.
Der Fine-Tuning-Artikel behandelt dies ausführlicher. Das Prinzip: Treffen hohes Volumen und eine enge Aufgabe zusammen, ist Fine-Tuning ein wirksamer Kostenhebel.
Technik 8: Vorfilterung
Bei mehrstufigen LLM-Workflows fängt ein günstiger Filter offensichtliche Fälle vor der teuren Verarbeitung ab.
Beispiel: Klassifizierung + Antwort im Kundensupport.
Günstige Vorfilterung:
- „Ist dies eine echte Supportfrage oder Spam/Rauschen?“ (Klassifizierung mit einem Token durch ein kleines Modell.)
- „Ist dies eine bekannte FAQ?“ (Embedding-Suche; günstig.)
Nur Anfragen, die den Filter passieren, erreichen die teure Antwortgenerierung.
Einsparung: Wenn 30 % der eingehenden Anfragen Rauschen sind oder anhand der FAQ beantwortet werden können, entfallen 30 % der teuren Aufrufe.
Der Vorfilter ist mit €0,0001 pro Aufruf gegenüber €0,05 für die Antwortgenerierung günstig. Der ROI liegt auf der Hand.
Technik 9: Caching über Prompt-Caching hinaus
Ergänzen Sie das Prompt-Caching des Modellanbieters durch Caching auf Anwendungsebene:
Antwort-Caching. Gleiche Anfrage, gleicher Kontext, gleiche Antwort. Speichern Sie die Antwort im Cache und geben Sie sie ohne Modellaufruf zurück.
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
Für idempotente Abfragen eliminiert dies Duplikate vollständig.
Embedding-Caching. Speichern Sie berechnete Embeddings im Cache.
Caching von Retrieval-Ergebnissen. Speichern Sie Suchergebnisse für eine Anfrage für kurze Zeiträume im Cache.
Caching von Werkzeugergebnissen. Cachen Sie Ergebnisse von Werkzeugaufrufen, wenn sich die zugrunde liegenden Daten selten ändern.
Caching-Ebenen ergänzen einander. Auf jeder Ebene vermeiden Sie Aufrufe.
Technik 10: Spekulative Ausführung
Bei latenzkritischen Abläufen, deren nächste Schritte vorhersehbar sind, können Sie Aufrufe spekulativ vorziehen.
Beispiel: Bei einem Support-Agenten folgt auf die Problembeschreibung des Kunden meist die Zusammenfassung des Anliegens. Starten Sie diese Zusammenfassung parallel zur Anzeige der Eingangsbestätigung.
Wenn die Vorhersage richtig ist, ist die Antwort bereit, wenn sie benötigt wird. Wenn falsch, haben Sie einen Aufruf verschwendet.
Das optimiert eher die Latenz als die Kosten, kann die UX bei bestimmten Abläufen aber deutlich verbessern.
Technik 11: Anbieterarbitrage
Verschiedene Anbieter verlangen unterschiedliche Preise für ähnliche Modelle. Nutzen Sie dies.
Open-Source-Modelle bei günstigen Inferenzanbietern.
Llama 3.3 70B bei Together AI: $0,88/M Eingabe und Ausgabe (Listenpreis, verifiziert 2026-07-07). Die geschlossene Modellklasse, mit der es konkurriert, Claude Sonnet 5: $3/M Eingabe, $15/M Ausgabe (Einführungspreis $2/$10 bis 2026-08-31).
Bei Aufgaben, für die ein offenes 70B-Modell genügt, entspricht das ~3,4x bei der Eingabe und ~17x bei der Ausgabe, also je nach Verhältnis von Eingabe zu Ausgabe etwa 3–17x.
Dasselbe Modell bei verschiedenen Anbietern.
Einige offene Modelle werden von mehreren Anbietern mit unterschiedlichen Preisen gehostet. Vergleichen Sie.
Selbsthosting bei Skalierung.
Bei ausreichendem Volumen – etwa €10.000+/Monat für ein bestimmtes Modell – wird Selbsthosting günstiger als API-Aufrufe. Dafür benötigen Sie betriebliche Kapazitäten.
Anbieterarbitrage erhöht die Komplexität: Sie benötigen Multi-Anbieter-Routing mit Fallback und müssen die Modellvariante jedes Anbieters auf Qualität prüfen. In großem Maßstab kann sich dieser Aufwand lohnen.
Technik 12: Inferenzbeschleunigung
Für Selbsthosting: Optimierung der Inferenzschicht selbst.
vLLM, TGI, SGLang. Optimierte Inferenzserver. Zwei- bis zehnfacher Durchsatz gegenüber naiven Implementierungen.
Quantisierung. Modelle mit geringerer Präzision ausführen (4 Bit, 8 Bit). Zwei- bis vierfacher Durchsatz bei geringen Qualitätseinbußen.
Flash Attention, Paged Attention. Architekturverfahren, die moderne Server unterstützen.
Kontinuierliches Batching. Server bündeln laufende Anfragen, um die GPU besser auszulasten.
Für Teams, die in großem Maßstab selbst hosten, ist das wichtig. Bei API-Nutzung übernimmt der Anbieter diese Optimierung.
Technik 13: Streaming
Streaming senkt die Tokenzahl nicht, verbessert jedoch die UX und damit die wahrgenommene Kosteneffektivität.
Bei langen Ausgaben sehen Nutzer sofort erste Inhalte und können während der Generierung mitlesen. Das wirkt deutlich schneller, als auf die vollständige Antwort zu warten.
Bei Agenten gibt das Streaming von Zwischenschritten Einblick in den Fortschritt.
Umsetzung: Jede moderne API unterstützt Streaming. Nutzen Sie es für benutzersichtbare Abläufe.
Technik 14: Budgetgrenzen
Setzen Sie zusätzlich zur Optimierung feste Budgets durch, um unkontrollierte Kosten zu verhindern.
Pro-Anfrage-Budget. Maximale Token pro Anfrage. Stoppen Sie, wenn überschritten.
Budget je Nutzer. Tägliche oder monatliche Kostenobergrenze je Nutzer. Drosseln Sie bei Annäherung.
Budget je Funktion. Jede Funktion erhält ein Budget. Automatische Abschaltung beim Zehnfachen des täglichen Durchschnitts.
Globales Budget. Gesamte tägliche oder monatliche Obergrenze. Pausieren Sie nicht wesentliche Arbeit in der Nähe des Limits.
Diese Grenzen sparen nicht unmittelbar Geld, verhindern aber Katastrophen. Ohne Schutz kann ein einzelner Fehler oder Angriff die Kosten schnell in die Höhe treiben.
Ein durchgerechnetes Beispiel: eine reale Kostenreduktion
Ein Team, das eine KI für den Kundensupport betrieb, zahlte €12.000/Monat. Sechs Monate nach Anwendung dieser Techniken waren es €1.800/Monat – eine Reduktion um 85 %.
Die Änderungen:
-
Prompt-Caching. Prompts wurden umstrukturiert, um den statischen Präfix zu maximieren. ~70 % der Eingabe werden nun gecacht. Einsparung ~30 %.
-
Modell-Routing. Klassifizierung und Ticket-Triage wurden von Claude Sonnet zu Claude Haiku verlagert. Einsparung ~15 %.
-
Ausgabelängensteuerung. Antworten auf 250 Wörter begrenzt, statt 800–1500. Einsparung ~25 %.
-
Vorfilterung. Eine günstige Klassifizierung erkennt Tickets, die sich aus den FAQ beantworten lassen und aus dem Cache bedient werden. ~20 % der Tickets durchlaufen den teuren Prozess nicht mehr. Einsparung ~10 %.
-
Antwort-Caching für FAQ. Identische Fragen liefern gecachte Antworten. Einsparung ~5 %.
Die genannten Prozentwerte sind der Anteil jeder Technik an der Gesamtreduktion. Sie addieren sich zu ~85 % und wurden jeweils anhand der nach der vorherigen Änderung verbleibenden Rechnung gemessen. Es sind keine unabhängigen Multiplikatoren, die Sie auf Ihre eigene Rechnung anwenden können.
Qualität: Gemäß allen erhobenen Kennzahlen – Kundenzufriedenheit, Korrektheit der Antworten und Lösungsquote – blieb die Qualität unverändert oder verbesserte sich leicht.
Betrieblicher Aufwand: ~80 Entwicklungsstunden über 3 Monate. ROI: Amortisation in 2 Wochen.
Häufige Fehler
Einige Muster, die wir beobachten:
Fehler 1: Keine Kostenverfolgung. Das Team weiß nicht, was eine Funktion, ein Nutzer oder ein Aufruf kostet. Ohne Messung ist keine Optimierung möglich.
Fehler 2: Die falsche Größe optimieren. Wochen werden darauf verwendet, Eingabetoken um 5 % zu reduzieren, obwohl Ausgabetoken 80 % der Rechnung ausmachen. Messen Sie zuerst und optimieren Sie die größten Kostenverursacher.
Fehler 3: Qualitätsregressionen. Kostensenkungen werden ohne Qualitätsüberwachung eingeführt. Geld wird gespart, Nutzer gehen verloren. Verbinden Sie Kostenarbeit immer mit Evaluationssuiten.
Fehler 4: Über-Routing. Aggressives Routing zu kleinen Modellen für Aufgaben, die sie nicht wirklich bewältigen können. Falsche Einsparungen.
Fehler 5: Cache-Verschmutzung. Der Cache füllt sich mit seltenen Anfragen. Die meisten Einträge werden nur einmal verwendet, Cache-Fehlschläge dominieren. Die Caching-Strategie muss verbessert werden.
Fehler 6: Batch-API überspringen. Echtzeit, obwohl Batch ausreichen würde. Die Hälfte des Preises lag auf dem Tisch.
Fehler 7: Über-Engineering. Aufwendige Kostenoptimierung auf Features, die ohnehin nicht profitabel sind. Manchmal ist die richtige Antwort: „Das Feature abschalten.“
Fehler 8: Keine Budgetgrenzen. Ein einziger Fehler löst unkontrollierte Kosten aus. Aus einer kleinen Unannehmlichkeit wird eine Katastrophe.
Der kulturelle Teil
Kostendisziplin ist zum Teil eine Frage der Kultur. Erfolgreiche Teams:
- behandeln Kosten als Kennzahl, nicht als nachträgliche Überlegung,
- benennen eine verantwortliche Person, häufig an der Schnittstelle zwischen Entwicklung und Finanzen,
- prüfen Kosten in den wöchentlichen Kennzahlen,
- untersuchen Kostenspitzen sofort,
- legen Budgets je Funktion fest und alarmieren bei Schwellenüberschreitungen,
- machen Zielkonflikte zwischen Kosten, Qualität und Latenz ausdrücklich sichtbar.
Weniger erfolgreiche Teams:
- behandeln Kosten als Problem anderer,
- entdecken die Rechnung erst am Monatsende,
- reagieren erst im Nachhinein auf Spitzen,
- verfügen über kein Budgetkonzept,
- überspringen die Diskussion über Zielkonflikte und optimieren jeweils nur eine Dimension.
Kultureller Wandel ist schwieriger als technischer Wandel. Er sorgt jedoch dafür, dass die technischen Verbesserungen Bestand haben.
Preisentwicklung
Ein Hinweis auf den breiteren Trend.
Die Kosten je Einheit Leistungsfähigkeit sind Jahr für Jahr stark gesunken – hauptsächlich, weil kleinere Modelle die Spitzenmodelle des Vorjahres einholen, nicht weil die Listenpreise aktueller Spitzenmodelle einbrechen. Behandeln Sie jede Angabe zum „Preis in einem Jahr“ als modellierte Annahme und prüfen Sie vor dem Zitieren erneut die Modell- und Preisreferenz.
Das bedeutet:
- Einige Optimierungen werden mit der Zeit weniger wichtig (die absoluten Kosten sinken ohnehin).
- Einige Workloads, die derzeit unprofitabel sind, werden profitabel.
- Bauen Sie langfristig: Eine saubere Architektur ist wichtiger, als heute jeden Cent einzusparen.
Dennoch bleibt Optimierung auch bei sinkenden Preisen wichtig. Ineffiziente Systeme verschwenden auf jedem Preisniveau Geld. Wettbewerbsvorteile entstehen häufig bei Teams, die ihre Systeme effizient und kostengünstig betreiben.
Ein 90-Tage-Plan zur Kostenoptimierung
Für ein Team, das bei „Wir haben eine KI-Funktion, deren Kosten höher als erwartet sind“ beginnt:
Wochen 1–2: Messen.
- Instrumentieren Sie Kosten pro Aufruf.
- Erstellen Sie Dashboards je Funktion und Nutzer.
- Identifizieren Sie die größten Kostenbeiträge.
Wochen 3–4: Schnelle Gewinne.
- Aktivieren Sie Prompt-Caching, wo unterstützt.
- Strukturieren Sie die drei wichtigsten Prompts um, um die Cache-Trefferrate zu maximieren.
- Setzen Sie max_tokens auf allen Aufrufen.
- Implementieren Sie Budget-Alarme.
Wochen 5–6: Routing.
- Identifizieren Sie einfache Aufgaben, die derzeit auf Spitzenmodellen laufen.
- Erstellen Sie einen Router für die 3–5 am häufigsten genutzten Endpunkte.
- Testen Sie auf Qualitätseinbußen.
Wochen 7–8: Ausgabe und Caching.
- Begrenzen Sie Ausgabelängen, wo nicht sichtbar.
- Ergänzen Sie einen Antwort-Cache auf Anwendungsebene für häufige Anfragen.
- Ergänzen Sie Vorfilter für die Abläufe mit dem höchsten Volumen.
Wochen 9–10: Fortgeschrittene.
- Batch-API für Aufgaben ohne Echtzeitanforderung.
- Alternative Anbieter bewerten.
- Embedding-Cache, Retrieval-Cache.
Wochen 11–12: Absicherung.
- Budgetgrenzen für jede Funktion.
- Kosten-Dashboards in regelmäßige Teamprüfungen aufnehmen.
- Muster für künftige Funktionen dokumentieren.
Nach 90 Tagen ist eine Kostenreduktion um 50–80 % realistisch. Die Qualität wird überwacht, die Disziplin ist verankert.
Erst messen, dann Einsparungen kombinieren
LLM-Kosten lassen sich ohne Qualitätsverlust meist um 60–90 % reduzieren. Die Techniken sind bekannt: Caching, Routing, Ausgabesteuerung, Batching, Vorfilterung, Antwort-Caching, Modellauswahl und Budgetgrenzen.
Für sich genommen spart jede Maßnahme moderat. Zusammen führen sie zu erheblichen Einsparungen.
Teams, die dies richtig umsetzen, machen unrentable KI-Funktionen rentabel. Andere müssen schließlich Funktionen einstellen, die eigentlich tragfähig gewesen wären.
Messen Sie zuerst. Optimieren Sie die größten Kostenverursacher. Überwachen Sie weiterhin die Qualität. Verankern Sie Kostendisziplin in der regelmäßigen Arbeit des Teams.
Das Ergebnis sind KI-Funktionen, die nicht nur technisch, sondern auch wirtschaftlich skalieren. So wird KI zu einem nachhaltigen Teil des Produkts und nicht nur zu einer Schlagzeile bei der Einführung.
