Prompt Caching: Kosten der ersten und wiederholten Anfrage

Was das Experiment misst

Prompt Cache verringert die erneute Verarbeitung des unveränderten Eingabeteils. Das kann ein System Prompt, ein Satz Anweisungen, ein großes Dokument oder ein stabiler Text sein. Die veränderte Frage steht nach dem allgemeinen Prefix.

Das Experiment braucht drei Zustände:

A. erste Anfrage: stabiler Prefix + Frage 1
B. Cache Hit:     stabiler Prefix + Frage 2
C. Cache Miss:    geänderter Prefix + Frage 3

A und B nutzen dasselbe Modell, dieselben Einstellungen und dieselbe Cache-Policy. C ändert ein Zeichen im gecachten Bereich oder wird nach bestätigtem TTL-Ablauf ausgeführt. Wenn Modell, Output und Prompt-Länge zugleich geändert werden, lässt sich das Ergebnis nicht allein durch Cache erklären.

Möchten Sie die Formel mit Ihrer eigenen Nutzung prüfen? Erstellen Sie ein BetterToken-Konto und einen API Key, entnehmen Sie die aktuellen Sätze der Preisseite und führen Sie erste und wiederholte Anfrage mit demselben Prefix aus. Ordnen Sie Input, Output, anwendbare Cache-Token und Verbrauch im Dashboard zu. Prüfen Sie Cache- und TTL-Regeln zuerst in der API-Referenz und der Provider-Dokumentation.

OpenAI und Anthropic zählen Cache unterschiedlich

Dasselbe Wort Cache bezeichnet nicht denselben Mechanismus.

OpenAI Prompt Caching

In unterstützten OpenAI APIs und Modellen wird Caching automatisch auf einen passenden Prefix angewandt. Usage zeigt gecachte Tokens in den Input-Details. Der Code erstellt meist kein separates Cache-Objekt, soll aber den gemeinsamen Prefix unverändert halten. Exakte Schwellen, Retention und Rabatte prüfen Sie auf der offiziellen Prompt-Caching-Seite.

Anthropic Prompt Caching

Anthropic Messages erlaubt das Markieren einer Cache-Grenze über cache_control. Usage kann Cache-Erstellung und Lesen getrennt zeigen. Mindestgröße, TTL, Blockreihenfolge und Kosten hängen vom aktuellen Vertrag und Modell ab; prüfen Sie sie in der offiziellen Anthropic-Dokumentation.

Übertragen Sie Usage-Feldnamen oder Koeffizienten nicht zwischen beiden Protokollen. Notieren Sie in der Versuchstabelle genau die Kategorien, die der aktuelle Endpoint zurückgab.

Einen stabilen Prefix vorbereiten

Teilen Sie die Eingabe in zwei Teile:

STABLE_PREFIX
  Systemanweisungen
  Tool-Definitionen, falls nötig
  unverändertes Referenzdokument

DYNAMIC_SUFFIX
  aktuelle Nutzerfrage

Für den ersten Versuch entfernen Sie besser Tools und Streaming. Sie verhindern Cache nicht automatisch, fügen aber Variablen bei Usage und Output hinzu.

Der Prefix muss gemäß Regeln des gewählten Modells lang genug sein. Unter der Mindestschwelle ist kein Cache Hit das erwartete Ergebnis. Verlängern Sie ihn in Produktion nicht mit sinnlosem Text; verwenden Sie im Versuch ein echtes Dokument, das im Problem ohnehin wiederholt wird.

Speichern Sie vor dem Aufruf den Hash des gecachten Teils:

import hashlib

prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest()
print(prefix_hash)

Der Hash bestätigt, dass A und B denselben Prefix erhielten, ohne dessen Inhalt offenzulegen.

Welche Felder notiert werden sollen

Speichern Sie pro Anfrage:

• Zeitstempel und Request ID;
• Model ID und Protokoll;
• prefix_hash;
• reguläre Input Tokens;
• Cache-Erstellungs-/Write-Tokens, wenn der Vertrag sie ausweist;
• Cache-Read-/Cached-Tokens, wenn der Vertrag sie ausweist;
• Output Tokens;
• tatsächlichen Verbrauch;
• Status und Latenz nur als Diagnosefelder.

Latenz ist kein Preisbeweis. Eine schnelle Antwort kann ein Cache Miss sein, ein Hit kann in einer Warteschlange warten. Die Kostenfolgerung wird aus Usage und Tarif gezogen.

Formel der ersten Anfrage

Definieren wir:

I  — reguläre Input Tokens
W  — Cache Write / Creation Tokens
R  — Cache Read / Cached Tokens
O  — Output Tokens
Pi — regulärer Input-Preis pro 1.000.000 Tokens
Pw — Cache-Write-Preis pro 1.000.000 Tokens
Pr — Cache-Read-Preis pro 1.000.000 Tokens
Po — Output-Preis pro 1.000.000 Tokens

Dann lautet die Berechnung für einen Endpoint, der diese Kategorien trennt:

cost = I / 1_000_000 × Pi
     + W / 1_000_000 × Pw
     + R / 1_000_000 × Pr
     + O / 1_000_000 × Po

In der ersten Anfrage kann W größer als null sein und R ebenfalls größer als null. Bei automatischem Caching kann es andere Felder geben: Verwenden Sie uncached und cached input aus der tatsächlichen Usage und erfinden Sie keine Kategorie.

Der erste Request kann teurer als einer ohne Cache sein, wenn Cache-Erstellung getrennt abgerechnet wird. Das ist nicht automatisch ein Fehler. Der Nutzen entsteht erst nach ausreichend vielen Reads.

Formel für Wiederholung und Break-even-Punkt

Sei:

C0 — Kosten der ersten Anfrage, die Cache erstellt
Ch — Kosten einer Anfrage mit Cache Hit
Cu — Kosten einer vergleichbaren Anfrage ohne Cache
n  — Gesamtzahl der Anfragen

Serie mit einer Erstellung und n - 1 Hits:

C_cached(n) = C0 + (n - 1) × Ch
C_uncached(n) = n × Cu

Das kleinste n, bei dem Cache sich lohnt, ist die erste ganze Zahl mit:

C_cached(n) < C_uncached(n)

Setzen Sie keine Preise eines anderen Modells in die Formel ein. Ist Ch >= Cu, bringt die aktuelle Konfiguration keine Einsparung; prüfen Sie Cache Hit, Prefix-Größe und Tarifkategorien.

Kontrollierter Cache Miss

Führen Sie nach A und B C aus. Ändern Sie nur den gecachten Prefix und behalten Sie Modell sowie erwartete Antwortlänge. Die Cache-Read-Kategorie muss gemäß Vertrag sinken oder verschwinden; normale Verarbeitung oder Cache-Erstellung muss sich ändern.

Gründe für unerwarteten Miss:

• Ein Symbol oder Leerzeichen im Prefix hat sich geändert.
• Tool-Definitionen kamen in anderer Reihenfolge.
• Systemblock wurde verschoben.
• Modell oder Endpoint änderte sich.
• Die Anfrage lag außerhalb der TTL.
• Prefix war kürzer als Mindestschwelle.
• Client serialisiert dieselben Daten in anderer Reihenfolge.

Eine Änderung der Frage nach stabilem Prefix ist erwartet. Eine Änderung im Prefix erzeugt eine andere Cache-Identität.

Warum wir kein „Ergebnis in Dollar“ veröffentlichen

Dieser Artikel hat keinen Zugriff auf API Key und Usage eines bestimmten Kontos; er gibt daher kein berechnetes Beispiel für einen ausgeführten Test aus. Preise, Modelle und Caching-Regeln ändern sich. Eine zufällige Zahl würde einen reproduzierbaren Test rasch zu veralteter Werbung machen.

Für Ihr Ergebnis:

1. Wählen Sie ein Modell und ein Protokoll.
2. Öffnen Sie die aktuelle BetterToken-Preisseite.
3. Führen Sie A, B und C aus.
4. Übernehmen Sie Usage und Verbrauch aus dem Dashboard.
5. Berechnen Sie C0, Ch, Cu und Break-even-Punkt.
6. Speichern Sie Prüfdatum und prefix_hash.

FAQ

Warum kann die erste Cache-Anfrage mehr kosten?

Manche Protokolle berechnen Cache-Erstellung/Write getrennt. Der anfängliche Aufschlag wird erst durch wiederholte Cache Reads ausgeglichen. Prüfen Sie den aktuellen Preis des konkreten Modells.

Warum erhielt die Wiederholung keinen Cache Hit?

Prüfen Sie Prefix-Länge und Unveränderlichkeit, Blockreihenfolge, Modell, Endpoint, TTL und Mindestschwelle. Vergleichen Sie prefix_hash.

Lassen sich OpenAI und Anthropic mit einem Usage-Feld vergleichen?

Nein. Mechanismen, Konfigurationen und Kategorienamen unterscheiden sich. Normalisieren Sie Werte in eigene Felder I, W, R und O, behalten Sie aber die Originalfelder.

Senkt Cache immer Kosten?

Nein. Ein kurzer Prefix, seltene Wiederholungen, häufige Änderungen und niedrige Hit-Rate können die Erstellungskosten nicht amortisieren.

Wo prüfe ich die tatsächliche BetterToken-Abbuchung?

Im Dashboard nach Zeit, Modell und Request-Status. Den Tarif entnehmen Sie der Preisseite, Caching-Regeln der Dokumentation des jeweiligen Protokolls.