Zum Inhalt springen
Founder-Preis — fest für frühe KundenLoslegen →

LLM-Kostenoptimierung: Sechs Hebel für Produktions-Agent-Flotten

LLM-Kostenoptimierung ist die Praxis, Token-Ausgaben in produktiven KI-Systemen zu senken, ohne die Aufgabenqualität zu beeinträchtigen. Der State of FinOps 2026-Bericht der FinOps Foundation ergab, dass KI/ML-Ausgaben bei 67 % der Befragten die Nummer-1-Kostenkategorie sind, wobei der mediane LLM-Aufwand jährlich verdoppelt wird. Sechs konkrete Hebel, nämlich Modell-Routing, Prompt-Caching, Batch-Inferenz, Kontextkomprimierung, agentenspezifische Budgetobergrenzen und Ausgabe-Token-Steuerung, können die Kosten pro Aufgabe in gemischten Produktions-Agent-Pipelines um 50 bis 80 % senken, ohne die Ergebnisqualität zu verändern.

LLM-Kostenoptimierung ist die strukturierte Praxis, die Token- und Rechenausgaben von Large-Language-Model-API-Aufrufen in Produktionssystemen zu reduzieren, angewendet auf Modellauswahl, Prompt-Struktur, Inferenz-Timing, Kontextverwaltung und Budgetdurchsetzung, um die Kosten pro erfolgreich abgeschlossener Aufgabe ohne Qualitätsverlust zu minimieren.

Warum LLM-Ausgaben zum Vorstandsthema geworden sind

Unternehmens-KI-Budgets folgten einem vorhersehbaren Verlauf: schnell aufbauen in 2024 bis 2025, dann die Rechnung in Empfang nehmen. Ein einziger GPT-4o-Aufruf mit einem vollständig ausgefüllten 128k-Kontext kostet allein $0,32 an Eingabe-Token. Eine Multi-Agent-Pipeline mit 20 LLM-Aufrufen pro Aufgabe erreicht $6,40 pro Aufgabe nur aus Eingabe-Token, bevor Ausgabe, Werkzeugaufrufe oder Infrastrukturkosten anfallen. Bei 10.000 Aufgaben pro Tag sind das $64.000 täglich an LLM-API-Ausgaben, also $23 Mio. pro Jahr, aus einer einzigen kostenoptimierten Pipeline.

Der State of FinOps 2026 der FinOps Foundation veranschaulicht dies organisatorisch: KI/ML ist die am schnellsten wachsende neue Budgetlinie für 67 % der Enterprise-FinOps-Teams, wobei sich der mediane LLM-Aufwand jährlich verdoppelt. Dies ist keine einmalige Kostenspitze in der Prototypenphase, sondern eine wiederkehrende Betriebsausgabe, die direkt mit der Nutzung skaliert und ein Unit-Economics-Problem schafft, das sich mit wachsender Akzeptanz potenziert.

Die gute Nachricht: LLM-Kosten lassen sich stark komprimieren. Im Gegensatz zu Infrastrukturkosten (wo mehr Hardware für mehr Last benötigt wird) reagieren Token-Kosten auf Designentscheidungen. Eine Pipeline, die mit den sechs unten beschriebenen Hebeln neu gestaltet wurde, erzielt routinemäßig 50 bis 80 % Kostenreduzierung ohne Qualitätsverlust, nicht durch schlechtere Modelle, sondern durch das richtige Modell für jede Aufgabe, das Entfernen verschwendeter Token und die Durchsetzung harter Ausgabegrenzen.

OpenLegion-Bewertung: Budgetobergrenzen sind ein Sicherheitsprimitivum, keine reine FinOps-Maßnahme

Die meisten Frameworks behandeln LLM-Kosten als Überwachungsproblem: Dashboard einrichten, Alarm bei Überschreitung des Schwellenwerts, nachträglich untersuchen. Der Zähler lief weiter, während Sie schliefen.

OpenLegion behandelt agentenspezifische Budgetobergrenzen als Sicherheitsprimitivum, das auf Infrastrukturebene durchgesetzt wird. Jeder Agent hat eine daily_usd- und monthly_usd-Obergrenze. Wenn ein Agent seine Obergrenze erreicht, werden LLM-Aufrufe für diesen Agenten blockiert, nicht für die gesamte Pipeline, nur für den über Budget liegenden Agenten. Andere Agenten in der Flotte laufen weiter. Dies ist ein harter Schnitt, keine weiche Warnung.

Drei konkrete Implikationen:

Prävention von Endlosschleifen. Ein Agent in einer rekursiven Schleifenanalogie, ob durch Prompt-Injektion, eine fehlerhafte Aufgabe oder einen Modellausfall, erreicht seine Tagesobergrenze und stoppt. Ohne harte Obergrenze kann eine rekursive Schleife in einem Long-Context-Agenten in wenigen Minuten Hunderte von Dollar kosten. Mit einer Obergrenze von $2/Tag pro Agent beträgt der Worst Case $2.

Denial-of-Wallet-Abwehr. OWASP LLM10:2025 nennt Denial-of-Wallet als eines der größten LLM-Anwendungsrisiken: Ein Angreifer manipuliert einen Agenten zur Erzeugung unbegrenzter Token-Ausgabe und verbrennt das API-Budget des Betreibers. Eine harte Obergrenze, die auf Mesh-Ebene durchgesetzt wird, kann vom Agenten nicht umgangen werden.

Planbare Kostenmodellierung. Mit agentenspezifischen Obergrenzen sind die maximalen Tagesausgaben für eine Flotte von N Agenten N mal die Tagesobergrenze. Kosten werden zu einer begrenzten Variable, keinem offenen Risiko.

Für den vollständigen Sicherheitskontext einschließlich Prompt-Injektion und Credential-Schutz, siehe KI-Agent-Sicherheit und Denial-of-Wallet-Abwehr.

Die sechs Hebel

Hebel 1: Modell-Routing — das günstigste ausreichende Modell verwenden

Der größte Einzelhebel. Claude Haiku 4.5 kostet $0,80/$4 pro Million Eingabe-/Ausgabe-Token. Claude Opus 4.8 kostet $5/$25. Das Routing einer Aufgabe zu Haiku statt Opus spart 84 % bei Eingabe und 84 % bei Ausgabe für diesen Aufruf. Die meisten Schritte in einer Produktions-Agent-Pipeline erfordern keine Opus-Reasoning-Kapazität.

Ein Drei-Stufen-Routing-Muster deckt die meisten Pipelines ab:

AufgabentypModellKosten (Eingabe/M)
Klassifizierung, Formatierung, ExtraktionClaude Haiku 4.5$0,80
Mittleres Reasoning, ZusammenfassungClaude Sonnet 4$3,00
Komplexe Synthese, mehrstufiges ReasoningClaude Opus 4.8$5,00

Die Routing-Logik ist ein Klassifikator, der vor dem Dispatch läuft: Eingabeaufgaben auf Komplexität bewerten, einem Tier zuordnen, zum entsprechenden Modell routen. Databricks Genie implementierte dieses Muster und berichtete von 61 % Kostensenkung gegenüber dem Routing aller Aufgaben zu Opus 4.7.

Ein konservatives Routing-Verhältnis, 80 % der Schritte zu Haiku, 15 % zu Sonnet, 5 % zu Opus, ergibt gemischte Kosten von ungefähr $1,09/M Eingabe-Token gegenüber $5,00/M bei ausschließlichem Einsatz von Opus. Bei einer Pipeline mit 10.000 Aufgaben/Tag bedeutet das ca. $39.100 tägliche Einsparung.

Hebel 2: Prompt-Caching — 90 % Einsparung bei wiederholtem Kontext

Anthropic veröffentlichte Prompt-Caching am 2024-08-14. Wenn ein großer Teil eines Prompts (Systemanweisungen, Dokumentkontext, Few-Shot-Beispiele) über mehrere API-Aufrufe hinweg identisch ist, werden diese Token nach dem ersten Aufruf zwischengespeichert. Nachfolgende Aufrufe, die dasselbe Präfix enthalten, zahlen 10 % des Standard-Eingabe-Token-Preises für den gecachten Teil, eine Reduzierung um 90 %.

Bei Opus 4.8-Preisen ($5,00/M Eingabe-Token) kostet ein 10.000-Token-Systemaufruf $0,05 pro Aufruf ohne Cache. Mit Caching fällt er auf $0,005. Für einen Agenten mit 200 Aufrufen pro Tag mit demselben Systemprompt sind das $10/Tag ohne Cache gegenüber $1/Tag mit Cache, eine Einsparung von $9/Tag durch eine einzige API-Parameteränderung.

Caching gilt für stabilen Inhalt: Systemprompts, großen Dokumentkontext, der einmal pro Sitzung geladen wird, Few-Shot-Beispiele und lange Tool-Definitionen. Es gilt nicht für dynamischen Inhalt (die Nachricht des Benutzers, aktuelle Tool-Ergebnisse). Die Aktivierung erfordert cache_control: {"type": "ephemeral"} auf dem Inhaltsblock in der Anthropic-API.

OpenAI bietet ca. 50 % Einsparung bei gecachten Eingabe-Token über automatisches Prompt-Caching auf GPT-4o.

Hebel 3: Batch-Inferenz — 50 % Rabatt für Nicht-Echtzeit-Aufgaben

Anthropics Message Batches API und OpenAIs Batch API berechnen asynchrone Workloads mit 50 % des Standardpreises. Anforderungen werden in die Warteschlange gestellt und innerhalb von Minuten bis Stunden verarbeitet.

Batch-Verarbeitung eignet sich für Workloads, die asynchrone Latenz tolerieren:

  • Nächtliche Berichterstattung aus akkumulierten Daten
  • Dokumentenverarbeitungswarteschlangen (klassifizieren, zusammenfassen, extrahieren)
  • Bulk-Evaluierungsläufe (Agent-Ausgaben gegen Grundwahrheit bewerten)
  • Vorberechnung von Einbettungen oder Zusammenfassungen für eine Wissensbasis-Aktualisierung

Eine nächtliche Pipeline, die 5.000 Dokumente zum GPT-4o-Standardpreis ($2,50/M Eingabe) gegenüber dem Batch-Preis ($1,25/M) verarbeitet, spart $1,25 pro Million Token. Bei einer Pipeline mit 100M Token pro Nacht sind das $125 Einsparung jede Nacht, $45.000/Jahr aus einer einzigen Planungsänderung.

Hebel 4: Kontextkomprimierung — Unnötiges herausfiltern

Jedes Token, das in einem API-Aufruf gesendet wird, ist ein in Rechnung gestelltes Token. Kontextkomprimierung entfernt Token, die nicht zur Ausgabequalität beitragen.

Drei Komprimierungstechniken in Prioritätsreihenfolge:

Gesprächszusammenfassung. Eine 40.000-Token-Gesprächshistorie, komprimiert auf eine strukturierte 8.000-Token-Zusammenfassung, senkt die Eingabekosten für nachfolgende Aufrufe um 80 %. Für Aufgaben, bei denen das Modell die Essenz früherer Arbeit benötigt, nicht wörtliche frühere Gesprächsrunden, ist der Qualitätseffekt minimal.

Tool-Ergebnis-Bereinigung. Ein Web-Scrape oder eine Datenbankabfrage kann 50.000 Token an Rohinhalten zurückgeben, wenn der Agent 200 Token extrahierter Fakten benötigt. Tool-Ergebnisse vor dem Einfügen in den Kontext parsen und filtern.

Ausführliche API-Antwort-Bereinigung. Viele APIs geben tief verschachteltes JSON mit Metadaten, Paginierungsobjekten und Verwaltungsfeldern zurück, die der LLM nicht benötigt. Einen Nachverarbeitungsschritt schreiben, der nur die für den nächsten Reasoning-Schritt des Agenten erforderlichen Felder extrahiert.

Hebel 5: Agentenspezifische Budgetobergrenzen — Durchsetzung auf Infrastrukturebene

Agentenspezifische Budgetobergrenzen sind nicht nur FinOps-Governance, sie sind die Absicherung, die alle anderen Kostenoptimierungen in der Produktion vertrauenswürdig macht. Ohne harte Obergrenze kann jede Routing-Fehlkonfiguration, jeder Cache-Fehler oder jede Endlosschleife die Einsparungen aus den Hebeln 1 bis 4 zunichte machen.

OpenLegion implementiert daily_usd und monthly_usd pro Agent auf Mesh-Ebene. Der Cost Tracker in Zone 2 des Vier-Zonen-Vertrauensmodells führt eine laufende Ausgabensumme pro Agent in Echtzeit. Wenn die Obergrenze erreicht wird:

  1. LLM-Aufrufe für diesen Agenten werden blockiert
  2. Die Pipeline läuft weiter, andere Agenten in der Flotte sind nicht betroffen
  3. Der Status des blockierten Agenten wird auf der Blackboard auf blocked aktualisiert
  4. Logik auf Orchestrator-Ebene kann eine Umleitung oder einen eleganten Abschluss für die Aufgabe dieses Agenten auslösen

Dies unterscheidet sich strukturell von weichen Warnungen. Eine weiche Warnung löst aus, wenn die Ausgaben einen Schwellenwert überschreiten; der Zähler läuft weiter, während ein Mensch untersucht. Ein harter Schnitt stoppt die Ausgaben sofort.

Hebel 6: Ausgabe-Token-Steuerung — strukturierte Ausgaben und eingeschränkte Generierung

Ausgabe-Token kosten bei den meisten Preisplänen mehr als Eingabe-Token (Opus 4.8: $5 Eingabe, $25 Ausgabe pro Million). Unkontrollierte Textgenerierung verschwendet Ausgabe-Token durch Absicherungsformulierungen, Haftungsausschlüsse, Präambeln und Formatierungen, die das nachgelagerte System ignoriert.

Drei Ausgabesteuerungstechniken:

JSON-Modus / strukturierte Ausgaben. Für Aufgaben, die strukturierte Daten produzieren (Klassifizierungsbezeichnungen, extrahierte Felder, Bewertungsergebnisse), reduziert das Verlangen nach JSON-Ausgabe statt Prosa die Ausgabe-Token-Anzahl um 40 bis 60 % und eliminiert Post-Processing-Parsing-Fehler.

Explizite max_tokens-Obergrenzen. max_tokens auf die realistische Obergrenze für die Aufgabe setzen. Eine Klassifizierungsaufgabe, die eine von fünf Bezeichnungen ausgibt, sollte max_tokens: 20 haben, nicht die Modellstandardeinstellung von 4.096.

Systemaufruf-Framing für Kürze. Anweisungen wie "Nur JSON antworten. Keine Präambel, keine Erklärung." reduzieren die Ausgabe-Token-Anzahl für strukturierte Aufgaben zuverlässig.

Wie eine kostenoptimierte Agent-Flotte in der Praxis aussieht

Eine konkrete fünfstufige Inhaltspipeline vor und nach der Optimierung:

Vorher (unkontrollierte Standardwerte):

  • Alle Agenten verwenden Claude Opus 4.8
  • Kein Prompt-Caching
  • Vollständige Tool-Ausgaben in den Kontext eingefügt
  • Keine agentenspezifischen Budgetobergrenzen
  • Prosa-Ausgabe für strukturierte Extraktionsschritte
  • Geschätzte Kosten pro Aufgabe: ca. $0,082

Nachher (alle sechs Hebel angewendet):

  • Schritt 1 (Themenklassifikation): Haiku 4.5, $0,0004
  • Schritt 2 (Recherche, 5 Websuchen): Sonnet 4 + Tool-Ergebnis-Bereinigung, $0,008
  • Schritt 3 (Gliederungsgenerierung): Sonnet 4 + Prompt-Caching auf Systemaufruf, $0,003
  • Schritt 4 (Entwurfserstellung): Opus 4.8 + strukturierte JSON-Ausgabe, $0,014
  • Schritt 5 (Validierung): Haiku 4.5 + strukturierte Ausgabe, $0,0005
  • Agentenspezifische Obergrenzen: $2/Tag je Agent (5 Agenten = $10/Tag maximale Flottenausgaben)
  • Geschätzte Kosten pro Aufgabe: ca. $0,026

Das ist eine Reduzierung um 68 %, von $0,082 auf $0,026 pro Aufgabe. Bei 1.000 Aufgaben/Tag ergibt der Unterschied $56/Tag, $20.440/Jahr, aus Designentscheidungen ohne Änderung der Ausgabequalität.

Vergleich: Kostensteuerung über Agent-Frameworks hinweg

DimensionOpenLegionLangGraphCrewAIAutoGen
Modell-Routing eingebautJa, pro-Agent-Modellfeld; jeder Agent kann ein anderes Modell verwendenNein, manuell im BenutzercodeNein, manuell im BenutzercodeNein, manuell im Benutzercode
Prompt-Caching-IntegrationUnterstützt über Anthropic/OpenAI-APIUnterstützt über APIUnterstützt über APIUnterstützt über API
Agentenspezifische BudgetobergrenzenJa, daily_usd + monthly_usd auf Mesh-EbeneNeinNeinNein
Harter AusgabenstoppJa, LLM-Aufrufe bei Überschreitung blockiert, Pipeline läuft weiterNeinNeinNein
Batch-Inferenz-UnterstützungÜber API (Anthropic/OpenAI Batch APIs)Über APIÜber APIÜber API
Echtzeit-Kosten-TrackingJa, Cost Tracker in Zone 2 pro AgentNicht eingebautNicht eingebautNicht eingebaut

Für einen vollständigen Framework-Vergleich einschließlich Orchestrierung, Sicherheit und Speicher, siehe den KI-Agent-Framework-Vergleich. Für Orchestrierungsmuster, die mit der Budgetdurchsetzung interagieren, siehe den KI-Agent-Orchestrierungsleitfaden.

Häufig gestellte Fragen

Was ist LLM-Kostenoptimierung?

LLM-Kostenoptimierung ist die Praxis, Token- und Rechenausgaben in produktiven KI-Systemen ohne Qualitätsverschlechterung zu reduzieren. Sechs Haupthebel decken den Bereich ab: Modell-Routing (günstigstes ausreichendes Modell pro Aufgabe verwenden), Prompt-Caching (90 % Einsparung bei wiederholtem Kontext), Batch-Inferenz (50 % Rabatt für asynchrone Workloads), Kontextkomprimierung (Unnötiges herausfiltern), agentenspezifische Budgetobergrenzen (harte infrastrukturelle Schnitte) und Ausgabe-Token-Steuerung (strukturierte Ausgaben statt ausführlicher Prosa). Gemeinsam angewendet erzielen diese Hebel routinemäßig 50 bis 80 % Kostenreduzierung in Produktions-Agent-Pipelines.

Wie stark kann Prompt-Caching die LLM-Kosten senken?

Anthropic-Prompt-Caching, veröffentlicht am 2024-08-14, reduziert Eingabe-Token-Kosten um bis zu 90 % bei wiederholtem Kontext. Ein 10.000-Token-Systemaufruf kostet bei Claude Opus 4.8-Preisen $0,05 pro Aufruf ohne Cache und $0,005 mit Cache. OpenAI bietet etwa 50 % Einsparung bei gecachten Eingabe-Token durch automatisches Prompt-Caching auf GPT-4o. Caching gilt für stabilen Inhalt: Systemprompts, Dokumentkontext, Few-Shot-Beispiele und große Tool-Definitionsblöcke.

Was ist Modell-Routing bei KI-Agenten?

Modell-Routing sendet jeden Schritt in einer Agent-Pipeline zum günstigsten Modell, das ihn zuverlässig handhaben kann. Einfache Klassifizierungs- und Extraktionsaufgaben gehen zu Claude Haiku 4.5 bei $0,80 pro Million Eingabe-Token; mittleres Reasoning zu Sonnet 4 bei $3,00; komplexe Synthese zu Opus 4.8 bei $5,00. Databricks Genie erzielte 61 % Kostensenkung gegenüber dem Routing aller Aufgaben zu Opus 4.7.

Was ist die Anthropic-Batch-Inferenz-API und wie viel spart sie?

Anthropics Message Batches API verarbeitet Anfragen asynchron zu 50 % des Standardpreises; Ergebnisse werden innerhalb von Minuten bis Stunden zurückgegeben. OpenAI bietet eine ähnliche Batch-API zum gleichen 50-%-Rabatt. Batch-Verarbeitung eignet sich für Workloads, die asynchrone Latenz tolerieren: nächtliche Berichterstattung, Dokumentenverarbeitungswarteschlangen, Bulk-Klassifizierung und Evaluierungsläufe.

Wie funktionieren agentenspezifische Budgetobergrenzen in OpenLegion?

Jeder Agent in OpenLegion hat eine daily_usd- und monthly_usd-Obergrenze, die auf Mesh-Ebene durch den Cost Tracker in Zone 2 durchgesetzt wird. Wenn ein Agent seine Obergrenze erreicht, werden LLM-Aufrufe für diesen Agenten sofort blockiert; der Rest der Pipeline läuft weiter. Eine Flotte von 20 Agenten, die jeweils auf $5/Tag begrenzt sind, hat ein maximales tägliches Risiko von $100.

Wie reduziert Kontextkomprimierung LLM-Token-Kosten?

Kontextkomprimierung entfernt Token aus API-Aufrufen, die nicht zur Ausgabequalität beitragen: Zusammenfassung der Gesprächshistorie (ein 40.000-Token-Kontext komprimiert auf 8.000 Token senkt die Eingabekosten um 80 %), Bereinigung von Tool-Ergebnissen auf wesentliche Felder und Bereinigung ausführlicher API-Antwort-Metadaten vor der Kontextinjektion. Kombiniert können diese Techniken das Eingabe-Token-Volumen um das 4- bis 6-Fache reduzieren.

Was ist Denial-of-Wallet und wie verhindern Budgetobergrenzen es?

Denial-of-Wallet ist OWASP LLM10:2025, ein Angriff, bei dem ein Agent manipuliert wird, um unbegrenzte Token zu verbrauchen und das API-Budget des Betreibers zu erschöpfen. Agentenspezifische Budgetobergrenzen mit harten infrastrukturellen Schnitten verhindern dies: Wenn die Obergrenze erreicht wird, werden LLM-Aufrufe von der Mesh-Ebene blockiert, nicht vom Agenten selbst.

Agenten mit eingebauter Kostensteuerung betreiben

LLM-Kosten sind eine Engineering-Variable, kein fixer Overhead. Modell-Routing, Prompt-Caching, Batch-Inferenz, Kontextkomprimierung, strukturierte Ausgaben und harte agentenspezifische Budgetobergrenzen adressieren jeweils einen eigenen Kostentreiber. Gemeinsam eingesetzt wandeln sie eine unvorhersehbare Ausgabe in eine begrenzte, planbare Position um, die effizient mit der Nutzung skaliert.

Für die Plattform, die Budgetobergrenzen auf Infrastrukturebene durchsetzt, siehe die KI-Agent-Plattform-Übersicht. Für die Sicherheitsdimension der Budgetdurchsetzung einschließlich Denial-of-Wallet, siehe KI-Agent-Sicherheit.

Produktionsagenten mit auf Infrastrukturebene durchgesetzten Budgetobergrenzen betreiben