DeepSeek V4.1 Flash liest mit 8B Parametern – klein ist das Modell nicht
DeepSeek veröffentlichte V4.1 Flash am 10. September 2026 und stellte das Modell zugleich über die eigene API bereit. Die Ankündigung von DeepSeek nennt einen Mixture-of-Experts-Backbone mit 552 Milliarden Parametern, von denen beim Einlesen 8 Milliarden und bei der Ausgabe 16 Milliarden aktiv sind.
Das senkt den Rechenaufwand bestimmter Inferenzphasen, macht V4.1 Flash aber nicht zu einem kompakten 8B-Modell. VentureBeat bestätigte den Start am selben Datum, den 552B-Backbone, ein Kontextfenster von einer Million Tokens und die Veröffentlichung kommerziell nutzbarer Gewichte unter MIT-Lizenz. Wer das Modell selbst betreiben will, muss daher zwischen aktiven, vorhandenen und zwischengespeicherten Parametern unterscheiden.
8B gelten nur für das Einlesen
Die 8 Milliarden aktiven Parameter beschreiben den Prefill: die Phase, in der das Modell einen Prompt, Dokumente oder den bisherigen Verlauf eines Agenten verarbeitet. Beim anschließenden autoregressiven Erzeugen der Antwort werden 16 Milliarden Parameter pro Token aktiviert. Das Versprechen im Namen „Flash“ bezieht sich damit auf einen sparsamen Rechenpfad, nicht auf die Gesamtgröße der Gewichte.
Grundlage ist eine Causal-Encoder-Decoder-Architektur mit 40 Transformer-Schichten. Je 20 Schichten entfallen auf Encoder und Decoder. Der Decoder gewinnt seinen globalen KV-Cache aus den finalen Zuständen des Encoders, statt für jede Decoderschicht eine vollständige eigene Darstellung der Eingabe vorzuhalten.
Aktive Parameter messen Rechenarbeit, nicht die Größe des Downloads. Ein Mixture-of-Experts-Modell wählt für ein Token nur einen Teil seiner Experten aus; die übrigen Gewichte gehören dennoch zum veröffentlichten Modell und müssen bei einer eigenen Installation gespeichert und für die Inferenz erreichbar sein. Aus „8B beim Prefill“ folgt deshalb weder ein Speicherbedarf auf dem Niveau eines gewöhnlichen 8B-Modells noch eine unkomplizierte Ausführung auf einzelner Consumer-Hardware.
Der KV-Cache schrumpft unabhängig von den Gewichten
Die offizielle Modellkarte auf Hugging Face dokumentiert 890 Byte globalen KV-Cache pro Token, etwa ein Viertel des Werts von V4 Flash; der persistent gespeicherte Cache soll ungefähr auf ein Achtel sinken. Dort sind außerdem der 552B-Backbone, 196 Milliarden Parameter für den bedingt abgefragten Engram-Speicher, die 8B-/16B-Aktivierung, das Kontextlimit von einer Million Tokens und die MIT-Lizenz für Repository und Gewichte ausgewiesen.
Bei einer Million Tokens ergeben 890 Byte pro Token rechnerisch rund 890 Megabyte für diesen globalen Cache einer Sequenz. Das ist keine vollständige Schätzung des Laufzeitspeichers: zusätzliche Zustände, Puffer, Parallelisierung und die Modellgewichte kommen hinzu. Die Zahl zeigt lediglich, welche konkrete Speicherlast die neue Architektur bei langen Kontexten reduziert.
Für Agentensysteme kann diese Trennung erheblich sein. Wenn ein Agent dieselben Systemanweisungen, Werkzeugdefinitionen oder Teile eines Repositorys wiederholt verarbeitet, beeinflussen Prefill und KV-Cache den Durchsatz und die Kosten. Die vollständigen Gewichte bleiben davon unberührt; Cache-Kompression ersetzt keine Kapazitätsplanung für das Modell selbst.
552B sind nicht zwingend die vollständige Zählung
Bei der Gesamtzahl der Parameter sind die veröffentlichten Angaben erklärungsbedürftig. Die Modellkarte bezeichnet 552 Milliarden ausdrücklich als Backbone-Parameter und führt 196 Milliarden Engram-Parameter separat auf. Die automatische Metadatenanzeige derselben Plattform weist dagegen 763 Milliarden Parameter aus.
Diese Werte messen offenbar nicht exakt dieselbe Abgrenzung. Der Backbone beschreibt die tragende Modellarchitektur, während Engram eine zusätzliche, nur bedingt abgefragte Speicherkomponente ist; die Plattformanzeige kann darüber hinaus weitere ausgelieferte Tensoren oder eine andere Zählweise erfassen. Ohne eine abgeglichene Aufstellung sollte 552B deshalb als bestätigte Backbone-Größe gelesen werden, nicht als zweifelsfreie Gesamtzahl sämtlicher Dateien.
Für das Self-Hosting ist die Unterscheidung praktisch: Entscheidend sind Dateiumfang, Zahlenformat, Quantisierung, Verteilung über Beschleuniger und Hosts sowie zusätzlicher Laufzeitspeicher. DeepSeek richtet seine Kontaktaufforderung für groß angelegte Installationen an Betreiber mit 2.000 GPUs plus Storage-Cluster. Das ist kein veröffentlichter Mindestbedarf für jede Installation, zeigt aber, dass der Hersteller großflächige Bereitstellungen in einer Rechenzentrumsklasse verortet.
Die API wechselt auf neue Modellrouten
Über die DeepSeek-API ist V4.1 Flash unter der Kennung deepseek-flash verfügbar. Die ausgemusterten Kennungen deepseek-v4-flash und deepseek-v4-flash-vision-exp werden vorübergehend auf das neue Modell geleitet. Eine weiterhin akzeptierte alte Kennung garantiert daher nicht, dass im Hintergrund der vorherige Checkpoint arbeitet.
Für den 14. September 2026 um 04:00 Uhr UTC kündigte DeepSeek einen weiteren Wechsel an: Anfragen an deepseek-v4-pro sollen bis zum Erscheinen von V4.1 Pro ebenfalls zu V4.1 Flash geleitet und zu dessen Tarifen abgerechnet werden. Am 13. September war diese Umstellung noch nicht wirksam. Für reproduzierbare Anwendungen ist die serverseitige Zuordnung damit ebenso relevant wie der im eigenen Code verwendete Modellname.
Gesichert sind zum jetzigen Stand die Veröffentlichung, die asymmetrische Aktivierung, der verkleinerte Cache, die API-Verfügbarkeit und die offenen Gewichte. Noch fehlen unabhängige Messungen, die Speicherbedarf und Durchsatz unterschiedlicher Self-Hosting-Konfigurationen systematisch vergleichen. Gerade deshalb ist die Bezeichnung „8B aktiv“ nur mit ihrer Phasengrenze aussagekräftig: V4.1 Flash liest sparsam, bleibt als vollständiges Modell aber groß.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.