DeepSeek V4.1 Flash: Günstige API, riesige offene Gewichte

DeepSeek V4.1 Flash verbindet niedrige API-Preise mit einem sehr großen Open-Weights-Modell. Der Release vom 10. September 2026 aktiviert 8 Milliarden Parameter bei der Eingabeverarbeitung und 16 Milliarden bei der Ausgabe. Allein der Modellkern enthält aber 552 Milliarden. Verbessert wird der Rechenaufwand der einzelnen Phasen; daraus wird kein kleiner Download für deinen Laptop. [1] [2]

Was bedeutet „8B aktiv“ tatsächlich?

Die Zahl der aktiven Parameter beschreibt den pro Token genutzten Modellanteil, nicht das gesamte zu speichernde Modell. V4.1 Flash ist ein Mixture-of-Experts-Modell, das Teile seines Netzes für die Berechnung auswählt. DeepSeeks neuer Aufbau trennt außerdem Eingabeverarbeitung und Ausgabegenerierung, sodass in beiden Phasen unterschiedlich viele Parameter aktiv sind. [2]

Die Eingabeverarbeitung heißt meist Prefill: Das Modell liest den Prompt, bevor es antwortet. Bei Decode erzeugt es nacheinander die Ausgabe-Token. DeepSeeks technischer Bericht beschreibt eine kausale Encoder-Decoder-Architektur mit je 20 Schichten für Encoder und Decoder. Angegeben werden 8B aktive Parameter beim Prefill und 16B beim Decode; B steht hier für Milliarden. [2]

Deshalb wäre es irreführend, beide Zahlen zu mitteln und von einem „12B-Modell“ zu sprechen. Ein langer Prompt mit kurzer Antwort verteilt die Arbeit anders als eine kurze Eingabe mit einem umfangreichen Patch als Ergebnis. Die Architektur teilt den Phasen unterschiedliche Berechnung zu. Keine davon macht aber aus dem vollständigen Modell einen kleinen Checkpoint für Verbraucherhardware.

Die Speicheraufteilung zeigt das deutlich. DeepSeek nennt einen Modellkern mit 552B Parametern plus rund 196B Parameter im Engram-Speicher, einer Nachschlagekomponente. Das Deployment-Rezept des vLLM-Projekts berücksichtigt zusätzlich das DSpark-Entwurfsmodell und weitere Tensoren. Das vollständige Hugging-Face-Artefakt wird derzeit mit 763B Parametern angezeigt. Diese Zahlen beziehen sich auf unterschiedliche Bestandteile desselben Releases. [2] [3]

In der Launch-Diskussion auf r/LocalLLaMA vom 10. September standen neben Begeisterung auch Fragen zu Architektur und Betrieb. Darin liegt die interessante Spannung: Ein Modell kann selektiv rechnen und trotzdem sehr groß zu hosten sein. [5]

Warum ist ein kleinerer Kontextcache wichtig?

Ein kleinerer Kontextcache reduziert einen Teil des Speicherbedarfs langer Gespräche. Der KV-Cache bewahrt Aufmerksamkeitsinformationen bereits verarbeiteter Token auf, damit das Modell sie bei der Ausgabe wiederverwenden kann. Dieser Speicher ist vom Speicher für die Modellgewichte zu unterscheiden.

DeepSeeks Bericht nennt für den globalen KV-Speicher 890 Byte pro Token, ungefähr ein Viertel des Werts von V4 Flash. Die Ankündigung nennt separat ein Viertel des HBM-Bedarfs und ein Achtel des SSD-Bedarfs für den KV-Cache gegenüber der vorherigen Generation. HBM ist Speicher mit hoher Bandbreite. Die Angaben hängen zusammen, sind aber keine austauschbaren Angaben zum gesamten Modellspeicher. [1] [2]

Für Coding-Agenten ist das relevant, weil sich Repository-Inhalte, Werkzeugausgaben und aufeinanderfolgende Änderungen ansammeln können. Ein kleinerer Cache senkt den Aufwand, diesen Kontext vorzuhalten. Er beweist nicht, dass das Modell jede Abhängigkeit richtig erinnert oder einen guten Patch wählt. Die veröffentlichte Kontextkapazität liegt bei rund einer Million Token; das Serving-Rezept nennt genau 1.048.576. [2] [3]

Ich würde die Speicheränderung deshalb als Infrastrukturverbesserung lesen. Sie macht das lange Kontextfenster praktikabler im Betrieb. Wie gut eine lange Programmieraufgabe gelingt, bleibt eine eigene Frage.

Sind die Coding-Verbesserungen unabhängig bestätigt?

Dieser Vergleich stammt aus DeepSeeks eigener Evaluation, nicht aus einem unabhängigen Test dieser Publikation. Die Tabelle des auf Anweisungen abgestimmten Modells zeigt deutliche Gewinne gegenüber V4 Flash auf mehreren Agentenbenchmarks. Hilfreich ist der Vergleich mit diesem Vorgänger unter den offengelegten Bedingungen, nicht mit fremden Launch-Zahlen aus einem anderen Aufbau.

DeepSeek meldet bei DeepSWE v1.1 einen Anstieg von 54,4 auf 74,2 Prozent, also um 19,8 Prozentpunkte. Die Modellkarte nennt reasoning_effort=100, temperature=1.0 und top_p=0.95. Code-Agent-Evaluationen nutzen DeepSeek Harness Minimal mit einem Kontext von einer Million Token; DeepSWE verwendet mini-SWE. Diese Bedingungen gehören zu den Zahlen. [2]

Meine Einordnung: Der Release verdient eine neue Coding-Evaluation. Mein früherer V4-Flash-Vergleich betrifft den Vorgänger und entscheidet nicht über das Verhalten von V4.1. Ich würde typische Aufgaben mit denselben Tests und Review-Kriterien erneut ausführen, bevor ich ein altes negatives Urteil oder einen neuen Launch-Score auf den Arbeitsalltag übertrage.

Was kostet DeepSeek V4.1 Flash über die API?

Die aktuelle Preistabelle nennt deepseek-flash als Modellkennung und unterscheidet Haupt- und Nebenzeiten. Beim Abruf am 14. September 2026 kostet nicht zwischengespeicherte Eingabe pro Million Token 0,15 US-Dollar in Nebenzeiten und 0,30 US-Dollar in Hauptzeiten. Ausgabe kostet entsprechend 0,60 und 1,20 US-Dollar. Für gecachte Eingabe gilt ein eigener niedrigerer Tarif. [4]

Die Hauptzeitpreise sind doppelt so hoch wie die Nebenzeitpreise. Ein Preisvergleich braucht deshalb Zeitfenster und Cache-Kategorie, nicht nur den niedrigsten Tabellenwert. Die Gesamtkosten einer Aufgabe hängen außerdem von Reasoning, Werkzeugausgaben und Wiederholungen ab. Ein niedriger Preis pro Ausgabe-Token ist attraktiv; messen würde ich aber die Kosten eines prüfbaren Ergebnisses.

Kannst du die offenen Gewichte lokal betreiben?

Die Gewichte sind unter MIT-Lizenz verfügbar, der dokumentierte Betrieb benötigt aber umfangreiche Serverhardware. Das vLLM-Rezept beschreibt einen Checkpoint von rund 511 GB und ein minimales GPU-Speicherbudget von 614 GB. Als Beispiele nennt es ein GB200-NVL4-Tray und einen Knoten mit acht H200-GPUs. Das sind Anforderungen dieses Rezepts, kein allgemeines Minimum für jede mögliche künftige Implementierung. [2] [3]

Deshalb würde ich API-Nutzung und eigenes Hosting getrennt entscheiden. Ein fester Aufgabensatz über die API zeigt, ob das Modell für deine Arbeit nützlich ist. Beim Hosting kommen ein Betriebsplan für Modell, Speicher, Laufzeitumgebung und Kapazität hinzu. Offene Gewichte geben Betreibern diese Möglichkeit, nehmen ihnen aber die Betriebsarbeit nicht ab.

Als einzelner Entwickler würde ich mit einem begrenzten API-Vergleich zum bisher verwendeten Modell beginnen. Ein Serving-Team sollte mit dem Deployment-Rezept und den tatsächlichen Eingabe- und Ausgabelängen seiner Arbeitslast anfangen. Die 8B-Angabe wird nützlich, sobald klar ist, welche Phase deiner Arbeit sie beschreibt.