Prompt-Caching-Mindestgrößen: Doku um 1,4-2,4x zu niedrig

Ein Kunde meldete uns, dass das Prompt-Caching unseres Gateways nicht bei der Token-Zahl einsetzte, die laut Dokumentation des Modells ausreichen sollte. Wir konnten das Verhalten reproduzieren und testeten anschließend jedes Modell über einen zweiten, unabhängigen Serving-Pfad bei einem der größten AI-Gateways. Dort traten exakt dieselben Abweichungen auf. Nicht ein einzelnes Gateway war das Problem, sondern die zu optimistische Dokumentation: Die veröffentlichte Mindestgröße ist lediglich die Untergrenze, ab der ein Prompt für den Cache infrage kommt. Sie entspricht nicht der Länge, ab der tatsächlich ein Cache Hit erfolgt. Bei Modellfamilien mit automatischem Cache unterscheiden sich beide Werte um den Faktor 1.4 bis 2.4. Bei OpenAI lag die effektive Schwelle für den ersten Hit bei etwa 1,456 Tokens statt der dokumentierten 1,024. Gemini 2.5 Flash lieferte ab ungefähr 5,000 Tokens erstmals Daten aus dem Cache, dokumentiert sind 2,048. Claude, das nur an explizit markierten Stellen cached, erreichte die dokumentierte Mindestgröße des jeweiligen Modells mit wenigen Prozent Abweichung.

TL;DR

• OpenAIs dokumentierte Cache-Mindestgröße von 1,024 Tokens liegt unter der effektiven Schwelle von etwa 1,456 Tokens, gemessen über zwei Pfade.
• Bei Gemini 2.5 Flash sind 2,048 Tokens dokumentiert, der erste Read erfolgte jedoch erst bei ungefähr 5,000 Tokens, also etwa 2.4-mal später.
• Claudes explizites cache_control erreichte die dokumentierte Mindestgröße mit wenigen Prozent Abweichung (Opus 1,073 statt 1,024).
• GLM 5.2 und DeepSeek V4 veröffentlichen keine Mindestgröße und liefern ab etwa 800 Tokens aus dem Cache; MiniMax M3 meldet unabhängig von der Länge ungefähr 114 gecachte Tokens.
• Automatische Caches benötigen vor dem ersten Read außerdem eine Aufwärmphase von 2 bis 8 Aufrufen.

Wir führten jede Messung über zwei Serving-Pfade aus: unser eigenes Gateway und eines der größten unabhängigen AI-Gateways. Nur wenn beide Pfade übereinstimmten, werteten wir ein Ergebnis als Verhalten des Modells. Der zweite Pfad dient der eindeutigen Zuordnung: Tritt eine Abweichung auch auf dem Stack eines unabhängigen Anbieters auf, liegt sie am Modell und nicht an unserem Gateway. Bei OpenAI, Gemini und GLM funktionierte dieser Abgleich eindeutig. Alle drei cachedten auf beiden Pfaden bei denselben effektiven Schwellenwerten. Nicht jedes Modell lässt sich so prüfen. Die Open-Weight-Modelle laufen beim zweiten Gateway größtenteils auf GPU-Hosts, die den Prompt Cache des Anbieters nicht implementieren. Das bestätigen auch die Endpoint-Metadaten des Gateways für die jeweiligen Provider. Ohne festes Routing wechseln Requests zwischen diesen Hosts, wodurch die Cache-Affinität verloren geht. Wo der zweite Pfad keine Bestätigung liefern konnte, stammen die folgenden Werte von dem Pfad, der die jeweilige Caching-API des Anbieters direkt erreicht. Die Längen sind in den modellinternen Tokens angegeben und anhand des zurückgegebenen usage kalibriert, nicht anhand von Zeichen. Für jeden Testzweig verwendeten wir ein neues Präfix und erfassten den ersten Aufruf, der einen Cache Read lieferte. Ein einzelner Hit oder Miss war nicht ausschlaggebend.

Abweichung zwischen dokumentierter und effektiver Mindestgröße

Die dokumentierte Mindestgröße gibt an, ab wann ein Prompt überhaupt gecacht werden kann. Die effektive Schwelle ist die Länge, ab der ein wiederholter Prompt tatsächlich aus dem Cache gelesen wird. Bei Modellfamilien mit automatischem Cache sind das nicht dieselben Werte.

Der OpenAI-Wert war auf beiden Pfaden bis auf das Token identisch: Ein Prompt mit 1,356 Tokens wurde nie aus dem Cache gelesen, einer mit 1,456 Tokens dagegen schon. Bei Gemini war die Abweichung am größten. Ein Sweep bis 3,300 Tokens lieferte keinen einzigen Read und erweckte den Eindruck, das Caching sei deaktiviert. Nach einer Erweiterung auf 5,000 Tokens erfolgte auf beiden Pfaden bei derselben Länge ein eindeutiger Read. Die dokumentierten 2,048 Tokens sind lediglich die Untergrenze, ab der der Cache den Prompt aufnehmen darf. Reads liefert er dort noch nicht.

Das Muster der gesamten Untersuchung war eindeutig: Bei explizit markierten Caches stimmen die Spezifikationen. Bei automatischen Caches tun sie es nicht.

Die Mindestgröße ist nicht die einzige undokumentierte Variable

Das Überschreiten der effektiven Schwelle ist notwendig, reicht aber nicht aus. Modellfamilien mit automatischem Cache benötigen eine Aufwärmphase. Der erste Read erfolgt erst bei einem späteren Aufruf, nicht bereits beim zweiten.

• OpenAI: erster Read bei Aufruf 2 bis 3.
• Gemini: erster Read bei Aufruf 4 bis 8.

Das beeinflusst die Kostenmodellierung. Ein Prompt mit 6,000 Tokens liegt über allen dokumentierten und effektiven Gemini-Schwellen. Wird er in einem Workload aber nur zweimal gesendet und danach nicht mehr verwendet, können trotzdem beide Aufrufe zum vollen Preis abgerechnet werden, weil der Cache noch nicht aufgewärmt war. Kurzer oder stoßweiser Traffic wird daher zum Preis ohne Cache abgerechnet, obwohl die Prompt-Länge ausreichen würde. Wir stuften ein Modell erst dann als „cached nicht“ ein, wenn mindestens zwölf wiederholte Aufrufe mit einer Wartephase dazwischen keinen Read erzeugten. Ein kürzerer Sweep hatte bei Gemini zunächst ein falsch negatives Ergebnis geliefert, das ein längerer Test widerlegte.

Auch die Anzahl gecachter Tokens wird auf feste Blöcke gerundet. Das ist beim Abgleich mit der Rechnung relevant: OpenAI verwendet Blöcke mit 128 Tokens, DeepSeek Blöcke mit 64 Tokens. Werden bei einem Prompt mit 5,014 Tokens 4,073 gecachte Tokens gelesen, handelt es sich um einen partiellen Präfix-Hit mit Rundung auf eine Blockgrenze, nicht um einen Fehler.

Explizit steuerbare Caches halten sich an die Spezifikation

Claude cached nur Segmente, die mit cache_control markiert sind. Dafür ist die Spezifikation präzise. Alle getesteten Angaben von Anthropic trafen zu:

• Modellspezifische Mindestgröße, bis auf das Token genau. Opus 4.8 und Sonnet 5 lieferten den ersten Read bei 1,073 Tokens statt der dokumentierten 1,024; Haiku 4.5 bei 4,206 statt 4,096. Die geringe Differenz entsteht durch die Blockrundung, nicht durch eine abweichende Schwelle.
• Read-Preis von 0.1x des Input-Preises. Wir leiteten den Input-Preis jedes Modells aus dessen eigenen Cold Rows ab und berechneten anschließend anhand einer Zeile mit Hit den Preis für gecachte Reads. Bei Opus 4.8 und Haiku 4.5 ergab sich jeweils 0.10, entsprechend dem dokumentierten Multiplikator.
• Kostenlose Verlängerung des Fünf-Minuten-TTL bei jedem Read. Wir legten ein Präfix im Cache ab und lasen es nach zwei, vier und sechs Minuten erneut. Jeder Read war ein Hit. Ein Read innerhalb des jeweiligen Fünf-Minuten-Fensters hält den Eintrag ohne zusätzlichen Write am Leben.
• Kaskadierende Invalidierung. Bei einem stabilen Systempräfix und einem definierten Tool erzwang bereits eine Änderung der Tool-Beschreibung einen vollständigen Rewrite des darunterliegenden System-Caches. Wird eine Tool-Definition geändert, werden die System- und Message-Caches invalidiert. Das entspricht der dokumentierten Hierarchie.

Dabei fiel auch ein Widerspruch zwischen zwei Dokumentationen auf. Eine Tabelle eines Drittanbieters nannte für Claude Opus eine Mindestgröße von 4,096 Tokens. Unsere Messung ergab einen Read bei 1,073 Tokens. Anthropics eigene Angabe von 1,024 ist korrekt.

Open-Weight-Familien dokumentieren meist keine Mindestgröße

Die zuvor genannten Familien veröffentlichen wenigstens einen Wert, auch wenn er nicht stimmt. Bei Open-Weight-Modellen und Modellen chinesischer Labs fehlt eine Mindestgröße meist vollständig. Hier bleibt nur die Messung. Unser Vergleich der Provider-Caches zeigt, wie gut die veröffentlichten Preise nach einem Hit mit den Messwerten übereinstimmen. Hier geht es ausschließlich um die Länge, ab der der erste Read erfolgt.

GLM 5.2 veröffentlicht keine Mindestlänge und cached auf beiden Pfaden ab etwa 800 Tokens in Blöcken zu 64 Tokens. Damit liegt die Schwelle unter der aller dokumentierten Familien. DeepSeek V4 veröffentlicht ebenfalls keine Mindestgröße und lieferte ab ungefähr 800 Tokens aus dem Cache, ebenfalls mit einer Granularität von 64 Tokens. Das funktionierte allerdings nur über die eigene Caching-API. Laut DeepSeek-Dokumentation arbeitet der Cache nach dem Best-Effort-Prinzip und bietet keine garantierte Hit Rate. Genau das zeigt sich bei einem zwischengeschalteten Anbieter: Das andere Gateway betreibt DeepSeek über mehrere GPU-Hosts, von denen nur DeepSeeks eigener Endpoint den Cache implementiert. Ohne festes Routing auf diesen Endpoint erfolgen überhaupt keine Reads.

Bei MiniMax M3 ist bereits der gemeldete Wert irreführend. Dokumentiert ist eine Mindestgröße von 512 Tokens. Das Modell meldet jedoch schon beim ersten Aufruf konstant ungefähr 114 gecachte Tokens, unabhängig davon, ob der Prompt 200 oder 5,000 Tokens lang ist. Dieser Wert folgt nicht der Prompt-Länge und erscheint sogar auf Pfaden, auf denen kein Caching stattfindet. Er bildet daher lediglich die interne Buchhaltung des Modells ab und sagt nichts darüber aus, welche Daten wiederverwendet wurden. Neuere OpenAI-Modelle zeigen dasselbe Problem aus der anderen Richtung: Die Token-Felder in usage können vom tatsächlichen Caching abweichen. Wenn die Einsparung relevant ist, sollte deshalb usage.cost abgeglichen werden und nicht die Token-Anzahl.

Bei den neuesten Modellen ändern sich die Regeln

Bevor man das Verhalten älterer Modelle auf neue Familien überträgt, sind zwei Änderungen in der Dokumentation zu beachten. Für die GPT-5.6-Familie gibt OpenAI an, dass Cache Writes das 1.25-Fache des regulären Input-Preises kosten. Bei älteren Familien waren Writes kostenlos. Derselbe Guide beschreibt implizites Caching so, dass am Ende der neuesten Message ein Breakpoint gesetzt wird. Das unterscheidet sich vom Prefix Caching, bei dem ein stabiler Systemblock über mehrere Turns hinweg wiederverwendet wird. Soll bei diesen Modellen ein stabiles Präfix trotz unterschiedlicher User Turns erhalten bleiben, muss es mit einem expliziten Breakpoint markiert werden, statt sich auf den impliziten Pfad zu verlassen. Sowohl der Write-Multiplikator als auch die Mindestgröße müssen für jedes Modell einzeln geprüft werden. Inzwischen unterscheiden sich beide je nach Familie, auch wenn eine gemeinsame Dokumentationsseite diese Unterschiede nicht erkennen lässt.

Konsequenzen für die Praxis

• Die effektive Schwelle selbst messen. Die Prompt-Länge in den Tokens des jeweiligen Modells schrittweise erhöhen und die erste Länge erfassen, bei der ein Cache Read erfolgt. Die dokumentierte Mindestgröße ist nicht automatisch der Punkt, ab dem Hits beginnen.
• Die Aufwärmphase einkalkulieren. Bei Providern mit automatischem Cache sollten die ersten zwei bis acht Aufrufe eines neuen Präfixes im Kostenmodell als ungecached gelten.
• Explizite Marker bevorzugen, sofern der Provider sie anbietet. Claudes cache_control lieferte eine präzise und überprüfbare Spezifikation: bekannte Mindestgröße, bekannter Read-Preis, bekanntes TTL und bekannte Invalidierungsregeln. Diese Planbarkeit ist wertvoller als eine niedrigere dokumentierte Schwelle, auf die kein Verlass ist.
• Neue Modellfamilien neu vermessen. Mindestgrößen, Write-Preise und Breakpoint-Verhalten änderten sich während dieser Untersuchung sogar innerhalb des Portfolios eines einzelnen Anbieters.

Unser Leitfaden zum Prompt-Caching beschreibt die providerspezifischen Read-Preise, TTLs und Regeln zur Bildung von Cache Keys hinter diesen Schwellenwerten.

Kurz gesagt: Die dokumentierte Mindestgröße ist lediglich die Untergrenze für die Cache-Berechtigung, nicht die Schwelle für einen Hit. Bei automatischen Caches unterscheiden sich beide Werte um den Faktor 1.4 bis 2.4. Maßgeblich für die Rechnung ist der Wert, den man mit den Tokens des eigenen Modells und dem eigenen Traffic misst.

← Zurück zum Blog