KV-Cache vs. Prompt-Cache: Unterschiede erklärt

KV-Cache vs. Prompt-Cache: die kurze Antwort

Der KV-Cache und der Prompt-Cache eines Providers haben ein gemeinsames Wort, aber fast nichts anderes. Der KV-Cache ist ein Arbeitsspeicher pro Anfrage. Er befindet sich während der gesamten Lebensdauer einer Anfrage im RAM oder VRAM Ihres Servers. Er wächst mit der Kontextlänge und mit der Anzahl der Anfragen, die Sie gleichzeitig ausführen. Prompt-Caching durch den Provider ist eine Funktion für Abrechnung und Latenz. Ein stabiler Präfix Ihres Prompts wird auf den Servern des Providers gespeichert. Wenn Sie ihn erneut senden, wird er zu einem reduzierten Preis abgerechnet.

Das eine ist Speicher, den Sie als Hardware kaufen. Das andere ist Speicher, den ein anderer verwaltet und für den er Miete berechnet.

Der praktische Unterschied ist wichtiger als die Definition. Der KV-Cache kann voll laufen. Dann verweigert das Modell das Laden, oder die Anfrage wird abgelehnt. Der Prompt-Cache kann nicht voll laufen. Sie können ihn nur verfehlen. Dann zahlen Sie unbemerkt den vollen Preis.

Was der KV-Cache enthält und warum es ihn gibt

Ein Transformer, der Token Nummer 500 generiert, muss auf alle 499 vorherigen Token achten. Für jedes dieser Token benötigt jede Schicht einen Key-Vektor und einen Value-Vektor. Würden diese für jedes neue Token vollständig neu berechnet, würde die Generierung quadratisch mit der Sequenzlänge wachsen. Deshalb hält die Laufzeitumgebung sie stattdessen vor. Dieser Speicher ist der KV-Cache (Key/Value-Cache).

Der Zustand gilt pro Anfrage, weil er aus der exakten Token-Sequenz dieser Anfrage aufgebaut wird. Zwei Benutzer mit unterschiedlichen Prompts können ihn nicht gemeinsam nutzen, außer die Laufzeitumgebung verwendet Prefix-Caching. Das ist eine separate Funktion, die später beschrieben wird.

Das Serving erfolgt in zwei Phasen. Beim Prefill wird der gesamte Prompt gelesen und der Cache gefüllt. Dieser Vorgang ist durch die Rechenleistung begrenzt. Beim Decode wird jeweils ein Token erzeugt und an den Cache angehängt. Dieser Vorgang ist durch die Speicherbandbreite begrenzt. Deshalb weisen die Verarbeitung des Prompts und die Token-Generierung unterschiedliche Geschwindigkeiten aus, wenn Sie Tokens pro Sekunde auf Ihrem eigenen System messen.

Wie viel Arbeitsspeicher benötigt der KV-Cache?

Suchen Sie nicht nach einer Herstellertabelle. Die Größe lässt sich für jedes Modell mit einer einfachen Rechnung bestimmen:

bytes per token = 2 * layers * kv_heads * head_dim * bytes per element

Die 2 steht für Key und Value. Alle anderen Zahlen stammen aus der config.json des Modells, die auf der Hugging-Face-Seite des Modells veröffentlicht ist.

Nehmen wir Llama 3.1 8B. Die Konfiguration enthält num_hidden_layers 32 und num_key_value_heads 8. Die hidden_size von 4096 verteilt auf 32 Attention-Heads ergibt eine Head-Dimension von 128. Bei f16 belegt jedes Element 2 Byte:

2 * 32 * 8 * 128 * 2 = 131072 bytes = 128 KiB per token

Multiplizieren Sie diesen Wert mit dem angeforderten Kontext und anschließend mit der Anzahl der Anfragen, die Sie gleichzeitig ausführen.

[
  {
    "label": "2k context",
    "one_request_gib": 0.25,
    "four_requests_gib": 1
  },
  {
    "label": "8k context",
    "one_request_gib": 1,
    "four_requests_gib": 4
  },
  {
    "label": "32k context",
    "one_request_gib": 4,
    "four_requests_gib": 16
  },
  {
    "label": "128k context",
    "one_request_gib": 16,
    "four_requests_gib": 64
  }
]

Bei einem Kontext von 8k beträgt der Cache für 1 GiB. Bei 32k sind es 4 GiB. Das liegt in derselben Größenordnung wie die 4-Bit-Gewichte selbst. Beim vollständigen Kontext von 128k benötigt eine einzelne Anfrage 16 GiB. Wenn vier Anfragen jeweils den gesamten Kontext ausschöpfen, sind es 64 GiB. Die Gewichte haben sich nicht verändert. Nur der Cache ist gewachsen.

Grouped Query Attention (GQA) hat großen Anteil an diesem Wert. Llama 3.1 8B verfügt über 8 Key/Value-Heads für 32 Query-Heads. Dadurch teilen sich jeweils vier Query-Heads ein gespeichertes Key/Value-Paar. Ein Modell, bei dem num_key_value_heads num_attention_heads entspricht, benötigt bei gleicher Parameteranzahl den vierfachen Cache. Prüfen Sie dieses Feld, bevor Sie davon ausgehen, dass sich zwei 8B-Modelle mit demselben Aufwand bereitstellen lassen.

Warum ein Modell, das mit 2k lief, bei 32k das Laden verweigert

Die Laufzeitumgebung reserviert den KV-Cache beim Laden des Modells. Seine Größe richtet sich nach der konfigurierten Kontextlänge, nicht nach dem tatsächlich gesendeten Prompt. Ollamas Standard-Kontextfenster umfasst 4096 Tokens. Wenn Sie es auf 32k erhöhen, fordern Sie 4 GiB zusätzlichen Speicher an, bevor auch nur ein einziges Token eintrifft.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Dieselbe Einstellung pro Sitzung, über die interaktive Eingabeaufforderung:

ollama run llama3.1:8b
/set parameter num_ctx 32768

Der Fehler sieht je nach Stack unterschiedlich aus. vLLM prüft die Berechnung beim Start und verweigert den Betrieb:

ValueError: The model's max seq len (131072) is larger than the maximum number of tokens that can be stored in KV cache (78336). Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine.

Auf einer CPU-only-VPS gibt es keine solche Prüfung, weil die Reservierung aus dem normalen System-RAM erfolgt. Stattdessen beendet der Out-of-Memory-Killer des Kernels den Prozess. Die entsprechenden Hinweise stehen im Kernel-Ringpuffer:

dmesg -T | grep -i "killed process"

Eine Zeile mit dem Namen Ihres Serving-Prozesses bedeutet, dass der Server mehr Speicher zugesagt hat, als tatsächlich verfügbar war. Die Lösung ist eine kleinere Kontextlänge, nicht eine größere Swap-Datei: Ein auf der Festplatte ausgelagerter KV-Cache wird bei jedem einzelnen generierten Token gelesen. Dadurch wird die Generierung so langsam, dass sie praktisch unbrauchbar ist. Wie Sie einen sinnvollen Wert auswählen, wird in unserem Leitfaden zu num_ctx und der Kontextlänge in Ollama beschrieben.

Auswirkungen der Parallelität auf die Anzahl

Jede laufende Anfrage benötigt einen eigenen KV-Cache. Das wird bei den meisten Kapazitätsplanungen übersehen. Vier Benutzer mit jeweils 32k Kontext benötigen zusammen 16 GiB, zusätzlich zu den Gewichten.

Die Runtimes gehen damit unterschiedlich strikt um. Ollama und llama.cpp reservieren beim Laden des Modells den angeforderten Kontext. Der Speicher ist daher belegt, unabhängig davon, ob ihn jemand nutzt. vLLM teilt den Pool in Blöcke fester Größe auf und weist diese zu, wenn die jeweilige Anfrage wächst. Eine Anfrage mit 500 Tokens belegt daher nur Speicher für 500 Tokens. Der Pool ist in beiden Fällen begrenzt. Sobald er vollständig belegt ist, werden neue Anfragen in eine Warteschlange eingereiht, statt ausgeführt zu werden. Welche Auswirkungen diese Warteschlange auf die Antwortzeiten hat, wird unter wie viele gleichzeitige Benutzer ein selbst gehostetes LLM bedienen kann erläutert.

Vier Möglichkeiten, den KV-Cache zu verkleinern

1. Verringern Sie die Kontextlänge. Das ist der größte Hebel und in der Regel die günstigste Maßnahme. Die meisten Chat-Workloads erreichen 32k nicht annähernd.
2. Quantisieren Sie den Cache selbst. Ollama verwendet für OLLAMA_KV_CACHE_TYPE standardmäßig f16 und akzeptiert q8_0, das ungefähr die Hälfte des Arbeitsspeichers benötigt, sowie q4_0, das ungefähr ein Viertel benötigt. Die entsprechenden llama.cpp-Werte sind -ctk q8_0 und -ctv q8_0.
3. Wählen Sie ein Modell mit weniger Key/Value-Heads oder weniger Layern. Lesen Sie config.json, bevor Sie 40 GB Gewichte herunterladen.
4. Verarbeiten Sie weniger Anfragen gleichzeitig und stellen Sie die übrigen in eine Warteschlange.

Bei q4_0 sinkt der Wert für Llama 3.1 8B von 128 KiB pro Token auf ungefähr 32 KiB. Dadurch benötigt ein Kontext mit 32k ungefähr 1 GiB statt 4 GiB. Diese Einsparung ist nicht kostenlos. Die Keys und Values werden mit geringerer Präzision gespeichert. Vergleichen Sie daher die Ausgabe anhand Ihrer eigenen Prompts, bevor Sie diese Einstellung beibehalten.

Was das Prompt-Caching des Providers tatsächlich bringt

Das Prompt-Caching des Providers ist ein anderes Produkt mit einer anderen Abrechnungseinheit. Sie markieren einen stabilen Präfix. Der Provider speichert ihn. Spätere Aufrufe, die exakt denselben Präfix wiederholen, werden zu einem reduzierten Preis statt zum vollständigen Preis für Eingabetokens abgerechnet.

Anthropics veröffentlichte Multiplikatoren (Stand August 2026): Das Schreiben in einen 5-Minuten-Cache kostet das 1,25-Fache des regulären Preises für Eingabetokens. Das Schreiben in einen 1-Stunden-Cache kostet das 2-Fache. Das Lesen aus dem Cache kostet das 0,1-Fache. Setzt man einen System-Prompt mit 20.000 Tokens in diese Rechnung ein, wird das Verhältnis unmittelbar deutlich.

[
  {
    "label": "No caching, every call",
    "billed_token_equivalents": "20,000"
  },
  {
    "label": "First call, 5 minute cache write",
    "billed_token_equivalents": "25,000"
  },
  {
    "label": "First call, 1 hour cache write",
    "billed_token_equivalents": "40,000"
  },
  {
    "label": "Every later call, cache hit",
    "billed_token_equivalents": "2,000"
  }
]

Betrachten Sie die Rechnung. Der Aufschlag für das Schreiben in den 5-Minuten-Cache entspricht beim ersten Aufruf 5.000 Token-Äquivalenten: 25,000 gegenüber 20,000 für die Übertragung ohne Cache. Jeder weitere Aufruf innerhalb des Zeitfensters wird mit 2,000 statt mit 20,000 abgerechnet. Das spart 18.000 Token-Äquivalente. Der 5-Minuten-Cache ist daher ab dem zweiten Aufruf günstiger.

Der 1-Stunden-Cache ist eine andere Abwägung. Beim Schreiben werden 40,000 abgerechnet. Das entspricht einem Aufschlag von 20.000 Token-Äquivalenten. Daher sind innerhalb dieser Stunde zwei Treffer erforderlich, bevor sich der Cache lohnt. Das hängt von Ihrem Zugriffsmuster ab, nicht vom Modell. Die vollständige Berechnung einschließlich der Auswahl des Zeitfensters finden Sie unter der Break-even-Berechnung für das Claude-Prompt-Caching.

Zwei Details entscheiden darüber, ob Sie den Cache überhaupt treffen. Erstens wird ein Präfix unterhalb der vom Modell geforderten Mindestlänge stillschweigend nicht zwischengespeichert. Stand August 2026 beträgt die dokumentierte Mindestlänge 512 Tokens für Claude Opus 5 und 1.024 Tokens für Claude Sonnet 5. Eine kürzere Anfrage wird normal verarbeitet. Es wird kein Fehler zurückgegeben. Zweitens wird die Lebensdauer ab dem Beginn der Anfrage gemessen, die den Eintrag schreibt oder liest. Jeder Lesezugriff verlängert die Lebensdauer ohne zusätzliche Kosten. Ein stark ausgelasteter Endpunkt kann einen 5-Minuten-Cache daher unbegrenzt aktiv halten. Ein Endpunkt, der alle zehn Minuten aufgerufen wird, zahlt jedes Mal den Aufschlag für das Schreiben und erzielt nie einen Vorteil.

Prüfen Sie die Antwort, statt den Cache-Treffer vorauszusetzen. Das usage-Objekt meldet cache_creation_input_tokens und cache_read_input_tokens. Eine Trefferanzahl von null bei jedem Aufruf bedeutet, dass Sie Schreibvorgänge bezahlen, aber keinen Nutzen daraus erhalten.

Wenn die beiden Caches zusammentreffen

Ein langer System-Prompt ist der Punkt, an dem sie zusammentreffen. Er verursacht auf beiden Seiten gleichzeitig Kosten.

Lokal belegt ein System-Prompt mit 20,000 Token auf einem Llama 3.1 8B-Server bei f16 etwa 2.4 GiB KV-Cache. Dieser Speicher wird für jede gleichzeitige Anfrage, die den Prompt enthält, separat benötigt. Remote verursacht dasselbe Präfix zunächst einen Cache-Schreibvorgang und danach bei jedem weiteren Aufruf das 0.1-Fache der Eingabekosten. Die lokalen Kosten steigen mit der Zahl Ihrer Benutzer. Die Remote-Kosten steigen mit Ihrem Datenverkehr und werden während Ihrer Leerlaufzeit zurückgesetzt.

Es gibt eine lokale Funktion, die wie Prompt-Caching beim Anbieter aussieht und häufig damit verwechselt wird: Prefix-Caching. Die vLLM-Dokumentation beschreibt das automatische Prefix-Caching als Caching „the KV cache of existing queries, so that a new query can directly reuse the KV cache if it shares the same prefix with one of the existing queries“. Der llama.cpp-Server verwaltet standardmäßig einen Prompt-Cache pro Slot. --cache-reuse N legt den kleinsten Abschnitt fest, den der Server wiederzuverwenden versucht.

Prefix-Caching spart Prefill-Berechnungen. Ihr 20,000-Token-System-Prompt wird einmal statt bei jeder Anfrage verarbeitet. Dadurch verkürzt sich die Zeit bis zum ersten Token deutlich. In vLLM werden die gemeinsam genutzten Blöcke wiederverwendet, statt dupliziert zu werden. Dadurch sinkt auch der Speicherbedarf. Die Größe des Caches, den Sie für aktuell aktive Token vorhalten müssen, verringert sich dadurch jedoch nicht. Das Vorhalten der Gewichte zwischen Anfragen ist ein verwandter, aber separater Stellhebel. Er wird unter ein Ollama-Modell zwischen Anfragen geladen halten behandelt.

Was Sie auf Ihrem eigenen System messen sollten

Laden Sie das Modell mit dem Zielkontext und lesen Sie anschließend die tatsächlichen Werte ab, statt der Schätzung zu vertrauen.

ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
free -g

ollama ps listet das geladene Modell mit seiner Größe und der Information auf, ob es auf der GPU oder der CPU ausgeführt wird. Wenn ein Modell, das erwartungsgemäß vollständig auf der GPU liegen sollte, einen CPU-Anteil meldet, hat der KV-Cache einen Teil des Modells ausgelagert. Die Generierungsgeschwindigkeit sinkt entsprechend. nvidia-smi liefert den tatsächlichen VRAM-Wert. free -g übernimmt dieselbe Aufgabe auf einer CPU-only-VPS. Erhöhen Sie den Kontext schrittweise, laden Sie das Modell neu und beobachten Sie, wie sich der Wert verändert. Ihre Berechnung und der angezeigte Wert sollten nahe beieinanderliegen. Wenn das nicht der Fall ist, stammt die Abweichung meist von den Compute-Puffern der Laufzeitumgebung und nicht aus einem Fehler in der Formel.

Wenn diese Werte für Hardware sprechen, die Sie lieber nicht mieten möchten, finden Sie den Vergleich mit der Abrechnung pro Token unter GPU-VPS im Vergleich zu API-Tokens.

FAQ

Ist der KV-Cache dasselbe wie Prompt-Caching?

Nein. Der KV-Cache ist ein anfragebezogener Speicher innerhalb des Serving-Prozesses. Er enthält die Key- und Value-Vektoren für jedes Token im aktuellen Kontext. Er liegt in Ihrem RAM oder VRAM und wird freigegeben, sobald die Anfrage endet. Prompt-Caching beim Provider ist eine Abrechnungsfunktion. Dabei wird ein stabiler Prompt-Präfix auf der Infrastruktur des Providers gespeichert. Wenn Sie ihn erneut senden, wird ein reduzierter Preis berechnet. Wenn der KV-Cache nicht ausreicht, kann ein Modell nicht geladen werden. Ein fehlender Prompt-Cache erhöht nur Ihre Rechnung und die Zeit bis zum ersten Token.

Warum wird mein Modell mit einem Kontext von 2k geladen, schlägt aber mit 32k fehl?

Der Grund ist, dass die Laufzeitumgebung den gesamten KV-Cache beim Laden reserviert. Die Größe richtet sich nach der konfigurierten Kontextlänge und nicht nach dem Prompt, den Sie senden. Bei Llama 3.1 8B mit f16 benötigt der Cache 128 KiB pro Token. Ein Kontext von 2k benötigt daher 0.25 GiB, ein Kontext von 32k dagegen 4 GiB. Die Gewichte passen in beiden Fällen in den Speicher. Die Reservierung schlägt fehl. vLLM meldet dies als ValueError. Darin wird die maximale Anzahl der Tokens genannt, die gespeichert werden konnte. Außerdem wird vorgeschlagen, gpu_memory_utilization zu erhöhen oder max_model_len zu verringern. Auf einem System, das nur die CPU verwendet, beendet stattdessen der Out-of-Memory-Killer des Kernels den Prozess. Das können Sie mit dmesg -T | grep -i "killed process" bestätigen.

Wie berechne ich die Größe des KV-Caches für mein Modell?

Multiplizieren Sie 2 mit der Anzahl der Layer, der Anzahl der Key/Value-Heads, der Head-Dimension und der Byteanzahl pro Element. Das ergibt die Byteanzahl pro Token. Multiplizieren Sie diesen Wert anschließend mit Ihrer Kontextlänge und der Anzahl der gleichzeitig laufenden Anfragen. Entnehmen Sie die Layer- und Head-Anzahlen dem config.json des Modells. Verwenden Sie 2 Bytes pro Element für f16 oder bf16. Ein q8_0-Cache benötigt ungefähr halb so viel Speicher, ein q4_0-Cache ungefähr ein Viertel.

Verringert Prompt-Caching den Speicherbedarf meines eigenen Servers?

Prompt-Caching beim Provider wirkt sich nicht auf Ihre Hardware aus, weil der Speicher auf der Seite des Providers liegt. Das lokale Gegenstück ist Prefix-Caching, das sowohl vLLM als auch der llama.cpp-Server anbieten. Dabei werden bereits berechnete Key- und Value-Vektoren für einen gemeinsamen Präfix wiederverwendet. Das spart Prefill-Rechenzeit und verkürzt die Zeit bis zum ersten Token. In vLLM werden die gemeinsamen Blöcke wiederverwendet und nicht dupliziert. Dadurch verbessert sich auch die Speichernutzung. Keine der beiden Funktionen verringert den Cache-Bedarf für Tokens, die gerade verarbeitet werden. Ihre Berechnung für Kontext und Parallelität legt daher weiterhin den Mindestbedarf fest.

Lohnt es sich, einen Prompt zu cachen, den ich nur einmal sende?

Nein. Das Schreiben in den Cache kostet mehr als eine normale Eingabe. Für die Option mit 5 Minuten beträgt der Preisstand im August 2026 das 1.25-Fache des Basistarifs. Ein Präfix, das Sie innerhalb dieses Zeitfensters nicht erneut senden, verursacht daher direkt einen Verlust. Caching lohnt sich, wenn derselbe Präfix wiederholt verwendet wird, zum Beispiel bei einem langen System-Prompt oder einem Dokument, zu dem Sie mehrere Fragen stellen möchten. Prüfen Sie cache_read_input_tokens in der API-Antwort, um zu bestätigen, dass Cache-Treffer vorliegen und Sie nicht für Schreibvorgänge bezahlen.