LLM-Prompt-Caching kann eine Premium-API bei wiederholtem Kontext günstiger machen als eine unzureichend ausgelastete lokale GPU. Es kann aber auch überhaupt keine Einsparung bringen. Ausschlaggebend sind nicht die Listenpreise der Modelle, sondern Präfix-Wiederverwendung, Kosten für das Schreiben des Caches, Rabatte für Lesezugriffe, Ablauf, Verdrängung, Auslastung und die Kosten fehlgeschlagener Arbeit.
Zielgruppe: Fortgeschrittene Praktiker, die für LLM-Plattformkosten, Latenz oder Infrastrukturentscheidungen verantwortlich sind.
Die praktische Regel: Messen Sie Cache-Lesezugriffe und Invalidierungen in Ihrem realen Workload, bevor Sie GPU-Kapazität kaufen. Eine neue Fallstudie zu einem Enterprise-Coding-Agenten unterstreicht diesen Punkt mit einem auffälligen Cache-Hit-Ergebnis von 99,3 %. Die Autoren untersuchten jedoch eine Person, zwei aufeinanderfolgende Zeiträume von 28 Tagen, unterschiedliche Modellfamilien und eine produktive Codebasis. Betrachten Sie die Studie als Anstoß zur Messung, nicht als Urteil über Cloud gegenüber lokal.
Was LLM-Prompt-Caching verändert
Ein LLM verarbeitet Eingaben in zwei groben Phasen:
Auf der Serving-Ebene kann Prefix-Caching wiederverwendbare Attention- oder Key-Value-Zustände für ein Prompt-Präfix speichern. Eine spätere Anfrage mit demselben geeigneten Präfix kann einen Teil der wiederholten Prefill-Arbeit überspringen. Das sich ändernde Suffix muss weiterhin verarbeitet werden, und das Modell dekodiert weiterhin eine neue Antwort.
Diese Unterscheidung ist wichtig. Prompt-Caching ist kein Response-Caching. Es gibt keine gespeicherte Antwort zurück, verkürzt die Ausgabe nicht, repariert keinen schwachen Prompt und garantiert keine geringere End-to-End-Latenz. Es zielt hauptsächlich auf wiederholte Eingabeberechnung ab und verbessert häufig die Time to First Token.
Das ursprüngliche Prompt-Cache-Paper formalisierte wiederverwendbare Prompt-Module und berichtete über Verbesserungen der Time to First Token von 8× auf GPUs bis zu 60× auf CPUs in einem Prototyp. Das sind Ergebnisse der im Paper getesteten Modelle, Hardware, Prompts und Implementierung – keine Prognose für aktuelle kommerzielle APIs.
Die Fallstudie mit 99,3 %: Nützliche Evidenz mit engen Grenzen
Ein Preprint vom Juli 2026, *Inference Economics of Enterprise Coding Agents*, verglich zwei zusammenhängende Zeiträume von jeweils 28 Tagen in einem produktiven Monorepo:
Die Autoren analysierten LLM-Telemetrie und Git-Historie. Für den API-Zeitraum berichteten sie eine Prompt-Cache-Hit-Rate von 99,3 %, effektive API-Kosten von 0,573 $ pro Million verarbeiteter Tokens und amortisierte Stückkosten von 2,83 $ für die gemeinsam genutzte On-Premise-Zuweisung. Die API verarbeitete 16,9-mal mehr Tokens, während die lokale Hardware nur gering ausgelastet war. Daher klären diese normalisierten Tokenpreise die Infrastrukturfrage nicht.
Die Ergebnisse zu den Gesamtkosten weisen je nach Zuweisung in unterschiedliche Richtungen. Unter den Annahmen des Papers zu taiwanesischem Markt und Arbeitskosten senkte gemeinsam genutzte lokale Kapazität die geschätzten tatsächlichen Gesamtbetriebskosten um 40,1 %. Eine dedizierte lokale Reservierung kostete 43,8 % mehr als die gecachte API. Der lokale Zeitraum war außerdem mit einer höheren Fix-Commit-Quote verbunden: 74,9 % gegenüber 45,9 %.
Was die Autoren gemessen haben
Was sie daraus ableiteten
Was die Studie nicht belegen kann
Das Design war nicht randomisiert und sequenziell. Codebasis, Entwickler, Aufgabenmix und Arbeitsweisen könnten sich zwischen den Zeiträumen verändert haben. Modellfähigkeit, Serving-Stack, Harness und Quantisierung wurden gleichzeitig geändert. Der Erstautor kannte die Hypothese. Das Fix-Commit-Label ist ein Proxy und keine unabhängige Fehlerprüfung. Rohdaten aus der Produktion und die vollständige Replay-Umgebung wurden nicht veröffentlicht.
Die belastbare Schlussfolgerung ist enger als die Schlagzeilenzahlen: Prompt-Wiederverwendung und GPU-Auslastung können Listenpreisvergleiche dominieren, während Reparaturarbeit Token-Einsparungen dominieren kann.
Definieren Sie den Messvertrag, bevor Sie eine Hit-Rate berechnen
„Cache-Hit-Rate“ ist mehrdeutig, solange der Nenner nicht ausdrücklich festgelegt ist. Ein Dashboard kann gecachte Tokens durch geeignete Präfix-Tokens teilen. Ein anderes kann Anfragen mit irgendeinem Cache-Lesezugriff durch alle Anfragen teilen. Ein drittes kann gecachte Tokens als Anteil der gesamten Eingabe ausweisen, einschließlich eines nicht gecachten Suffixes.
Verwenden Sie getrennte Metriken:
Halten Sie vom Provider gemeldete Nutzungsfelder getrennt von selbst abgeleiteten Metriken. Tokenanzahlen können sich außerdem durch Model-Tokenizers und Templates ändern; der Erklärartikel zur LLM-Tokenizer-Steuer→ zeigt, warum rohe Zeichenanzahlen ein schwacher Ersatz sind.
Das aktuelle Verhalten von API und Self-Hosting ist nicht einheitlich
Der folgende Überblick wurde am 30. Juli 2026 geprüft. Überprüfen Sie die verlinkte Dokumentation erneut, bevor Sie ihn für Beschaffung oder Abrechnung verwenden.
| Plattform | Cache-Steuerung | Beobachtbares Signal | Operative Einschränkung |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 unterstützt implizites und explizites Prompt-Caching | `cached_tokens` und `cache_write_tokens` | Die aktuelle GPT-5.6-Dokumentation setzt explizite Schreibvorgänge mit dem 1,25-Fachen der nicht gecachten Eingabe an; Lesezugriffe sind rabattiert |
| Anthropic API | Automatisches Caching oder explizite Block-Breakpoints | Getrennte Nutzung für Cache-Erstellung und Lesezugriffe | Die Präfixreihenfolge lautet Tools, System, dann Messages; die Standard-TTL beträgt 5 Minuten, mit einer kostenpflichtigen Option für 1 Stunde |
| Gemini Interactions API | Implizites Context-Caching ist für Gemini 2.5 und neuere Modelle standardmäßig aktiviert | `usage.total_cached_tokens` | Gemeinsame Inhalte gehören an den Anfang; die aktuellen Mindestwerte reichen je nach Modell von 2.048 bis 4.096 Tokens |
| vLLM | Automatic Prefix Caching kann in der Engine aktiviert werden | Engine-Metriken und Anfrage-Timing | Ihr Team trägt die Verantwortung für Kapazität, Verdrängung, Isolation, Upgrades und Observability |
OpenAIs aktuelle Modell-Dokumentation weist Nutzer von GPT-5.6 an, Cache-Schreib- und Lesezugriffe zu überwachen, da explizite Schreibvorgänge mehr kosten als nicht gecachte Eingaben. Anthropics Dokumentation zum Prompt-Caching dokumentiert 5-Minuten-Schreibvorgänge zum 1,25-Fachen der Basis-Eingabe, 1-Stunden-Schreibvorgänge zum 2-Fachen und Cache-Lesezugriffe zum 0,1-Fachen. Googles Leitfaden zum Context-Caching erklärt, dass implizites Caching in der Interactions API automatisch erfolgt und gecachte Tokens in der Nutzung ausgewiesen werden. Das Beispiel zu Automatic Prefix Caching in vLLM zeigt dasselbe Prinzip gemeinsam genutzter Präfixe in einer Self-Hosting-Engine.
Diese Implementierungen teilen ein Prinzip, aber keinen übertragbaren Abrechnungsvertrag. Mindestlängen für Präfixe, Cache-Scope, Aufbewahrung, Speicherkosten, Nutzungsfelder und Isolation können sich unterscheiden.
*Messen Sie den Cache, bevor Sie die Infrastruktur ändern: Stabilisieren Sie das Präfix, führen Sie Kalt- und Warmtests durch, erzwingen Sie eine Invalidierung und vergleichen Sie anschließend die Gesamtkosten.*
Eine Break-even-Formel für das wiederverwendbare Präfix
Sei:
Unter Auslassung von Speicherkosten beträgt die durchschnittliche Gebühr für das wiederverwendbare Präfix pro Anfrage:
`(W + (N - 1) × R) / N`
Caching ist günstiger als die nicht gecachte Verarbeitung dieses Präfixes, wenn gilt:
`N > (W - R) / (U - R)`
Diese Gleichung isoliert das wiederverwendbare Präfix. Sie schließt das sich ändernde Suffix, Output-Tokens, die Mindestlänge für cachebare Inhalte, Speichergebühren, durch Verdrängung verursachte Fehlschläge, Konkurrrenzeffekte, Engineering-Arbeit und fehlgeschlagene Aufgaben aus.
Als zeitbezogenes Beispiel galten für Anthropics 5-Minuten-Multiplikatoren am 30. Juli 2026 `U = 1`, `W = 1.25` und `R = 0.1`. Die Schwelle für die Eingabe allein lautet `N > 1.28`; damit amortisiert die zweite Nutzung innerhalb der Cache-Lebensdauer die höhere Schreibgebühr für dieses geeignete Präfix. Das bedeutet nicht, dass zwei API-Aufrufe insgesamt Caching profitabel machen. Ein kurzes Präfix, ein langes nicht gecachtes Suffix, ein Cache-Miss oder eine teure Ausgabe kann die Einsparung aufzehren.
Verwenden Sie die Gleichung als Unit-Test für Ihr Kostenmodell. Ersetzen Sie jede Variable durch Werte aus dem aktuellen Provider-Vertrag und Ihrem gemessenen Workload.
Warum scheinbar stabile Prompts den Cache verfehlen
Die meisten Cache-Misses beginnen bei der Prompt-Erstellung, nicht im Modell.
Flüchtige Daten erscheinen zu früh
Ein Zeitstempel, eine Anfrage-ID, eine zufällige Nonce, ein Benutzername oder ein neues Retrieval-Ergebnis am Anfang verändert jedes nachfolgende Token. Platzieren Sie stabile Tools, Richtlinien, Templates und wiederverwendbare Dokumente zuerst. Verschieben Sie anfragespezifische Daten hinter das wiederverwendbare Präfix oder den expliziten Breakpoint.
Die Serialisierung ändert sich zwischen Anfragen
JSON-Schlüsselreihenfolge, Leerzeichen, Tool-Reihenfolge und Dokumentreihenfolge können ein ansonsten gleichwertiges Präfix verändern. Verwenden Sie deterministische Serialisierung. Sortieren Sie Tool-Definitionen und abgerufene Dokumente, sofern semantisch möglich, nach stabilen Identifikatoren.
Der Context-Manager zerstört die Präfixkontinuität
Aggressives Pruning kann Eingabe-Tokens sparen und gleichzeitig gecachte Präfixe invalidieren. TokenPilot, ein Work-in-Progress-Preprint vom Juni 2026, behandelt dies als gemeinsames Optimierungsproblem. Die Autoren stabilisieren die Aufnahme und verzögern die Verdrängung, bis der Kontext seinen Aufgabenwert verliert. Sie berichten über Kostenreduktionen von 56 % bis 87 % über zwei Benchmarks und zwei Ausführungsmodi hinweg, bei gleichzeitig wettbewerbsfähiger Aufgabenleistung. Diese Ergebnisse müssen über die Workloads des Papers und die LightMem2-Integration hinaus repliziert werden.
Der Cache läuft ab oder wird unter realer Last verdrängt
Ein warmer lokaler Test kann TTL-Grenzen und Kapazitätsdruck verbergen. Self-Hosted-Prefix-Caching unterliegt wie andere KV-Cache-Systeme derselben Realität begrenzten Speichers. Der ausführlichere Leitfaden zur KV-Cache-Verdrängung→ erklärt, warum die Wiederverwendung bei steigender Nebenläufigkeit und Sequenzlänge zusammenbrechen kann.
Das Modell oder Template ändert sich
Eine Modellversion, ein Tokenizer, ein Chat-Template, eine Einstellung für Bilddetails, ein Tool-Schema oder eine Sicherheitspräambel kann ein neues Präfix erzeugen. Behandeln Sie Releases und Prompt-Migrationen als Cache-Invalidierungsereignisse.
Aktuelle vLLM-Engineering-Diskussionen veranschaulichen diesen Druck. Ein Vorschlag zur kontextbewussten Aufbewahrung argumentiert, dass nebenläufige Agent-Workloads wertvolle Präfixe verdrängen können, während ein Vorschlag für einen semantischen KV-Cache Wiederverwendung über exakte Übereinstimmungen hinaus untersucht. Dies sind offene Designdiskussionen, keine Produktionsgarantien oder Messungen zur Verbreitung.
Ein reproduzierbarer Prompt-Cache-Test
Verwenden Sie denselben Aufgabensatz, den Sie zum Benchmarking von AI-Modellen für echte Arbeit→ einsetzen würden. Der Cache-Test ergänzt kontrollierte Präfixänderungen und eine Infrastrukturkostenrechnung.
1. Einen repräsentativen Workload einfrieren
Wählen Sie 30 bis 100 Aufgaben aus dem Produktionsverkehr oder einem datenschutzsicheren Replay-Datensatz. Bewahren Sie die reale Verteilung von Präfixlänge, Suffixlänge, Ausgabelänge, Tools, Dokumenten und Nebenläufigkeit. Definieren Sie den Aufgabenerfolg, bevor Sie den Test durchführen.
Optimieren Sie nicht anhand eines einzigen langen Demo-Prompts. Ein cachefreundlicher Support-Workflow und ein cachefeindlicher Research-Workflow können eine gegensätzliche Wirtschaftlichkeit haben.
2. Stabile und volatile Inhalte trennen
Kennzeichnen Sie jedes Prompt-Segment als:
Erstellen Sie einen deterministischen Prompt-Assembler. Zeichnen Sie eine undurchsichtige Präfixversion oder einen keyed Hash auf, damit jede Anfrage angibt, welches Präfix sie wiederzuverwenden versucht hat. Platzieren Sie keine Geheimnisse oder rohen Kundendaten in Logs.
3. Eine kontrollierte Matrix ausführen
Messen Sie für jede Aufgabenkategorie:
| Test | Änderung | Beantwortete Frage |
|---|---|---|
| --- | --- | --- |
| Kalt | Neues Präfix ohne wiederverwendbaren Zustand | Wie hoch sind die grundlegenden Schreib- oder Prefill-Kosten? |
| Warm | Identisches geeignetes Präfix | Meldet der Provider oder die Engine einen Lesezugriff? |
| Frühe Mutation | Ein Token am Anfang ändern | Wie viel Wiederverwendung geht verloren? |
| Späte Mutation | Nur das Suffix ändern | Bleibt das stabile Präfix wiederverwendbar? |
| TTL-Grenze | Vor und nach dem Ablauf wiederholen | Wie oft wird der Produktionsverkehr rechtzeitig eintreffen? |
| Nebenläufigkeit | Parallele Anfragen schrittweise erhöhen | Verringern Verdrängung oder Scheduling die Wiederverwendung? |
| Versionsänderung | Modell, Tools oder Template ändern | Welche Deployments invalidieren den Cache? |
Führen Sie genügend Wiederholungen durch, um Verteilungen statt einer einzigen Latenzzahl zu berichten. Trennen Sie p50 und p95 der Time to First Token von der End-to-End-Latenz.
4. Abrechnung und Qualität gemeinsam erfassen
Erfassen Sie:
Die Wiederverwendung eines Zustands für ein exaktes Präfix sollte wiederholte Prefill-Berechnung vermeiden; sie ersetzt jedoch keine Qualitätsprüfung. Eine Änderung von Modell, Quantisierungsstufe, Routing-Richtlinie oder Serving-Stack kann die Ausgabequalität verändern, selbst wenn der Cache-Mechanismus korrekt funktioniert.
5. Drei Kostenperspektiven berechnen
Wenn die lokale Option von dauerhaft hoher Auslastung abhängt, testen Sie diese Auslastungsannahme. Ein GPU-Kauf wird nicht wirtschaftlich, nur weil eine Tabelle jede ungenutzte Stunde künftiger Nachfrage zuschreibt.
Cloud-API, lokale GPU oder hybrides Routing?
Die Entscheidung ist selten binär.
Eine gecachte API bevorzugen, wenn
Gemeinsam genutzte lokale Kapazität bevorzugen, wenn
Hybrides Routing verwenden, wenn
Kostenlose oder subventionierte Endpoints können bei Prototypen helfen, beseitigen aber nicht die Notwendigkeit einer Workload-Abrechnung. Die Fallstudie zur Free AI Models API→ ist ein nützlicher Ausgangspunkt, um Zugangspreis und Produktionszuverlässigkeit getrennt zu betrachten.
Prompt-Cache-Sicherheit braucht einen eigenen Test
Caching erzeugt datenabhängiges Timing: Ein wiederverwendetes Präfix kann sein erstes Token schneller zurückgeben als ein Miss. Ein ICML-2025-Audit verwendete Timing-Messungen, um reale APIs zu testen, und berichtete während des Untersuchungszeitraums Hinweise auf Cache-Sharing zwischen Nutzern bei sieben Providern.
Dieses Ergebnis ist historische, providerspezifische Evidenz. Es belegt nicht, wie diese Dienste ihre Caches heute isolieren.
Fragen Sie aktuelle Provider und interne Plattformverantwortliche:
Führen Sie bei Self-Hosted-Systemen Tests zu Timing und Verdrängung zwischen Tenants durch. Protokollieren Sie wiederverwendbare sensible Präfixe nicht allein zur Fehlersuche am Cache. Speichern Sie Hashes, Tokenanzahlen, Versionskennungen und richtlinienkonforme Metadaten.
Die Entscheidungs-Checkliste
Genehmigen Sie keinen GPU-Kauf und keine API-Migration allein anhand von Listenpreisen. Verlangen Sie:
Prompt-Caching ist wertvoll, weil wiederholter Kontext häufig vorkommt. Als Beschaffungsabkürzung ist es riskant, weil die Wiederverwendung vom Workload abhängt. Messen Sie das Präfix, messen Sie die Misses und vergleichen Sie anschließend die Gesamtkosten.
Prüfung zentraler Aussagen
| Wichtige Aussage | Evidenztyp | Prüfung und Einschränkung |
|---|---|---|
| --- | --- | --- |
| Die Coding-Agent-Studie berichtete eine Prompt-Cache-Hit-Rate von 99,3 % | Primärforschung, Preprint vom Juli 2026 | Eine Person, eine Codebasis, zwei aufeinanderfolgende Zeiträume; das Ergebnis ist nicht übertragbar |
| Das Paper berichtete 0,573 $ pro Million verarbeiteter API-Tokens gegenüber 2,83 $ pro Million für die gemeinsam genutzte lokale Zuweisung | Primärforschung | Die API verarbeitete 16,9-mal mehr Tokens und die lokale Auslastung war gering; Gesamtausgaben und TCO sind aussagekräftigere Vergleiche |
| Gemeinsam genutzte lokale Kapazität sparte 40,1 % TCO, während dedizierte Kapazität 43,8 % mehr kostete | Primärforschung | Abhängig von den Annahmen des Papers zu Hardware, Zuweisung, taiwanesischem Markt, Arbeitskosten und Qualität |
| Prefix-Caching verwendet Attention-Zustände für wiederholte Prompt-Segmente wieder | Begutachtete Primärforschung und offizielle Engine-Dokumentation | Es reduziert wiederholte Prefill-Arbeit; Decoding und die Arbeit am sich ändernden Suffix bleiben bestehen |
| Anthropics 5-Minuten-Cache-Schreibvorgänge kosten das 1,25-Fache und Lesezugriffe das 0,1-Fache der Basis-Eingabe | Offizielle Dokumentation, geprüft am 30. Juli 2026 | Preise und unterstützte Modelle können sich ändern; das Beispiel schließt Ausgabe, Suffix und Speicher aus |
| Implizites Gemini-Caching ist für Gemini 2.5 und neuere Modelle in der Interactions API standardmäßig aktiviert | Offizielle Dokumentation, aktualisiert am 7. Juli 2026 | Mindestanzahlen von Tokens und Unterstützung für explizite Caches unterscheiden sich je nach API und Modell |
| TokenPilot berichtete Kostenreduktionen von 56 % bis 87 % über die getesteten Einstellungen hinweg | Primärforschung, Work-in-Progress-Preprint | Zwei Benchmarks und eine spezifische Integration; unabhängige Replikation ist erforderlich |
| Prompt-Cache-Timing kann Informationen offenlegen, wenn der Cache-Scope Nutzergrenzen überschreitet | Primärforschung, ICML 2025 | Historisches Audit der getesteten Provider; daraus darf nicht auf das aktuelle Verhalten von Anbietern geschlossen werden |