LLM Caching: So spart der KV-Cache Rechenarbeit

LLM Caching macht wiederverwendete Eingaben günstiger, weil das Modell bereits geleistete Arbeit nutzen kann. Ein KV-Cache speichert 2 Sätze von Attention-Daten: Keys und Values. So kann ein großes Sprachmodell ein Gespräch fortsetzen, ohne den Zustand jedes früheren Tokens erneut aufzubauen. Wiederholter Kontext lässt sich dadurch günstiger verarbeiten. Lange Gespräche belegen aber weiterhin Speicher und vergrößern den Kontext, den jedes neue Token berücksichtigen muss.

Nützliche Präfixe bewahren und den Umfang des gespeicherten Verlaufs begrenzen. Das sind getrennte Aufgaben. Ein Präfix ist der unveränderte Anfang einer Anfrage. Ihn zwischenzuspeichern kann die Eingabeverarbeitung verkürzen; die übrige Arbeit eines Agenten entfällt dadurch nicht.

Die folgenden Anbieterpreise und Cache-Regeln wurden am 15. Oktober 2026 anhand der aktuellen Preisseiten und Dokumentationen der Anbieter geprüft. Die Speicherberechnungen leiten sich aus dokumentierten Tensorformen ab. Es handelt sich nicht um Messungen auf einer bestimmten GPU.

Wie funktioniert LLM Caching mit dem KV-Cache?

Ein KV-Cache speichert den Zustand der Attention-Berechnung. Attention ist der Mechanismus, mit dem ein Transformer relevante frühere Informationen in seine aktuelle Vorhersage einbezieht. Ein Token, also eine Einheit aus Text oder anderen Modelleingaben, erzeugt innerhalb jeder Attention-Schicht numerische Repräsentationen. Der Cache bewahrt die Keys und Values dieser Schicht für die spätere Verwendung auf. Die Cache-Erklärung von Hugging Face beschreibt diese Speicherung pro Schicht.

Die drei Rollen innerhalb von Attention lassen sich am Beispiel einer Forschungsbibliothek veranschaulichen:

• Eine Query beschreibt, wonach die aktuelle Position sucht.
• Ein Key macht eine frühere Position für den Abgleich auffindbar.
• Ein Value liefert die Informationen, die ein Treffer beitragen kann.

Vor dem Schreiben eines Berichts werden Rechercheunterlagen geordnet und mit einem Register versehen. Jeder neue Satz kann auf diese vorbereiteten Unterlagen zurückgreifen. Register und Notizen für jeden Satz neu anzulegen würde Arbeit wiederholen; sie aufzubewahren kostet Platz. Bei der technischen Umsetzung endet der Vergleich: Das Modell speichert numerische Arrays, keine lesbaren Karteikarten und auch keine Zusammenfassung der Dokumente.

Die aktuelle Query wird mit früheren Keys verglichen. Die daraus entstehenden Attention-Gewichte bestimmen, wie deren Values kombiniert werden. In einem kausalen Transformer können frühere Positionen nicht in die Zukunft schauen. Ein später hinzugefügtes Token erfordert deshalb keine Änderung der bereits berechneten Zustände früherer Positionen. Darauf beruht die Wiederverwendbarkeit. Das ursprüngliche PagedAttention-Paper beschreibt diese Attention-Berechnungen und den Ablauf der Generierung.

Das erklärt auch, warum ein üblicher Cache K und V speichert, statt sämtliche früheren Queries aufzubewahren. Die nächste Vorhersage benötigt die aktuelle Query sowie die angesammelten Keys und Values. Die alten Queries haben ihre Aufgabe bereits erfüllt.

Bei einem Support-Agenten können die gespeicherten Zustände dessen Anweisungen, Werkzeugdefinitionen, Richtliniendokumente und bisherigen Gesprächsverlauf repräsentieren. Sie hängen vom Modell und vom vorausgehenden Kontext ab. Sie sind weder die trainierten Modellgewichte noch eine dauerhafte Datenbank für Kundenwissen.

Ein gespeichertes Präfix ist außerdem etwas anderes als eine gespeicherte Antwort. Das Modell erzeugt weiterhin eine neue Fortsetzung. Eine neue Frage zum selben Dokument kann dessen vorbereiteten Zustand wiederverwenden, ohne die vorige Antwort zurückzugeben.

Prefill und Decode: Eingaben vorbereiten, Antworten erzeugen

Prefill bereitet die Eingabe vor; Decode setzt sie fort. Diese Phasen erklären, warum eine Anfrage nach einem Cache-Treffer schneller anlaufen kann und trotzdem Zeit bis zum Abschluss benötigt.

Für einen herkömmlichen autoregressiven Transformer lässt sich der Ablauf so darstellen:

Prefill: Prompt-Tokens → Prompt verarbeiten → Keys und Values pro Schicht speichern → erstes Ausgabetoken vorhersagen.

Decode: zuletzt erzeugtes Token + gespeicherte Keys und Values → dieses Token verarbeiten und den Kontext über Attention einbeziehen → nächstes Token vorhersagen; neu berechnete Keys und Values anhängen.

Decode wiederholen: den wachsenden Cache bis zum Ende der Generierung weiterverwenden.

Prefill kann die bereits bekannten Positionen des Prompts gemeinsam verarbeiten. Decode arbeitet sich dagegen durch eine Fortsetzung, deren spätere Tokens noch nicht feststehen. Diesen Unterschied erläutert das PagedAttention-Paper im Ablauf von Generierung und Ausführung.

Der KV-Cache macht das nächste Token günstiger als eine erneute Berechnung des gesamten Präfixes. Er macht dessen Verarbeitung aber nicht unabhängig von der Kontextlänge. Bei herkömmlicher Full Attention interagiert die Query weiterhin mit den gespeicherten Keys und Values. Mehr gespeicherter Kontext bedeutet mehr Attention-Daten, die verarbeitet werden müssen. Hugging Face dokumentiert diese verbleibende Attention-Arbeit pro Schritt.

Dabei sind zwei Arten der Wiederverwendung zu unterscheiden. Innerhalb einer Antwort verhindert KV-Caching wiederholte Berechnungen während der Generierung. Über Anfragen hinweg bewahrt Prefix Caching, bei gehosteten APIs auch Prompt Caching genannt, geeignete Zustände auf. Ein späterer Aufruf kann so einen Teil der Prefill-Arbeit überspringen. Eine Gesprächskennung allein belegt nicht, dass diese Zustände verfügbar sind.

Ein Agent liest beispielsweise ein Richtliniendokument, ruft ein Tool auf und lässt das Modell anschließend entscheiden, wie mit dem Werkzeugergebnis weiterzuverfahren ist. Die nächste Anfrage kann die bisherigen Anweisungen und das Dokument als gemeinsames Präfix beibehalten und das Werkzeugergebnis anhängen. Erfüllt der Cache die Voraussetzungen und ist er verfügbar, muss der Anbieter diesen gemeinsamen Anfang nicht erneut vorbereiten.

Für die API-Entwicklung lohnt es sich deshalb, sowohl die Wartezeit bis zum ersten Token als auch die Dauer der Antwortgenerierung zu betrachten. Eine kürzere Wartezeit bis zum ersten Token belegt noch keinen schnelleren Decode. Die Dokumentation zu Automatic Prefix Caching von vLLM unterscheidet ausdrücklich zwischen eingesparter Prefill-Arbeit und Decode-Zeit.

Wie wird wiederverwendete Eingabe abgerechnet?

Der Rabatt gilt für wiederverwendete Eingabeverarbeitung nach den Abrechnungsregeln des Anbieters. Es gibt keinen allgemein gültigen Prozentsatz. Ein Treffer macht auch nicht jedes Token der betreffenden Anfrage günstiger.

Bei APIs, die zwischen regulärer Eingabe, Cache-Schreibvorgängen und Cache-Lesevorgängen unterscheiden, lassen sich die Eingabekosten so ausdrücken:

Eingabekosten = (U × p_input + W × p_write + R × p_read) / 1,000,000

Dabei steht U für reguläre Eingabetokens, W für als Cache-Schreibvorgang abgerechnete Tokens und R für als Cache-Lesevorgang abgerechnete Tokens. Jedes p bezeichnet den Preis der jeweiligen Kategorie pro Million Tokens. Die Kategorien dürfen sich nicht überschneiden: Ein geschriebenes Token darf nicht noch einmal zum regulären Eingabepreis berechnet werden. Die Formel ergibt sich aus den Einheiten und Preiskategorien von OpenAI und Anthropic.

Hinzu kommen anschließend die Ausgabe, gegebenenfalls Werkzeuggebühren und separat abgerechneter Cache-Speicher. Googles expliziter Cache berücksichtigt zusätzlich die Aufbewahrungsdauer. Ein Modell allein aus Schreib- und Lesevorgängen reicht dort deshalb nicht aus. Die folgenden Beispiele erläutern die Abrechnungsregeln; sie sind keine Rangliste der Modelle.

Anthropic: Das wiederverwendbare Präfix markieren

Anthropic steuert Prompt Caching über cache_control: entweder auf der obersten Ebene der Anfrage zur automatischen Verwaltung der Breakpoints oder auf einzelnen Inhaltsblöcken. Ein Breakpoint markiert das Ende des aufzubewahrenden Präfixes. Die Preisdokumentation beschreibt beide Verfahren.

Preisbeispiel, reguläre Claude API: Bei Claude Sonnet 5.5 kostet die Eingabe $2, das Lesen aus dem Cache $0.10, das Schreiben mit 5 Minuten Aufbewahrungsdauer $2.50 und das Schreiben mit 1 Stunde Aufbewahrungsdauer $4, jeweils pro Million Tokens. Anthropic-Preise.

Bei diesem Modell muss ein cachefähiges Präfix mindestens 512 Tokens umfassen. Der Inhalt muss bis zur Cache-Grenze exakt übereinstimmen. Lesevorgänge erneuern die Gültigkeitsdauer ohne weitere Schreibgebühr. Die Zeit läuft allerdings ab Beginn der Anfrage, sodass die Antwortgenerierung einen Teil des Intervalls verbraucht. Für andere Claude-Modelle gelten andere Mindestlängen und Leserabatte. Anthropics Regeln zum Prompt Caching.

Setzt ein Dokumentenagent seine Arbeit nach einer längeren menschlichen Pause fort, kann die Aufbewahrungsdauer darüber entscheiden, ob der nächste Aufruf ein vorhandenes Präfix liest oder erneut schreibt. Dafür sind cache_creation_input_tokens und cache_read_input_tokens in den Nutzungsdaten zu prüfen. Dass ein Dokument erneut gesendet wurde, belegt für sich genommen keinen rabattierten Lesevorgang. Nutzungsfelder.

OpenAI: Die Schreibregeln des Modells prüfen

OpenAI aktiviert Prompt Caching bei unterstützten Modellen standardmäßig. Neuere Modelle unterstützen sowohl implizite als auch explizite Breakpoints. Das Verhalten hängt vom jeweiligen Modell ab. OpenAI Prompt Caching.

Preisbeispiel, Standard-Tarif für kurzen Kontext: Bei GPT-6.1 Sol kostet die Eingabe $2.00, gecachte Eingabe $0.10 und das Schreiben in den Cache $2.50 pro Million Tokens. Oberhalb von 272K Eingabetokens verdoppeln sich die Eingabe- und Cache-Preise für die gesamte Anfrage. OpenAI-Preise, Schwellenwert des Modells.

Für GPT-5.6 und spätere Modelle beträgt das Minimum 1,024 sichtbare Eingabetokens. Die dokumentierte Cache-Gültigkeit liegt bei mindestens 30 Minuten nach dem letzten Schreiben oder Wiederverwenden. Der Cache-Schreibpreis ersetzt für diese Tokens den regulären Eingabepreis; er wird nicht als zusätzliche Kopie der gesamten Eingaberechnung erhoben. Bei älteren Modellen gelten andere Schreib- und Aufbewahrungsregeln. Aktuelle Caching-Regeln.

In der Responses API geben usage.input_tokens_details.cached_tokens und cache_write_tokens Aufschluss über die Nutzung. Eine fortgeführte Sitzung garantiert keinen Treffer. Bei der Untersuchung von Anfrageaufbau und gemeldeter Nutzung hilft der Diagnoseleitfaden zum Prompt Caching mit GPT-6 auf dieser Website.

Google Gemini: Automatische Wiederverwendung und explizite Speicherung

Google Gemini bietet automatisches implizites Caching, bei dem die Einsparungen bei einem Treffer weitergegeben werden. Für das Beispiel Gemini 3.8 Flash liegt das dokumentierte Minimum bei 4,096 Eingabetokens. Gemeinsame Inhalte am Anfang und zeitlich nahe beieinanderliegende Anfragen erhöhen die Chance auf Wiederverwendung. Googles Leitfaden zum Context Caching.

Preisbeispiel, kostenpflichtiger Standard-Tarif der Gemini Developer API: Bei Gemini 3.8 Flash kostet die Eingabe $0.75, gecachte Eingabe $0.075 pro Million Tokens und die explizite Cache-Speicherung $0.50 pro Million Tokens und Stunde, gültig bis 31. Dezember 2026. Google-Preise.

Explizites Caching verwendet eine benannte Ressource für zwischengespeicherte Inhalte mit festgelegter Ablaufzeit. Spätere generateContent-Anfragen verweisen auf diese Ressource. Wegen der Speichergebühr kann auch das Aufbewahren eines ungenutzten Dokuments Kosten verursachen. Googles API-Referenz zum Caching.

Die Wahl der API ist entscheidend: Die Interactions API unterstützt ausschließlich implizites Caching. Googles aktueller Leitfaden schließt außerdem explizites Caching für Gemini 4 Argon und spätere Modelle aus. Unterstützte Modelle der Reihen Gemini 3 und 2.5 verwenden für explizite Caches generateContent. In der Interactions API ist laut Leitfaden usage.total_cached_tokens zu prüfen. Googles API-spezifische Regeln.

Im API-Betrieb besteht der praktische Unterschied darin, ob automatische Treffer beobachtet werden oder bewusst für die Aufbewahrung einer Ressource bezahlt wird. Eine anbieterübergreifende Cache-Abstraktion darf nicht davon ausgehen, dass beides demselben Lebenszyklus folgt.

KV-Cache-Speicherbedarf: Mehr Kontext braucht mehr Platz

Bei herkömmlichen Full-Attention-Schichten wächst der reine KV-Speicherbedarf linear mit der Anzahl gespeicherter Tokens. Ein langes Gespräch vergrößert den aktiven Datenbestand, selbst wenn sein Anfang einen Abrechnungsrabatt erhält.

Für gleich lange Sequenzen und einheitlich aufgebaute Attention-Schichten gilt:

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: ein Key-Array und ein Value-Array.
• B: gleichzeitig verarbeitete Sequenzen, sofern sie ihre Cache-Daten nicht gemeinsam nutzen.
• T: gespeicherte, bereits verarbeitete Tokens pro Sequenz, einschließlich Prompt- und erzeugter Tokens.
• L: Attention-Schichten, die diese Art von Cache vorhalten.
• H_kv: Key/Value-Heads pro Schicht.
• D: Skalarwerte pro Head.
• S: Bytes zur Speicherung jedes Skalarwerts.

Diese Herleitung zählt die Elemente anhand der dokumentierten Cache-Form pro Schicht und der Anordnung der Key/Value-Heads in vLLM. Sie schätzt den Speicher der reinen Tensoren, nicht den gesamten Gerätespeicherbedarf.

Die Anzahl der Heads ist entscheidend. Bei Grouped-Query Attention teilen sich mehrere Query-Heads dieselben Key/Value-Heads. In die Formel gehört deshalb die Anzahl der KV-Heads. Die größere Anzahl der Query-Heads einzusetzen würde den Cache-Bedarf überschätzen.

Bleiben Modell und Speichergenauigkeit unverändert, verdoppelt eine Verdopplung von T den reinen dichten Cache. Werden sowohl T als auch die Anzahl unabhängiger, gleichzeitig verarbeiteter Sequenzen verdoppelt, wird er viermal so groß. Das folgt aus der Algebra und ist keine Aussage über die Kapazität einer bestimmten GPU oder einen gemessenen Durchsatz.

Für einen selbst gehosteten Supportdienst ergibt sich daraus eine hilfreiche Kapazitätsfrage: Wie viele gespeicherte Tokens sind über alle Kunden hinweg gleichzeitig aktiv? Dass das Modell in den Speicher passt, ist erst der Anfang. Ein Server muss auch den sich verändernden Inferenzzustand dieser Kunden unterbringen.

Hugging Faces Dokumentation zu Cache-Strategien beschreibt die Begrenzung bei Schichten mit Aufmerksamkeitsfenster. Das Prefix-Cache-Design von vLLM behandelt wiederverwendbare physische Blöcke. Weicht eine Architektur von diesen herkömmlichen dichten Key/Value-Arrays ab, ist ihr dokumentierter Zustandsaufbau maßgeblich.

Für Kunden gehosteter APIs hat dasselbe Wachstum eine andere sichtbare Folge: Pro Gesprächsrunde können mehr Tokens als Lesevorgänge abgerechnet werden, selbst wenn die Trefferquote stabil bleibt. Ein niedrigerer Stückpreis multipliziert mit einer wachsenden Eingabe ergibt weiterhin steigende Kosten. Auch die Ausgabegenerierung bezieht den Kontext weiterhin über Attention ein, und Preisschwellen können von der gesamten Eingabelänge abhängen.

Den KV-Cache in vLLM optimieren

vLLM ist eine Open-Source-Engine zur Bereitstellung von LLMs und bietet beim Selbsthosting Stellschrauben für Speicherzuweisung, Wiederverwendung und Darstellung der Cache-Daten. Vor einer Änderung der Bereitstellung sollte feststehen, welche Stellschraube den tatsächlichen Engpass adressiert.

PagedAttention: Speicherblöcke mit dem Gespräch wachsen lassen

PagedAttention ermöglicht Attention-Berechnungen auf KV-Daten, die in getrennten physischen Blöcken liegen. Eine logische Sequenz benötigt keine große, zusammenhängende Reservierung für ihren gesamten möglichen weiteren Verlauf. Das ursprüngliche Design reduziert ungenutzte Speicherzuweisungen und ermöglicht die gemeinsame Nutzung von Daten. PagedAttention-Paper.

Auch hier hilft das Bibliotheksbild: Ein wachsendes Forschungsprojekt erhält freie Regalabschnitte; eine Übersicht hält deren Reihenfolge fest. Es muss nicht vorab eine riesige leere Regalreihe reserviert werden, solange noch unbekannt ist, wie viel Material entsteht.

Paging allein verringert nicht die pro Token gespeicherte Informationsmenge. Es verbessert deren Unterbringung im verfügbaren Speicher. Zudem kennzeichnet vLLM seine Seite zum Paged-Attention-Kernel als historisch. Das Konzept bleibt nützlich; die alte Kernel-Beschreibung sollte jedoch nicht als heutige Implementierung verstanden werden.

Prefix Caching: Gemeinsame Arbeit früherer Anfragen nutzen

Automatic Prefix Caching verwendet den KV-Zustand eines übereinstimmenden Präfixes erneut. vLLM dokumentiert dafür enable_prefix_caching=True. Diese Funktion ist relevant, wenn wiederholte Fragen zu Dokumenten oder aufeinanderfolgende Agentenschritte stets denselben Anfang übermitteln. Automatic Prefix Caching.

Die Cache-Identität umfasst das vorausgehende Präfix, nicht nur den Text eines isolierten Blocks. Identische Absätze nach unterschiedlichen vorherigen Anweisungen können daher nicht ohne Weiteres als austauschbar gelten. vLLMs hashbasiertes Cache-Design macht diese Abhängigkeit ausdrücklich.

Die Grenze setzt die Arbeitslast: Unzusammenhängende Prompts bieten wenig gemeinsame Arbeit, und bei langen erzeugten Antworten kann weiterhin Decode den Zeitbedarf bestimmen. Geht es um die Wahl der Engine selbst, behandelt der Vergleich von vLLM und SGLang diese umfassendere Entscheidung.

KV-Cache-Quantisierung: Weniger Bytes pro gespeichertem Wert

Die Quantisierung des KV-Caches senkt die Genauigkeit der gespeicherten Zahlenwerte. vLLM unterstützt FP8-Cache-Speicherung über kv_cache_dtype="fp8" und empfiehlt zur Qualitätssicherung eine datensatzgestützte Kalibrierung der Skalierungsfaktoren. Welche Verfahren verfügbar sind, hängt vom Attention-Backend ab. vLLM-Dokumentation zum quantisierten Cache.

Der Wechsel von 16-Bit- zu 8-Bit-Werten halbiert in der Formel den reinen Speicherbedarf der Skalarwerte, bevor Skalierungsmetadaten und zusätzlicher Platzbedarf für die Speicherzuweisung hinzukommen. Er halbiert weder den gesamten Serverspeicherbedarf noch belegt er eine gemessene Beschleunigung. Modellgewichte zu quantisieren ist eine eigenständige Entscheidung, getrennt von der Quantisierung des Attention-Zustands.

Bei einem produktiv eingesetzten Agenten sollten die relevanten langen Aufgaben geprüft werden: Vorgaben beibehalten, Werkzeuge auswählen und Details aus früheren Nachrichten wiederfinden. Ein kleinerer Zustand ist nur dann hilfreich, wenn die Aufgabe weiterhin gelingt. Dass der Server startet, belegt keine unveränderte Qualität.

KV-Cache-Kompression: Genauigkeit und Inhalt unterscheiden

Werte mit geringerer Genauigkeit zu speichern und weniger Positionen aufzubewahren sind unterschiedliche Abwägungen. Quantisierung verändert die Darstellung der Werte. Ein begrenztes Attention-Fenster verändert, welche Positionen der betreffenden Schicht noch zur Verfügung stehen. Die jeweiligen Fehlermöglichkeiten sollten nicht unter einem pauschalen Kompressionsversprechen zusammengefasst werden. Cache-Strategien von Hugging Face.

Ein sinnvoller erster Schritt besteht darin, irrelevante Werkzeugausgaben nicht mehr zu senden. Das verkleinert künftigen Kontext bereits an der Quelle. Es ist allerdings eine Entscheidung auf Anwendungsebene: Die Belege, die der Agent benötigt, müssen erhalten bleiben, bevor sein gespeicherter Zustand optimiert wird.

KV-Cache-Offloading: Mehr Zustand speichern, dafür Daten übertragen

Offloading verlagert wiederverwendbaren Zustand auf eine andere Speicherebene. Der OffloadingConnector von vLLM kann abgeschlossene Blöcke im CPU-Arbeitsspeicher und auf unterstützten nachgeordneten Speicherebenen aufbewahren. Bei einem Treffer werden sie bei Bedarf wieder auf die GPU geladen. vLLM-Leitfaden zum Offloading.

Das kann helfen, wenn nützliche Präfixe länger gebraucht werden, als sie im GPU-Speicher verbleiben können. Es verursacht aber auch Datenübertragungen. Der Nutzen vermiedener Neuberechnungen muss für die eigene Arbeitslast gegen den Übertragungsaufwand abgewogen werden. Einen allgemein gültigen Latenzvorteil gibt es nicht.

Bei Speicherdruck durch aktive KV-Zustände kann vLLM Anfragen unterbrechen und später erneut berechnen. Der Optimierungsleitfaden empfiehlt, Parallelität und Speicherzuweisung zu untersuchen, wenn solche Unterbrechungen häufiger werden. Im Betrieb liefert eine steigende Zahl von Verdrängungen einen konkreteren Handlungsansatz als die bloße Beobachtung, dass der GPU-Speicher voll aussieht.

Was eine hohe Cache-Trefferquote nicht aussagt

Eine hohe Trefferquote allein macht noch keinen effizienten Agenten. Sie misst Wiederverwendung. Für den Geschäftsbetrieb zählt dagegen, dass eine Aufgabe innerhalb eines vertretbaren Zeit- und Kostenrahmens erfolgreich abgeschlossen wird.

Ein Gespräch kann fast seine gesamte bisherige Eingabe wiederverwenden und trotzdem mit jeder Runde wachsen. Es kann irrelevantes Material wiederholt zum rabattierten Preis lesen. Es kann auch den größten Teil seiner Zeit mit der Ausgabegenerierung verbringen, für die wiederverwendete Präfixe keine direkte Abkürzung bieten.

Ein aufgeblähter Gesprächsverlauf sollte nicht allein zum Schutz einer Cache-Kennzahl erhalten bleiben. Helfen die alten Inhalte nicht mehr, ist Verdichten oder Neustarten sinnvoll, auch wenn ein verändertes Präfix möglicherweise neu verarbeitet werden muss. Entscheidend sind Aufgabenqualität und Gesamtaufwand. Der Leitfaden zum Context Engineering auf dieser Website erklärt, wie sich bestimmen lässt, was in den Arbeitskontext gehört.

Beim Einsatz externer APIs lohnt sich die Optimierung des Prompt-Aufbaus bereits dann, wenn Anfragen regelmäßig umfangreiche gemeinsame Inhalte enthalten. Eine aufwendige Cache-Verwaltung kann warten, wenn sich Präfixe nur selten wiederholen. Beim Selbsthosting sollten zunächst Speicherdruck und Verdrängungen untersucht werden, bevor mehr Rechenleistung als Lösung gilt. Bei kurzen, voneinander unabhängigen Einzelanfragen gibt es wenig anfrageübergreifende Arbeit wiederzuverwenden.

Häufige Fragen zum KV-Cache bei LLMs

Verwendet ChatGPT einen KV-Cache?

OpenAI dokumentiert KV-basiertes Prompt Caching für seine APIs. Das beschreibt die Funktionsweise der öffentlichen API-Funktion, nicht sämtliche Details der internen Bereitstellung von ChatGPT. Für die Entwicklung sind die veröffentlichten Cache-Regeln und Nutzungsfelder des gewählten API-Modells maßgeblich. OpenAI-Dokumentation.

Sollte der KV-Cache in den GPU-Speicher ausgelagert werden?

Bei GPU-Inferenz wird der aktive Attention-Zustand auf der GPU verwendet. vLLMs Offloading-Funktion verschiebt wiederverwendbare Blöcke in den Host-Arbeitsspeicher oder auf andere unterstützte Speicherebenen und lädt sie bei Bedarf zurück. Das ist eine Überlegung wert, wenn die Aufbewahrung zusätzlicher Präfixe den Übertragungsaufwand rechtfertigt. vLLM-Offloading.

Was passiert, wenn der KV-Cache voll ist?

vLLM kann ungenutzte Cache-Blöcke entfernen. Bei Speicherdruck durch aktive Anfragen kann es Arbeit unterbrechen und später erneut berechnen. Das wirkt sich auf die Latenz aus. Dieser Vorgang ist vom Überschreiten des Kontextfensterlimits eines Modells zu unterscheiden. Cache-Verwaltung, Verdrängung von Anfragen.

Wie lässt sich der KV-Cache verkleinern?

Ansatzpunkte sind weniger gespeicherter Kontext, weniger gleichzeitig verarbeitete Sequenzen, die Wiederverwendung geeigneter gemeinsamer Präfixe oder eine Cache-Speicherung mit geringerer Genauigkeit. Offloading ändert den Speicherort des Zustands, ohne zwangsläufig dessen Gesamtgröße zu verringern. Neben dem Speicherbedarf sollten Aufgabenqualität und beobachtete Latenz über das Ergebnis entscheiden. Cache-Strategien.

Drei Gewohnheiten für hohe Cache-Trefferquoten bei Agenten

Während einer laufenden Aufgabe bleibt der Anfang stabil; Änderungen werden angehängt. Die Wiederverwendung exakt übereinstimmender Präfixe profitiert von einem vorhersehbaren Anfrageaufbau. Dabei gelten weiterhin die Anbieterregeln zu Mindestlänge, Aufbewahrung und Verfügbarkeit.

1. 1

   Den stabilen System-Prompt an den Anfang setzen

   Dauerhafte Anweisungen, Werkzeugdefinitionen und wiederverwendbares Referenzmaterial gehören vor veränderliche Aufgabendaten, innerhalb der von der API vorgegebenen Nachrichtenstruktur. Wortlaut, Werkzeugreihenfolge und Serialisierung bleiben stabil. Anthropics Hierarchie lautet Tools, System und dann Nachrichten. Ein veränderter Werkzeugsatz kann die nachfolgende Wiederverwendung ungültig machen. Anthropics Cache-Struktur.

2. 2

   Den Verlauf ergänzen, statt ihn umzuschreiben

   Frühere Nachrichten bleiben erhalten; die neue Nutzernachricht, der Werkzeugaufruf des Assistenten oder das Werkzeugergebnis werden angehängt. Vorherige Gesprächsrunden sollten nicht bei jedem Aufruf mit wechselnden Zusammenfassungen oder Formatierungen neu aufgebaut werden. Wird eine Verdichtung notwendig, bildet sie einen bewusst gesetzten Schnitt. Danach wird ein neues stabiles Präfix etabliert. Das folgt aus der Abhängigkeit jedes Blocks von den ihm vorausgehenden Tokens. Präfix-Identität in vLLM.

3. 3

   Zeitstempel hinter den wiederverwendbaren Inhalt stellen

   Die aktuelle Uhrzeit, die Anfragekennung und andere wechselnde Metadaten gehören hinter das wiederverwendbare Material. Ein Zeitstempel am Anfang kann die Wiederverwendung des dahinterliegenden Kontexts ungültig machen. Bei expliziten Breakpoints wird das Ende des stabilen Präfixes vor dem veränderlichen Suffix markiert. Anthropics Hinweise zu Breakpoints.

Ein konkreter Schritt für den nächsten Arbeitstag: ein repräsentatives Agentengespräch an den Übergängen zwischen Anfragen untersuchen. Zuerst wird das exakte Präfix aufeinanderfolgender Aufrufe verglichen. Anschließend werden die vom Anbieter gemeldeten Cache-Schreib- und Lesevorgänge zusammen mit Gesamteingabe, Ausgabe und Latenz betrachtet. Ein instabiles Präfix sollte vor einem Anbieterwechsel korrigiert werden. Ist die Trefferquote bereits gut und der Agent trotzdem langsam, sind als Nächstes gespeicherter Kontext, Ausgabelänge und konkurrierende Zugriffe auf Serverressourcen zu prüfen.

Den Newsletter abonnieren und praxisnahe Erklärungen zu den Systemen hinter KI-Agenten erhalten.