Wenn Ihre Lokalisierungs-Engine Text übersetzt, ist ein Teil des Prompts, den sie an das LLM sendet, bei jeder Anfrage identisch, ein anderer ändert sich von Anfrage zu Anfrage. Mit Prompt-Caching kann die Engine den stabilen Teil wiederverwenden, statt seine Verarbeitung jedes Mal erneut zu bezahlen. Diese wiederverwendeten Tokens erscheinen in Ihrer Nutzung als Cache-Tokens und kosten nur einen Bruchteil normaler Eingabe-Tokens.
So ist ein Übersetzungsprompt aufgebaut#
Jede Anfrage, die die Engine an ein Modell sendet, setzt sich aus mehreren Schichten zusammen. Einige davon bleiben über alle Anfragen hinweg für dieselbe Engine und Sprache stabil, eine ist dynamisch und ändert sich pro Anfrage.
| Schicht | Stabil oder dynamisch | Im Cache |
|---|---|---|
| System-Prompt – Engine-Identität, Lokalisierungsregeln, Grammatik | Stabil über alle Engines hinweg | Ja |
| Ihre Regeln und Markenstimme pro Sprache | Bleibt stabil, bis Sie sie bearbeiten | Ja |
| Für diese konkrete Anfrage abgerufene Glossarbegriffe | Dynamisch – variiert je nach Anfrage | Nein |
| Der zu übersetzende Text | Dynamisch | Nein |
Die stabilen Schichten bilden ein zusammenhängendes Präfix am Anfang des Prompts. Die Engine markiert das Ende dieses Präfixes als Cache-Breakpoint: Alles davor kann zwischengespeichert und wiederverwendet werden, alles danach – das anfragebezogene Glossar, Beispiele und Ihr Eingabetext – wird bei jeder Anfrage neu gesendet.
Warum das Glossar nicht gecacht wird
Das Glossar wird pro Anfrage auf Basis des exakt zu übersetzenden Textes abgerufen und ändert sich deshalb von Anfrage zu Anfrage. Wenn es hinter dem Cache-Breakpoint bleibt, bleibt der Rest des Prompts wiederverwendbar – unabhängig davon, welche Glossarbegriffe eine bestimmte Anfrage einbezieht.
Warum gecachte Eingaben günstiger sind#
Die erste Anfrage für eine bestimmte Engine und Sprache schreibt das stabile Präfix in den Cache des Anbieters. Jede spätere Anfrage, die dieses Präfix wiederverwendet, liest es aus dem Cache, statt es von Grund auf neu zu verarbeiten. Anbieter berechnen Cache-Lesevorgänge nur zu einem Bruchteil des normalen Preises für Eingabe-Tokens, sodass der Großteil Ihres Prompts – der Teil, der sich nie ändert – nicht bei jeder Anfrage erneut zum vollen Preis abgerechnet wird.
Der Cache ist kurzlebig und wird vom Modellanbieter verwaltet, nicht von Ihrer Engine. Das heißt: Der Vorteil ist am größten, wenn Sie in kurzer Zeit viel mit derselben Engine und Sprache übersetzen. Dann treffen Anfragen ein, solange das Präfix noch warm ist, und werden direkt aus dem Cache gelesen.
Wenn Sie ein Regelwerk oder eine Markenstimme bearbeiten, ändert sich das Präfix. Dadurch wird mit der nächsten Anfrage ein neues geschrieben. Da beides Ihrer Organisation gehört und gemeinsam genutzt wird, macht eine einzige Änderung das Präfix für jede Engine ungültig, die darauf zugreift.
Caching läuft automatisch
Sie müssen nichts konfigurieren. Ob eine Anfrage Caching nutzt, hängt vom Modell ab, das sie verarbeitet – Anthropic- und Google-Modelle verwenden explizite Cache-Breakpoints, OpenAI-Modelle cachen lange Präfixe eigenständig, und einige Anbieter cachen überhaupt nicht. Die Engine wendet je nach Modell das passende Verhalten an.
Was Sie davon haben#
- Niedrigere Kosten – für das stabile Präfix zahlen Sie einmal den vollen Preis, danach bei jeder wiederholten Anfrage nur den reduzierten Preis für Cache-Lesevorgänge.
- Geringere Latenz – gecachte Tokens müssen nicht erneut verarbeitet werden, daher kommen warme Anfragen schneller zurück.
- Kein Setup – Caching ist standardmäßig aktiviert; in Ihrer Engine-Konfiguration müssen Sie nichts einschalten.
Die Vorteile summieren sich bei konstantem Traffic auf dieselbe Engine und Sprache – genau das typische Muster einer Lokalisierungs-Pipeline in Produktion, bei der dieselbe Konfiguration Anfrage um Anfrage verarbeitet.
Cache-Tokens in Ihrer Nutzung verstehen#
Jede Übersetzungsantwort enthält eine Nutzungsaufschlüsselung, die Cache-Tokens von neuen Eingaben trennt:
{
"usage": {
"inputTokens": 1200,
"outputTokens": 800,
"cacheReadTokens": 950,
"cacheWriteTokens": 0
}
}| Feld | Bedeutung |
|---|---|
inputTokens | Prompt-Tokens, die bei dieser Anfrage neu verarbeitet wurden |
outputTokens | Tokens, die vom Modell generiert wurden |
cacheReadTokens | Prompt-Tokens, die aus dem Cache des Anbieters bereitgestellt wurden. 0, wenn nichts gecacht wurde. |
cacheWriteTokens | Prompt-Tokens, die bei dieser Anfrage in den Cache geschrieben wurden – ein Cache-Miss / erster Aufruf. |
Eine erste Anfrage für eine Engine und Sprache zeigt typischerweise ein positives cacheWriteTokens (das Präfix wird geschrieben) und cacheReadTokens von 0. Folgeanfragen, solange der Cache noch warm ist, drehen das Verhältnis um: cacheReadTokens steigt und cacheWriteTokens fällt auf 0. Verfolgen Sie die aggregierte Token-Nutzung über Ihre Engines hinweg in Reports.
