DeepSeek V4.1 Flash ist am 10. September 2026 gestartet. Das neue Open-Weight-Modell von DeepSeek verarbeitet Text und Bilder, erzeugt Text und kombiniert 552 Milliarden Gesamtparameter mit einer asymmetrischen Aktivierung: Beim Einlesen sind etwa 8 Milliarden Parameter aktiv, bei der Ausgabe rund 16 Milliarden. Dazu kommen ein Kontextfenster von bis zu 1 Million Token und ein globaler KV-Cache von etwa 890 Byte pro Token. Der entscheidende Haken: Die Effizienz beim Serving macht das Modell nicht automatisch leicht lokal betreibbar.
Was ist DeepSeek V4.1 Flash?
DeepSeek V4.1 Flash ist ein multimodales Mixture-of-Experts-Modell (MoE). Bei dieser Architektur steht ein großer Pool spezialisierter Parameter bereit, von dem für einen einzelnen Verarbeitungsschritt nur ein Teil verwendet wird. Das Modell nimmt Text und Bilder als Eingabe entgegen und erzeugt Text als Ausgabe.
Die Gewichte sind öffentlich unter der MIT-Lizenz verfügbar. Für API-Anfragen nennt DeepSeek den Modellbezeichner deepseek-flash. Ältere V4-Flash-Bezeichner wurden in der Ankündigung ebenfalls mit einer Weiterleitung zu V4.1 Flash in Verbindung gebracht. Separat kündigte DeepSeek an, Anfragen an deepseek-v4-pro ab dem 14. September 2026 bis zum Start von V4.1 Pro auf V4.1 Flash zu routen. Diese Routing-Regel ist eine angekündigte Änderung und keine Aussage über ihren späteren tatsächlichen Betrieb.
Warum die Parameterzahlen nicht dasselbe bedeuten
Die 552 Milliarden Parameter beschreiben die Gesamtgröße des Modell-Backbones. Die etwa 8 Milliarden aktiven Parameter beim sogenannten Prefill – also beim Einlesen der Eingabe – und die 16 Milliarden beim Decoding – der schrittweisen Ausgabe – sind dagegen die jeweils aktivierten Teile pro Token.
Diese Zahlen darfst du nicht gleichsetzen. Weniger aktive Parameter können den Rechenaufwand eines einzelnen Verarbeitungsschritts senken, sagen aber allein nicht, wie viel Speicher eine lokale Installation für Gewichte, Zwischendaten und zusätzliche Komponenten benötigt. Genau hier liegt der Unterschied zwischen effizienter Inferenz und einem kleinen Desktop-Modell.
Die Architektur umfasst 40 Schichten als Causal Encoder-Decoder: 20 Schichten entfallen auf den Encoder, 20 auf den Decoder. Ergänzt wird sie durch Verfahren wie Compressed Sparse Attention 2, DSpark für spekulatives Decoding und Engram-Speicher, der über tokenbasierte Zugriffe nur teilweise verwendet wird.
KV-Cache, Kontextfenster und Serving-Kosten
Der KV-Cache speichert bei der Verarbeitung bereits berechnete Zustände, damit ein Modell lange Eingaben nicht ständig komplett neu bearbeiten muss. DeepSeek gibt für V4.1 Flash einen globalen Speicherbedarf von etwa 890 Byte pro Token an. Für DeepSeek V4 Flash werden im gleichen technischen Vergleich 3.514 Byte pro Token genannt.
Das ist für lange Kontexte und Agenten-Workloads relevant: Je weniger Cache-Speicher pro Token anfällt, desto kleiner kann der Speicherbedarf während der laufenden Verarbeitung ausfallen. DeepSeek beschreibt außerdem einen geringeren Bedarf an HBM und SSD-Cache als bei der vorherigen V4-Flash-Generation.
Das maximale Kontextfenster umfasst bis zu 1.000.000 Token. Das ist eine Kapazitätsangabe, keine Garantie dafür, dass jede Aufgabe mit einer Million Token gleich zuverlässig oder gleich schnell verarbeitet wird. Die praktische Geschwindigkeit hängt unter anderem vom Anbieter, dem Modellmodus und der konkreten Aufgabe ab.
Benchmarks mit Bedingungen lesen
DeepSeek weist für V4.1 Flash hohe Werte in mehreren spezialisierten Tests aus. Bei maximalem Reasoning-Aufwand nennt das Modell unter anderem 74,2 Punkte bei DeepSWE v1.1, 88,1 bei CyberGym, 90,6 bei Terminal-Bench 2.1 und 54,8 bei AutomationBench. Diese Zahlen gehören jeweils zu den genannten Testreihen und Einstellungen; daraus folgt keine allgemeine Rangliste aller KI-Modelle.
Ein unabhängiger Bewertungsdienst weist für die Konfiguration mit maximalem Reasoning einen Intelligence-Index von 39,5, eine mittlere Ausgabegeschwindigkeit von 206,3 Token pro Sekunde und 1,13 Sekunden bis zum ersten Ausgabeblock aus. Diese Messwerte stammen aus einer eigenen Methodik und sind deshalb nicht direkt mit jedem lokalen Lauf oder jedem Benchmark aus DeepSeeks Modellkarte vergleichbar.
| Modell | Gesamtparameter | Aktive Parameter | Kontextfenster | Terminal-Bench 2.1 | CyberGym | DeepSWE v1.1 | Terminal-Bench 4.0 | Ausgabegeschwindigkeit unter der genannten Artificial-Analysis-Methode |
| DeepSeek V4.1 Flash | 552B | 8B Eingang / 16B Ausgabe | bis 1.000.000 Token | 90,6 | 88,1 | 74,2 | 31,2 | 206,3 Token/s |
| DeepSeek V4 Pro 0813 | 1,6T | 49B | — | 87,9 | 83,3 | 62,7 | 12,4 | 72,3 Token/s |
| GPT-5.6 Sol | — | — | — | 88,8 | 84,5 | 73,0 | 39,9 | 111,9 Token/s |
| Claude Opus 5 | — | — | — | 89,1 | — | 74,0 | 51,8 | 65,8 Token/s |
Die Tabelle zeigt, warum einzelne Spitzenwerte mit Vorsicht zu lesen sind: V4.1 Flash liegt in einigen Prüfungen vorn, in Terminal-Bench 4.0 aber hinter GPT-5.6 Sol und Claude Opus 5. Ein 24-Prompt-Coding-Test mit wiederholten Durchläufen weist zudem auf Schwankungen zwischen einzelnen Modellantworten hin. Für die Praxis zählt deshalb nicht nur der höchste Score, sondern ob das Modell im eigenen Arbeitsablauf zuverlässig genug bleibt.
Preise und V4-Pro-Weiterleitung
Die offizielle API-Abrechnung ist global in US-Dollar pro 1 Million Token angegeben, nicht als deutscher Euro-Tarif. DeepSeek unterscheidet zwischen Cache-Treffern und nicht gecachten Eingaben sowie zwischen Neben- und Spitzenzeiten. Für die tatsächlichen Kosten zählen daher mindestens vier Faktoren: Eingabemenge, Cache-Status, Ausgabemenge und Zeitfenster.
Für deutsche Nutzer bedeutet das: Eine Euro-Preisangabe lässt sich aus der globalen API-Tabelle nicht ableiten. Ebenso sollte ein einzelner Betrag nicht als dauerhaft gültiger Modellpreis verstanden werden, wenn sich die Abrechnung nach Zeitfenster und Cache-Nutzung unterscheidet.
Die angekündigte Weiterleitung von V4-Pro-Anfragen auf V4.1 Flash betrifft zusätzlich die API-Kompatibilität und die Zuordnung bestehender Modellbezeichner. Sie ist von der eigentlichen Veröffentlichung am 10. September getrennt zu betrachten.
Open Weights, lokale Hardware und die Grenze des Flash-Namens
Die offenen Gewichte machen Selbsthosting grundsätzlich möglich, aber nicht automatisch bequem. Eine lokale Demonstration verwendete vier NVIDIA DGX Sparks, SSD-Auslagerung und eine mehrteilige Speicherverwaltung. In diesem Aufbau wurden ungefähr 70 Token pro Sekunde bei Coding-Aufgaben und 54 Token pro Sekunde in einem Agenten-Harness beobachtet.
Das sind Werte dieses konkreten Setups. Sie lassen sich weder als API-Geschwindigkeit noch als allgemeine Mindestanforderung für lokale Installationen verwenden. Auch die aktiven 8 beziehungsweise 16 Milliarden Parameter liefern keine einfache Antwort auf die Frage, ob ein Rechner mit 256 GB Arbeitsspeicher genügt: Gesamtgewichte, Quantisierung, Auslagerung, Speicherbandbreite und Laufzeitumgebung spielen zusammen.
Für wen ist V4.1 Flash interessant?
API-Nutzer und Coding-Teams bekommen ein Modell, das lange Kontexte, Bilder und steuerbaren Reasoning-Aufwand in einem System verbindet. Die Kosten müssen sie anhand von Cache-Nutzung, Tokenvolumen und Zeitfenster kalkulieren – nicht anhand eines einzigen Werbewerts.
Entwickler von Agenten profitieren vor allem von der Kombination aus langem Kontext, Coding-Fokus und der auf Speicherreduktion ausgelegten Architektur. Die Benchmarkwerte zeigen dafür interessante Signale, ersetzen aber keinen Test mit dem eigenen Agenten-Harness.
Fans lokaler KI erhalten MIT-lizenzierte Gewichte und technische Materialien für Konvertierung, Inferenz und Evaluierung. Der praktische Einstieg ist jedoch deutlich anspruchsvoller als bei kleineren Modellen. V4.1 Flash ist offen zugänglich, aber nicht deshalb automatisch für typische Desktop-Hardware gedacht.
Unterm Strich ist DeepSeek V4.1 Flash weniger wegen einer pauschalen Vorherrschaft spannend als wegen seines technischen Ansatzes: ein sehr großes MoE-Modell, selektive Aktivierung und ein stark komprimierter KV-Cache. Für API- und Agenten-Workloads kann diese Kombination die Serving-Ökonomie verändern. Ob sie im Alltag überzeugt, entscheidet sich dagegen an den konkreten Aufgaben, den Abrechnungsbedingungen und der verfügbaren Hardware.
