Fortgeschritten 11 Min.Optimierung

KV-Cache quantisieren: VRAM sparen (lang contexte)

Sie haben genug VRAM, um das Modell zu laden, doch sobald Sie den Kontext auf 16k oder 32k Tokens erhöhen, reicht der Speicher nicht mehr aus. Schuld daran ist der KV-Cache: ein verborgener Speicherbereich, der linear mit dem Kontext wächst und bei langen Prompts genauso viel Speicher beanspruchen kann wie das Modell selbst. Die KV-Cache-Quantisierung komprimiert ihn auf Q8 oder Q4, um den auf derselben Karte nutzbaren Kontext zu verdoppeln. Hier erfahren Sie, wie Sie die Quantisierung in Ollama und llama.cpp aktivieren, welche bezifferten Vorteile sie bringt und wie sie sich tatsächlich auf die Qualität auswirkt.

Von Mohamed Meguedmi·Aktualisierung 2026-08-27·Unter Windows, macOS und Linux getestet

#Warum der KV-Cache Ihren VRAM auffrisst

Wenn ein LLM Text generiert, berechnet es nicht bei jedem neuen Token die Aufmerksamkeit für den gesamten Prompt neu: Es speichert die Schlüsselvektoren (K) und Wertvektoren (V) jedes bereits gesehenen Tokens. Das ist der KV-Cache, und er macht die Generierung schnell. Das Problem: Dieser Speicher wächst linear mit der Länge des Kontexts. Verdoppeln Sie den Kontext, verdoppelt sich auch der KV-Cache.

Bei einem kurzen Prompt mit einigen hundert Tokens ist das vernachlässigbar. Sobald Sie jedoch RAG mit großen Dokumenten, Zusammenfassungen von Transkriptionen oder Agenten mit Langzeitgedächtnis einsetzen, wächst der Kontext enorm – und der KV-Cache mit ihm. Bei einem 70B-Modell mit 32k Kontext kann allein der KV-Cache mehr als 10 GB belegen, zusätzlich zu den etwa 40 GB des Modells. Häufig verursacht er und nicht das Modell den Out-of-Memory-Fehler bei langen Prompts.

i
Modell vs. KV-Cache: zwei getrennte Posten beim Speicherbedarf
Der VRAM-Bedarf setzt sich aus drei Teilen zusammen: den Modellgewichten (fester Speicherbedarf, abhängig von Größe und Quantisierung), dem KV-Cache (variabler Speicherbedarf, abhängig vom Kontext) und etwas Overhead. Die Quantisierung des Modells (Q4_K_M) reduziert den ersten Posten. Die Quantisierung des KV-Caches reduziert den zweiten. Das sind zwei unabhängige Stellschrauben.

#Wie viel Speicher Ihr KV-Cache benötigt

Das Lokale-KI-Paket

Ihr privates, kostenloses ChatGPT auf Ihrem Rechner in einer Stunde – mit LM Studio, Ollama, Open WebUI und Ihren Dokumenten, ganz ohne Cloud.

  • Lebenslanger Online-Zugang
  • PDF + Dateien
  • Erstattung binnen 30 Tagen
Das Lokale-KI-Paket →oder alle Pakete lebenslang — 49 € →

Die Größe des KV-Caches hängt von vier Faktoren ab: der Anzahl der Modellschichten, der Attention-Dimension, der Kontextlänge und der Speicherpräzision. Bei FP16 (Standardeinstellung) lautet die näherungsweise Formel: 2 (K und V) × Schichten × dim_kv × Kontext × 2 Bytes. Merken Sie sich für die Praxis diese Größenordnungen bei FP16 mit einem Kontext von 32.000 Tokens:

7-9B (z. B. Qwen 3.5 9B, Granite 4.2 8B)
Etwa 2 bis 4 GB KV-Cache bei 32k, je nach Architektur (GQA hilft erheblich).
14B
≈ 4 bis 6 GB bei 32.000 Tokens.
32B
≈ 8 bis 10 GB bei 32.000 Tokens.
70B
≈ 10 bis 16 GB bei 32k Tokens — oft der begrenzende Faktor.
i
GQA verändert die Situation
Neuere Modelle verwenden Grouped-Query Attention (GQA), bei der sich mehrere Query-Heads dieselben K/V-Heads teilen. Dadurch benötigt ihr KV-Cache bereits deutlich weniger Speicher als der älterer Multi-Head-Modelle. Qwen 3.5, Gemma 4 und Granite 4.2 profitieren davon. Das macht die Quantisierung bei sehr langen Kontexten nicht überflüssig, verschiebt aber die Schwelle, ab der sie nötig wird.

#Was die Quantisierung des KV-Caches verändert

Die Idee ist die gleiche wie bei den Modellgewichten: Anstatt jedes Cache-Wert in 16 Bit (FP16) zu speichern, wird er in 8 Bit (Q8_0) oder 4 Bit (Q4_0) gespeichert. Die Cache-Memory wird mechanisch durch 2 (Q8) oder durch 4 (Q4) geteilt. Da der KV-Cache bei langen Kontexten einen großen Anteil an der VRAM ausmacht, ist der Vorteil direkt spürbar: Bei konstanter VRAM können mit Q8 die unterstützbare Kontextlänge etwa verdoppelt werden.

FP16
Referenzgenauigkeit, kein Qualitätsverlust, aber der höchste Ressourcenbedarf. Die Standardeinstellung.
Q8_0
Halb so viel Speicher, bei den meisten Modellen ein nahezu unmerklicher Qualitätsverlust. Der beste Kompromiss.
Q4_0
Nur ein Viertel des Speicherbedarfs, aber messbare Qualitätsverluste, die je nach Modell unterschiedlich ausfallen. Nur für Fälle vorsehen, in denen die VRAM tatsächlich der begrenzende Faktor ist.
!
Voraussetzungen: Flash Attention
Die Quantisierung des KV-Caches setzt voraus, dass Flash Attention aktiviert ist. Ohne Flash Attention verweigern llama.cpp und Ollama die Verwendung eines anderen Cache-Typs als FP16 oder brechen mit einem Fehler ab. Das ist schlüssig: Flash Attention und ein quantisierter Cache arbeiten zusammen, um den Speicherbedarf der Attention-Berechnung zu verringern.

#KV-Quantisierung in Ollama aktivieren

Ollama ermöglicht die Quantisierung des KV-Caches über zwei Umgebungsvariablen des Daemons. Zuerst muss Flash Attention aktiviert werden, dann wird der Cache-Typ gewählt. Diese Variablen werden für den Ollama-Dienst gesetzt, nicht beim Aufruf von ollama run.

  1. 01
    Flash Attention aktivieren
    Setzen Sie OLLAMA_FLASH_ATTENTION=1 in der Umgebung des Daemons. Dies ist die Voraussetzung für alle Caches außer FP16.
  2. 02
    Den Cache-Typ wählen
    Setzen Sie OLLAMA_KV_CACHE_TYPE auf den gewünschten Wert: f16 (Standard), q8_0 (empfohlen) oder q4_0 (aggressiv).
  3. 03
    Daemon neu starten
    Umgebungsvariablen werden nur beim Start des Dienstes gelesen. Starten Sie Ollama neu, damit sie wirksam werden.
  4. 04
    Den Zugewinn überprüfen
    Laden Sie ein Modell mit einem großen Kontext und überwachen Sie den VRAM mit nvidia-smi oder ollama ps. Sie müssen num_ctx auf einen höheren Wert als zuvor einstellen können.
Terminal — Linux (systemd)
# Éditer l'unité systemd du service
sudo systemctl edit ollama

# Ajouter dans la section [Service] :
[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

# Recharger et redémarrer
sudo systemctl daemon-reload
sudo systemctl restart ollama
Terminal – manueller Start
# Sur macOS ou pour un lancement direct du serveur
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve
PowerShell — Windows
# Poser les variables au niveau utilisateur puis redémarrer Ollama
setx OLLAMA_FLASH_ATTENTION 1
setx OLLAMA_KV_CACHE_TYPE q8_0

# Quitter Ollama depuis la barre des tâches et le relancer
→
Erweitern Sie den Kontext, um die Vorteile zu nutzen
Die Quantisierung des Caches bringt nichts, wenn Ihr num_ctx niedrig bleibt. Sobald die Quantisierung aktiv ist, vergrößern Sie das Kontextfenster des Modells (Parameter num_ctx im Modelfile oder im API-Aufruf), um den eingesparten VRAM in nutzbaren Kontext umzuwandeln.

#In llama.cpp aktivieren

Per Befehlszeile mit llama.cpp wird die Quantisierung des KV-Caches mit zwei separaten Flags für die Schlüssel (K) und die Werte (V) sowie dem Flash-Attention-Flag gesteuert. K und V können unabhängig voneinander quantisiert werden, in der Praxis werden sie jedoch auf dieselbe Stufe gesetzt.

Terminal — llama-cli / llama-server
# -fa active Flash Attention (obligatoire)
# -ctk = type du cache des clés, -ctv = type du cache des valeurs
llama-server \
  -m modele.gguf \
  -c 32768 \
  -fa \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 99
-fa
Aktiviert Flash Attention. Ohne dieses Flag schlagen -ctk/-ctv mit einer Präzision unter f16 fehl.
-ctk q8_0
Quantisiert den Schlüsselcache auf 8 Bit. Mögliche Werte: f16, q8_0, q4_0, q4_1, q5_0, q5_1.
-ctv q8_0
Quantisiert den Werte-Cache. Dieselben zulässigen Werte wie bei -ctk.
-c 32768
Die angestrebte Kontextgröße. Durch die Quantisierung können Sie diese erhöhen, ohne die Speicherkapazität zu überschreiten.
→
K/V-Asymmetrie möglich
Der Werte-Cache (V) verträgt aggressive Quantisierung besser als der empfindlichere Schlüssel-Cache (K). Ein interessanter Kompromiss bei knappem VRAM: -ctk q8_0 -ctv q4_0. Sie sparen Speicher auf der V-Seite, ohne die Genauigkeit der Schlüssel zu beeinträchtigen.

#Wie viel Kontext gewinnt man: echte Zahlen

Der konkrete Gewinn hängt davon ab, welchen Anteil der KV-Cache an Ihrem VRAM-Budget hat. Bei einem Modell, das problemlos in den VRAM passt, schafft die Quantisierung des Caches nur etwas zusätzlichen Spielraum. Bei einem Modell, das den VRAM bereits voll auslastet, kann sie den Unterschied zwischen 8k und 24k Kontext ausmachen. Hier sind beobachtete Größenordnungen bei gleichbleibender VRAM-Kapazität:

FP16 → Q8_0
Cache geteilt durch 2. Praktisch: tragbarer Kontext verdoppelt, wenn der Cache den Budgetanteil dominiert.
FP16 → Q4_0
Cache geteilt durch 4. Begriffslänge bis zu ~3-4× länger, mit einem messbaren Qualitätsverlust.
Beispiel 14B auf RTX 4080 16 GB
Von ~16k Kontext in FP16 auf ~32k+ in Q8_0, wobei das Modell und alles Weitere weiterhin in dieselben 16 GB passen.
Beispiel 32B auf RTX 4090 24GB
Die Umstellung des Caches auf Q8_0 ermöglicht es häufig, auch lange RAG-Dokumente ohne CPU-Offloading zu verarbeiten.
i
Der Vorteil beschränkt sich nicht auf die Speicherersparnis
Ein kleinerer KV-Cache bedeutet auch, dass bei jedem Token weniger Daten über den Speicher übertragen werden müssen. Bei sehr langen Kontexten lässt sich mit Q8 neben der VRAM-Ersparnis manchmal eine leicht höhere Generierungsgeschwindigkeit beobachten. Rechnen Sie nicht grundsätzlich damit, aber es ist ein häufiger Bonus.

#Auswirkungen auf die Qualität je nach Modell

Das ist die entscheidende Frage. Die Quantisierung des Caches bringt Rauschen in den Attention-Mechanismus, und nicht alle Modelle reagieren darauf gleich. Die Faustregel, die sich aus den Community-Tests ergibt:

Q8_0 im Cache
Bei der überwiegenden Mehrheit der Modelle ist der Unterschied kaum feststellbar. Perplexität und wahrgenommene Qualität sind nahezu identisch mit denen bei FP16. Diese Einstellung sollten Sie standardmäßig aktivieren – fast ohne darüber nachzudenken.
Q4_0 im Cache
Sichtbare und unterschiedlich starke Qualitätseinbußen. Manche Modelle verkraften das sehr gut, andere schweifen bei sehr langen Kontexten ab, verlieren den Faden oder halluzinieren häufiger. Für IHREN Anwendungsfall testen.
Modelle mit GQA
Sie sind im Allgemeinen robuster gegenüber der Quantisierung des Caches, da ihr Cache bereits kompakt und gut strukturiert ist.
Empfindliche Aufgaben (Code, Berechnungen, Extraktion nach strikten Vorgaben)
Anfälliger für Qualitätseinbußen durch Q4. Bleiben Sie bei Q8 für alles, was sachliche Genauigkeit erfordert.
!
Testen Sie Q4 vor der Einführung
Setzen Sie den Cache im Produktivbetrieb niemals in Q4 ein, ohne zuvor die Ausgaben mit Ihren eigenen langen Prompts verglichen zu haben. Die VRAM-Ersparnis ist verlockend, aber ein Verlust an Zuverlässigkeit bei einem RAG-System oder einem Agenten kostet mehr als der eingesparte VRAM. Q8 ist die sichere Standardeinstellung; Q4 ist eine Optimierung, die empirisch validiert werden muss.

#Fehlerbehebung

„flash attention required“ oder Cache ignoriert
Sie haben -fa (llama.cpp) oder OLLAMA_FLASH_ATTENTION=1 (Ollama) vergessen. Der quantisierte Cache wird ohne Hinweis auf FP16 zurückgesetzt, oder es wird ein Fehler ausgelöst.
Kein VRAM-Vorteil sichtbar
Ihr Kontext ist zu kurz, als dass der Cache viel Speicher beanspruchen würde. Die Einsparung zeigt sich nur bei langen Prompts. Erhöhen Sie num_ctx / -c, um sie zu beobachten.
Die Qualität verschlechtert sich bei langen Prompts
Sie verwenden wahrscheinlich Q4 bei einem Modell, das damit schlecht zurechtkommt. Stellen Sie K wieder auf q8_0 um (gegebenenfalls sogar alles auf q8_0) und testen Sie erneut.
Ollama-Variablen ohne Wirkung
Sie werden nur beim Start des Daemons eingelesen. Starten Sie den Dienst neu, nachdem Sie die Variablen gesetzt haben, und prüfen Sie, ob sie für den ollama-Prozess tatsächlich sichtbar sind.
Immer noch OOM, trotz Quantisierung
Das Modell selbst überschreitet die Speicherkapazität, nicht der Cache. Quantisieren Sie auch die Gewichte (Q4_K_M) oder wechseln Sie zu einem kleineren Modell.
Schnelle Diagnose
# Vérifier ce qui tourne sur GPU et la VRAM consommée
ollama ps
nvidia-smi

# Confirmer que les variables sont bien vues par le daemon (Linux)
systemctl show ollama --property=Environment

#Weiterführende Informationen

Die Quantisierung des KV-Cache ist eine von mehreren Möglichkeiten, große Kontexte lokal unterzubringen. Diese Leitfäden ergänzen den Überblick:

Flash Attention 2 bei einem lokalen LLM: aktivieren und den Leistungsgewinn per Benchmark messen
Die Voraussetzung für die KV-Quantisierung und zugleich ein eigenständiger Vorteil bei Speicherverbrauch und Geschwindigkeit. Zuerst lesen, wenn Flash Attention bei Ihnen noch nicht aktiv ist.
Quantisierung wählen (Q4, Q5, Q8, FP16)
Zur Quantisierung der Modellgewichte – des anderen großen Postens beim VRAM-Verbrauch, ergänzend zur Quantisierung des Caches.
Ollama installieren: Windows, macOS und Linux
Falls Ihr Stack noch nicht eingerichtet ist: mit den GPU-Voraussetzungen für die passende Dimensionierung.
Hat Ihnen dieser Guide geholfen?

Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.