Die Schlagzeile „DeepSeek V4 nutzt 98 % weniger Speicher“ klingt nach einem Durchbruch für alle, die GPUs bezahlen, beschaffen oder auslasten müssen. Genau dort liegt aber die Falle: In den belastbaren Quellen geht es vor allem um KV-Cache-Kompression bei langen Kontexten – nicht um eine offiziell bestätigte Senkung des gesamten VRAM-Bedarfs um 98 % [5][
13][
14].
VRAM ist der Videospeicher einer GPU. Der KV-Cache wiederum ist nur ein Teil davon: Er speichert Key- und Value-Vektoren bereits verarbeiteter Tokens, damit ein Sprachmodell bei der nächsten Token-Erzeugung nicht alles neu berechnen muss. Bei sehr langen Dokumenten, langen Chats oder Agenten-Workflows kann dieser Cache zum Engpass werden. Er ist aber nicht identisch mit dem gesamten Speicherbedarf eines Modells.
Die vorsichtige Kurzfassung
Wer DeepSeek V4 präzise beschreiben will, sollte es eher so formulieren:
DeepSeek V4 reduziert mit Hybrid Attention, Compressed Sparse Attention (CSA) und Heavily Compressed Attention (HCA) den KV-Cache-Druck und die Attention-Kosten bei langen Kontexten deutlich. Die öffentlich verfügbaren Quellen reichen aber nicht aus, um „98 % weniger Gesamt-VRAM“ als Spezifikation zu behaupten [
13][
14].
Dieser Unterschied ist nicht akademisch. Für Benchmarks, Cloud-Kosten, GPU-Cluster oder Einkaufsentscheidungen macht es einen großen Unterschied, ob nur ein Cache kleiner wird – oder ob das gesamte Serving-Setup entsprechend weniger Speicher braucht.
Was die offiziellen Angaben tatsächlich sagen
DeepSeeks API-News-Seite führt DeepSeek-V4 Preview mit dem Datum 24. April 2026 auf [5]. Die Model Card nennt als Modellfamilie DeepSeek-V4-Pro und DeepSeek-V4-Flash und beschreibt V4 als Mixture-of-Experts-Sprachmodellreihe, die das DeepSeekMoE-Framework und die Multi-Token-Prediction-Strategie beibehält, aber unter anderem eine Hybrid-Attention-Architektur einführt [
14].
Am nächsten an der Speicherfrage liegt die Beschreibung der Long-Context-Attention. NVIDIA erklärt, dass Compressed Sparse Attention (CSA) KV-Einträge per dynamischer Sequenzkompression verdichtet, um den Speicherbedarf des KV-Caches zu senken; anschließend macht DeepSeek Sparse Attention (DSA) die Attention-Matrizen spärlicher und reduziert Rechenaufwand [13]. Heavily Compressed Attention (HCA) geht noch weiter und fasst KV-Einträge über mehrere Token-Gruppen hinweg zu einem komprimierten Eintrag zusammen, was die Größe des KV-Caches zusätzlich verringert [
13].
Das belegt: V4 ist klar auf geringere KV-Cache-Größe und niedrigere Attention-Kosten bei langen Kontexten ausgelegt. Es belegt aber nicht, dass alle VRAM-Komponenten im gleichen Verhältnis schrumpfen.
98 %, 90 %, 9,5x: Diese Zahlen sollte man nicht vermischen
Die Zahl 98 % taucht am deutlichsten in einem nutzergenerierten LinkedIn-Beitrag auf, dessen Titel behauptet, DeepSeek Sparse Attention verkleinere KV-Speicher in realen Serving-Szenarien um 98 % [21]. So ein Beitrag kann ein Hinweis sein, dem man nachgeht. Er ist aber keine offizielle DeepSeek-Spezifikation.
Eine besser einzuordnende Drittanbieterangabe ist die 10-%-KV-Cache-Zahl. Wccftech berichtet, DeepSeek V4 benötige im Vergleich zu DeepSeek V3.2 nur 27 % der Single-Token-Inference-FLOPs und 10 % des Key-Value- beziehungsweise KV-Caches [20]. Rechnet man nur diese KV-Cache-Aussage um, entspricht das etwa 90 % weniger KV-Cache. Es sagt aber nichts darüber aus, dass bei jeder Kontextlänge, jeder Batch-Größe, jeder Hardwarekonfiguration oder beim gesamten VRAM dieselbe Reduktion gilt [
20].
Eine weitere Schlagzeile spricht von 9,5x lower memory requirements [3]. Mathematisch bedeutet 1/9,5 etwa 10,5 % Restbedarf, also rund 89,5 % weniger. Auch das ist nicht 98 % – und es bleibt zu prüfen, ob damit KV-Cache, ein bestimmtes Long-Context-Szenario oder wirklich der komplette Deploymentspeicher gemeint ist [
3].
| Behauptung | Stand der Belege | Genauere Einordnung |
|---|---|---|
| Gesamt-VRAM sinkt um 98 % | Keine offizielle Bestätigung in den vorliegenden Quellen | Nicht als Einkaufs-, Kapazitäts- oder Marketingaussage verwenden [ |
| KV-Cache wird stark komprimiert | Technisch gut gestützt | CSA und HCA komprimieren KV-Einträge für lange Kontexte [ |
| 10 % KV-Cache | Drittanbieterbericht | Entspricht gegenüber V3.2 etwa 90 % weniger KV-Cache, nicht 90 % weniger Gesamt-VRAM [ |
| 9,5x geringerer Speicherbedarf | Drittanbieter-Schlagzeile | Entspricht rechnerisch rund 89,5 % Reduktion; der genaue Bezugsrahmen bleibt entscheidend [ |
Warum KV-Cache nicht dasselbe ist wie Gesamt-VRAM
Bei langen Kontexten kann der KV-Cache tatsächlich einer der wichtigsten Speicherfaktoren sein. Hugging Face beschreibt das Problem bei lang laufenden Agenten-Workloads: Tool-Ergebnisse werden immer wieder an den Kontext angehängt, und jedes folgende Token muss mit einem längeren bisherigen Verlauf umgehen; sowohl Single-Token-Inference-FLOPs als auch KV-Cache-Größe wachsen mit der Sequenzlänge [17]. In der GitHub-Version des Hugging-Face-Beitrags werden typische Ausfälle langer Agentenläufe ähnlich beschrieben: Der Trace überschreitet das Kontextbudget, der KV-Cache füllt die GPU, oder Tool-Aufruf-Runden verlangsamen die Aufgabe [
22].
Ein vollständiges Modell-Deployment besteht aber aus mehr als KV-Cache. Selbst der LinkedIn-Beitrag, der die 98-%-Behauptung prominent macht, trennt in seiner Beispielrechnung zwischen Shared Weights, Expert Weights, Activations, KV-Cache und Framework-Overhead [21]. Genau das zeigt, warum man Speicherplanung sauber aufteilen muss: Wenn der KV-Cache in einem bestimmten Long-Context-Szenario stark schrumpft, folgt daraus nicht automatisch, dass der gesamte Serving-Stack im gleichen Verhältnis weniger VRAM benötigt.
CSA und HCA sind Effizienztechnik, keine magische Prozentzahl
DeepSeek V4 ist technisch trotzdem interessant. Der Ansatz zielt auf einen besonders teuren Teil von Million-Token-Kontexten: Attention und KV-Cache bei sehr langen Sequenzen. NVIDIA beschreibt, dass CSA KV-Einträge komprimiert, Attention-Matrizen spärlicher macht und dadurch Speicher- sowie Rechenaufwand reduziert; HCA fasst zusätzlich KV-Einträge mehrerer Token-Sets in komprimierte Einträge zusammen [13].
Auch der technische Bericht zu DeepSeek V4 nennt Infrastruktur-Optimierungen für Training und Inferenz, darunter einen einzelnen fused Kernel für MoE-Module, der Berechnung, Kommunikation und Speicherzugriffe überlappen soll [2]. Das sind ernst zu nehmende Effizienzmaßnahmen. Sie sind aber weiterhin kein direkter Beleg für „98 % weniger Gesamt-VRAM“.
Worauf es bei einer echten Bewertung ankommt
Wer DeepSeek V4 für lange Dokumente, lange Dialoge oder Agenten-Workflows prüft, sollte nicht an einer einzelnen Prozentzahl hängen bleiben. Die belastbaren Hinweise sprechen dafür, dass V4 den KV-Cache bei langen Kontexten deutlich entlastet [13][
20][
22]. Für Beschaffung, Kapazitätsplanung oder öffentliche Produktversprechen reicht das aber nicht aus, um „98 % weniger Speicher“ als allgemeine Aussage zu verwenden [
21].
Sinnvoller ist ein Benchmark mit den eigenen Parametern: Kontextlänge, Batch Size, gleichzeitige Anfragen, Serving Engine und GPU-Konfiguration. Wenn der eigene Engpass wirklich der KV-Cache ist, können CSA und HCA sehr relevant sein. Wenn dagegen Modellgewichte, Aktivierungen, Framework-Overhead oder Parallelisierungsstrategie dominieren, wird ein kleinerer KV-Cache nicht automatisch zu derselben prozentualen VRAM-Ersparnis im Gesamtsystem [13][
21][
22].
