Lange Präfixe cachen

Bei jedem langen Prompt fallen Prefill-Kosten an, weil seine Tokens vor der Generierung verarbeitet werden müssen. Wenn sich dasselbe lange Präfix bei vielen Aufrufen wiederholt – etwa ein System-Prompt, eine Tool-Spezifikation oder ein großes Referenzdokument –, ermöglicht Prompt-Caching dem Anbieter, den bereits berechneten Attention-Zustand wiederzuverwenden, statt ihn erneut zu berechnen.

• Cache-Treffer senken Latenz und Eingabekosten erheblich.
• Die Einsparungen steigen mit der Präfixgröße und der Häufigkeit der Wiederverwendung.

Caches verwenden eine exakte Übereinstimmung des Tokenpräfixes vom Anfang des Prompts an als Schlüssel. Der gecachte Bereich reicht vom Anfang bis zum ersten Abweichungspunkt. Wenn Sie früh etwas ändern, verfehlt alles danach den Cache.

Die Konsequenz: Für möglichst viele Treffer muss das Layout die stabilsten Inhalte zuerst und die variabelsten Inhalte zuletzt platzieren.

Ordnen Sie die Inhalte von stabil nach instabil: unveränderliche Systemregeln und Tooldefinitionen, danach umfangreiches stabiles Referenzmaterial, dann sitzungsstabiler Kontext und zuletzt die volatile, anfrageabhängige Eingabe und Frage.

• Stabil -> vorne (cachefähig).
• Volatil -> hinten (nur dieser Teil wird neu berechnet).

Dieses eine Ordnungsprinzip bestimmt die meisten Erfolge beim Caching.

Einige Anbieter erlauben Ihnen, explizite Cache-Grenzen zu markieren. Platzieren Sie sie am Ende jedes stabilen Segments, damit das System bis zu diesem Punkt cachen kann. Markieren Sie den größten stabilen Block – den Referenzbestand oder den langen System-Prompt – als cachefähig.

Auch ohne explizite Markierungen sollten Sie die Struktur nach Stabilität ordnen, damit die implizite Präfixübereinstimmung weiterhin hilft.

Unauffällige, unbeabsichtigte Änderungen unterbrechen das Caching unbemerkt: ein Zeitstempel im System-Prompt, eine früh eingefügte anfrageabhängige ID, neu angeordnete Tooldefinitionen oder eine nichtdeterministische Reihenfolge von JSON-Schlüsseln. Jede solche Änderung verschiebt das Präfix und erzwingt eine vollständige Neuberechnung.

Überprüfen Sie Ihr Präfix auf alles, was sich zwischen Aufrufen ändert, und verschieben Sie solche Inhalte hinter den gecachten Bereich.

Caches laufen nach einer vom Provider festgelegten Time-to-Live ab, die bei jedem Treffer häufig verlängert wird. Bei zu seltenen Aufrufen treten Cold Misses erneut auf. Für stoßartige Workloads mit hoher Frequenz lohnt sich Caching; bei seltenen, verstreuten Aufrufen kann der Cache zwischen den Nutzungen ablaufen.

Stimmen Sie Ihr Traffic-Muster auf die TTL ab und ziehen Sie Keep-Alive-Pings für wertvolle Präfixe in Betracht.

Beim Caching fällt typischerweise ein kleiner Aufpreis für das Schreiben eines Cache-Eintrags an, während das Lesen deutlich günstiger ist. Die Wirtschaftlichkeit spricht für Wiederverwendung: Ein Schreibvorgang, der sich auf viele Lesevorgänge verteilt, ergibt eine große Nettoersparnis; eine einmalige Nutzung, bei der nur geschrieben wird, kann geringfügig mehr kosten.

• Hohe Wiederverwendung - aggressiv cachen.
• Einmalige Präfixe - Caching lohnt sich möglicherweise nicht.

Machen Sie Ihren System-Prompt und Ihre Tool-Spezifikationen deterministisch und versionsgebunden. Sortieren Sie Tool-Definitionen kanonisch, vermeiden Sie das Einbetten dynamischer Daten und ändern Sie sie nur im Rahmen bewusst geplanter Releases. Ein stabiler Systemblock wird zu einem langlebigen Cache-Eintrag mit hoher Trefferquote, der von allen Requests gemeinsam genutzt wird.

Behandeln Sie das gecachte Präfix als Artefakt mit einer Version, nicht als Zeichenkette, die Sie beiläufig anpassen.

In Agentenschleifen ist die wachsende Konversation ein natürlicher Cache: Jeder Turn erweitert ein Präfix, das im nächsten Turn wiederverwendet wird. Hängen Sie neue Turns am Ende an und schreiben Sie frühere Turns niemals um, damit der bisherige Cache gültig bleibt.

Wenn Sie komprimieren müssen, tun Sie dies so, dass für die folgenden Turns ein neues stabiles Präfix entsteht, anstatt alte Präfixe wiederholt zu verändern.

Instrumentieren Sie den Cache. Die meisten Provider melden pro Aufruf die gecachten und nicht gecachten Input-Tokens. Verfolgen Sie die Trefferquote. Wenn sie niedrig ist, untersuchen Sie das Präfix auf Drift. Ein Rückgang der Trefferquote deutet meist auf einen kürzlich eingeführten dynamischen Wert am Anfang des Prompts hin.

• Protokollieren Sie cached_tokens / total_input_tokens.
• Alamieren Sie, wenn die Trefferquote nach einem Deployment sinkt.

Um die Kosten langer Präfixe zu kontrollieren: Ordnen Sie Inhalte nach ihrer Stabilität, markieren Sie den größten stabilen Block als Cache-Breakpoint, beseitigen Sie verborgene Drift, binden und versionieren Sie System- und Tool-Blöcke, hängen Sie in Agentenschleifen nur neue Inhalte an und überwachen Sie die Trefferquote. Ziel ist ein großes wiederverwendbares Präfix und ein kleiner variabler Teil, der bei jedem Aufruf neu berechnet wird.

Sie verwenden einen Referenzkorpus mit 100.000 Tokens für Tausende täglicher Abfragen wieder, aber Ihre Cache-Trefferquote liegt nahe null.

Prompt-Caching verwendet das Prefill eines exakt übereinstimmenden, stabilen Präfixes wieder und senkt bei häufiger Wiederverwendung Latenz und Input-Kosten deutlich. Ordnen Sie Inhalte von besonders stabil nach variabel an, markieren Sie den großen stabilen Block als Breakpoint und verschieben Sie alle variablen Inhalte ans Ende. Beseitigen Sie verborgene Drift, binden und versionieren Sie System- und Tool-Blöcke, hängen Sie in Agentenschleifen nur neue Inhalte an und überwachen Sie die Trefferquote, damit ein Rückgang auf einen neu eingeführten, früh variierenden Wert hinweist.