Bestes LLM nach Anwendungsfall (2026): Kostenmatrix für Chat, RAG und Agents

TL;DR — Welches LLM das „beste“ ist, lässt sich nicht mit einem einzelnen Benchmark beantworten. Entscheidend ist, ob du einen Chatbot, eine RAG-/Batch-API oder einen AI Agent baust. Diese Workloads unterscheiden sich bei Prompt-Struktur, Hit Rate, passender TTL und Latenztoleranz. Deshalb braucht jeder Anwendungsfall eine andere Kombination aus Modell und Caching-Strategie. Dieser Leitfaden baut auf den Messwerten aus Teil 3 auf: gleiches Gateway, gleiches OpenAI SDK, pro Aufruf wird nur das Feld model ausgetauscht.

Serie: Teil 4 von 5 · Bisher: Teil 1 — Grundlagen des Cachings · Teil 2 — Provider-Vergleich und Bewertung · Teil 3 — Tutorial mit lauffähigem Code · Als Nächstes: Teil 5 — LangChain-Integration

0. Die allgemeine Kostenformel

Jede Entscheidung sollte dieselbe Gleichung optimieren:

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

Es gibt vier Stellschrauben:

1. Stückpreis senken (P_in / P_out) → ein günstigeres Modell wählen.
2. Hit Rate erhöhen → Prompt umstrukturieren und die TTL an die Taktung des Traffics anpassen.
3. Cache-Discount-Koeffizienten senken → einen Provider mit besserem Caching wählen.
4. Provider mit schnellem gecachtem Prefill wählen → Latenz ist für die UX entscheidend.

Die folgenden Anwendungsfälle gewichten diese Stellschrauben unterschiedlich.

Anwendungsfall 1: Chatbots, Kundensupport und Assistenten

Traffic-Profil

• Jeder Request besteht aus einem langen System-Prompt (Persona + Wissen + Regeln), dem bisherigen Dialog und der neuen Nutzernachricht.
• Durchschnittlicher Kontext: 4K–20K tokens.
• Nutzer reagieren sehr empfindlich auf die Time-to-First-Token (>2 s wirkt defekt).
• Innerhalb einer Session liegen zwischen Requests nur Sekunden oder Minuten. Damit bleiben sie innerhalb der Cache-TTL jedes Providers.

Warum Chat fast von selbst gecacht wird

Chat gehört zu den Workloads, die sich am besten cachen lassen. Innerhalb einer einzelnen Session sieht das so aus:

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 ────────↑

Solange zwischen Nachrichten weniger Zeit als die TTL liegt – bei allen Providern einige Minuten –, erreicht der System-Prompt ohne zusätzlichen Aufwand eine Hit Rate von über 90 %. Keep-alives sind nicht nötig.

Modellempfehlungen (gemessen 2026-05)

* Gemessen mit einem stabilen System-Prompt aus 7,300 tokens, einem einzelnen sequenziellen Lauf und ohne parallele Last. Die vollständige Tabelle steht in 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
        ],
    )

Mehr ist nicht nötig. Bei allen oben genannten Modellen läuft das Caching automatisch; ein Marker ist nicht erforderlich. Prüfe während der Entwicklung über resp.usage.prompt_tokens_details.cached_tokens, ob Cache Hits auftreten.

Typische Fehler bei Chatbots

• ❌ Baue keinen aktuellen Zeitstempel in den System-Prompt ein ("Today is 2026-05-25 14:30:25"). Sekundengenaue Werte machen jeden Cache ungültig.
• ❌ Setze den bisherigen Dialog nicht bei jedem Turn neu zusammen. Die Reihenfolge im Message-Array muss byte-identisch und append-only bleiben.
• ✅ Lege nutzerspezifische Persona-Daten in der ersten User-Nachricht ab, nicht im System-Prompt. So zerstören Unterschiede zwischen Nutzern nicht den gemeinsam genutzten Prefix.
• ✅ Wenn eine Session länger als die TTL inaktiv war, sende einen Keep-alive-Ping mit 1 token (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-Fragen und -Antworten: Input = stabiles System + variable abgerufene Dokumente + variable Anfrage.
• Content-Generierung (Marketingtexte, Code, Übersetzung): stabiles Template, wechselnde Daten.
• Batch-Verarbeitung (Dokumentenklassifizierung, Datenbereinigung): dieselbe Aufgabe mit hohem Volumen.
• Latenz ist zweitrangig; entscheidend sind die Kosten pro Aufruf.

Das Kernproblem: Retrieval ordnet den Prefix neu

Das zentrale Caching-Problem bei RAG: Die abgerufenen Dokumente ändern sich zwischen den Aufrufen und unterbrechen den gemeinsamen Prefix 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 Lösungen, nach steigender Komplexität:

Lösung A — Abgerufene Dokumente ans Ende setzen, nicht an den Anfang.

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-Abschnitt – die stabilen ~3.5K tokens – wird gecacht. Nur der nutzerspezifische Abschnitt ist bei jedem Aufruf ein Miss. Für die meisten produktiven RAG-Systeme reicht das aus. Mit diesem Muster haben wir bei gpt-5.4-mini für die System-tokens eine Hit Rate von über 80 % gemessen.

Lösung B — Deterministische Reihenfolge beim Retrieval. Sortiere abgerufene Chunks nach einem stabilen Schlüssel (doc_id aufsteigend) statt nach Relevanz-Score. Häufig verwendete Chunks bleiben dadurch an derselben Position und der Prefix stimmt öfter überein. Die Ranking-Genauigkeit sinkt geringfügig, was in der Praxis meist keine Rolle spielt.

Lösung C — Native Marker für explizites Caching über die SDKs der Provider. Wenn du Anthropic Claude direkt nutzt und nicht über dieses Gateway, kannst du mit mehreren cache_control-Markern separate Breakpoints für „ändert sich nie“, „ändert sich selten“ und „ändert sich pro Aufgabe“ definieren. Für komplexe RAG-Systeme ist das sehr wirkungsvoll, sofern ein zusätzliches SDK vertretbar ist.

TTL für API-Workloads

• Kontinuierlicher Traffic (RAG-Endpunkt rund um die Uhr): Eine TTL von 5 min reicht aus, weil der nächste Request immer innerhalb des Fensters eintrifft.
• Bursts / Cronjobs (täglicher Batch um 09:00): Nutze einen Provider mit langer TTL (deepseek-v4-flash hielt in unseren Tests am längsten) oder sende während des Ausführungsfensters alle TTL/2 einen Keep-alive mit 1 token. Das Muster steht in Teil 3 §8.2.

Modellempfehlungen nach Aufgabe

† Claudes mehrere cache_control-Marker sind für mehrschichtiges RAG unübertroffen. Nutze das anthropic SDK mit dem Gateway als Ziel; siehe Teil 3 §2.

RAG-Kostenschätzung (100K Abfragen/Tag)

3K System + 5K abgerufene Dokumente + Anfrage mit 200 tokens + Ausgabe mit 300 tokens. Die Werte wurden aus den gemessenen Kosten einzelner Aufrufe in Teil 3 §6 auf dieses Szenario hochgerechnet: ein einzelner Tenant, keine parallele Last. Für deinen eigenen Workload kannst du die Rechnung mit dem LLM-Kostenrechner abschätzen und die aktuellen Tarife im Live-Preisvergleich für Modelle prüfen.

Das sind Größenordnungen. In der Produktion gibt es parallele Aufrufe und Lastspitzen; vor allem die Längenverteilung deiner abgerufenen Dokumente bestimmt die Kosten.

Typische Fehler bei RAG und APIs

• ❌ Sortiere abgerufene Chunks nicht nach einem dynamischen Relevanz-Score. Dadurch erhält jeder Request einen anderen Prefix.
• ❌ Verzichte beim Streaming nicht auf Usage-Logs. Sonst ist keine saubere Kostenzuordnung mehr möglich. Übergib stream_options={"include_usage": True} und speichere prompt_tokens_details.cached_tokens sowie usage.cost.
• ✅ Kombiniere bei Batch-Aufgaben das Caching mit den Batch APIs der Provider (OpenAI Batch, Anthropic Message Batches), um weitere ~50 % zu sparen. Das erfolgt außerhalb dieses Gateways über einen direkten Aufruf beim Provider.

Anwendungsfall 3: AI Agents (mehrstufiges Reasoning, Tool-Nutzung, lange Abläufe)

Traffic-Profil

• Eine Agent-Aufgabe besteht aus vielen LLM-Aufrufen, unterbrochen von Tool-Ergebnissen.
• Sehr langer Kontext (System + Tools + angesammelter Verlauf): bei Schritt 10 typischerweise 30K–100K tokens.
• Stark strukturierte Prompts: langer stabiler Prefix, kleiner variabler Teil am Ende.
• Latenz und Kosten sind gleichermaßen relevant. Jede zusätzliche Sekunde Prefill erzeugt sichtbare Wartezeit, und ein Agent mit 15 Schritten multipliziert sie mit 15.

Warum Agents auf Caching angewiesen sind

Jeder Schritt hängt den vorherigen Tool-Aufruf und dessen Ergebnis an. Ohne Caching wird das Prefill bei jedem Schritt erneut für Zehntausende tokens berechnet und abgerechnet.

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 ────↑

Entscheidende Regel: Tool-Aufrufe und Ergebnisse müssen über alle Schritte hinweg append-only und byte-identisch bleiben. Jede Änderung oder neue Sortierung macht den Cache ab dieser Stelle unbrauchbar. Der häufigste Fehler bei Agents lautet: „Ich habe das Tool-Ergebnis vor dem erneuten Senden bereinigt.“ Dadurch fällt die Cache Rate auf null, und Kosten sowie Latenz vervielfachen sich.

Passende TTL – nur hier wirklich kritisch

Eine typische Agent-Aufgabe läuft 10–60 Sekunden. Innerhalb einer einzelnen Aufgabe reicht die übliche TTL von 5 min aus. Agents, die auf menschliche Freigaben warten („Prüfe diesen Plan und antworte“), können jedoch mehrere Minuten stillstehen. Wenn die Person 10 Minuten braucht und der Cache inzwischen kalt ist, wird beim nächsten Schritt das Prefill für 50K tokens erneut berechnet und abgerechnet. Für solche Workflows gibt es zwei Optionen:

• Einen Provider mit längerer TTL verwenden (deepseek-v4-flash hielt in unseren Tests am längsten), oder
• während der Wartezeit alle TTL/2 einen Keep-alive-Ping senden (siehe Teil 3 §8.2).

Modellempfehlungen für Agents

Agents brauchen gute Reasoning-Fähigkeiten. Wähle zuerst nach Qualität und optimiere danach die Kosten.

† Claudes Muster mit 4 cache_control-Markern bleibt die beste Konfiguration für Agent-Caching, weil der kumulative Prefix über mehr als 10 Schritte rabattiert wird. Nutze das anthropic SDK mit dem Gateway als Ziel. Das genaue Payload-Format und die TTL-Optionen findest du in Teil 3 §2.

Realistische Kostenschätzung: Agent-Aufgabe mit 15 Schritten

Annahme: 5K System + 3K Tools + pro Schritt etwa 3K zusätzlich angehängte tokens, insgesamt 15 Schritte. Die Kosten pro Aufruf aus Teil 3 §6 wurden auf diesen Agent-Workload hochgerechnet:

Auch hier handelt es sich um eine grobe Schätzung. Entscheidend ist, ob der Prefix von Schritt zu Schritt tatsächlich byte-identisch bleibt.

Typische Fehler bei Agents

• ❌ Baue die Messages-Liste nicht bei jedem Schritt neu auf. Das Array muss byte-identisch bleiben; neue Einträge werden nur angehängt.
• ❌ Kürze oder formatiere Tool-Ergebnisse nicht neu. Jede Änderung an den Bytes macht den nachfolgenden Cache ungültig.
• ❌ Nutze keinen gemeinsamen Cache Key für parallele Agent-Instanzen. Ihre Schrittreihenfolgen laufen auseinander und verunreinigen sich gegenseitig.
• ✅ Überwache pro Aufgabe das Verhältnis cache_creation_tokens : cache_read_tokens. Bei Schritt 10 sollte es 1:50 oder besser sein.

Die zentrale 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 leistet und was nicht

Die Grenzen sind klar:

Wenn du heute eine der Funktionen auf der rechten Seite brauchst, musst du sie in deiner Anwendungsschicht oder direkt über das SDK des Providers umsetzen. Das Gateway ist ein schlanker Proxy mit einer zusätzlichen Preisschicht. Das eigentliche Caching findet upstream auf Modellebene statt.

Fazit

Die gesamte Serie lässt sich auf vier Zeilen reduzieren:

Caching bringt zwei Vorteile, nicht nur einen. Kosten UND Latenz. Stabile Inhalte nach vorn, veränderliche nach hinten. Ein sauberer Prefix kostet nichts – nutze ihn überall. Modell und Cache-Verhalten müssen zum Anwendungsfall passen. Chat ≠ RAG ≠ Agents. Miss deinen eigenen Traffic. Einzelne Benchmark-Läufe sind ein Ausgangspunkt, nicht die endgültige Antwort.

Der schnellste nächste Schritt: Wähle in der Matrix den Anwendungsfall, der deinem am nächsten kommt. Setze dann die strukturellen Änderungen um – stabiler Prefix zuerst, deterministisches Retrieval, byte-identischer Agent-Zustand. Protokolliere eine Woche lang cached_tokens und usage.cost und bewerte die Auswahl anschließend neu.

FAQ

Welches LLM ist für einen chinesischsprachigen Chatbot am günstigsten? deepseek-v4-flash und qwen3.5-flash waren in unseren Tests bei chinesischen Texten um eine Größenordnung günstiger als auf Englisch optimierte Modelle. Bei typischen Chat-Workloads erreichen sie zugleich die Qualität von gpt-5.4-mini.

Welches LLM eignet sich 2026 am besten für RAG? Für Englisch liefert gpt-5.4-mini mit dem Prompt-Aufbau aus Lösung A – System-tokens am Anfang, Referenzen am Ende – auf dem stabilen Abschnitt eine Hit Rate von über 80 %. Für Chinesisch: deepseek-v4-flash. Für sehr lange Dokumente, die häufig abgefragt werden: gemini-2.5-pro, da es Kontexte mit mehr als 1M tokens nativ verarbeitet.

Sollte ich GPT oder Claude für Agents verwenden? Beide sind leistungsfähig. Die Wahl hängt davon ab, wie viel Aufwand du in sauberes Caching investieren willst. Claudes Muster mit 4 cache_control-Markern – über das anthropic SDK gegen das Gateway – ist besonders stark bei kumulativen Agent-Prefixes. Sobald der Prefix warm ist, sinken die Input-Kosten über mehr als 10 Schritte um ~90 %. Wenn du lieber beim OpenAI-kompatiblen Client bleibst und ohne Marker eine Cache-Ersparnis von ~50 % akzeptierst, sind gpt-5.4-mini oder gpt-5.5-pro einfacher zu integrieren.

Wie viel kann ich realistisch sparen, wenn ich von einer „naiven“ auf eine optimierte LLM-Nutzung umstelle? In den Messläufen dieser Serie waren es beim selben Modell 50–88 % weniger Kosten und eine 30–60 % niedrigere TTFT. Der größte Effekt entsteht durch eine Hit Rate von über 80 %, nicht durch den Wechsel auf ein anderes Modell.

Wo fange ich an? Wähle in der Matrix den Anwendungsfall, der deinem am nächsten kommt. Passe die Prompt-Struktur an. Miss eine Woche lang cached_tokens und usage.cost im produktiven Traffic. Erst danach solltest du über einen Modellwechsel nachdenken.

Wie vergleiche ich die Preise von LLM APIs verschiedener Provider? Die Modellseite von Synthorai bietet einen Live-Preisvergleich. Du kannst nach Provider filtern und nach Input- oder Output-Preis pro Million tokens sortieren. Die Werte entsprechen immer den aktuellen Listenpreisen des Gateways. Die Matrix oben zeigt, welcher Modelltyp zu deinem Anwendungsfall passt; auf der Modellseite siehst du die aktuellen Kosten.

Quellen und Verifizierung: Messwerte aus Teil 3 §6, https://synthorai.io/v1 am 2026-05-25, openai SDK 2.38.0. Preisseiten der Provider: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Zurück zum Blog