DeepSeek V4.1-Flash-Architektur 2026

Micha Mirz, Sovereign AI bei Pexon Consulting | 7 Min. Lesezeit | 18.09.2026

TL;DR: DeepSeek Engrams in fünf Sätzen

DeepSeek Engrams sind ein externes Gedächtnis aus 196 Milliarden Parametern, das kurze Wortmuster als Hash-Tabelle speichert statt im Modellkern. Zusammen mit dem Causal Encoder-Decoder drückt das den KV-Cache auf 890 Byte pro Token. Pexon prüft für Sie, ob daraus günstigere Inferenz wird oder nur eine größere Hardware-Rechnung. Die kurze Antwort: nur bei sehr langen, wiederkehrenden Kontexten.

Das Problem: ein Modell, das kleiner wirkt, als es im Speicher ist

Am 10. September 2026 hat DeepSeek V4.1 Flash veröffentlicht, unter MIT-Lizenz, mit 8 Milliarden aktiven Parametern beim Verarbeiten der Eingabe und 16 Milliarden beim Erzeugen der Antwort. Diese beiden Zahlen stehen in jedem Zweitartikel, und sie erzeugen ein falsches Bild.

Der Backbone hat 552 Milliarden Parameter. Dazu kommen 196 Milliarden Engram-Parameter. The Register nennt 763 Milliarden gesamt, DeepSeeks eigene Modellkarte zählt Backbone und Engram getrennt. Wie man es auch addiert: das Ding ist mehr als doppelt so groß wie das Modell, das es ablöst.

Die interessante Frage ist deshalb nicht, ob V4.1 Flash gut ist. Sie ist, ob die drei Architektur-Bausteine, die DeepSeek dafür eingebaut hat, den Mehraufwand rechtfertigen.

Was DeepSeek Engrams von n-Grammen unterscheidet

Ein n-Gramm ist eine statistische Häufigkeit: wie oft folgt Wort C auf A und B. Ein Engram ist eine gelernte Repräsentation, die über denselben Schlüssel gefunden wird. Der Schlüssel ist ein Hash aus 2-, 3- und 4-Token-Folgen, der Inhalt ist ein trainierter Vektor, und wie stark er in den Modellstrom einfließt, entscheidet ein gelerntes Gate.

Konkret: In den Schichten 1 und 14 liegt je eine Hash-Tabelle mit rund 384 Millionen Zeilen à 256 Dimensionen. Acht unabhängige Lookup-Heads bilden jedes n-Gramm auf mehrere Positionen ab. Kollidiert ein Hash, gleichen die anderen Heads das aus. Pro Token braucht es ein paar Dutzend Tabellenzugriffe, keine dichte Matrixmultiplikation.

Der Einwand, das sei nur umbenanntes Context Caching, hält der Prüfung nicht stand, und zwar aus einem einfachen Grund: Context Caching speichert Ihre Anfrage, damit derselbe Prompt beim zweiten Mal billiger wird. Ein Engram speichert Trainingswissen, das für jede Anfrage gilt, auch für die erste.

Der eigentliche Zweck ist Arbeitsteilung. Kurze wiederkehrende Sprachmuster muss sich das Backbone nicht mehr merken, es kann seine aktiven Parameter für Schlussfolgerungen verwenden. Alibaba geht mit Qwen 3.8-Flash-Next und einem 51 Milliarden Parameter großen Speicherpool denselben Weg, deutlich kleiner.

Der Causal Encoder-Decoder: halbe Tiefe beim Prefill

40 Schichten, aufgeteilt in 20 Encoder- und 20 Decoder-Schichten. Beim Verarbeiten der Eingabe läuft der Text nur durch den Encoder. Der globale KV-Zustand, den der Decoder später braucht, wird aus dem finalen Encoder-Zustand projiziert, statt dass jede Decoder-Schicht ihn nochmal selbst aufbaut.

Das ist der Unterschied zu früheren Shared-Cache-Verfahren, und er ist wichtiger, als er klingt. Die nachgelagerten Schichten behalten ihre eigenen KV-Projektionen, sie teilen sich nur den darunterliegenden Zustand. Man spart den Speicher, ohne allen Schichten dieselbe Sicht aufzuzwingen.

DeepSeek gibt an, dass der Prefill-Rechenaufwand bei ausreichend langen Sequenzen dadurch etwa halbiert wird, während die FLOPs pro erzeugtem Token nur um rund 25 Prozent steigen, wenn der Kontext von 4.000 auf eine Million Token wächst. Dazu kommt CSA2, die zweite Generation der komprimierten Sparse Attention, mit einem 128-Token-Schiebefenster und drei statischen Modi: Full, Reindex und Reuse. Der globale KV liegt in FP4, ein E4M3-Skalierungsfaktor je 16 Kanäle.

Das Ergebnis dieser Kette ist die eine Zahl, die man sich merken sollte:

437-fach über vier Generationen. Für einen API-Betreiber heißt das vier- bis achtmal so viele gleichzeitige Nutzer bei gleichem KV-Speicher. Für Sie heißt es erstmal gar nichts, solange Sie das Modell nicht selbst betreiben.

Der Offloading-Punkt: Theorie und Serving-Rezept widersprechen sich

Hier wird es unangenehm, und hier steht die meistgestellte Frage zu dieser Architektur. Weil Engram-Tabellen reine Nachschlagewerke sind, sollten sich ihre Gewichte in günstigen Systemspeicher oder auf schnelle SSDs auslagern lassen, per RDMA-Prefetch parallel zur GPU-Berechnung. The Register rechnet auf dieser Basis vor, dass rund 567 GB GPU-Speicher für das volle Modell reichen.

Das offizielle vLLM-Rezept sagt etwas anderes. Stand 18.09.2026 verlangt es vLLM 0.30.0 als Docker-Image, ein pip-Wheel für diese Architektur gibt es nicht, es nennt 614 GB VRAM als Minimum inklusive Overhead, und es schreibt ausdrücklich, dass die Engram-Tabellen mit 183,1 GiB im VRAM liegen müssen. Von Host-Offloading steht dort kein Wort.

# vLLM 0.30.0, Docker-Image. Ein pip-Wheel existiert fuer diese Architektur nicht.
docker run --gpus all --ipc=host 
  -v ~/.cache/huggingface:/root/.cache/huggingface 
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 
  vllm/vllm-openai:v0.30.0 
  --model deepseek-ai/DeepSeek-V4.1-Flash 
  --tensor-parallel-size 4 
  --max-model-len 1048576 
  --language-model-only

Unsere Empfehlung dazu ist deutlich: Planen Sie keine Hardware auf einer Fähigkeit, die im Serving-Stack noch nicht existiert. Realistisch ist heute ein GB200-NVL4-Tray mit 768 GB bei TP4 oder ein H200-Knoten mit acht Karten. Wer 150 bis 170 GB im Rechner hat und das Modell lokal erwartet hat, wird es in dieser Generation nicht bekommen. Die Auslagerungsidee ist plausibel und wird vermutlich kommen, aber sie ist ein Versprechen, kein Feature.

Lohnt V4.1 Flash gegenüber V4 Flash? Die ehrliche Token-Rechnung

Nein, für die meisten Produktionsfälle nicht. Das ist die unbequeme Antwort, und die Zahlen stützen den Einwand, nicht das Modell.

Artificial Analysis misst den Intelligence Index bei 40 gegenüber 35 für deepseek/deepseek-v4-flash-0731. Fünf Punkte. Dafür verbraucht V4.1 Flash 89.000 Token je Aufgabe statt 62.000, und auf OpenRouter kostet die Ausgabe 0,60 statt 0,13 Dollar je Million.

Das ist der Faktor sechs bis sieben für fünf Indexpunkte. Dazu kommt ein zweiter Hebel, den DeepSeek selbst offenlegt: Wer die Denkstufe von 25 auf 100 hebt, kommt auf DeepSWE v1.1 von 66,0 auf 74,2 Prozent, zahlt dafür aber etwa die 2,5-fache Menge Ausgabe-Token. Die Architektur spart am Prefill, die Modellführung gibt es beim Decode wieder aus.

Es gibt genau einen Fall, in dem sich das dreht, und der steht in DeepSeeks eigener Preisliste: 0,003 Dollar je Million zwischengespeicherter Eingabe-Token außerhalb der Stoßzeiten, gegenüber 0,15 Dollar ohne Cache. Faktor 50. Wenn Sie Agenten mit sehr langem, weitgehend gleichbleibendem Kontext fahren, also Codebasen, Aktenbestände, Vertragskorpora, dann greift genau die Asymmetrie, für die der Causal Encoder-Decoder gebaut wurde. In jedem anderen Fall bleiben Sie bei V4 Flash 0731 und sparen Geld.

Drei Fragen entscheiden das in der Praxis:

1. Wiederholt sich Ihr Eingabekontext über viele Anfragen hinweg? Ohne Cache-Treffer verlieren Sie den einzigen echten Preisvorteil.
2. Ist Ihr Verhältnis von Eingabe zu Ausgabe klar eingabelastig? Der Architektur-Gewinn liegt im Prefill, nicht beim Schreiben der Antwort.
3. Brauchen Sie die fünf Indexpunkte messbar, oder ist das ein Benchmark-Gefühl? Wenn Sie es nicht am eigenen Testfall belegen können, ist die Antwort nein.

Was mit Mixture of Recursions noch dazukommen könnte

Technisch spricht nichts dagegen, praktisch ist es die naheliegende nächste Schraube. Mixture of Recursions teilt sich einen Schichtstapel über mehrere Durchläufe und lässt einen Router pro Token entscheiden, wie oft dieser Stapel durchlaufen wird. Das Paper von Juli 2025 zeigt 43,1 gegenüber 42,3 Prozent bei Few-Shot-Aufgaben mit fast 50 Prozent weniger Parametern.

Engrams sparen Gedächtnis, CED spart Prefill-Tiefe, MoR würde Decode-Tiefe sparen. Die drei greifen an unterschiedlichen Stellen an, sie schließen sich nicht aus. Nur: Wir sehen bei unseren Kunden, dass jede zusätzliche Architektur-Neuheit den Serving-Stack für Monate ausbremst. V4.1 Flash braucht heute ein Docker-Image, weil kein Wheel die Architektur kennt. Wer MoR obendrauf will, verlängert genau diese Wartezeit.

Häufig gestellte Fragen

Was kostet DeepSeek V4.1 Flash im Vergleich zu V4 Flash?

Über OpenRouter 0,15 Dollar je Million Eingabe-Token und 0,60 Dollar je Million Ausgabe-Token, gegenüber 0,03 und 0,13 Dollar bei V4 Flash 0731. Weil V4.1 zusätzlich rund 44 Prozent mehr Token je Aufgabe verbraucht, liegt der reale Aufgabenpreis eher beim Sechs- bis Siebenfachen. Über DeepSeeks eigene API mit zwischengespeicherter Eingabe außerhalb der Stoßzeiten sind es 0,003 Dollar je Million, das dreht die Rechnung für Agenten mit langem Kontext.

Kann ich DeepSeek Engrams auf langsameren Speicher auslagern?

Nach der Architekturbeschreibung ja, im offiziellen vLLM-Rezept vom Stand 18.09.2026 nein. Dort müssen die 183,1 GiB Engram-Tabellen im VRAM liegen. Planen Sie mit 614 GB VRAM, nicht mit der Auslagerungsvariante.

Sind Engrams dasselbe wie Prompt Caching?

Nein. Prompt Caching speichert die KV-Zustände Ihrer konkreten Anfrage und wirkt erst ab der zweiten identischen Anfrage. Engrams sind trainierte Parameter, die für jede Anfrage gelten, auch die erste. Die beiden ergänzen sich, bei DeepSeek sind auch beide aktiv.

Läuft das Modell auf 150 bis 170 GB lokalem Speicher?

Nicht in dieser Generation. Die niedrigste belegte Zahl sind 567 GB GPU-Speicher und die setzt Host-Offloading voraus, das der Serving-Stack heute nicht anbietet. Das Rezept selbst nennt 614 GB Minimum.

Wie viel Kontext verträgt V4.1 Flash wirklich?

1.048.576 Token über YaRN-Rope-Skalierung, bei rund 0,87 GiB globalem KV je Sequenz. Die FLOPs pro erzeugtem Token steigen dabei nur um etwa 25 Prozent gegenüber 4.000 Token Kontext. Das ist die eigentliche Leistung der Architektur, und sie ist unabhängig davon, ob sich der Preis für Sie rechnet.

Nächster Schritt

Wer ernsthaft in Richtung eigener Inferenz plant, braucht davor zwei Dinge geklärt: die hybride KI-Infrastruktur aus GPU-Speicher und Systemspeicher und ein tragfähiges Betriebsmodell für GPU-Cluster. Ohne beides wird aus dem Architektur-Fortschritt eine Rechnung ohne Gegenwert.

Verwandte Themen