Amazon Bedrock Prompt Caching liest ein zwischengespeichertes Präfix zu etwa 90 Prozent Rabatt, aber ein Cache-Write kostet mehr als ein normales Input-Token. Ein Cache, der nie getroffen wird, macht die Rechnung also schlechter, nicht besser. Das Feature ist seit April 2025 allgemein verfügbar, und die einstündige Cache-Dauer, die im Januar 2026 kam, macht es für ganze Sessions und Batch-Jobs nützlich. Die meisten Teams lassen es trotzdem ausgeschaltet, oder aktivieren es an der falschen Stelle und zahlen still einen Aufschlag. Der Rabatt ist real. Ob man ihn einfängt, hängt vollständig davon ab, wo der Cache-Breakpoint sitzt.

Das Mentalmodell, das Leute stolpern lässt, ist, den Cache wie eine kostenlose Beschleunigung zu behandeln, die man einfach draufstreut. Das ist er nicht. Jeder Cache-Checkpoint ist eine Wette, dass die Tokens davor unverändert erneut gesendet werden, bevor der Cache abläuft. Gewinnt man die Wette, zahlt man ein Zehntel des Lesepreises. Verliert man sie, hat man den Write-Aufschlag umsonst bezahlt.

Wie die Preisgestaltung tatsächlich funktioniert

Drei Token-Klassen sind relevant, und sie werden unterschiedlich bepreist:

  • Cache-Write: Das erste Mal, dass Bedrock ein Präfix speichert, werden diese Tokens über dem normalen Input-Satz abgerechnet. Bei Anthropic-Modellen liegt der Write bei etwa dem 1,25-fachen des Basis-Input-Preises für die kurze Cache-Dauer und etwa dem 2-fachen für die einstündige Dauer.
  • Cache-Read: Jede spätere Anfrage, die dem gespeicherten Präfix entspricht, liest diese Tokens zu etwa 0,1x, dem headline-tauglichen 90-Prozent-Rabatt.
  • Uncached Input: Alles nach dem letzten Cache-Checkpoint, jedes Mal zum normalen Satz abgerechnet.

Der Write-Aufschlag ist das ganze Spiel. Man zahlt im Voraus, um zukünftige Reads billig zu machen. Der Break-even ist einfach: Man braucht genug Treffer auf einem zwischengespeicherten Präfix, um den Aufpreis fürs Schreiben wieder hereinzuholen. Ein Write plus ein Read kann mehr kosten als zwei normale Aufrufe. Die Ersparnis summiert sich nur, wenn dasselbe Präfix viele Male gelesen wird.

Wo der Breakpoint hingehört

Ein Cache-Checkpoint sagt: "Alles vor diesem Punkt ist stabil, speichere es." Also setzt man ihn nach den Teilen des Prompts, die sich zwischen Aufrufen nicht ändern, und vor die Teile, die sich ändern. Bei einem typischen Assistenten sieht diese Reihenfolge so aus:

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

Der System-Prompt und die Tool-Definitionen sind bei jedem Aufruf identisch, sie gehören also in das zwischengespeicherte Präfix. Der neue User-Turn wiederholt sich nie, also gehört er nach draußen. Retrieved Context sitzt in der Mitte: Man cacht ihn, wenn dieselben Dokumente über eine Session hinweg wiederverwendet werden, lässt ihn uncached, wenn jeder Aufruf etwas Neues abruft. Setzt man diese Reihenfolge falsch, den Checkpoint vor die Tool-Definitionen, cacht man fast nichts und zahlt trotzdem fürs Schreiben.

Wenn ein Miss mehr kostet als kein Cache

Cache-Treffer brauchen eine exakte Übereinstimmung auf dem Präfix, Byte für Byte, und der Eintrag muss noch lebendig sein. Man verliert die Wette auf drei gängige Arten:

  • Man mutiert das Präfix. Einen Timestamp, eine Request-ID oder eine nutzerspezifische Begrüßung nahe dem Anfang des System-Prompts einzufügen ändert die Bytes, sodass jeder Aufruf ein frischer Write ist und nie ein Read. Das ist das häufigste Eigentor.
  • Der Traffic ist zu dünn für die TTL. Kommen Anfragen weiter auseinander als die Cache-Lebensdauer, schreibt jede und läuft ab, bevor die nächste eintrifft. Die einstündige Dauer hat dieses Fenster deutlich vergrößert, aber ein Endpunkt mit wenig Traffic kann trotzdem jedes Mal danebenliegen.
  • Das Präfix liegt unter dem Minimum. Bedrock cacht nur Präfixe oberhalb einer modellabhängigen Token-Untergrenze. Ein kurzer System-Prompt ist möglicherweise gar nicht cachebar, sodass der Checkpoint ignoriert wird und man nichts gewinnt.

In jedem Fall zahlt man entweder den Write-Aufschlag ohne Reads, um ihn zu amortisieren, oder man zahlt nichts extra, spart aber auch nichts, während man glaubt, optimiert zu haben. Beides ist schlechter als die klare Entscheidung, das Caching für diesen Pfad einfach auszulassen.

Ein schneller Weg zu wissen, ob es funktioniert

Man sollte nicht annehmen, dass der Cache heiß ist. Die Antworten von Converse und InvokeModel melden Cache-Read- und Cache-Write-Token-Zahlen in ihren Usage-Feldern. Man loggt sie und beobachtet das Verhältnis. Ein gesunder gecachter Pfad zeigt einen kleinen, stetigen Strom von Writes und ein großes Volumen an Reads. Laufen Writes und Reads eins zu eins parallel, ist das Präfix nicht stabil, und man zahlt den Aufschlag für einen Cache, den niemand trifft. Präfix reparieren oder Checkpoint abschalten.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

Das Fazit

Prompt Caching auf Bedrock ist kein Schalter, den man für kostenlose 90 Prozent umlegt. Es ist ein vorausbezahlter Rabatt: Man zahlt im Voraus einen Write-Aufschlag und verdient ihn durch wiederholte Reads eines unveränderten Präfixes zurück. Man setzt den Checkpoint nach dem stabilen System-Prompt und den Tool-Definitionen, hält alles Volatile aus der gecachten Region heraus und loggt das Read-zu-Write-Verhältnis, um zu belegen, dass sich die Wette auszahlt. Richtig gemacht ist es die günstigste große Ersparnis auf Bedrock. Nachlässig gemacht ist es ein Posten, der die Rechnung verschlechtert, während er wie eine Optimierung aussieht.

Weiterlesen

Für das breitere Kostenoptimierungs-Playbook über AWS hinweg gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.