Prompt Caching vollständiger Leitfaden: Prinzipien, Kostenmodell und Umsetzung

Welches Problem löst Prompt Caching

Ein erheblicher Teil der Eingaben bei den meisten LLM-Aufrufen ist jedes Mal identisch: System-Prompts, Few-Shot-Beispiele, abgerufene feste Dokumente, Tool-Definitionen (Tool-Schema). Bei normaler Abrechnung wird für diese wiederholten Inhalte jedes Mal erneut für Eingabe-Token bezahlt und jedes Mal die Attention erneut berechnet.

Der Ansatz von Prompt Caching ist direkt: Der Server speichert das Berechnungsergebnis dieses Präfixes; ist das Präfix bei der nächsten Anfrage vollständig identisch, wird es direkt wiederverwendet und nur der neue Teil neu berechnet. Anthropic positioniert es in der [Prompt-Caching-Dokumentation](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) als Mittel zur Senkung von Latenz und Kosten; auf OpenAI-Seite entsprechen dem automatisches Prompt Caching und Batch-Rabatte.

Welche Szenarien wirklich Geld sparen

Prompt Caching ist kein Schalter, der beim Einschalten sofort spart. Es gibt eine klare Gewinnschwelle: Anzahl der Wiederverwendungen desselben Präfixes × Präfixlänge > zusätzlicher Aufwand für das Schreiben des Caches.

• Langer System-Prompt + mehrstufiger Dialog: System-Prompt mit mehreren Tausend Token und viele Gesprächsrunden lohnen sich fast immer.
• RAG + feste Dokumentensammlung: Unveränderliche Richtlinien-/Wissensdokumente ins Präfix, nur die Benutzerfrage variiert.
• Code-Agent / Tool-Aufrufe: Tool-Schema und Repository-Strukturbeschreibung wiederholen sich meist bei jedem Aufruf.
• Einmalige Aufrufe mit kurzem Präfix: Der Aufwand für das Schreiben des Caches kann höher sein als die Ersparnis; nicht zwangsweise cachen.

Fünf häufige Fehler, die den Cache ungültig machen

• Zeitstempel oder Zufalls-IDs im Präfix: Selbst ein Date.now() an einer festen Stelle verändert das gesamte Präfix.
• Dynamisches Zusammensetzen des System-Prompts: Verschiedene Nutzer erhalten verschiedene Präfixe, die Trefferquote wird nahezu auf 0 verdünnt.
• Zusammenfassen der Nachrichtenhistorie: Wird pro Runde umgeschrieben, ist das Präfix nicht mehr stabil.
• Benutzereingabe an den Anfang stellen: Der häufigste Strukturfehler; Variablen sollten möglichst weit hinten stehen.
• Nur die Rechnung betrachten, nicht die Trefferquote: Ohne Trefferquoten-Kennzahl lässt sich der Nutzen des Caches nicht zuordnen.

Dieselbe Cache-Strategie über mehrere Modelle hinweg wiederverwenden

Wenn Ihr Produkt gleichzeitig Claude und GPT nutzt, sind die Cache-Semantiken der Anbieter nicht vollständig identisch (wer Cache-Breakpoints deklariert, wie lang die TTL ist, wie abgerechnet wird). Diese Anpassung hinter einem einheitlichen Gateway zu bündeln hat den Vorteil, dass der Anwendungscode nur eine Prompt-Struktur pflegt und beim Modellwechsel nichts neu geschrieben werden muss.

Das Gateway von Admesh hält gegenüber den nachgelagerten Diensten das OpenAI-kompatible Protokoll ein, sodass dieselbe Prompt-Struktur durch Ändern nur des model-Feldes zwischen Anbietern gewechselt werden kann; die Abrechnungslogik für Cache-Treffer wird einheitlich in den usage-Details der Rechnung ausgewiesen, ohne dass für jeden Anbieter separat die Abrechnung angebunden werden muss.

Abrechnungseinheiten und Cache-Token-Erläuterung ansehen →

Umsetzungs-Checkliste

1. Den Prompt in drei Teile zerlegen: 'stabiles Präfix / halbstabiler Teil / Benutzereingabe', wobei der stabile Teil vorne steht.
2. Sicherstellen, dass im stabilen Präfix keine Zeitstempel, Zufallszahlen oder Benutzer-IDs vorkommen.
3. In der Rechnung Cache-Lese- und -Schreib-Token separat erfassen und in eine echte Trefferquote umrechnen.
4. Mit einem festen Satz von Evaluierungsanfragen regelmäßig regressieren, um sicherzustellen, dass Prompt-Änderungen die Trefferquote nicht einbrechen lassen.
5. Eine Untergrenze für den Cache-Nutzen festlegen (z. B. unter 5 % die Prompt-Struktur zurückrollen), um Optimierung um der Optimierung willen zu vermeiden.