Caching ist ein Präfixabgleich, und diese eine Tatsache entscheidet alles. Das erste geänderte Byte macht jedes Byte danach ungültig, also bedeutet eine flüchtige Zeile — ein Zeitstempel, eine Anfrage-ID, die Nutzerfrage — vor fünfundzwanzigtausend stabilen Token, dass keines davon gecacht wird. Die Behebung hat immer dieselbe Form: Stabiles zuerst, Flüchtiges zuletzt. Nicht offensichtlich sind die Kosten des Fehlers, und deshalb bekommt er hier eine Zahl. Geben Sie die Blöcke Ihrer Anfrage mit ihrer Änderungshäufigkeit ein — sie werden sortiert, das Präfix wird gemessen und der Unterschied über beliebig viele Anfragen bepreist.
Funktionen
Blöcke sortiert, um das Präfix zu maximieren
Benennt, welche stabilen Blöcke hinter flüchtigen gestrandet sind
Misst das cachefähige Präfix und den stets bezahlten Rest
Warnt, wenn das Präfix unter dem Minimum liegt und still nicht gecacht wird
Bepreist den Unterschied über eine Serie von Anfragen
Markiert gelegentlich wechselnde Blöcke, die alles danach ungültig machen
Cache-Leseraten je Modell, mit Prüfdatum
Editierbare Blockgrößen, passend zu Ihrer Anfrage
So verwendest du Prompt-Cache-Planer
Listen Sie die Blöcke Ihrer Anfrage mit Größen
Markieren Sie, wie oft jeder sich ändert
Lesen Sie die empfohlene Reihenfolge und die Ersparnis
Setzen Sie Ihren Cache-Punkt ans Ende des stabilen Präfixes
Beispiel
Eingabe
User question (300) sent first
Ausgabe
29,500 stable tokens cannot be cached
Ein flüchtiger Block vorn macht alles dahinter ungültig.
Häufige Fehler & Fehlerbehebung
Meine Trefferquote ist null. — Etwas Flüchtiges steckt im Präfix. Ein Zeitstempel, eine Anfrage-ID oder eine Werkzeugliste ohne stabile Reihenfolge genügen jeweils allein.
Das Präfix liegt unter dem Minimum. — Kurze Präfixe werden gar nicht gecacht, und nichts sagt es Ihnen. Entweder wird das Präfix größer, oder Caching greift nicht.
Mal wird gecacht, mal nicht. — Meist ein gelegentlich wechselnder Block weit vorn. Jede Änderung macht alles danach ungültig, eine gelegentliche Änderung ist also eine gelegentliche Anfrage zum vollen Preis.
Umsortieren würde den Sinn ändern. — Dann ist es ein echter Kompromiss. Was bleiben muss, ist eine Randbedingung; das Werkzeug zeigt die Kosten, damit die Entscheidung informiert statt zufällig fällt.
Häufig gestellte Fragen
Wie funktioniert Prompt-Caching wirklich?
Die Anfrage wird per Präfix mit dem Gecachten abgeglichen. Alles bis zur ersten Abweichung kommt zu einem Bruchteil des Preises aus dem Cache; alles danach wird voll berechnet. Deshalb ist die Reihenfolge das ganze Spiel.
Was macht einen Cache still ungültig?
Alles, was früh Bytes ändert: ein Zeitstempel im Systemprompt, eine Anfrage-ID, eine aus einer ungeordneten Map gebaute Werkzeugliste, ein nutzerspezifisches Feld. Keines erzeugt einen Fehler — die Trefferquote sinkt einfach.
Warum gibt es ein Mindestpräfix?
Unterhalb einer modellabhängigen Größe wird gar nicht gecacht. Es scheitert still, also war ein kleiner Systemprompt, den Sie für gecacht hielten, es vielleicht nie.
Wohin gehört der Cache-Punkt?
Ans Ende des letzten stabilen Blocks. Alles davor wird wiederverwendet, alles danach ist jedes Mal neu — genau der Schnitt, den die Sortierung hier erzeugt.
Lohnt Caching immer?
Wenn ein großes Präfix wirklich wiederverwendet wird, ja: Die Leserate ist ein Bruchteil der Eingaberate. Eine Anfrage ohne stabiles Präfix dafür zu verbiegen lohnt nicht — genau das sagt hier der Fehler.