DeepSeek V4 Flash und V4.1 Flash fürs Coding: offizielle Benchmarks, max_tokens, Preise und Tools

Wer nach „deepseek v4 flash benchmark official“ sucht, möchte in der Regel mehr als die Aussage, das Modell sei schnell oder günstig. Entscheidend ist, welche Werte DeepSeek tatsächlich veröffentlicht hat, unter welchen Testbedingungen sie entstanden sind und was sie für den Entwicklungsalltag aussagen. Die Suche nach „deepseek v4 max_tokens“ ist noch konkreter: Wie groß ist das Kontextfenster, wie viel kann eine einzelne Antwort erzeugen und welcher Wert gehört in den API-Aufruf?

Zuerst muss die wichtigste Verwechslung aufgelöst werden: DeepSeek V4 Flash, V4 Flash 0731 und das aktuelle DeepSeek V4.1 Flash sind unterschiedliche Releases. Das ursprüngliche V4 Flash nutzte eine MoE-Architektur mit insgesamt 284 Milliarden Parametern und rund 13 Milliarden aktiven Parametern pro Token. V4.1 Flash verwendet ein 552B-MoE-Backbone, mit etwa 8 Milliarden aktiven Parametern im Prefill und 16 Milliarden beim Decoding. Wer alte Architekturangaben, die aktuelle Modell-ID und Werte aus mehreren Releases zusammenführt, erhält eine sauber wirkende, aber nicht reproduzierbare Übersicht.

Stand 18. September 2026: Die aktuelle Modell-ID der DeepSeek-API lautet deepseek-flash. Alte V4-Flash- und Vision-Aliase befinden sich in einer Kompatibilitätsphase und können vorübergehend auf V4.1 umgeleitet werden. Für Produktionstests sollten Modell-ID, Datum, Anbieter, Reasoning-Stufe und Request-Parameter protokolliert werden.

Zentrale Spezifikationen

Merkmal	DeepSeek V4 Flash / 0731	DeepSeek V4.1 Flash
Status	Historischer Release; alter Alias kann umgeleitet werden	Aktueller Flash-Release
Kontextfenster	1.000.000 Tokens	1.000.000 Tokens
Architektur	284B MoE, etwa 13B aktiv	552B MoE; etwa 8B im Prefill und 16B beim Decode aktiv
Empfehlung für lange Ausgaben	Lokale High/Max-Konfigurationen empfahlen eine maximale Ausgabelänge von 384K	Die aktuelle offizielle API erlaubt bis zu 384K; lokal werden für Reproduktionen max_tokens >= 256K empfohlen
Eingabemodalität	Text	Text und Bilder
Reasoning-Steuerung	Frühere High/Max-Konfigurationen	API unterstützt unter anderem reasoning_effort
Aktuelle API-Modell-ID	deepseek-v4-flash ist eine ältere Namensform	deepseek-flash

Weder 384K noch 256K sind ein universelles hartes Limit für jede gehostete API. Es handelt sich um Empfehlungen für verschiedene Releases und Laufzeitumgebungen. Anbieter, SDK, Gateway oder Kontorichtlinie können niedrigere Grenzen setzen. Vor langen Produktionsaufgaben sollte deshalb die aktuelle Fähigkeit des tatsächlich verwendeten Endpoints geprüft werden.

Was steuert max_tokens wirklich?

max_tokens begrenzt die maximale Zahl der Tokens, die eine Antwort erzeugen darf. Der Parameter verändert nicht die Größe des Kontextfensters. Zum Kontextbudget gehören üblicherweise Eingabe, Chatverlauf, Tool-Ergebnisse und der für die Antwort reservierte Platz. Ein 1M-Kontext bedeutet nicht, dass jede Anfrage eine Ausgabe von 256K oder 384K benötigt.

Sinnvolle Startwerte sind:

• max_tokens=4096 für Codeerklärungen, die Korrektur einer Funktion, kurzes SQL und Konfigurationsfehler.
• max_tokens=16384 für Änderungen über mehrere Dateien, längere Testberichte oder Migrationspläne.
• max_tokens=32768 oder mehr für Repository-Analysen, lange Agentenläufe oder umfangreiche Codegenerierung – erst nach Prüfung des Endpoint-Limits und des tatsächlichen Nutzens.

Ein zu kleiner Wert kann Patch, Testergebnis oder Schlussfolgerung abschneiden. Ein unnötig hoher Wert vergrößert Kosten und Latenz im ungünstigsten Fall. Bei Coding-Agenten ist ein begrenztes Budget mit wiederholten Lesen–Ändern–Testen-Zyklen meist sicherer als der Versuch, ein ganzes Repository in einer einzigen Antwort lösen zu lassen.

Sichtbare Ausgabetokens, Reasoning-Tokens und abrechenbare Tokens können zudem unterschiedlich gezählt werden. Für Kostenberechnungen sind die usage-Felder und die Rechnung des konkret genutzten Endpoints maßgeblich.

Offizielle Benchmarks: Release, Modus und Harness müssen passen

Ein offizieller Wert beantwortet eine enge Frage: Was erreicht das Modell in einem dokumentierten Evaluationsaufbau? Er garantiert nicht dasselbe Ergebnis im eigenen Repository. Die folgenden Tabellen trennen Releases und lassen die ursprünglichen Benchmark-Namen stehen, damit unterschiedliche Tests und Reasoning-Stufen nicht zu einer künstlichen Gesamtnote verschmolzen werden.

Repräsentative Werte aus der ursprünglichen V4-Flash-Model-Card

Benchmark	Wert	Einordnung
GPQA Diamond (Pass@1)	88.1	Für High/Max-Reasoning berichtet
LiveCodeBench (Pass@1)	91.6	Codegenerierung
SWE-bench Verified (Resolved)	79.0	Behebung realer Repository-Issues
Terminal-Bench 2.0 (Acc)	56.9	Aufgaben eines Terminal-Agenten
HumanEval Base (Pass@1)	69.5	Base-Modell; nicht direkt mit Max vergleichbar

Die Zahlen stammen aus DeepSeeks offizieller Model Card und nicht aus einer einheitlichen unabhängigen Wiederholung. Insbesondere HumanEval Base wurde unter anderen Bedingungen als die High-Reasoning-Zeilen ermittelt. Die Differenz zwischen 69.5 und 91.6 ist daher kein sinnvoller Fähigkeitsabstand. Die Tabelle zeigt vor allem, welche Bereiche untersucht wurden.

Offizieller Familienvergleich: 0731, V4 Pro und V4.1 Flash

Benchmark	V4 Flash 0731	V4 Pro	V4.1 Flash
GPQA Diamond	89.9	92.4	90.9
Terminal-Bench 2.1	82.7	87.9	90.6
Terminal-Bench 4.0	7.0	12.4	31.2
DeepSWE v1.1	54.4	62.7	74.2
NL2Repo-Bench	54.2	61.5	64.0

Die nützliche Erkenntnis lautet nicht, dass jede einzelne Kennzahl ausnahmslos am höchsten ist. Wichtig ist, dass V4.1 Flash bei Terminal-Agenten, Software-Engineering auf Repository-Ebene und der Erstellung von Projekten aus natürlicher Sprache deutlich zulegt. Terminal-Bench 4.0 ist außerdem wesentlich schwieriger als 2.1; beide Zeilen dürfen nicht als austauschbare Versionen derselben Skala behandelt werden.

V4.1 Flash im offiziellen Vergleich mit Frontier-Modellen

Benchmark	V4.1 Flash	GPT-5.6 Sol	Opus-5.0	GLM-5.3
GPQA Diamond	90.9	94.1	93.4	88.1
Terminal-Bench 2.1	90.6	88.8	89.1	88.2
Terminal-Bench 4.0	31.2	39.9	51.8	37.9
DeepSWE v1.1	74.2	73.0	74.0	66.9
NL2Repo-Bench	64.0	56.8	75.3	58.0

Diese Gegenüberstellung wurde von DeepSeek in der V4.1-Model-Card veröffentlicht. Sie ist deshalb als Herstellerangabe und nicht als vollständig neutrales Ranking zu lesen. Modelle sollten innerhalb derselben Zeile und desselben Harness verglichen und anschließend mit unabhängigen Quellen sowie eigenen Aufgaben überprüft werden. V4.1 ist bei Terminal-Bench 2.1 und DeepSWE v1.1 stark, führt aber nicht jede Zeile an, etwa bei Terminal-Bench 4.0 und NL2Repo-Bench.

HumanEval eignet sich weiterhin für einen schnellen Funktionstest der Codegenerierung, ist für moderne Coding-Agenten jedoch zu eng. SWE-bench, DeepSWE, Terminal-Bench und NL2Repo bilden die Praxis besser ab: Repository lesen, Tools verwenden, Dateien ändern, Tests ausführen und nach einem Fehlschlag weiterarbeiten.

Benchmarks richtig lesen

1. Harness-Version prüfen. Terminal-Bench 2.0, 2.1 und 4.0 enthalten andere Aufgaben und Schwierigkeitsgrade.
2. Reasoning-Stufe und Ausgabebudget festhalten. low, high und max können Erfolgsquote, Latenz und Tokenverbrauch stark verändern.
3. Preis pro Request in Kosten pro akzeptierter Aufgabe umrechnen. Ein billiges Modell mit drei Wiederholungen kann teurer sein als ein Modell, das beim ersten Versuch fertig wird.
4. Auf dem eigenen Repository nachtesten. Installation von Abhängigkeiten, Testdauer, Tool-Rechte, Dateizahl und Codekonventionen beeinflussen die Leistung.

Offizielle Benchmarks eignen sich zur Vorauswahl. Sie ersetzen keinen Akzeptanztest für Produktion, Routing oder Beschaffung.

Preise: Ein niedriger Tokenpreis garantiert keine günstige Aufgabe

Am 18. September 2026 galten für deepseek-flash folgende offizielle DeepSeek-Basispreise:

Abrechnung	Spitzenpreis	Preis außerhalb der Spitze
Eingabe mit Cache-Treffer	$0.006 / 1M Tokens	$0.003 / 1M Tokens
Eingabe ohne Cache-Treffer	$0.30 / 1M Tokens	$0.15 / 1M Tokens
Ausgabe	$1.20 / 1M Tokens	$0.60 / 1M Tokens

Das sind offizielle DeepSeek-Basispreise, kein garantierter BetterToken-Endpreis. Der BetterToken-Katalog wird aus der Live-Pricing-API aktualisiert; Zugriffsgruppen, Cache-Regeln, Mindestabrechnung und Wiederholungen können abweichen. Aktuellen Preis prüfen, Datum speichern und mit tatsächlichem usage rechnen:

request_cost =
  cache_hit_input / 1_000_000 * cache_hit_rate
+ cache_miss_input / 1_000_000 * cache_miss_rate
+ output_tokens / 1_000_000 * output_rate

cost_per_accepted_task = sum(request_costs) / accepted_tasks

Für Coding sind häufig die Quote bestandener Tests im ersten Versuch, durchschnittliche Wiederholungen, Gesamttokens pro akzeptiertem Patch, Zeit bis zu grünen Tests und Minuten manueller Nacharbeit aussagekräftiger. Der Preis pro Million Tokens ist nur ein Faktor.

Artificial Analysis betrachtet zusätzlich Umfang der Evaluationssuite, Ausgabemenge, Geschwindigkeit und geschätzte Kosten. Die Methodik entspricht nicht exakt einer Anbieterrechnung, ist aber informativer als ein reiner Listenpreisvergleich.

Python-API-Beispiel

Das folgende Beispiel nutzt ein OpenAI-kompatibles SDK, die BetterToken Base URL und die aktuelle Modell-ID. Ein Ausgabebudget von 4K genügt, um Verbindung und grundlegende Codequalität zu prüfen. Ein komplettes Repository sollte nicht nur deshalb gesendet werden, um das 1M-Kontextfenster „auszunutzen“.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["BETTERTOKEN_API_KEY"],
    base_url="https://www.bettertoken.ai/v1",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[
        {"role": "user", "content": "Prüfe diese Python-Funktion, finde die Ursache des fehlgeschlagenen Tests und schlage die kleinste Korrektur vor. Refaktoriere keinen unbeteiligten Code."}
    ],
    max_tokens=4096,
    reasoning_effort="low",
)

print(response.choices[0].message.content)

reasoning_effort="low" ist ein sinnvoller Start für schnelle Iterationen. Bei schwierigen Regressionen, dateiübergreifenden Abhängigkeiten oder mehreren Tool-Runden können high und max verglichen werden. Wenn die installierte SDK-Version das Feld nicht direkt anbietet, muss es über zusätzliche Request-Parameter oder nach aktueller Gateway-Dokumentation übergeben werden.

Cursor, Cline, Aider, OpenCode und weitere Tools

• Cursor / Cline / Aider / OpenCode: OpenAI-kompatiblen Anbieter wählen, Base URL auf https://www.bettertoken.ai/v1 setzen, deepseek-flash als Modell eintragen und den API-Key in einer Umgebungsvariable oder im sicheren Secretspeicher des Tools ablegen.
• Codex und externe Agenten: Das funktioniert nur bei Unterstützung eines eigenen OpenAI-kompatiblen Endpoints. Prüfen, ob das Tool /v1 automatisch anhängt, damit der Pfad nicht doppelt entsteht.
• Claude Code: Verwendet nativ das Anthropic-Protokoll. Die Anthropic-kompatible BetterToken Base URL lautet https://bettertoken.ai; die Request-Felder unterscheiden sich. Die OpenAI-Python-Konfiguration darf nicht unverändert übernommen werden.
• Lang laufende Agenten: Budget, Timeout, maximale Wiederholungen und Abbruchbedingung festlegen. Tool-Unterstützung ist kein Grund für unbegrenzte Datei- oder Kommando-Rechte.

Nach der Konfiguration drei kleine Tests ausführen: verfügbare Modelle auflisten, eine kurze Nachricht senden und eine einzelne Datei samt Test korrigieren. Erst wenn alle drei funktionieren, auf Repository-Aufgaben erweitern. So lassen sich Authentifizierung, Modell-ID und Protokollprobleme von Qualitätsproblemen trennen.

Einen reproduzierbaren Test mit eigenen Aufgaben durchführen

20 bis 50 Aufgaben mit bekanntem korrektem Ergebnis auswählen. Sie sollten die tatsächliche Arbeit repräsentieren und nicht erst nach Sichtung der Modellergebnisse zusammengestellt werden.

1. Repository-Commit, Laufzeit, Dependency-Cache und Tool-Rechte fixieren.
2. Für alle Modelle denselben Prompt, Timeout und dieselbe Retry-Policy verwenden.
3. low, high und max getrennt auswerten.
4. Eingabe, cache hit/miss, sichtbare Ausgabe, Wiederholungen und Gesamtzeit protokollieren.
5. Nur Patches als Erfolg zählen, die automatische Tests und eine kurze menschliche Prüfung bestehen.

Feld	Empfohlener Eintrag
Model ID	deepseek-flash
reasoning_effort	low, high oder max
max_tokens	Je Aufgabenklasse feste 4K / 16K / 32K
Akzeptanzregel	Tests bestanden, keine sachfremden Änderungen, Anforderungen erfüllt
Tokenverbrauch	input, cache hit/miss, output, retries
Zeit	erste Antwort, grüne Tests, Minuten menschlicher Nacharbeit

Mindestens zwei Durchläufe sind sinnvoll, damit kalte Caches, vorübergehende Tool-Fehler oder kurze Dienstschwankungen das Ergebnis nicht bestimmen. Erfolgsquote, Kosten pro akzeptierter Aufgabe und Abschlusszeit sollten gemeinsam berichtet werden.

low, high oder max auswählen

• low: Alltagsfragen, Erklärungen, kleine Patches und Automatisierung mit hohem Volumen. Üblicher Standard.
• high: Schwierige Fehlersuche, Änderungen über mehrere Dateien und Aufgaben mit mehr Planungsbedarf. Nur dauerhaft nutzen, wenn die höhere Erfolgsquote den Mehrpreis trägt.
• max: Schwerste Agentenaufgaben, Architektur-Migrationen oder seltene, hochwertige Probleme. Immer mit klarem Budget und Timeout.
• Eskalationsstrategie: Mit low beginnen; bei einem Fehlschlag Logs und Testergebnisse behalten und auf high wechseln; max nur einsetzen, wenn die Hinweise auf unzureichendes Reasoning statt auf eine defekte Umgebung zeigen.

Wenn eine Abhängigkeit nicht installiert werden kann, der Testbefehl falsch ist, Dateien fehlen oder Schreibrechte nicht vorhanden sind, erhöht eine höhere Reasoning-Stufe meist nur die Kosten.

Fazit

Der Wert der DeepSeek-V4-Flash-Familie liegt nicht in einer einzelnen auffälligen Punktzahl, sondern in der Kombination aus langem Kontext, niedrigem Tokenpreis und zunehmend starker Software-Engineering-Leistung. Für neue Integrationen sollten V4.1 Flash und deepseek-flash im Mittelpunkt stehen; V4 und 0731 dienen als historische Referenz.

Die verlässliche Reihenfolge lautet: Release und Parameter prüfen, offizielle Werte unter vergleichbaren Bedingungen ansehen und anschließend im eigenen Repository Erfolgsquote, Abschlusszeit und Kosten pro akzeptierter Aufgabe messen. Das ist aussagekräftiger als „billigster Preis pro Million Tokens“ oder „Platz eins in einem Benchmark“.

Häufig gestellte Fragen

Wie groß ist das Kontextfenster von DeepSeek V4 Flash?

Die offiziellen Model Cards für V4 Flash, 0731 und V4.1 Flash nennen 1.000.000 Tokens. Ein gehosteter Endpoint kann weniger anbieten; Eingabe, Verlauf, Tool-Ergebnisse und reservierte Ausgabe teilen sich dieses Budget.

Welchen Wert sollte max_tokens haben?

Für kurze Coding-Aufgaben mit 4K beginnen, für längere Änderungen 16K verwenden und für Repository-Arbeit nach Prüfung der Grenze 32K oder mehr erwägen. Die aktuelle offizielle DeepSeek-API nennt bis zu 384K Ausgabe; die V4.1-Model-Card empfiehlt für lokale Benchmark-Reproduktionen max_tokens >= 256K. Beides sind keine universellen Grenzen für jedes Gateway oder Konto.

Welche Modell-ID sollte jetzt verwendet werden?

Die aktuelle DeepSeek-API verwendet deepseek-flash. Ein alter Alias kann vorübergehend auf V4.1 zeigen, für Produktion sollten jedoch die aktuelle ID sowie Anbieter und Datum erfasst werden.

Sagen offizielle Benchmarks die Leistung in Cursor oder Aider voraus?

Nicht direkt. Prompt, Tool-Implementierung, Repository-Struktur, Netzwerk, Rechte, Testdauer und Retry-Policy wirken ebenfalls mit. Ein eigener Aufgabenbestand ist nötig.

Eignet sich DeepSeek V4.1 Flash fürs Coding?

Die offiziellen Ergebnisse in Terminal-Bench 2.1, DeepSWE v1.1 und NL2Repo-Bench zeigen starke Software-Engineering-Fähigkeiten. Hinzu kommen 1M Kontext und Reasoning-Steuerung. Ob es für ein konkretes Projekt passt, entscheiden beobachtete Erfolgsquote, Latenz, Kosten und Code-Review.

Quellen

• Offizielle Model Card von DeepSeek V4 Flash
• Offizielle Model Card von DeepSeek V4 Flash 0731
• Offizielle Model Card von DeepSeek V4.1 Flash
• Offizielle Ankündigung von DeepSeek V4.1 Flash
• DeepSeek-Dokumentation zum Thinking Mode
• Offizielle DeepSeek-Preise
• Artificial Analysis: DeepSeek V4.1 Flash
• BetterToken API-Dokumentation
• BetterToken-Preise