Optimierung der Kosten für KI-Agenten: Token-Nutzung und Caching

Die Betriebskosten von KI-Agenten können überraschend schnell von überschaubar bis alarmierend ansteigen. Ein Agent, der 10 Transaktionen pro Tag abwickelt, ist kostengünstig. Derselbe Agent, der 5.000 Transaktionen pro Tag verarbeitet, wobei jede Transaktion 3–4 LLM-Aufrufe mit großen Kontextfenstern erfordert, kann Tausende von Dollar an monatlichen API-Kosten generieren – Kosten, die im ursprünglichen ROI-Modell nicht enthalten waren.

Kostenoptimierung ist für KI-Bereitstellungen im Produktionsmaßstab keine Option. Es ist der Unterschied zwischen einem Agenten, der einen positiven ROI liefert, und einem Agenten, der ihn schmälert. Dieser Leitfaden behandelt die praktischen Strategien, die die Kosten bei typischen OpenClaw-Bereitstellungen um 40–70 % senken, ohne die Ausgabequalität zu beeinträchtigen.

Wichtige Erkenntnisse

• Token-Optimierung (prompte Komprimierung, Kontextbereinigung) reduziert die API-Kosten um 25–40 % ohne Qualitätsverlust – Semantisches Caching eliminiert LLM-Aufrufe für wiederholte oder ähnliche Anfragen, wodurch die Kosten bei vielen Arbeitslasten um 30–60 % gesenkt werden
• Beim Modellrouting werden günstige Modelle für einfache Aufgaben und teure Modelle nur bei Bedarf verwendet
• Prompt-Caching (sofern von Anbietern verfügbar) reduziert die Eingabe-Token-Kosten für sich wiederholende System-Prompts – Durch die Stapelverarbeitung wird der Overhead pro Anruf für hochvolumige, nicht zeitkritische Arbeitslasten reduziert – Die Kostenüberwachung mit Zuordnung pro Workflow identifiziert das teuerste Agentenverhalten – Streaming reduziert die Latenzzeit bis zum ersten Token für benutzerorientierte Agenten, ohne die Gesamtkosten zu erhöhen – Eine umfassende Kostenoptimierungsstrategie reduziert die gesamten LLM-Ausgaben im Vergleich zu nicht optimierten Bereitstellungen in der Regel um 45–65 %

---

Kostentreiber für KI-Agenten verstehen

Bevor Sie die Kosten optimieren, sollten Sie verstehen, was sie antreibt. Die LLM-API-Kosten basieren hauptsächlich auf dem Token-Verbrauch:

Eingabetokens: Jedes an das Modell gesendete Token kostet Geld – die Systemeingabeaufforderung, die Benutzernachricht, den abgerufenen Kontext (RAG-Blöcke), den Konversationsverlauf und alle Beispiele (wenige Aufnahmen). Bei aktuellen Frontier-Modellen sind die Input-Token-Kosten in der Regel zwei- bis fünfmal niedriger als die Output-Token-Kosten.

Ausgabetoken: Vom Modell in seiner Antwort generierte Token. Ausführliche Ausgaben kosten mehr. Argumentationsschritte (Gedankenkette) kosten mehr als direkte Antworten. Strukturierte JSON-Ausgaben kosten mehr als Prosa, wenn der JSON viele Felder hat.

Anrufvolumen: Für jeden LLM-Anruf fallen Mindestkosten an. Multi-Step-Agenten, die 5 LLM-Anrufe pro Aufgabe tätigen, kosten fünfmal mehr als Single-Call-Agenten – können aber deutlich bessere Ergebnisse liefern. Der Schlüssel liegt darin, unnötige Anrufe zu vermeiden.

Modellauswahl: Der Kostenunterschied zwischen den Modellen ist enorm. Claude 3 Haiku kostet etwa 50x weniger als Claude 3 Opus pro Token. GPT-4o kostet etwa 15x mehr als GPT-4o mini. Die Verwendung eines Grenzmodells für jede Aufgabe ist die häufigste Quelle unnötiger Kosten.

Ein realistisches Kostenszenario:

Der Agent bearbeitet 1.000 Kundendiensttickets pro Tag. Für jedes Ticket ist Folgendes erforderlich:

• Systemaufforderung: 800 Token – Abgerufener Kontext: 1.200 Token
• Ticketinhalt: 400 Token
• Gesamteingabe: 2.400 Token
• Antwort: 600 Token

Verwendung von Claude 3.5 Sonnet (3 $/M Input, 15 $/M Output):

• Tägliche Kosten: 1.000 × [(2.400 × 3 $/M) + (600 × 15 $/M)] = 16,20 $/Tag = 486 $/Monat

Mit der Optimierung (in diesem Leitfaden gezeigt) sinkt dieser Wert auf 150–200 US-Dollar/Monat – eine Reduzierung um 60 %.

---

Sofortige Komprimierung und Token-Reduzierung

System-Prompt-Optimierung

Bei jeder Anfrage werden Systemaufforderungen gesendet. Eine aufgeblähte Systemeingabeaufforderung mit 2.000 Token, die ohne Informationsverlust auf 800 Token komprimiert werden könnte, zahlt 2,5-mal mehr als nötig für Eingabe-Token.

Techniken:

Redundanz entfernen: Überprüfen Sie Ihre Systemaufforderungen auf Informationen, die an mehreren Stellen wiederholt werden. Konsolidieren.

Komprimierte Sprache verwenden: Konversationspräambel vermeiden. Vergleichen Sie:

Ausführlich (47 Token): „Sie sind ein hilfreicher Assistent, der sich mit der Überprüfung von Verträgen auskennt. Ihre Aufgabe ist es, den Vertrag sorgfältig durchzulesen und alle Klauseln zu identifizieren, die ein Risiko für unser Unternehmen darstellen könnten.“

Komprimiert (23 Token): „Sie sind ein Vertragsrisikoanalyst. Identifizieren Sie Klauseln, die ein Risiko für das Kundenunternehmen darstellen.“

Die komprimierte Version vermittelt identische Anweisungen. LLMs reagieren auf semantische Inhalte, nicht auf die Wortzahl.

Verwenden Sie eine strukturierte Formatierung: Nummerierte Listen und Aufzählungspunkte vermitteln Informationen dichter als Absätze.

Entfernen Sie Beispiele aus der Systemeingabeaufforderung, wenn Sie Few-Shot verwenden: Wenn Sie Beispiele sowohl in der Systemeingabeaufforderung als auch in der Benutzernachricht haben, zahlen Sie doppelt dafür. An einem Standort konsolidieren.

Überprüfen Sie regelmäßig die Länge der Systemaufforderungen: Systemaufforderungen nehmen tendenziell zu, da Teams im Laufe der Zeit Anweisungen hinzufügen, ohne veraltete zu entfernen. Bei einer vierteljährlichen Überprüfung wird in der Regel festgestellt, dass 20–30 % des Inhalts von Systemaufforderungen entfernt oder komprimiert werden können.

Kontextfensterverwaltung

RAG-Abrufe (Retrieval Augmented Generation) sind einer der größten Kostentreiber für wissensintensive Agenten. Jeder abgerufene Block besteht aus Eingabetokens. Nicht optimiertes RAG ruft häufig mehr Kontext ab als nötig.

Optimierung der Chunk-Größe: Kleinere Chunks (256–512 Token), die in größeren Mengen abgerufen werden, übertreffen bei der sachlichen Beantwortung von Fragen häufig große Chunks (über 1.000 Token). Kleinere Abschnitte sind außerdem günstiger, da irrelevante Passagen innerhalb eines großen Abschnitts nicht abgerufen werden.

Optimierung der Abrufanzahl: Wenn Ihr Agent 10 Blöcke pro Abfrage abruft, aber konsistent nur Informationen aus den oberen 2–3 verwendet, reduzieren Sie die Abrufanzahl. Überwachen Sie, welche abgerufenen Blöcke tatsächlich in den Agentenausgaben referenziert werden.

Relevanzfilterung: Wenden Sie einen Schwellenwert für die Relevanzbewertung an – schließen Sie nur abgerufene Blöcke oberhalb des Schwellenwerts in den Kontext ein. Blöcke mit geringer Relevanz erhöhen die Kosten, ohne die Qualität zu verbessern.

Bereinigung des Gesprächsverlaufs: Bei Agenten mit mehreren Runden wächst der Gesprächsverlauf mit jeder Runde. Ältere Wendungen sind oft weniger relevant. Implementieren Sie eine Zusammenfassungsstrategie: Fassen Sie nach 8–10 Runden die erste Konversation in einer komprimierten Zusammenfassung (200–300 Token) zusammen, anstatt den vollständigen Rundenverlauf beizubehalten.

def manage_conversation_history(messages: list, max_tokens: int = 2000) -> list:
    """Prune conversation history to stay within token budget"""
    # Always keep system message and last N user/assistant turns
    if count_tokens(messages) <= max_tokens:
        return messages

    # Summarize early conversation if too long
    early_messages = messages[1:-6]  # Exclude system + recent 3 turns
    summary = summarize_conversation(early_messages)

    return [
        messages[0],  # System message
        {"role": "user", "content": f"[Earlier conversation summary: {summary}]"},
        *messages[-6:]  # Recent 3 turns
    ]

---

Semantisches Caching

Semantisches Caching ist die wirkungsvollste Kostenoptimierung für Agenten, die sich wiederholende Abfragen bearbeiten. Es speichert das Ergebnis von LLM-Aufrufen und gibt zwischengespeicherte Ergebnisse für nachfolgende Anfragen zurück, die semantisch ähnlich sind – auch wenn sie nicht identisch sind.

Wie semantisches Caching funktioniert

1. Wenn ein LLM-Aufruf erfolgt, berechnen Sie einen Einbettungsvektor für die Eingabe (Eingabeaufforderung + Kontext).
2. Durchsuchen Sie den Cache nach gespeicherten Ergebnissen mit hoher Vektorähnlichkeit zur aktuellen Eingabe
3. Wenn die Ähnlichkeit den Schwellenwert überschreitet, wird das zwischengespeicherte Ergebnis zurückgegeben (kein LLM-Aufruf).
4. Wenn nicht, führen Sie den LLM-Aufruf durch und speichern Sie das Ergebnis mit seiner Einbettung

Die entscheidende Erkenntnis: Viele Anfragen aus der realen Welt sind semantisch ähnlich, auch wenn sie textlich nicht identisch sind. „Welche Rückgabebedingungen gelten für Bestellungen, die in den letzten 30 Tagen aufgegeben wurden?“ und „Kann ich etwas zurückgeben, das ich vor 3 Wochen bestellt habe?“ sind unterschiedliche Wörter, aber die gleiche Frage – semantisches Caching kann das zweite aus dem Cache des ersten bedienen.

Cache-Trefferrate nach Agent-Typ

Für Kundensupportmitarbeiter mit einer Cache-Trefferquote von 65 % reduziert semantisches Caching das LLM-Anrufvolumen – und damit die LLM-Kosten – um 65 %.

Cache-Konfiguration

Ähnlichkeitsschwellenwert: Der Schwellenwert für die Deklaration zweier Anforderungen als „ähnlich genug“ für die Wiederverwendung des Caches. Höherer Schwellenwert = weniger Cache-Treffer, aber höhere Genauigkeit. Niedrigerer Schwellenwert = mehr Cache-Treffer, aber das Risiko, subtil falsche Antworten auf unterschiedliche Anfragen zurückzugeben.

Für sachliche Abfragen ist ein Ähnlichkeitsschwellenwert von 0,92–0,95 normalerweise sicher. Verwenden Sie für Analyse- oder Argumentationsaufgaben einen höheren Schwellenwert (0,97+), um zu vermeiden, dass bei geringfügig unterschiedlichen Fragen eine falsche Analyse zurückgegeben wird.

Cache-TTL: Verschiedene Cache-Eintragstypen sollten unterschiedliche Ablaufzeiträume haben:

• Produktpreise: 1–4 Stunden (Preise ändern sich)
• Richtlinieninformationen: 24–48 Stunden (Richtlinien ändern sich selten)
• Allgemeinwissen: 7 Tage (sehr stabile Informationen)
• Generierte Berichte: Zwischenspeichern, bis sich die zugrunde liegenden Daten ändern (ereignisgesteuerte Ungültigmachung)

Cache-Bereich: Konfigurieren Sie, ob der Cache pro Benutzer, pro Organisation oder global ist. Kundendienstmitarbeiter sollten über organisationsspezifische Caches verfügen (eine Antwort, die für Ihre Organisation geeignet ist, ist möglicherweise nicht für eine andere geeignet). Allgemeinwissensagenten können einen globalen Cache gemeinsam nutzen.

---

Modellrouting und abgestufte LLM-Auswahl

Nicht jede Aufgabe erfordert ein Grenzmodell. Die Verwendung von GPT-4o oder Claude 3.5 Sonnet für eine einfache Klassifizierungsaufgabe, die GPT-4o mini korrekt erledigt, zahlt sich 15- bis 50-mal mehr aus als nötig.

Routing-Strategie

Klassifizierung der Aufgabenkomplexität: Implementieren Sie einen einfachen Klassifikator, der jede eingehende Anfrage nach Komplexität kategorisiert:

• Einfach: Nachschlagen, Klassifizierung mit wenigen Kategorien, kurze Generierung mit klarer Vorlage
• Moderat: Mehrstufiges Denken, Extraktion aus komplexen Dokumenten, bedingte Logik
• Komplex: Offene Analyse, kreative Synthese, differenziertes Urteil

Modellzuordnung:

• Einfach → GPT-4o mini, Claude 3 Haiku (Kosten: ~0,15–0,30 $/M. Token)
• Mäßig → Claude 3.5 Sonnet, GPT-4o (Kosten: ~3–5 $/M. Token)
• Komplex → Claude 3.5 Sonnet, GPT-4o (oder o1 für tiefgründige Argumentationsaufgaben) (Kosten: 5-15 $/Mio. Token)

Fallback-Routing: Wenn das billigere Modell eine Ausgabe erzeugt, die unter dem Qualitätsschwellenwert liegt (durch automatische Auswertung erkannt), versuchen Sie es erneut mit dem teureren Modell. Dieser „Kaskaden“-Ansatz nutzt günstige Modelle optimistisch und eskaliert nur bei Bedarf.

def route_to_model(task: AgentTask) -> str:
    complexity = classify_task_complexity(task)

    model_map = {
        "simple": "claude-haiku-3",
        "moderate": "claude-3-5-sonnet",
        "complex": "claude-3-5-sonnet"
    }
    return model_map[complexity]

def execute_with_fallback(task: AgentTask):
    primary_model = route_to_model(task)
    result = execute_with_model(task, primary_model)

    if not meets_quality_threshold(result):
        # Escalate to more capable model
        result = execute_with_model(task, "claude-3-5-sonnet")

    return result

Realistische Einsparungen durch Modellrouting: In einer Agentenflotte mit gemischter Arbeitslast gelten 60–70 % der Aufgaben typischerweise als „einfach“. Durch die Weiterleitung dieser Maßnahmen an Billigmodelle wird in diesem Segment eine Kostenreduzierung von 50–70 % erreicht, was einer Gesamtkostenreduzierung von 30–50 % entspricht.

---

Prompt Caching (Anbieterebene)

Anthropic und OpenAI bieten Prompt-Caching-Funktionen, die die Kosten für wiederholte Systemaufforderungen reduzieren. Wenn die Systemaufforderung (oder ein beliebiges Präfix der Eingabeaufforderung) bei mehreren Anforderungen identisch ist, kosten zwischengespeicherte Token deutlich weniger als neue Token.

Anthropic-Cache-Preise: Zwischengespeicherte Eingabe-Tokens kosten etwa 10 % des Standard-Eingabe-Token-Preises (0,30 USD/Mio. gegenüber 3 USD/Mio. für Sonnet). Die Cache-Schreibkosten betragen 3,75 $/M (einmal geschrieben, dann gelesen für 0,30 $/M).

Effektive Strategie: Strukturieren Sie Eingabeaufforderungen so, dass der stabile Teil (Systemeingabeaufforderung, Beispiele, Anweisungen) an erster Stelle und der variable Teil (Benutzereingabe, abgerufener Kontext) an letzter Stelle steht. Der Anbieter speichert das stabile Präfix automatisch zwischen.

Break-Even-Berechnung: Cache-Schreibkosten betragen das 1,25-fache des Standard-Eingabe-Token-Preises; Cache-Lesen kostet 0,1x. Die Gewinnschwelle liegt bei zwei Anfragen, die das Präfix teilen. Jede Anfrage über die Sekunde hinaus ist für den zwischengespeicherten Teil 90 % günstiger.

Für einen Agenten mit einer Systemaufforderung mit 1.000 Token, der 1.000 Anfragen pro Tag ausführt:

• Ohne Caching: 1.000 × 1.000 Token × 3 $/M = 3 $/Tag Eingabekosten allein für die Systemaufforderung – Mit Caching: 3,75 $ (ein Schreibvorgang) + 999 × 1.000 × 0,30 $/M = 0,30 $/Tag
• Tägliche Ersparnis: 2,70 $ (90 % Ermäßigung auf diese Komponente)

---

Stapelverarbeitung

Für nicht zeitkritische Arbeitslasten (Berichterstellung über Nacht, Stapelverarbeitung von Dokumenten, geplante Datenanalyse) bieten Batch-API-Aufrufe erhebliche Kostensenkungen.

OpenAI Batch API: 50 % Kostenreduzierung für Anfragen, die als Batches mit 24-Stunden-Abschlussfenstern eingereicht werden. Für die Berichterstellung über Nacht halbiert dies allein die LLM-API-Kosten.

Anthropic Message Batches: Ähnliche Batch-Preise für nicht zeitkritische Arbeitslasten.

Batch-Planungsmuster:

• Sammeln Sie Anfragen zur Berichterstellung im Laufe des Tages und übermitteln Sie sie am Ende des Geschäfts als Stapel
• Verarbeiten Sie die Dokumentenaufnahme für RAG außerhalb der Hauptverkehrszeiten als Batch-Jobs
• Führen Sie jeden Abend stapelweise Compliance-Überwachungsscans durch

---

Kostenüberwachung und -zuordnung

Für die Optimierung ist es erforderlich zu wissen, woher die Kosten kommen. Kostenüberwachung ab dem ersten Produktionstag umsetzen:

Kostenverfolgung pro Workflow: Kennzeichnen Sie jeden LLM-Anruf mit dem Workflow, zu dem er gehört. Berechnen Sie die Gesamtkosten pro Arbeitsablauf und Tag. Dies zeigt, welche Verhaltensweisen der Agenten am teuersten sind, und priorisiert Optimierungsbemühungen.

Zuordnung pro Token: Teilen Sie die Kosten nach Eingabe- vs. Ausgabetokens, nach Eingabeaufforderungskomponente (Systemeingabeaufforderung vs. Kontext vs. Benutzereingabe) und nach Modell auf. Eine Kostenzuordnung auf dieser Granularität ermöglicht eine gezielte Optimierung.

Erkennung von Kostenanomalien: Warnung, wenn die täglichen Kosten um mehr als 20 % über den gleitenden 7-Tage-Durchschnitt steigen. Spitzen weisen entweder auf legitime Volumenzuwächse (erwartet) oder auf Fehler hin (Endlosschleifen, außer Kontrolle geratene Kontextfenster, prompte Injektion, die ungewöhnlich lange Abschlüsse verursacht).

Kosten pro erfolgreicher Aufgabe: Teilen Sie die Gesamtkosten durch die erfolgreichen Aufgabenabschlüsse, um die Kosten pro Werteinheit zu erhalten. Dies ist die Kennzahl, die für den ROI von Bedeutung ist: Wenn die Kosten pro Aufgabe sinken, während das Aufgabenvolumen und die Qualität gleich bleiben, funktioniert die Optimierung.

---

Häufig gestellte Fragen

Um wie viel kann die Kostenoptimierung die LLM-API-Kosten realistisch senken?

Bei typischen OpenClaw-Bereitstellungen führt ein systematischer Optimierungsaufwand, der sich mit prompter Komprimierung, semantischem Caching und Modellrouting befasst, zu einer Kostenreduzierung von 45–65 % im Vergleich zu nicht optimierten Bereitstellungen. Die spezifischen Einsparungen hängen stark von den Arbeitslastmerkmalen ab – Agenten mit sich stark wiederholenden Abfragen profitieren am meisten vom Caching; Agenten mit vielfältigen, einzigartigen Abfragen profitieren stärker vom Modellrouting.

Beeinträchtigt semantisches Caching die Antwortgenauigkeit?

Bei richtiger Schwellenwertkonfiguration ist die Auswirkung auf die Genauigkeit vernachlässigbar – typischerweise weniger als 0,5 % Verschlechterung bei Sachaufgaben. Der Schlüssel liegt darin, den Ähnlichkeitsschwellenwert entsprechend dem Aufgabentyp festzulegen. Für Aufgaben, bei denen geringfügige Unterschiede in der Frage zu unterschiedlichen richtigen Antworten führen, verwenden Sie höhere Ähnlichkeitsschwellenwerte (0,96+), um sicherzustellen, dass nur wirklich gleichwertige Abfragen aus dem Cache bedient werden.

Welche Auswirkungen hat das semantische Caching auf die Latenz?

Cache-Suchen (Vektorähnlichkeitssuche) verursachen eine Latenz von 5–15 ms. Cache-Treffer eliminieren die LLM-Aufruflatenz (normalerweise 500 ms bis 3 s). Nettoergebnis: Zwischengespeicherte Antworten sind 20–200-mal schneller als nicht zwischengespeicherte Antworten. Dies ist eine Verbesserung der Latenz, keine Verschlechterung.

Wie implementieren wir eine Kostenüberwachung ohne großen technischen Aufwand?

Die Observability-Schicht von OpenClaw erfasst automatisch die Anzahl der Token und die Modellauswahl für jede Ausführung. ECOSIRE konfiguriert während der Implementierung ein Kosten-Dashboard, das die Kosten nach Workflow, Modell und Zeitraum anzeigt. Es ist kein kundenspezifisches Engineering erforderlich – die Überwachungsinfrastruktur ist Teil der Standardimplementierung.

Ab welchem Ausmaß lohnen sich Kostenoptimierungsmaßnahmen?

Die meisten Optimierungsmaßnahmen lohnen sich bei LLM-API-Kosten von mehr als 500 US-Dollar pro Monat. Unterhalb dieses Schwellenwerts übersteigt der technische Aufwand typischerweise die Einsparungen. Über 2.000 US-Dollar pro Monat wird eine systematische Optimierung dringend empfohlen – der ROI der in die Optimierung investierten Entwicklungszeit ist in dieser Größenordnung sehr hoch.

Beeinträchtigt der Wechsel zu günstigeren Modellen die Qualität der Agentenergebnisse?

Bei Aufgaben, bei denen günstigere Modelle wirklich die gleiche Qualität bieten, ist der Umstieg auf diese eine reine Ersparnis. Bei Aufgaben, die tiefes Denken, differenziertes Urteilsvermögen oder komplexe Synthesen erfordern, liefern billigere Modelle deutlich schlechtere Ergebnisse. Das Modell-Routing-Muster behebt dieses Problem, indem billigere Modelle nur dort eingesetzt werden, wo sie angemessen sind, und bei Aufgaben, die sie erfordern, auf Premium-Modelle umgeleitet wird. Der Schlüssel liegt in der empirischen Validierung – testen Sie das günstigere Modell für Ihre spezifische Aufgabe, bevor Sie den Produktionsverkehr dorthin leiten.

---

Nächste Schritte

Die Kostenoptimierung für KI-Agenten ist eine fortlaufende Disziplin und kein einmaliges Projekt. Die OpenClaw-Implementierungen von ECOSIRE umfassen vom ersten Tag an eine Kostenoptimierungsebene – semantisches Caching, Modellrouting und Prompt-Optimierung sind in die Bereitstellungsarchitektur integriert und werden nicht nachträglich hinzugefügt.

[Entdecken Sie die ECOSIRE OpenClaw Services] (/services/openclaw), um Ihre Kostenoptimierungsanforderungen zu besprechen, oder sehen Sie sich unsere Optionen für Wartungs- und Optimierungsverträge an, um zu verstehen, wie ECOSIRE die laufende Kosteneffizienz für OpenClaw-Produktionsbereitstellungen verwaltet.