Einheiten
1. Grundlagen der LLM-API: Anforderungs-, Antwort- und Nachrichtenrollen 2. Token- und Preislogik 3. Streaming und lange Antworten 4. Systemaufforderung und Modellparameter 5. Modelauswahl: Das richtige Model für den richtigen Job 6. Kostenoptimierung: Prompt Caching 7. Batch- und asynchrone Workloads 8. Geschwindigkeitsbegrenzungen und robustes Fehlermanagement 9. Sichere Schlüsselverwaltung und Datenschutz 10. Automatisierungsintegration: n8n, Zapier und Make 11. End-to-End-Produktion: Überprüfung, Überwachung und Ethik
Einheit 6 / 11

Kostenoptimierung: Prompt Caching

Gewinne:

  • Erklären Sie die Präfix-Matching-Logik des Prompt-Cachings
  • Erhöht den Cache-Treffer, indem der feste Kontext zuerst und der variable Kontext danach gesetzt wird
  • Kann die Wirtschaftlichkeit des Cache-Schreibens/Lesens und den Break-Even-Punkt berechnen

Ein LLM-Produkt sieht im Prototyp billig aus; Wenn man auf die Waage tritt, überrascht die Rechnung. Bei den meisten Workloads stammt der Großteil der Rechnung aus demselben festen Kontext, der bei jeder Anfrage immer wieder gesendet wird: eine lange Systemaufforderung, ein Regelwerk, eine Referenzdokumentation. Prompt-Caching eliminiert genau diese Verschwendung. In dieser Einheit erfahren Sie, wie der Cache funktioniert, wie Sie die Trefferaufforderung anordnen und wie Sie den Break-Even-Punkt der Cache-Ökonomie berechnen. Bei korrekter Installation allein kann es Ihre Rechnung halbieren oder sogar senken.

Wie funktioniert Cache? Die eine unveränderliche Regel

Prompt-Caching ist eine Präfixübereinstimmung. Der Anbieter speichert vorübergehend die Token, die er seit Beginn Ihrer Abfrage verarbeitet hat. Wenn die Eingabeaufforderung bei der nächsten Anfrage mit demselben Präfix beginnt, wird dieser gemeinsame Teil nicht neu berechnet. Es ist viel günstiger zu lesen als Cache.

Daraus folgt eine unveränderliche Regel: Ändert sich irgendwo im Präfix ein einzelnes Byte, wird ab diesem Zeitpunkt der gesamte Cache ungültig. Das heißt, feste Inhalte sollten am Anfang und variable Inhalte am Ende stehen. Wenn Sie an den Anfang der Systemaufforderung eine Zeile setzen, die sich bei jeder Anfrage ändert, z. B. „Heutiges Datum: 18.07.2026“, kann alles, was dahinter steht, nicht in den Cache gelangen.

Die Verarbeitungsreihenfolge lautet normalerweise: Tools → Systemaufforderung → Meldungen. Den Cache-Punkt (Breakpoint) setzen Sie am Ende des festen Abschnitts.

Cache-Ökonomie

Cache hat drei Preisstufen:

  • Cache-Schreiben: Zum ersten Mal speichern. ~1,25x normaler Eingabepreis (für 5-Minuten-Speicherung).
  • Cache-Lesung: Lesen bei nachfolgenden Anfragen. ~0,1-fache des normalen Inputpreises – also ein Zehntel.
  • Normale Eingabe: Der Teil, der nicht in den Cache gelangt und jedes Mal zum vollen Preis verarbeitet wird.

Break-Even-Punkt: Bei der ersten Anfrage wird eine Schreibprämie gezahlt (1,25×). Ab der zweiten Anfrage kommt der Messwert (0,1×) ins Spiel. Grob gesagt werden Sie bei zwei Anfragen ein Kopf-an-Kopf-Rennen haben; Danach handelt es sich um Nettoeinsparungen. Je größer der feste Kontext und je mehr Anfragen er wiederverwendet wird, desto größer wird der Gewinn.

Szenario

Funktioniert der Cache?

Große, feste Systemaufforderung, Tausende von Anfragen

Ja – höchstes Einkommen

Viele Fragen zu denselben Referenzdokumenten

Ja

Völlig anderer Kurztext für jede Anfrage

Nein – der Schreibbonus ist verschwendet

Einmalige Anfrage

Nein – überhaupt keine Lektüre

Datum/ID ändern sich bei jeder Anfrage an der Systemeingabeaufforderung

Nein – Präfix ist kaputt, Treffer ist Null

Schritt für Schritt: Wie richtet man eine Eingabeaufforderung ein?

  1. Trennen Sie Konstante und Variable. Welcher Inhalt ändert sich nie (Systemaufforderung, Regelwerk, Dokumentation)? Was ändert sich bei jeder Anfrage (Benutzerfrage, Datum, ID)?
  2. Setzen Sie die Konstante an den Anfang. Bei der Bearbeitung muss das zuerst kommende Teil (Werkzeuge, Anlage) stabil sein.
  3. Fügen Sie die Variable am Ende ein. Die aktuelle Frage des Benutzers, zuletzt.
  4. Platzieren Sie das Schild am Ende der Umrandung. Platzieren Sie den Cache-Punkt im letzten Block des festen Teils.
  5. Treffer bestätigen. Überprüfen Sie, ob „cache_read_input_tokens“ im Verwendungsfeld der Antwort größer als Null ist. Bei Null gibt es einen versteckten Disruptor im Präfix.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

Tipp: Cache-Treffer nicht erraten, sondern messen. Wenn „usage.cache_read_input_tokens“ bei aufeinanderfolgenden Anfragen immer noch Null ist, wird ein stiller Unterbrecher (datetime.now() an der Systemeingabeaufforderung, ungeordnetes JSON, Liste der Tools, die sich mit jeder Anfrage ändern) ausgeführt. Vergleichen Sie die Roheingabeaufforderung der beiden Anforderungen Byte für Byte und finden Sie den Unterschied.

Stille Störer

Typische Muster, die den Cache unwissentlich beschädigen:

# BREAKER: Einbettung von Informationen in die Systemeingabeaufforderung, die sich bei jeder Anfrage ändert „Heutiges Datum: {{jetzt}}. Sie sind ein Assistent …“ ← Präfix ändert sich bei jeder Anfrage, Treffer ist Null# TRUE: Variable in das Nachrichtensystem verschieben: „Sie sind ein Assistent ...“ ← Konstante trägt den Cache ein Nachrichten: [{Rolle: Benutzer, Inhalt: „Heute ist {{jetzt}}. Frage: ...“}] ← Variable am Ende

Andere Fehler: JSON wird bei jeder Anfrage unterschiedlich sortiert (Schlüssel in fester Reihenfolge beibehalten), Liste der Tools variiert je nach Benutzer (Tools werden zuerst verarbeitet; nichts wird in den Cache verschoben, wenn sie sich ändern), Ändern des Modells während der Konversation (Caches sind modellspezifisch).

Schwache Eingabeaufforderung / Starke Eingabeaufforderung (Cache-freundliche Struktur)

# SCHWACH (Cache-Busting-Build)system: „Datum: 18.07.2026 14:32. Benutzer: Ahmet (ID 8842). Sie sind ein Support-Bot. Regeln: ...(2000 Token)…“

# STRONG (cachefreundliche Struktur)System: „Sie sind ein Support-Bot. Regeln: ...(2000 Token, ändert sich nie)…“ [Cache-Zeichen]Nachrichten: [ { Rolle: Benutzer, Inhalt: „Datum: 18.07.2026 14:32. Benutzer-ID: 8842. Frage: Wie veranlasse ich meine Rückerstattung?“ }]

In der schwachen Version wird der Regelblock von 2000 Token bei jeder Anfrage zum vollen Preis verarbeitet. In der starken Version wird derselbe Block einmal geschrieben und bei allen nachfolgenden Anfragen für ein Zehntel des Preises gelesen.

Drei Mini-Hüllen

Fall 1 – Zwischenspeichern des Regelwerks. Eine Buchhaltungsautomatisierung fügte jeder Rechnung das 12.000-Token-Regelwerk hinzu; 5.000 Anfragen pro Tag. Die Cacheless-Eingabe kostet etwa 180 $ pro Tag. Sie hielten das Regelwerk konstant und speicherten es zwischen: Erste Anfragen zahlten eine Schreibprämie, nachfolgende Lesevorgänge 0,1x. Die Inputkosten sanken um etwa 90 % auf etwa 18 US-Dollar pro Tag.

Fall 2 – Kosten der verdeckten Datumsgrenze. Ein Team richtete einen Cache ein, bekam aber keine Treffer; Cache_read_input_tokens war immer Null. Grund: In der ersten Zeile der Systemeingabeaufforderung stand datetime.now(), das Präfix änderte sich bei jeder Anfrage. Als wir das Datum in die Benutzernachricht verschoben haben, stieg die Trefferquote plötzlich von 0 % auf 94 %.

Fall 3 – Cache falsch platziert. Eine Suchanwendung sendete bei jeder Anfrage völlig unterschiedliche kurze Abfragen; Sie fügten eifrig ein Cache-Schild hinzu. Ohne gemeinsames Präfix zahlte jede Anfrage nur eine Schreibprämie, keine Lesevorgänge – was die Kosten erhöhte. Sie haben das Schild entfernt. Lektion: Cache zahlt sich nur aus, wenn ein großes und konstantes Präfix vorhanden ist, das wiederverwendet wird.

Häufige Fehler

  • Mischen von Konstante und Variable: Wenn der Variableninhalt im Präfix steht, wird der Treffer zurückgesetzt.
  • Einbetten von Datum/ID in die Systemaufforderung: Der häufigste stille Störfaktor.
  • Den Treffer nicht messen: Wenn „cache_read_input_tokens“ nicht aktiviert ist, wird Verschwendung nicht bemerkt.
  • Hinzufügen von Cache, wenn kein öffentliches Präfix vorhanden ist: Sie zahlen nur die Schreibprämie, die Kosten steigen.
  • Änderung der Fahrzeugliste oder des Modells: Das Präfix ist von Anfang an gebrochen; alles ist neu geschrieben.
  • Vergessen der minimalen Cache-Größe: Sehr kurze Caches (unter ~1–4.000 Token, je nach Modell) werden nicht stillschweigend in den Cache übernommen.

Tiefer: Entwerfen des Caches nach Workload-Typ

Der tatsächliche Nutzen des Cachings hängt von der Art Ihrer Arbeitslast ab; Machen Sie sich also zunächst mit Ihrem Datenverkehr vertraut. Drei typische Muster und korrekte Installation:

Gemeinsame Systemaufforderung, unterschiedliche Fragen. Häufigstes Unternehmensmuster: eine große Systemeingabeaufforderung (Rolle, Regeln, möglicherweise Referenzdokument) mit Hunderten verschiedener Benutzerfragen. Hier wird zunächst der feste Teil (System) zwischengespeichert; Jede neue Frage zahlt nur für ihren eigenen kleinen Teil den vollen Preis. Der Gewinn ist sehr hoch, da der große Teil wiederholt zu einem Zehntel des Preises rezitiert wird.

Mehrrundiger Monolog. Während sich ein Gespräch hinzieht, baut jede neue Runde auf der gesamten vorherigen Geschichte auf. Wenn Sie das Cache-Flag am Ende der letzten Runde setzen, verwendet jede Anfrage das vorherige Konversationspräfix wieder; Die Treffer häufen sich, je länger das Gespräch wird. Dadurch werden die Kosten für lange Assistenzsitzungen erheblich gesenkt.

Das gemeinsame Präfix ist das letzte zu ändernde Bit. Mehrere Anfragen teilen sich einen großen Satz fester Prioritäten (Beispielsatz, Anweisungen), werden jedoch am Ende durch eine einzige Frage getrennt. Sie platzieren den Cache-Zeiger am Ende des gemeinsam genutzten Teils. Andernfalls würde jede Anfrage ihren eigenen separaten Cache schreiben und nichts davon würde gelesen werden.

Eine Einschränkung: Der Cache hängt vom Modell und einer bestimmten Mindestgröße ab. Sehr kleine Präfixe (unter ein paar tausend Token, je nach Modell) gelangen nicht unbemerkt in den Cache, selbst wenn Sie sie markieren – „cache_creation_input_tokens“ bleibt Null. Wenn Sie das Modell während der Konversation ändern, wird außerdem der gesamte Cache ungültig. Wenn für eine andere Aufgabe ein günstiges Modell erforderlich ist, behalten Sie den Hauptablauf in einem Modell bei und legen Sie die Nebenaufgabe in einem separaten Aufruf fest.

Zusammenfassend

Prompt-Caching ist eine Präfixübereinstimmung: Feste Inhalte sollten am Anfang stehen, variable Inhalte am Ende. Für einen großen, wiederverwendeten Kontext betragen die Lesekosten ein Zehntel des Gesamtpreises und sind bei zwei Anfragen ungefähr ausgeglichen. Der häufigste Fehler besteht darin, das Präfix durch die Einbettung variabler Daten in die Systemeingabeaufforderung zu beschädigen; Sie verifizieren den Treffer, indem Sie ihn im Nutzungsfeld messen.

Anwendungsaufgabe

Wählen Sie eine Arbeitsbelastung. (1) Teilen Sie den Inhalt in zwei Spalten auf: „Ändert sich nie“ und „Ändert sich bei jeder Anfrage“. (2) Zeichnen Sie die Eingabeaufforderungsstruktur neu und platzieren Sie den konstanten Teil am Anfang und den variablen Teil am Ende. (3) Schätzen Sie die Tokengröße des festen Teils und vergleichen Sie die monatlichen Kosten mit/ohne Cache. (4) Beachten Sie, aus welchem ​​Feld (cache_read_input_tokens) Sie den Treffer überprüfen.

Checkliste

  • [ ] Ich kann erklären, dass der Cache ein Präfixabgleich ist und die einzige unveränderliche Regel ist.
  • [ ] Ich kann die Genauigkeit erhöhen, indem ich den festen Inhalt am Anfang und die Variable am Ende platziere.
  • [ ] Ich kenne die Schreib-/Leseökonomie und den Break-Even-Point mit zwei Anfragen.
  • [ ] Ich kann stille Störer erkennen (Datum, ungeordneter JSON, sich ändernde Fahrzeugliste).
  • [ ] Ich kann den Treffer mit use.cache_read_input_tokens überprüfen.
Zurück Weiter