DeepSeek V4.1 Flash: Chinas neue KI-Preis-Leistungs-Revolution
Geschrieben von Gab
Inhalt
DeepSeek V4.1 Flash wird von @kimmonismus als besonders schnelle Weiterentwicklung vorgestellt, nur sechs Wochen nach dem V4-Flash-Update vom Juli. Sein Beitrag greift die wichtigsten Eckdaten auf: eine Causal Encoder Decoder-Architektur, 552 Milliarden MoE-Parameter, davon 8 Milliarden bei der Eingabeverarbeitung aktiv und 16 Milliarden bei der Generierung, sowie einen KV-Cache, der nur noch ein Viertel des HBM und ein Achtel des SSD-Speichers der vorherigen Generation benötigt. Er fügt hinzu, dass DeepSeek nun DeepSeek V4 Pro bei Leistungsfähigkeit, Kosten und Geschwindigkeit übertreffen soll und dass der V4-Pro-Traffic ab dem 14. September vorübergehend auf V4.1 Flash umgeleitet werden soll.
Diese Einordnung gibt die Ankündigung im Großen und Ganzen korrekt wieder, legt den Schwerpunkt jedoch vor allem auf die schnelle Abfolge der Veröffentlichungen und den Produktsprung. Der offizielle Thread vermittelt ein vollständigeres Bild: Die Fortschritte werden nicht allein der Architektur zugeschrieben, sondern auch neuen Methoden des Vortrainings und einem in größerem Maßstab durchgeführten RL-Post-Training. Vor allem betrifft die operativ wichtigste Änderung hinter der Beschreibung eines „intelligenteren, schnelleren und effizienteren“ Flash-Modells den für lange Inferenzvorgänge erforderlichen Speicher, ein entscheidender Aspekt für KI-Agenten.
Die von @kimmonismus geteilte Grafik zeigt zudem ein weniger einheitliches Bild als die Marketingdarstellung: DeepSeek V4.1 Flash ist in mehreren Evaluierungen konkurrenzfähig, dominiert die Spitzenmodelle bei Terminal-Bench jedoch nicht durchgängig.
Der am 10. September veröffentlichte Beitrag von @kimmonismus stützt sich ausdrücklich auf den Thread des offiziellen DeepSeek-Accounts. Dieser Punkt ist wichtig: Die Zahlen, die Migration der Endpunkte und die Leistungsversprechen stammen ursprünglich vom Anbieter des Modells und nicht von dem Analysten, der sie zusammengefasst hat.
Hier ist der ursprüngliche Beitrag, den DeepSeek einige Stunden zuvor veröffentlicht hatte:
Der offizielle Thread: eine neue Familie, nicht nur ein einfaches Flash-Update
In seinem ersten Beitrag stellt @deepseek_ai V4.1 Flash als „das kleinste Modell unserer neuen Architekturfamilie“ mit nativem Bildverständnis vor. Die Positionierung ist eindeutig: Flash ist nicht mehr nur eine abgespeckte Variante, sondern das erste Modell einer Familie, die auf Geschwindigkeit, Durchsatz und Skalierbarkeit ausgelegt ist.
Der zweite Teil des Threads erläutert die Architektur im Detail. DeepSeek V4.1 Flash basiert auf einem MoE mit 552 Milliarden Parametern, aktiviert jedoch nicht bei jedem Schritt das gesamte Netzwerk. Laut DeepSeek sind während der Eingabeverarbeitung nur 8 Milliarden Parameter aktiv, bei der Generierung hingegen 16 Milliarden.
Diese Asymmetrie bildet den Kern der Causal Encoder Decoder-Architektur. Die Verarbeitung des Kontexts und die Erzeugung neuer Tokens verursachen nicht mehr dieselben Kosten und beanspruchen nicht exakt dieselben Ressourcen. Bei Anwendungsfällen, in denen ein umfangreicher Kontext gelesen werden muss, bevor eine vergleichsweise kurze Antwort generiert wird, kann diese Trennung das Kosten-Leistungs-Verhältnis verbessern.
Die offizielle Tabelle vergleicht V4.1 Flash mit V4 Pro 0813, V4 Flash 0731 und mehreren Konkurrenzmodellen. Für V4.1 Flash weist sie unter anderem 30,0 bei Terminal-Bench 3.0, 31,2 bei Terminal-Bench 4.0 und 74,2 bei DeepSWE v1.1 aus.
Wichtige Benchmarks von DeepSeek V4.1 Flash
| Benchmark | Angegebener Wert für V4.1 Flash | Einordnung |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | V4.1 Flash liegt in der offiziellen Tabelle vor GLM 5.3. |
| Terminal-Bench 4.0 | 31,2 | Das Modell bleibt hinter GLM 5.3 zurück, das mit 37,9 ausgewiesen wird. |
| DeepSWE v1.1 | 74,2 | Von DeepSeek hervorgehobenes Ergebnis für Softwareentwicklungsaufgaben. |
DeepSeek behauptet, dass seine neuen Vortrainingsmethoden in Kombination mit einem ambitionierteren RL-Post-Training das Modell vor führende Systeme bringen, darunter DeepSeek V4 Pro. Diese Präzisierung ist im Vergleich zur Zusammenfassung von @kimmonismus wichtig: Die Architektur spielt eine zentrale Rolle, erklärt die beanspruchten Ergebnisse aber nicht allein.
Die offizielle Formulierung ist bewusst einfach gehalten:
„Kleinerer KV-Cache. Größere Einsparungen.“ @deepseek_ai
Das konkreteste Versprechen von V4.1 Flash ist somit nicht unbedingt ein höherer Rohwert, sondern ein deutlich geringerer Speicherbedarf bei langen und wiederkehrenden Workloads.
Der DeepSeek-KV-Cache als entscheidender Hebel für Agenten
Der KV-Cache speichert die erforderlichen Repräsentationen, damit nicht bei jedem generierten Token der gesamte Kontext neu berechnet werden muss. Dieser Speicher ist für lange Unterhaltungen, Agenten mit Tool-Aufrufen, Code-Workflows, iterative Recherchen und Systeme mit umfangreicher Historie unverzichtbar.
DeepSeek gibt an, dass der Cache von V4.1 Flash nur noch Folgendes benötigt:
- Ein Viertel des HBM, das von der vorherigen Generation benötigt wurde.
- Ein Achtel des zuvor erforderlichen SSD-Speichers.
- Rund 890 Byte pro Token für den gesamten Cache, gegenüber 3.514 Byte bei V4 Flash laut der vom Unternehmen veröffentlichten Grafik.
Die offizielle Darstellung zeigt einen drastischen Rückgang seit DeepSeek-V1: 389.120 Byte pro Token bei V1, 48.068 bei V3.2, 3.514 bei V4 Flash und schließlich 890 bei V4.1 Flash.
Für den Betreiber von Agenten kann dieser Fortschritt bedeutsamer sein als ein marginaler Unterschied in einem Benchmark. Cache Hits machen häufig einen erheblichen Teil der Kosten aus, wenn ein Agent regelmäßig einen umfangreichen Kontext wiederverwendet. Die Komprimierung dieses Caches verringert sowohl die Belastung des GPU-Speichers als auch die in großem Maßstab erforderliche Speicherkapazität.
Genau darauf weist @datachad in den Antworten auf den Beitrag von @kimmonismus hin:
„Die Reduzierung des KV-Caches auf ein Viertel des HBM ist das, was für lokale Inferenz wirklich zählt.“ @datachad
Diese Beobachtung ist richtig, muss jedoch differenziert betrachtet werden. Ein kompakterer DeepSeek-KV-Cache macht das KI-Selbsthosting für bereits entsprechend ausgestattete Infrastrukturen zugänglicher. Dadurch wird ein MoE-Modell mit 552 Milliarden Parametern jedoch noch lange nicht zu einer Software, die sich problemlos auf einem PC ausführen lässt.
DeepSeek räumt dies indirekt ein, wenn das Unternehmen selbst von Bereitstellungen in einer ganz anderen Größenordnung spricht:
„Planen Sie eine groß angelegte Bereitstellung mit mehr als 2.000 GPUs und einem Speichercluster? Lassen Sie uns darüber sprechen.“ @deepseek_ai
Der kleinere Cache verbessert die Wirtschaftlichkeit des Betriebs erheblich, beseitigt jedoch nicht die durch die Modellgröße bedingte Hardwarehürde.
Das Modell und sein technischer Bericht sind über die Hugging-Face-Seite von DeepSeek-V4.1-Flash und den technischen Bericht zu DeepSeek V4.1 verfügbar. Das im Thread verfügbare Material reicht jedoch nicht aus, um die von @UnslothAI in einer Antwort gemachten Angaben zu „196B engram“ zu bestätigen. Diese Angabe sollte daher ohne direkte Prüfung des technischen Berichts nicht als verifizierte Spezifikation behandelt werden.
Ein API-Übergang, der Flash zum Standardprodukt macht
Die Ankündigung beschränkt sich nicht darauf, ein neues Modell zu bewerben. Sie strukturiert zugleich das DeepSeek-Angebot neu.
Im offiziellen Thread heißt es:
- V4 Flash und V4 Flash Vision Exp werden eingestellt.
- Die bisherigen Kennungen
deepseek-v4-flashunddeepseek-v4-flash-vision-expwerden vorübergehend an V4.1 Flash weitergeleitet, um die Kompatibilität zu gewährleisten. - Ab dem 14. September 2026 um 04:00 Uhr UTC werden auch Anfragen an DeepSeek V4 Pro an V4.1 Flash weitergeleitet.
- Diese Regelung soll bis zur Einführung von V4.1 Pro gelten.
- Von V4 Pro migrierte Anfragen werden zu den Tarifen von V4.1 Flash abgerechnet.
Diese Entscheidung geht weit über einen werblichen Vergleich hinaus. DeepSeek macht V4.1 Flash noch vor der Einführung von V4.1 Pro zu seinem maßgeblichen API-Produkt. Für Teams, die die API bereits verwenden, verringert die Migration das Risiko einer unmittelbaren Unterbrechung. Sie beseitigt jedoch nicht die Notwendigkeit, Ausgaben, Latenz, Tool-Aufrufe, native Vision-Funktionen und das Verhalten des Modells im Produktivbetrieb erneut zu validieren.
@bygregorr fasst das Problem aus Sicht von Anwendungsentwicklern zusammen:
„Sechs Wochen zwischen Architekturfamilien sind eine kurze Übergangsfrist für API-Entwickler.“ @bygregorr
DeepSeek reagiert darauf mit vorübergehender Kompatibilität und der Weiterleitung der bisherigen Kennungen. Dies ist eine pragmatische Lösung zur Aufrechterhaltung der Betriebskontinuität, aber keine Garantie für eine vollständige funktionale Gleichwertigkeit. Eine agentenbasierte Anwendung, die empfindlich auf Ausgabeformate, Tool-Aufrufe oder Reasoning-Richtlinien reagiert, muss dennoch erneut getestet werden.
Die Preistabelle von DeepSeek weist je nach Tageszeit unterschiedliche Preise pro Million Token aus. Außerhalb der Spitzenzeiten nennt sie 0,003 US-Dollar für Eingaben mit Cache, 0,15 US-Dollar für Eingaben ohne Cache und 0,6 US-Dollar für Ausgaben. Während der Spitzenzeiten steigen diese Beträge auf 0,006, 0,3 beziehungsweise 1,2 US-Dollar.
DeepSeek weist darauf hin, dass die Preise außerhalb der Spitzenzeiten 50 % der Spitzenpreise betragen. Diese Preisstruktur erhöht die Wirtschaftlichkeit flexibler Workloads, insbesondere bei Batch-Verarbeitungen, automatisierten Evaluierungen oder asynchronen agentischen Aufgaben.
Ein in der erweiterten Diskussion erwähnter Drittanbieter-Post von @ns123abc spricht von einer etwa 86-mal günstigeren Ausführung pro Million Tokens und einem Durchsatz von 420 bis 507 Tokens pro Sekunde. Diese Zahlen können zur Debatte beitragen, sind jedoch nicht im bereitgestellten offiziellen Thread enthalten. Sie sollten daher als Aussagen Dritter betrachtet werden, die von der Hardware, der Kontextlänge, dem Quantisierungsgrad und der getesteten Last abhängen, und nicht als von DeepSeek bestätigte Daten.
Terminal-Bench: angekündigte Dominanz, aber kein allgemeingültiges Urteil
DeepSeek behauptet, dass „Tests by multiple parties“ V4.1 Flash bei Leistung, Kosten, Geschwindigkeit und Gesamtausführungszeit vor V4 Pro sehen. Diese Aussage kann die vergleichende Positionierung stützen, doch der Thread dokumentiert die Protokolle, Anbieter, Inferenzkonfigurationen oder die genaue Zusammensetzung dieser Tests nicht ausreichend.
Der wichtigste Streitpunkt betrifft Terminal-Bench, einen besonders beachteten Benchmark zur Bewertung agentischer Fähigkeiten bei der Computernutzung und Programmierung.
@Greg_GL_87 weist auf eine offensichtliche Inkonsistenz zwischen zwei Versionen der Evaluierung hin:
„In der Tabelle verliert es bei Terminal-Bench 4.0 mit 31,2 zu 37,9 gegen GLM 5.3, gewinnt aber bei 3.0. Eine seltsame Aufteilung bei zwei Versionen derselben Evaluierung.“ @Greg_GL_87
Auf diese Kritik gab es im Thread keine Antwort. Sie ist präzise und wichtig. Die offizielle Tabelle weist für V4.1 Flash bei Terminal-Bench 4.0 tatsächlich 31,2 aus, während @Greg_GL_87 diesen Wert mit den 37,9 von GLM 5.3 vergleicht. Gleichzeitig erreicht V4.1 Flash bei Terminal-Bench 3.0 30,0 und liegt dort vor GLM 5.3.
Ein Modell kann V4 Pro bei mehreren Kennzahlen schlagen, ohne für alle agentischen Programmieraufgaben die beste Wahl zu sein. Ohne ein detailliertes Protokoll lässt sich nicht feststellen, ob der Unterschied zwischen Terminal-Bench 3.0 und 4.0 auf die Aufgaben, Umgebungen, Testparameter oder einen anderen methodischen Faktor zurückzuführen ist.
@kryptosopus formuliert einen umfassenderen Einwand und vergleicht V4.1 Flash mit Claude Opus 5:
„Native Bildverarbeitung ist bereits in das kleinste Modell integriert, aber bei Terminal-Bench liegt es trotzdem 13 Punkte hinter Opus 5. Flash ist eindeutig die ‚günstige und schnelle‘ Option, nicht das Frontier-Modell. Die Skalierungszeile ganz unten ist hier der eigentliche Hinweis.“ @kryptosopus
Diese Interpretation widerspricht der von DeepSeek nicht vollständig. V4.1 Flash kann nach mehreren vom Unternehmen ausgewählten Messgrößen besser als DeepSeek V4 Pro sein und bei einem bestimmten agentischen Benchmark dennoch hinter Opus 5 zurückliegen. Problematisch wird es, wenn eine relative Verbesserung innerhalb einer Modellfamilie in eine Behauptung allgemeiner Überlegenheit umgedeutet wird.
Reaktionen: Open-Source-Begeisterung, produktbezogene Zurückhaltung und Fragen zur künftigen Pro-Version
Die Antworten auf den offiziellen Thread sind hinsichtlich der Offenheit des Modells und seiner schnellen Integration überwiegend begeistert. @MrAhmadAwais gibt beispielsweise an, dass V4.1 Flash bereits in seinem CommandCodeAI-Angebot verfügbar ist. @Presidentlin würdigt vor allem den Beitrag von DeepSeek zum Open-Source-Ökosystem:
„Nochmals vielen Dank, dass ihr Open Source voranbringt.“ „Wie immer Pflicht.“ „Wie hoch wird eure Obergrenze noch steigen?!!“ @Presidentlin
Die Antwort wurde von einer Manga-Seite begleitet, die diese Mischung aus Faszination und Herausforderung angesichts des Tempos von DeepSeek zum Ausdruck bringt.
@ParthM1001 wiederum fasst die Stimmung mit einer kulinarischen Metapher zusammen:
„Der Wal hat wieder etwas Großartiges gezaubert.“ @ParthM1001
Die Antworten auf den Post von @kimmonismus konzentrieren sich stärker auf die Positionierung der Modellfamilie. @elshayib_ ist der Ansicht, dass die bisherige Pro-Version ihren Sinn verliert:
„V4 Pro ist jetzt irgendwie irrelevant.“ @elshayib_
@kimmonismus antwortet darauf:
„Ja, ich warte einfach auf eine weitere Veröffentlichung der Pro-Version.“ @kimmonismus
Diese Antwort steht im Einklang mit der offiziellen Ankündigung: V4 Pro wird tatsächlich vorübergehend eingestellt, doch DeepSeek kündigt ausdrücklich eine künftige Version V4.1 Pro an. Die Schlussfolgerung, dass die gesamte Pro-Reihe endgültig nutzlos sei, geht daher über die gesicherten Fakten hinaus.
Dieselbe Frage stellt sich auch bei @RimasXYZ:
„Wenn Flash V4 Pro jetzt bei Fähigkeiten, Kosten und Geschwindigkeit schlägt, womit kann V4.1 Pro dann noch punkten?“ @RimasXYZ
Der Thread beantwortet diese Frage nicht. Damit bleibt die Definition des künftigen Pro-Produkts völlig offen: höhere Qualität bei schwierigen Aufgaben, stärkere Schlussfolgerungsfähigkeiten, ein längerer Kontext, agentische Zuverlässigkeit oder ein anderer Leistungskompromiss.
Causal-Encoder-Decoder-Architektur: Was sich technisch ändert
Die Reaktion von @austinyuhao, „Willkommen zurück, Encoder-Decoder“, ist kurz, aber treffend. DeepSeek schlägt nicht nur eine Cache-Komprimierung vor, sondern führt erneut eine architektonische Trennung zwischen dem kausalen Encoding-Pfad und dem Decoder ein.
„Willkommen zurück, Encoder-Decoder“ @austinyuhao
Das in der Antwort geteilte Diagramm zeigt einen Causal Encoder und einen Decoder mit jeweils zwanzig Schichten, sodass das gesamte Netzwerk aus vierzig Schichten besteht. Außerdem sind darin die Komponenten MoE, CSA2, SWA, Vision Encoder, Text Embedding, Engram, DSpark und Candidate Pool dargestellt.
Diese Struktur erklärt, warum multimodale Inferenz und der KV-Cache miteinander verknüpft sind. DeepSeek will Bildverarbeitung nativ unterstützen und zugleich die Kosten bei langen Sequenzen in einem vertretbaren Rahmen halten. Dieses Versprechen ist besonders attraktiv für Agenten, die Dokumente lesen, Benutzeroberflächen analysieren, Code bearbeiten und ein persistentes Arbeitsgedächtnis aufrechterhalten müssen.
FAQ zu DeepSeek V4.1 Flash
Wie viele Parameter sind in DeepSeek V4.1 Flash aktiv?
DeepSeek kündigt ein MoE-Modell mit 552 Milliarden Parametern an. Während der Verarbeitung der Eingabe sollen lediglich 8 Milliarden Parameter aktiv sein, bei der Generierung dann 16 Milliarden.
Warum ist der DeepSeek-KV-Cache für KI-Agenten wichtig?
Der KV-Cache speichert die Repräsentationen des bereits verarbeiteten Kontexts. Ein kompakterer Cache reduziert den Bedarf an GPU-Speicher und Datenspeicher, wodurch sich die Kosten langer Unterhaltungen, von Agenten mit Tool-Aufrufen und von Workflows senken lassen, die häufig denselben Kontext wiederverwenden.
Was geschieht mit den Nutzern von DeepSeek V4 Pro?
Ab dem 14. September 2026 um 04:00 UTC müssen für DeepSeek V4 Pro bestimmte Anfragen vorübergehend an V4.1 Flash weitergeleitet werden, bis V4.1 Pro veröffentlicht wird. Die betroffenen Teams müssen ihre Produktionsanwendungen erneut validieren, auch wenn die API-Kompatibilität während des Übergangs erhalten bleibt.
Das Wichtigste in Kürze
DeepSeek V4.1 Flash ist nicht nur ein weiteres schnelles Update. Die Ankündigung kombiniert eine neue asymmetrische Architektur, eine zwischen Eingabe und Generierung differenzierte MoE-Aktivierung, eine starke Komprimierung des KV-Caches, aggressive API-Preise und eine konkrete Migration des Datenverkehrs von V4 Pro.
Für professionelle Anwender sind die Auswirkungen klar:
- Der verkleinerte KV-Cache kann die Kosten von Agenten mit langem Kontext deutlich senken.
- KI-Selbsthosting wird für Betreiber, die bereits über eine umfangreiche Infrastruktur verfügen, realistischer.
- Die Weiterleitung von V4 Pro zu Flash erfordert eine Phase der Anwendungsvalidierung.
- Die gegenüber V4 Pro beanspruchten Leistungswerte reichen nicht aus, um eine Überlegenheit bei allen agentischen Benchmarks zu belegen.
- Terminal-Bench bleibt ein kritischer Punkt, insbesondere angesichts der von @Greg_GL_87 festgestellten Abweichung zwischen den Versionen 3.0 und 4.0.
Der Thread lässt daher mehrere Fragen offen: Welche Protokolle rechtfertigen die „Tests durch mehrere Parteien“, warum weichen die Ergebnisse je nach Version von Terminal-Bench voneinander ab, welche eigenständige Rolle wird V4.1 Pro spielen und mit welcher Hardwarekonfiguration wird Selbsthosting tatsächlich praktikabel?
Die vernünftigste Schlussfolgerung ist zugleich die nützlichste: V4.1 Flash scheint einen bedeutenden Fortschritt bei Effizienz und Bereitstellung darzustellen, beweist aber noch nicht, dass ein Flash-Modell die für Frontier-Modelle typischen Kompromisse beseitigt hat.