LLM-Prompt-Caching #4: Das beste Modell für Chat, RAG & Agenten

TL;DR — Die Wahl des „besten” LLM ist keine einzelne Benchmark-Frage — sie hängt davon ab, ob Sie einen Chatbot, eine RAG-/Batch-API oder einen KI-Agenten ausliefern. Jede Form hat eine andere Prompt-Struktur, ein anderes Trefferraten-Profil, eine andere TTL-Eignung und eine andere Latenztoleranz, was jeweils eine andere optimale Kombination aus Modell + Caching-Strategie vorgibt. Dieser Leitfaden baut auf den gemessenen Zahlen aus Teil 3 auf — gleiches Gateway, gleiches OpenAI-SDK, pro Aufruf wird nur das Feld model getauscht.

Serie: Teil 4 von 4 · Zuvor: Teil 1 — Caching-Grundlagen · Teil 2 — Anbietervergleich & Bewertung · Teil 3 — Praxistutorial mit Code

0. Die universelle Kostenformel

Bevor wir uns den Anwendungsfällen widmen, hier die Gleichung, die jede Entscheidung optimieren sollte:

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

Vier Hebel:

1. Den Stückpreis senken (P_in / P_out) → ein günstigeres Modell wählen.
2. Die Trefferrate erhöhen → Ihren Prompt umstrukturieren; die TTL an die Kadenz Ihres Traffics anpassen.
3. Den Cache-Rabattkoeffizienten senken → einen Anbieter mit stärkerem Caching wählen.
4. Einen Anbieter wählen, dessen gecachtes Prefill am schnellsten ist → Latenz ist für die UX entscheidend.

Jeder Anwendungsfall unten betätigt diese Hebel unterschiedlich.

Anwendungsfall 1: Chatbots, Kundensupport und Assistenten

Traffic-Profil

• Jede Anfrage = langer System-Prompt (Persona + Wissen + Regeln) + mehrstufiger Verlauf + neue Benutzernachricht.
• Durchschnittlicher Kontext: 4K–20K Tokens.
• Nutzer sind extrem empfindlich gegenüber der Zeit bis zum ersten Token (>2 s fühlt sich defekt an).
• Innerhalb einer Sitzung kommen Anfragen im Abstand von Sekunden bis Minuten — gut innerhalb der Cache-TTL jedes Anbieters.

Warum Chat sich fast von selbst cacht

Chat ist die cache-freundlichste Workload. Innerhalb einer einzelnen Sitzung:

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

Wenn die Abstände zwischen den Nachrichten unter der TTL bleiben (bei jedem Anbieter einige Minuten), erreicht der System-Prompt-Anteil mühelos eine Trefferrate von über 90 %. Sie brauchen keine Keep-Alives.

Modellempfehlungen (gemessen 2026-05)

* Gemessen gegen einen stabilen System-Prompt von 7.300 Tokens, einzelner sequenzieller Durchlauf, ohne gleichzeitige Last. Die vollständige Tabelle siehe Teil 3 §6.

Minimaler Produktionscode

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

Das war’s. Caching ist für alle oben aufgeführten Modelle automatisch; kein Marker ist erforderlich. Lesen Sie resp.usage.prompt_tokens_details.cached_tokens, um Treffer während der Entwicklung zu bestätigen.

Chatbot-Fallstricke

• ❌ Backen Sie nicht den aktuellen Zeitstempel in den System-Prompt ein ("Today is 2026-05-25 14:30:25"). Sekundengenauigkeit invalidiert jeden Cache.
• ❌ Setzen Sie den Verlauf nicht in jeder Runde neu zusammen — halten Sie die Reihenfolge des Message-Arrays byte-identisch und append-only.
• ✅ Platzieren Sie Benutzer-Persona-Daten in der ersten Benutzernachricht, nicht im System-Prompt — die nutzerspezifische Variation vergiftet dann nicht das gemeinsame Präfix.
• ✅ Senden Sie bei Sitzungen, die jenseits der TTL kalt geworden sind, einen 1-Token-Keep-Alive-Ping (siehe Teil 3 §8.2), bevor die nächste Nachricht des Nutzers eintrifft.

Anwendungsfall 2: API-Workloads (RAG, Content-Generierung, Batch-Verarbeitung)

Traffic-Profil

• RAG-Q&A: Eingabe = stabiles System + variable abgerufene Dokumente + variable Anfrage.
• Content-Generierung (Marketing-Texte, Code, Übersetzung): stabile Vorlage, variierende Daten.
• Batch-Verarbeitung (Dokumentklassifizierung, Datenbereinigung): gleiche Aufgabe in hohem Volumen.
• Latenz ist zweitrangig; die Kosten pro Aufruf dominieren.

Das harte Problem: Retrieval ordnet Ihr Präfix um

Das zentrale Caching-Problem von RAG: Abgerufene Dokumente ändern sich zwischen Aufrufen und brechen das Präfix mitten im Prompt.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

Drei Korrekturen, in steigender Komplexität:

Korrektur A — Schieben Sie abgerufene Dokumente nach hinten, nicht nach vorne.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

Ergebnis: Der gesamte system-Anteil (die stabilen ~3,5K Tokens) wird gecacht. Nur der nutzerseitige Anteil verfehlt bei jedem Aufruf. Das reicht für die meisten Produktions-RAGs. Gemessene Trefferrate bei diesem Muster mit gpt-5.4-mini: über 80 % auf den System-Tokens.

Korrektur B — Deterministische Retrieval-Reihenfolge. Sortieren Sie abgerufene Chunks nach einem stabilen Schlüssel (doc_id aufsteigend) statt nach dem Relevanz-Score. Häufig vorkommende Chunks bleiben an konsistenten Positionen, und das Präfix stimmt öfter überein. Das kostet einen kleinen Genauigkeitsverlust beim Ranker; meist irrelevant.

Korrektur C — Native explizite Cache-Marker über direkte Anbieter-SDKs. Wenn Sie direkt auf Anthropic Claude sind (nicht über dieses Gateway), erlaubt das Multi-cache_control-Muster, „ändert sich nie” + „ändert sich selten” + „ändert sich pro Aufgabe” als getrennte Breakpoints zu cachen. Hervorragend für komplexe RAGs, wenn Sie ein zusätzliches SDK mitführen können.

TTL-Überlegungen für API-Workloads

• Kontinuierlicher Traffic (24/7-RAG-Endpunkt): 5-Minuten-TTLs funktionieren einwandfrei — es gibt immer eine nächste Anfrage innerhalb des Fensters.
• Stoßweise / Cron (täglicher 09:00-Batch): Verwenden Sie einen Anbieter mit langer TTL (deepseek-v4-flash ist der langlebigste in unserem Testset) oder führen Sie während des Ausführungsfensters alle TTL/2 einen 1-Token-Keep-Alive aus. Muster in Teil 3 §8.2.

Modellempfehlungen nach Aufgabe

† Claudes Multi-cache_control-Marker sind für geschichtetes RAG unübertroffen — verwenden Sie das auf das Gateway gerichtete anthropic-SDK, siehe Teil 3 §2.

RAG-Kostenskizze (100K Anfragen/Tag)

3K System + 5K abgerufene Dokumente + 200-Token-Anfrage + 300-Token-Ausgabe. Die Zahlen sind aus den gemessenen Einzelaufrufkosten in Teil 3 §6 hochgerechnet — Single-Tenant, ohne gleichzeitige Last.

Als Größenordnung verstehen. Echte Produktion hat gleichzeitige Aufrufe, Lastspitzen, und die Längenverteilung Ihrer abgerufenen Dokumente wird die Rechnung dominieren.

RAG-/API-Fallstricke

• ❌ Sortieren Sie abgerufene Chunks nicht nach dynamischem Relevanz-Score — jede Anfrage erhält ein einzigartiges Präfix.
• ❌ Verlieren Sie beim Streaming keine Usage-Logs — Ihre Kostenzuordnung bricht zusammen. Übergeben Sie stream_options={"include_usage": True} und speichern Sie prompt_tokens_details.cached_tokens und usage.cost.
• ✅ Stapeln Sie bei Batch-Aufgaben die Batch-APIs der Anbieter (OpenAI Batch, Anthropic Message Batches) auf das Caching obendrauf für weitere ~50 % Rabatt — außerhalb dieses Gateways durch direkten Aufruf des Anbieters.

Anwendungsfall 3: KI-Agenten (mehrstufiges Reasoning, Tool-Nutzung, lange Ketten)

Traffic-Profil

• Eine Agentenaufgabe = viele LLM-Aufrufe, verschachtelt mit Tool-Ergebnissen.
• Sehr langer Kontext (System + Tools + akkumulierter Verlauf): typischerweise 30K–100K Tokens bis Schritt 10.
• Hochstrukturierte Prompts: langes stabiles Präfix, kleiner variabler Schwanz.
• Sowohl Latenz als auch Kosten zählen — jede zusätzliche Prefill-Sekunde fügt sichtbare Wartezeit hinzu, und ein 15-Schritt-Agent multipliziert das mit 15.

Warum Agenten von Caching abhängen

Jeder Schritt hängt sich an den Tool-Aufruf und das Ergebnis des vorherigen Schritts an. Ohne Caching zahlt jeder Schritt das Prefill auf zehntausenden Tokens erneut.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

Kritische Regel: Tool-Aufrufe und -Ergebnisse müssen über die Schritte hinweg append-only und byte-identisch sein. Jedes Umschreiben oder Umsortieren tötet den Cache ab diesem Punkt. Der mit Abstand häufigste Agenten-Bug ist „Ich habe das Tool-Ergebnis bereinigt, bevor ich es erneut gesendet habe” → Cache-Rate fällt auf null → Kosten und Latenz vervielfachen sich.

TTL-Abgleich — der eine Anwendungsfall, bei dem es zählt

Eine typische Agentenaufgabe läuft 10–60 Sekunden; innerhalb einer einzelnen Aufgabe sind die Standard-5-Minuten-TTLs in Ordnung. Aber Agenten, die auf eine menschliche Freigabe warten („überprüfe diesen Plan und antworte”), können minutenlang inaktiv bleiben. Wenn der Mensch 10 Minuten pausiert und der Cache kalt geworden ist, zahlt Ihr Folgeschritt das Prefill auf 50K Tokens erneut. Für solche Workflows entweder:

• Verwenden Sie einen Anbieter mit längerer TTL (deepseek-v4-flash ist der langlebigste in unserem Testset), oder
• Senden Sie während des Wartens alle TTL/2 einen Keep-Alive-Ping (siehe Teil 3 §8.2).

Modellempfehlungen für Agenten

Agenten verlangen Reasoning-Fähigkeit — wählen Sie zuerst nach Qualität, optimieren Sie dann die Kosten.

† Claudes 4-cache_control-Marker-Muster bleibt die stärkste Konfiguration für Agenten-Caching (kumulativer Präfix-Rabatt über mehr als 10 Schritte). Verwenden Sie das auf das Gateway gerichtete anthropic-SDK — siehe Teil 3 §2 für die genaue Payload-Form und die TTL-Optionen.

Reale Kostenschätzung: eine Agentenaufgabe mit 15 Schritten

Annahme: 5K System + 3K Tools + ~3K pro Schritt angehängt, insgesamt 15 Schritte. Kosten pro Aufruf aus Teil 3 §6, skaliert auf die Agentenform:

Auch hier nur Richtwerte. Die dominante Variable ist, ob Sie das Präfix tatsächlich von Schritt zu Schritt byte-identisch halten.

Agenten-Fallstricke

• ❌ Bauen Sie die Message-Liste nicht in jedem Schritt neu auf — halten Sie das Array byte-identisch, nur anhängen.
• ❌ Kürzen oder reformatieren Sie Tool-Ergebnisse nicht — jede Byte-Änderung invalidiert den nachgelagerten Cache.
• ❌ Teilen Sie keinen Cache-Schlüssel über gleichzeitige Agenteninstanzen hinweg — ihre Schrittabfolgen divergieren und kontaminieren sich gegenseitig.
• ✅ Überwachen Sie cache_creation_tokens : cache_read_tokens pro Aufgabe — ein gesundes Verhältnis ist 1:50 oder besser bis Schritt 10.

Die Master-Entscheidungsmatrix

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

TTL-Kurzreferenz nach Anwendungsfall

Was dieses Gateway tut und nicht tut

Um die Erwartungen ehrlich zu setzen:

Wenn Sie heute eines der Elemente auf der rechten Seite benötigen, tun Sie es in Ihrer Anwendungsschicht oder direkt gegen das Anbieter-SDK. Das Gateway ist ein dünner Proxy plus eine Preisschicht; alles rund ums Caching geschieht upstream auf der Modellebene.

Abschließende Erkenntnis

Die vierteilige Serie lässt sich auf vier Zeilen verdichten:

Caching bringt zwei Vorteile, nicht einen. Kosten UND Latenz. Stabiler Inhalt zuerst, flüchtiger Inhalt zuletzt. Präfix-Disziplin ist kostenlos, machen Sie es überall. Stimmen Sie Modell + Cache-Verhalten auf den Anwendungsfall ab. Chat ≠ RAG ≠ Agenten. Messen Sie an Ihrem eigenen Traffic. Einzeldurchlauf-Benchmarks sind ein Ausgangspunkt, nicht die Antwort.

Der schnellste Weg von hier: Wählen Sie aus der obigen Matrix den Anwendungsfall, der Ihrem am nächsten kommt, wenden Sie die strukturellen Änderungen an (stabiles Präfix zuerst, deterministisches Retrieval, byte-identischer Agentenzustand), loggen Sie cached_tokens und usage.cost eine Woche lang und bewerten Sie dann neu.

FAQ

Welches LLM ist am günstigsten für einen chinesischsprachigen Chatbot? deepseek-v4-flash und qwen3.5-flash sind bei chinesischem Text in unserem Testset eine Größenordnung günstiger als auf Englisch abgestimmte Modelle und erreichen dabei bei typischen Chat-Workloads die Qualität von gpt-5.4-mini.

Was ist das beste LLM für RAG im Jahr 2026? Für Englisch: gpt-5.4-mini mit dem Prompt-Layout aus Korrektur A (System-Tokens vorne, Referenzen unten) liefert über 80 % Trefferrate auf dem stabilen Anteil. Für Chinesisch: deepseek-v4-flash. Für sehr lange, häufig abgefragte Dokumente: gemini-2.5-pro (verarbeitet nativ Kontexte von über 1 Mio. Tokens).

Sollte ich GPT oder Claude für Agenten verwenden? Beide sind stark; die Wahl hängt davon ab, wie viel Cache-Disziplin Sie investieren möchten. Claudes 4-cache_control-Marker-Muster (über das gegen das Gateway gerichtete anthropic-SDK) ist einzigartig leistungsfähig für kumulative Agenten-Präfixe — ~90 % Reduktion der Eingabekosten, sobald das Präfix warm ist, über mehr als 10 Schritte. Wenn Sie lieber beim OpenAI-förmigen Client bleiben und ~50 % Cache-Einsparungen ohne jegliche Marker akzeptieren, sind gpt-5.4-mini oder gpt-5.5-pro die reibungsärmere Wahl.

Wie viel kann ich realistisch sparen, wenn ich von „naiver” zu „optimierter” LLM-Nutzung wechsle? Bei den gemessenen Durchläufen in dieser Serie: 50–88 % Kostenreduktion und 30–60 % TTFT-Reduktion beim selben Modell. Der Großteil des Gewinns kommt daher, Ihre Trefferrate über 80 % zu bringen, nicht von der Wahl eines anderen Modells.

Wo fange ich an? Wählen Sie aus der Matrix den Anwendungsfall, der Ihrem am nächsten kommt. Wenden Sie die strukturellen Prompt-Änderungen an. Messen Sie cached_tokens und usage.cost über eine Woche Produktions-Traffic. Erst danach ziehen Sie einen Modellwechsel in Betracht.

Quellen & Verifikation: Gemessene Zahlen aus Teil 3 §6, https://synthorai.io/v1 am 2026-05-25, openai-SDK 2.38.0. Preisseiten der Anbieter: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Zurück zum Blog