Provider-Drift: Wie Default-Routing die LLM-Kosten in die Höhe treibt

Du hast Prompt Caching aktiviert. Der Hit-Counter steigt gelegentlich, aber auf der Rechnung ist kaum ein Unterschied zu sehen. Bevor du die Struktur deines Prompts dafür verantwortlich machst, solltest du prüfen, was das Dashboard nicht zeigt: Welcher Upstream hat den jeweiligen Request tatsächlich verarbeitet?

Multi-Provider-Gateways verteilen ein einzelnes Modell auf mehrere Upstream-Provider und wählen für jeden Request einen davon aus. Prompt Caches gelten pro Provider, häufig sogar nur pro Node innerhalb eines Providers. Landet der zweite identische Request bei einem anderen Upstream als der erste, ist das ein Cache Miss, obwohl sich am Prompt kein einziges Byte geändert hat. Das ist Provider-Drift. Bei einem Pay-per-Token-Modell vervielfacht sie unbemerkt die Kosten.

TL;DR

• Mit dem Routing ab Werk verteilte ein Multi-Provider-Gateway 20 identische Calls auf 9 Upstreams. Nur 4 von 20 Requests trafen den Prompt Cache.
• Ein Single-Backend-Gateway erreichte mit derselben Workload 19/20 Hits. Durch die Drift kostete der Lauf etwa 3.9x mehr ($0.0102 statt $0.0026).
• Beim gemessenen Modell aus der DeepSeek-Familie kostete ein Cache Miss etwa 4x so viel wie ein Hit ($0.00062 statt $0.00015 Median pro Call).
• Drift tritt modellspezifisch auf: Dasselbe Gateway leitete alle 20 Calls eines GPT-Modells an einen einzigen Upstream weiter und erreichte 19/20 Hits.

Die beiden Auslöser

Das ist keine Fehlkonfiguration, für die du dich bewusst entschieden hast. Dieses Verhalten bekommst du ab Werk:

1. Default Auto-Routing. Der Request wird an das Modell gesendet, ohne einen Upstream fest vorzugeben. Das Gateway wählt daher bei jedem Call einen aus.
2. Default-Provider-Sortierung = “default (balanced)”. Das Gateway verteilt die Last auf alle infrage kommenden Upstreams, statt bei einem zu bleiben.

Beides sind die Werkseinstellungen. Du musst nichts ändern, damit Drift entsteht. Du musst Einstellungen ändern, um sie zu vermeiden.

So sehen 20 identische Requests aus

Wir haben denselben Prefix mit rund 8K Tokens 20-mal hintereinander an ein bekanntes Multi-Provider-Gateway gesendet. Dabei galten die oben genannten Defaults. Bei jedem Request ließen wir uns die vom Upstream gemeldeten Provider- und Cache-Felder ausgeben. Für ein disk-cached Modell aus der DeepSeek-Familie ergab sich folgendes Bild:

• 9 unterschiedliche Upstreams verarbeiteten die 20 Calls: N***a, S***w, M***h, D***a, A***L, P***l, S***e, V***e, A***d.
• Cache-Hit-Rate: 4/20 (20%). Ein Hit trat nur dann auf, wenn ein Call zufällig bei einem Upstream landete, der den Prefix bereits im Cache hatte.

Mit denselben 20 Calls erreichte ein Single-Backend-Gateway (ein Modell, ein Upstream, kein Load Balancing) eine Hit-Rate von 19/20 (95%). Gleiches Modell, gleicher Prompt, gleiche Anzahl an Calls. Der einzige Unterschied war, ob das Routing driftete.

Zum Vergleich: Dasselbe Multi-Provider-Gateway leitete alle 20 Calls eines GPT-Modells an einen Upstream (A***e) weiter und erreichte 19/20 Hits. Drift ist nicht gleichmäßig verteilt. Sie betrifft die Modelle, die das Gateway gerade über mehrere Upstreams verteilt. In diesem Lauf war das Modell aus der DeepSeek-Familie betroffen.

Fazit A: Erwartete und tatsächliche Kosten

Beim driftenden Modell unterschieden sich die Kosten pro Call deutlich nach dem Cache-Ergebnis:

Bei diesem Modell kostet ein Miss etwa 4x so viel wie ein Hit. Bei den reinen Input Tokens ist der veröffentlichte Abstand mit ungefähr 50x noch größer. Über alle 20 Calls ergibt sich:

Gleiches Modell, gleicher Prompt, dieselben 20 Requests. Durch die Provider-Drift kostete der Lauf ~3.9x mehr. Caching war die ganze Zeit aktiviert. Die Routing-Schicht rechnete lediglich den Großteil der Tokens zum Miss-Tarif ab. Übertragen auf einen Production Endpoint, der den ganzen Tag einen großen, stabilen Prefix wiederverwendet, macht diese Differenz den Großteil der Input-Kosten aus.

Fazit B: Ohne Cache entfällt auch der Latenzvorteil

Caching senkt nicht nur die Kosten. Bei einem warmen Prefill kommt auch das erste Token schneller zurück. Ist der Cache wegen Drift nicht erreichbar, fällt dieser Geschwindigkeitsvorteil ebenfalls weg. Wir haben die Time-to-First-Token (TTFT) bei wiederholten identischen Calls gemessen:

GPT-Modell (Routing zu einem konsistenten Upstream, Cache erreichbar):

Mit Caching kommt das erste Token etwa 36% schneller. Das Ergebnis ist stabil: Alle warmen Calls liegen dicht beieinander.

Modell aus der DeepSeek-Familie (Default-Drift, Cache selten erreichbar):

• Cache Hits bei 10 wiederholten Calls: 0.
• Die TTFT schwankte von Call zu Call zwischen ~1000 ms und ~4500 ms. Gelegentlich kamen leere Responses zurück.

Da fast jeder Request bei einem neuen Upstream landet, bleibt die Latenz auf dem Niveau eines kalten Prefills. Dazu kommt die Varianz des jeweiligen Providers, der den Request verarbeitet. Beim GPT-Modell verbesserte der erreichbare Cache die TTFT um 36%. Beim driftenden Modell gab es keine Verbesserung. Zwischen dem schnellsten und langsamsten Call lag außerdem der Faktor 4.5x.

Prüfe dein Setup in fünf Minuten

Verlass dich weder auf diese Zahlen noch auf andere Messungen. Sende denselben langen Prefix mehrmals und beobachte zwei Felder. Im Code sind keine Domains fest eingetragen. Konfiguriere dein eigenes Gateway über Umgebungsvariablen.

import os, uuid
from openai import OpenAI

client = OpenAI(api_key=os.environ["GW_KEY"], base_url=os.environ["GW_BASE"])
SYS = f"[probe {uuid.uuid4().hex}]\n\n" + ("You are a support assistant. " * 300)

seen, hits = {}, 0
for i in range(20):
    r = client.chat.completions.create(
        model=os.environ["GW_MODEL"], max_tokens=16,
        messages=[{"role": "system", "content": SYS},
                  {"role": "user", "content": f"q{i}"}],
        extra_body={"usage": {"include": True}})
    d = r.model_dump()
    det = r.usage.prompt_tokens_details
    cached = (getattr(det, "cached_tokens", 0) or 0) if det else 0
    seen[d.get("provider")] = seen.get(d.get("provider"), 0) + 1   # populated when exposed
    hits += 1 if cached else 0

print(f"hit rate {hits}/20; upstreams seen: {len(seen)}")

Mehr als ein Upstream für dasselbe Modell bedeutet Drift. Liegt die Hit-Rate deutlich unter dem Wert, den die Stabilität deines Prompts erwarten lässt, zahlst du dafür. Die vollständige Methode findest du unter Macht dein LLM-Gateway falsche Angaben zum Cache?.

Worauf du achten solltest

Drift lässt sich nur strukturell beheben: Route ein bestimmtes Modell konsistent zu einem Backend. Dann ist ein warmer Cache beim nächsten Request tatsächlich erreichbar. Verteile nicht jeden Call per Load Balancing auf einen neuen Upstream, der deinen Prefix noch nie gesehen hat. Sende bei der Evaluierung eines Gateways denselben Prefix 20-mal und zähle die Upstreams. Einer ist das Ziel. Neun sind eine Zusatzsteuer.

Eine Einschränkung bleibt: Prompt Caching funktioniert überall nur nach dem Best-Effort-Prinzip. Bei disk-cached Modellen sinkt die Hit-Rate auch mit einem einzelnen Backend, wenn zwischen den Requests lange Pausen liegen. Das Vermeiden von Drift macht den Cache nicht unbegrenzt haltbar. Es beseitigt aber die größte und teuerste Ursache für Misses: eine, der du nie zugestimmt hast und die du nicht sehen kannst.

Schluss

„Unterstützt Prompt Caching“ und „dein Cache ist erreichbar“ sind zwei verschiedene Aussagen. Ein Gateway kann ein Modell auf wechselnde Upstreams verteilen und trotzdem wahrheitsgemäß Cache-Unterstützung angeben. Das Ergebnis können dennoch eine Hit-Rate von 20%, eine ~4x höhere Rechnung und eine um den Faktor 4.5x schwankende Latenz bis zum ersten Token sein. Entscheidend ist nicht, ob Caching beworben wird. Miss deine tatsächliche Hit-Rate und die Zahl der Upstreams, die identische Requests verarbeiten. Führe den Test aus und entscheide anhand der Daten.

Die umfassendere Prüfmethode findest du unter Macht dein LLM-Gateway falsche Angaben zum Cache?. Warum es Caches überhaupt gibt, erklärt So funktionieren KV Cache und TTL.

FAQ

Ist das eine Fehlkonfiguration auf meiner Seite? Nein. Das passiert mit den Werkseinstellungen: Auto-Routing und der Provider-Sortierung “default (balanced).” Um Drift zu vermeiden, musst du einen Upstream aktiv fest vorgeben, nicht umgekehrt.

Löst das Festlegen eines Upstreams das Problem? Damit entfällt die Drift zwischen Providern. Ein einzelner Upstream betreibt aber häufig mehrere Replicas ohne Prefix Affinity, sodass Hits weiterhin ausbleiben können. Miss das Ergebnis nach der Umstellung, statt davon auszugehen, dass sie ausreicht.

Warum gab es beim GPT-Modell keine Drift? In diesem Lauf leitete das Gateway das Modell zufällig an einen einzelnen Upstream weiter. Drift ist modellspezifisch und hängt davon ab, über wie viele geeignete Upstreams das Gateway die Last verteilt. Sie tritt nicht bei allen Modellen gleich auf.

Beträgt der Kostenunterschied wirklich ~4x? Bei den von uns gemessenen Gesamtkosten pro Call kostete ein Miss ~4x so viel wie ein Hit. Bei den veröffentlichten Preisen für reine Input Tokens dieser Modellklasse liegt der Abstand zwischen Hit und Miss eher bei 50x. In beiden Fällen wird es teuer, wenn aus erwarteten Hits Misses werden.

Welche einzelne Metrik sollte ich überwachen? Die Cache-Hit-Rate pro Modell im Zeitverlauf, ergänzt um die Anzahl unterschiedlicher Upstreams pro Modell. Sinkt die Hit-Rate oder steigt die Zahl der Upstreams, sind deine effektiven Token-Kosten gerade gestiegen.

← Zurück zum Blog