Ein Cache hilft nur, wenn die nächste Anfrage schneller ist. Wenn Ihre durchschnittliche Leerlauflücke zwischen Anfragen beträgt G Minuten und die Cache-TTL beträgt T Minuten beträgt die Steady-State-Trefferquote 1 − e−T/g. Ein 5-Minuten-Cache und ein 1-Stunden-Cache für genau denselben Code können allein aufgrund des Timings völlig unterschiedliche Trefferraten haben – und ein Fehlschlag zahlt die Schreibprämie statt des billigen Lesevorgangs.
Kein Cache vs. 5-Minuten- vs. 1-Stunden-TTL
Gleicher Verkehr, drei Strategien. Die Trefferquote wird aus Ihrer Leerlauflücke berechnet. Ein Fehlschlag zahlt die Schreibprämie (1,25× für 5 Minuten, 2,0× für 1 Stunde), ein Treffer zahlt die Leserate.
| Strategie | Cache-Trefferquote | Kosten / Anfrage | Kosten/Monat | vs kein Cache |
|---|
Warum die Trefferquote ein Timing-Problem ist, keine Vermutung
Prompte Zwischenspeicherung von Rechnungen in drei Staaten: a Cache schreiben (zum ersten Mal, wenn ein Präfix angezeigt wird oder nachdem es abgelaufen ist) mit einem Aufschlag über dem Basis-Token-Preis, a Cache lesen (das Präfix ist noch aktiv) mit einem hohen Rabatt und einfache, nicht zwischengespeicherte Token zum vollen Preis. In welchem Bundesstaat Sie bei einer bestimmten Anfrage landen, hängt von einer Sache ab: Ist die vorherige Anfrage so lange her, dass das zwischengespeicherte Präfix noch aktiv ist? Modellieren Sie die Leerlauflücke zwischen Anfragen als gedächtnislos – die Standardannahme für unabhängige Ankünfte – und die Wahrscheinlichkeit, dass die Lücke kürzer als die TTL ist T ist genau 1 − e−T/g, Wo G ist Ihr durchschnittlicher Abstand. Das ist Ihre Trefferquote. Aus diesem Grund erzielt ein Support-Bot, der alle paar Minuten eine Nachricht bearbeitet, bei einem 1-Stunden-Cache eine hohe Trefferquote, bei einem 5-Minuten-Cache jedoch eine schlechte, wenn er denselben Code ausführt.
Der Kompromiss zwischen 5 Minuten und 1 Stunde
Der 1-Stunden-Cache ist nicht unbedingt besser – er kostet mehr schreiben (ca. 2,0× Basis gegenüber 1,25× für die 5-Minuten-Stufe). Die Frage ist, ob durch die längere Lebensdauer genügend teure Fehler eingespart werden, um die teureren Schreibvorgänge zu bezahlen. Wenn Ihre Leerlauflücke im Vergleich zu fünf Minuten klein ist (enge Bursts), erhalten Sie mit dem günstigen 5-Minuten-Schreibvorgang bereits eine Trefferquote von nahezu 100 %, und der 1-Stunden-Aufschlag ist pure Verschwendung. Wenn Ihre Lücke nur wenige Minuten beträgt, läuft der 5-Minuten-Cache ständig ab und zahlt den Schreibvorgang bei fast jeder Anfrage erneut, während der 1-Stunden-Cache warm bleibt – sodass die 1-Stunden-Stufe trotz des höheren Schreibmultiplikators am Ende günstiger ist. Die Frequenzweiche hängt ganz von Ihnen ab G, weshalb die Annahme einer pauschalen Trefferquote in die Irre führt. Dieses Tool findet den Crossover für Ihre Zahlen.
Was sich im Jahr 2026 geändert hat und wie man darauf reagiert
Wenn ein Anbieter die Standard-Cache-Lebensdauer verkürzt – die weit verbreitete Änderung von etwa einer Stunde auf fünf Minuten – verschiebt sich jede Arbeitslast mit zeitlich begrenzten Anfragen stillschweigend von überwiegend Lesevorgängen auf überwiegend Schreibvorgänge, und die Rechnungen steigen ohne Codeänderung um 30–60 %. Zwei Antworten funktionieren: Halten Sie den Cache mit einer leichten Heartbeat-Anfrage innerhalb des kürzeren Fensters warm oder entscheiden Sie sich explizit für eine längere TTL-Stufe, wenn sich die Schreibprämie amortisiert. Entscheiden Sie, welche, indem Sie oben Ihre tatsächliche Leerlauflücke und Ihr Anforderungsvolumen ermitteln und dann mit der vergleichen Rechner für schnelle Caching-Einsparungen für die Flat-Hit-Rate-Ansicht und die Cache-Schreib-Break-Even-Rechner für den Fall der einmaligen Wiederverwendung.
So funktioniert dieser Rechner
Es berechnet Ihre Cache-Trefferquote im stationären Zustand als 1 − e^(−T/g) aus Ihrer durchschnittlichen Leerlauflücke g und der TTL T jeder Stufe (5 Minuten oder 60 Minuten) und bewertet dann jede Anfrage als eine Mischung aus Cache-Lesevorgängen (Treffer) und Cache-Schreibvorgängen (Misses) auf dem zwischengespeicherten Präfix sowie nicht zwischengespeicherten Token zum vollen Preis. Es vergleicht No-Cache, die 5-Minuten-Stufe und die 1-Stunden-Stufe und meldet die günstigste für Ihren Datenverkehr und Ihr Volumen.
Häufig gestellte Fragen
Wie erfahre ich meine tatsächliche Trefferquote im Prompt-Cache?
Sie leiten es daraus ab, wie oft Anfragen eingehen und wie lange der Cache aktiv ist. Bei einer durchschnittlichen Leerlauflücke von g Minuten und einer Cache-TTL von T Minuten beträgt die Trefferquote im stationären Zustand 1 − e^(−T/g). Derselbe Code kann rein aus zeitlichen Gründen eine Trefferquote von 10 % bei einem 5-Minuten-Cache und eine Trefferquote von 95 % bei einem 1-Stunden-Cache haben.
Ist der einstündige Prompt-Cache die höheren Schreibkosten wert?
Es hängt von Ihrer Leerlauflücke ab. Der 1-Stunden-Cache schreibt mit ~2× Basis gegenüber ~1,25× für 5 Minuten, aber eine längere TTL vermeidet teure Fehler. Bei Anfragen im Minutenabstand wird in der Regel die 1-Stunden-Stufe bevorzugt; Enge Bursts im Abstand von ein paar Sekunden sind beim günstigeren 5-Minuten-Schreibvorgang in Ordnung.
Warum ist meine Prompt-Caching-Rechnung im Jahr 2026 gestiegen?
Weil die Standard-Cache-Lebensdauer kürzer geworden ist. Durch die Verschiebung der Standard-TTL von etwa 1 Stunde auf etwa 5 Minuten wird jeglicher Datenverkehr mit Leerlauflücken von mehr als ein paar Minuten nicht im Cache gespeichert und zahlt die Schreibprämie zurück, wodurch sich die Rechnungen für verteilte Arbeitslasten stillschweigend um 30–60 % erhöhen.