DeepSeek V4: Was Flash und Pro für die Praxis bedeuten

DeepSeek V4 aktuell: Zwei Modellnamen und eine wichtige Umstellung

DeepSeek bietet seine Modellfamilie per API und als herunterladbare Modellgewichte an. In der Dokumentation eines Produktivsystems gehört deshalb die genaue Version dazu. „V4“ allein verrät nicht mehr, welches Modell eine Anfrage verarbeitet hat. Die aktuell von DeepSeek betriebene API ordnet deepseek-flash dem Modell DeepSeek-V4.1-Flash-1017 und deepseek-v4-pro dem Modell DeepSeek-V4-Pro-0813 zu. Modelle und Preise.

Geprüft am 18. Oktober 2026 anhand der aktuellen Seite „Models & Pricing“ von DeepSeek und der Hugging-Face-Modellkarten für genau diese Revisionen. Die Empfehlungen beruhen auf dokumentierten Funktionen, Anforderungen an den Betrieb und der Gestaltung aussagekräftiger Tests. Eigene Leistungsmessungen liegen ihnen nicht zugrunde.

DeepSeek V4 Release: Was hat sich am 17. Oktober geändert?

Mit dem Oktober-Release wurde die Flash-Seite der Modellfamilie aktualisiert. Die bisherigen Namen deepseek-v4-flash und deepseek-v4-flash-vision-exp werden weiterhin akzeptiert, ihre früheren Modelle wurden jedoch außer Betrieb genommen. Anfragen erreichen nun V4.1-Flash-1017; die Flash-Preise gelten weiterhin. Für neue Integrationen ist deepseek-flash vorgesehen. Aktuelle Zuordnung der Aliasse.

Für den Betrieb ist entscheidend: Eine erfolgreiche Anfrage belegt nicht, dass noch das alte Modell läuft. Ein Alias funktioniert wie die Telefonnummer einer Abteilung: Die Nummer kann gleich bleiben, obwohl jemand anderes abnimmt. Ändern sich bei einem internen Tool der Schreibstil, die Werkzeugauswahl oder die Antwortlänge ohne Konfigurationsänderung, sollte die Umstellung des bereitgestellten Modells in die Fehlersuche einfließen.

Als unmittelbarer Schritt empfiehlt es sich, repräsentative Aufgaben erneut auszuführen und die akzeptierten Ergebnisse zu vergleichen. Der Wechsel zum empfohlenen Namen macht die Konfiguration eindeutiger, bringt aber das abgeschaltete Modell nicht zurück.

Diese Grenzen gelten für die von DeepSeek betriebene API und stammen aus der Modellübersicht von DeepSeek. Ein Token ist eine Texteinheit, die das Modell verarbeitet. Der Kontext bildet den Arbeitsraum einer Anfrage; die maximale Ausgabe begrenzt, wie viel das Modell erzeugen kann. Keine der beiden Zahlen garantiert, dass es sämtliche übergebenen Informationen zuverlässig wiederfindet.

Wer als CTO die Analyse von Code-Repositories erprobt, sollte die relevanten Dateien und Abnahmekriterien ausdrücklich festlegen. Ein großes Kontextfenster bietet Platz für mehr Material. Daraus folgt aber nicht, dass das Modell die richtigen Belege gefunden oder jede Vorgabe eingehalten hat.

Welches Modell passt zum Produkt?

Zuerst zählen die benötigten Eingaben und brauchbare Ergebnisse, danach die Betriebskosten. Meine Empfehlung für eine neue Evaluierung ist zunächst Flash: Es verbindet breitere Eingabemöglichkeiten mit den niedrigeren veröffentlichten Tokenpreisen. Pro bekommt seinen Platz in einem Verarbeitungspfad, wenn es dort bessere, akzeptierte Ergebnisse liefert oder eine bestehende Pro-Integration die Anforderungen bereits erfüllt.

DeepSeek V4 Flash: Mit einer klar begrenzten Aufgabe beginnen

Für ein finanziertes Start-up, das Supporttickets klassifizieren oder Antwortentwürfe erstellen möchte, bietet sich Flash mit einer überprüfbaren Aufgabe an. Dazu gehören die relevanten Richtlinien, klar definierte zulässige Kategorien und eine Messung, wie oft eine prüfende Person das Ergebnis akzeptiert. Das sind Vorschläge für die Evaluierung, keine Behauptungen darüber, dass das Modell diese Aufgaben im konkreten Produkt bereits bewältigt hat.

Wer allein Software entwickelt, sollte bei Code genauso vorgehen: eine eng begrenzte Änderung wählen, das fehlschlagende Beispiel sichern und verlangen, dass der erzeugte Patch die Prüfungen des Projekts besteht. Ein Modell, das überzeugend erklärt, den Fehler aber bestehen lässt, hat die Aufgabe nicht erledigt.

DeepSeek V4 mit Vision: Bei Bildern steht die Wahl fest

Flash unterstützt Bildeingaben, Pro nicht. Bei einem Oberflächenfehler, der per Screenshot gezeigt wird, einem fotografierten Formular oder einer Anfrage zum Lesen eines Diagramms entscheidet diese Grenze bereits vor jeder Benchmark-Diskussion. Bildunterstützung nach Modell.

Leitet eine Anwendung schwierige Anfragen an Pro weiter, brauchen Anfragen mit Bildern einen eigenen Verarbeitungspfad. Dieselbe Anfrage an ein Modell ohne Bildverarbeitung zu schicken, erhält die Aufgabe nicht. Ein Bild zunächst in eine Textbeschreibung umzuwandeln, ist ein anderer Workflow – mit einer weiteren Stelle, an der Informationen verloren gehen können.

Pro sollte bei Textaufgaben bleiben, in denen es sich bewährt hat. Ein CTO im Mittelstand mit einem stabilen internen Assistenten auf Pro-Basis sollte diesen Ausgangspunkt während der Flash-Evaluierung erhalten. Erfahrene Betriebsverantwortliche sollten neben fertigen Antworten auch den Prüfaufwand und den Umgang mit Fehlern vergleichen. Ein zuverlässiger Textworkflow muss nicht allein deshalb umgestellt werden, weil eine neuere Revision existiert.

Außerhalb der Spitzenzeiten kostet Flash $0.15 für Eingaben / $0.60 für Ausgaben, Pro dagegen $0.66 / $1.98 pro 1M Token; in beiden Fällen sind nicht gecachte Eingaben gemeint. Die Originalpreise von DeepSeek und unsere Übersicht zu den DeepSeek-Preisen enthalten die vollständige Preistabelle.

Thinking-Modus: Eine Einstellung der Anfrage, kein anderer Modellname

Thinking und Non-Thinking sind Einstellungen beider Modelle, keine separat auszuwählenden Produkte. Thinking gibt dem Modell vor der endgültigen Antwort eine ausdrückliche Schlussfolgerungsphase. Der Modus kommt für Planung, schwierige Fehlersuche und Aufgaben mit voneinander abhängigen Vorgaben infrage. Bei klar begrenzter Extraktion oder Klassifizierung lohnt sich ein Test mit Non-Thinking, wenn zusätzliche Überlegungen wenig Mehrwert bringen könnten.

Die von DeepSeek betriebene API aktiviert Thinking standardmäßig. In Chat-Completions-Anfragen wird thinking.type auf enabled oder disabled gesetzt. Für den Denkaufwand sind low, high und max dokumentiert; der Standard ist high. Diese Einstellungen sollten ausdrücklich gesetzt werden, damit spätere Vergleiche reproduzierbar bleiben. Steuerung des Thinking-Modus.

Bei der Umstellung eines Agenten zählt neben der endgültigen Antwort auch der Gesprächszustand. Enthält eine Anfrage tools, verlangt DeepSeek, dass vorheriges reasoning_content erneut übergeben wird – auch aus Gesprächsrunden ohne Werkzeugaufruf. Fehlt es, kann ein 400-Fehler entstehen. Ein erfolgreicher Chat mit nur einer Gesprächsrunde validiert deshalb noch keinen Agenten mit mehreren Runden. Anforderungen an den Zustand bei Werkzeugaufrufen.

So lässt sich die aktuelle DeepSeek API aufrufen

In model gehört der API-Alias, nicht der Name des Hugging-Face-Repositories. Wenn der DeepSeek-Schlüssel bereits in der Umgebungsvariable DEEPSEEK_API_KEY vorliegt, entspricht diese Anfrage der dokumentierten Chat-Completions-Schnittstelle:

curl --fail-with-body https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -d '{
    "model": "deepseek-flash",
    "messages": [
      {"role": "user", "content": "List the checks before releasing a small API change."}
    ],
    "thinking": {"type": "enabled"},
    "reasoning_effort": "high",
    "stream": false
  }'

Für einen Texttest mit Pro wird der Modellwert durch deepseek-v4-pro ersetzt. Für Non-Thinking wird thinking.type auf disabled gesetzt. Die dokumentierten Basis-URLs lauten https://api.deepseek.com für das OpenAI-kompatible Format und https://api.deepseek.com/anthropic für das Anthropic-kompatible Format. DeepSeeks API-Schnellstart.

Dieses Beispiel beruht auf der Dokumentation; die Anfrage wurde für diesen Artikel nicht ausgeführt. Sobald die Verbindung funktioniert, müssen mit dem tatsächlich im Produkt eingesetzten Client das Einlesen der Antworten, der vollständige Ablauf von Werkzeugaufrufen, Fehlerfälle und Zeitüberschreitungen geprüft werden. Diese Tests entscheiden darüber, ob die Integration einsatzbereit ist.

DeepSeek-V4-Benchmarks brauchen genaue Versionsangaben

Der genaue Checkpoint und der Testaufbau sagen mehr aus als die Überschrift „Flash gegen Pro“. Ein Benchmark besteht aus einer festgelegten Sammlung von Aufgaben. Ein Agent-Harness ist die umgebende Software, die Werkzeuge ausführt und Ergebnisse an das Modell zurückgibt. Ändert sich eines davon, kann sich auch das Ergebnis ändern.

DeepSeek nennt auf der Modellkarte zu Flash-1017 einen Wert von 77.0 bei DeepSWE v1.1 mit Mini-SWE-V2 und 42.3 bei Terminal-Bench 4.0 mit Claude Code. Das sind DeepSeeks eigene Zahlen, hier mit den Benchmark-Namen und Harness-Angaben der Modellkarte wiedergegeben. Sie sind keine unabhängigen Messungen für die eigene Anwendung. Modellkarte zu Flash-1017.

DeepSeek V4 Pro im Benchmark: Die Aufgaben gehören zum Ergebnis

DeepSeek nennt auf der Modellkarte zu Pro-0813 einen Wert von 87.9 bei Terminal Bench 2.1. Für öffentliche Aufgaben für Code-Agenten beschreibt die Karte DeepSeek Harness im Minimalmodus mit maximalem Denkaufwand. Das ist DeepSeeks eigenes Ergebnis für diese Benchmark-Version. Es lässt sich nicht so mit dem Terminal-Bench-4.0-Wert von Flash-1017 in eine Rangfolge bringen, als wären die Aufgabensammlungen identisch. Modellkarte zu Pro-0813.

Bei der Auswahl eines Programmierassistenten ist ein Versuch aussagekräftig, der Repository, Aufgabe, Werkzeuge und Abnahmekriterien konstant hält. Festgehalten werden sollte, ob der Patch funktioniert und wie viel Prüfung er erfordert. Die veröffentlichten Ergebnisse sind ein Anlass, einen Kandidaten zu testen. Sie entscheiden nicht darüber, welches Modell die Anfragen im Produktivbetrieb übernehmen sollte.

Wenn jemand ein älteres Ergebnis teilt, ist die Modellkarte der jeweiligen Revision der richtige Ausgangspunkt. Ein Wert, der nur mit „V4.1 Flash“ beschriftet ist, kann sich auf den früheren Checkpoint beziehen.

Offene Modellgewichte: Wer übernimmt den Betrieb?

Für beide genannten Revisionen sind Repositories und Modellgewichte unter der MIT-Lizenz veröffentlicht. Modellgewichte sind die erlernten Parameter eines Modells. Wer sie herunterlädt, kann die Inferenz auf selbst betriebener Infrastruktur einrichten. Die Nutzung der von DeepSeek betriebenen API ist eine eigenständige Bereitstellungsoption. Flash-1017, Pro-0813.

Für Einzelentwickler ist ein Versuch über die gehostete API das kleinere Integrationsprojekt. Für ein Unternehmen, das bereits Modellinfrastruktur betreibt, schaffen herunterladbare Gewichte eine weitere Möglichkeit. Entscheidend ist, wer sich um Bereitstellungskapazität, Updates, Protokolle und die Behebung von Störungen kümmert.

DeepSeek V4: Technischer Bericht und Anleitungen zum Betrieb

Die Modellkarte zu Flash-1017 verlinkt den technischen Bericht zu V4.1 sowie eigene Anleitungen zur lokalen Inferenz einschließlich der Konvertierung der Modellgewichte. Die Karte zu Pro-0813 verlinkt den V4-Bericht und dokumentiert ausdrücklich den Betrieb mit vLLM und SGLang, Software zur Ausführung der Modellinferenz. Maßgeblich sind die Anleitungen für den tatsächlich heruntergeladenen Checkpoint. Flash-Anleitungen, Pro-Anleitungen.

Bei der Integration bleibt eine konkrete Lücke einzuplanen: Beide Modellkarten stellen eigene Implementierungen zur Prompt-Kodierung bereit, statt einer Chatvorlage im Jinja-Format, mit der viele Serving-Stacks Gesprächsnachrichten anordnen. Die Flash-Karte beschreibt außerdem deepseek-recipe zum Kodieren von Anfragen und Auswerten von Antworten. Inferenz, Werkzeugausführung und HTTP-Transport bleiben dabei Aufgabe der aufrufenden Anwendung. Der Download der Modellgewichte fügt diese Teile nicht automatisch zusammen.

Für eine breitere Auswahl zum Eigenbetrieb bietet sich unser Leitfaden zu Open-Source-LLMs an. Die Betriebsentscheidung sollte getrennt von der Benchmark-Platzierung des Modells getroffen werden.

Search und Fetch: Was Agenten zusätzlich erfassen müssen

Anfragen an Web-Werkzeuge müssen getrennt von Modell-Token erfasst werden. DeepSeeks Seite „Models & Pricing“ führt Search und Fetch als eigenständige APIs auf, die pro erfolgreicher Anfrage abgerechnet werden. Laut dieser Seite nutzen die serverseitigen Werkzeuge in DeepSeek Harness, Claude Code und Codex diese APIs bereits. Solche integrierten Aufrufe sind derzeit kostenlos; ihre Abrechnung pro Anfrage beginnt am 1. November 2026 um 00:00 Uhr Pekinger Zeit. Abrechnungshinweis zu Search und Fetch.

Bei einem Rechercheagenten kann eine fertige Antwort sowohl Modellausgaben als auch mehrere Web-Operationen erfordern. Ein Nutzungsdashboard, das nur Token zählt, zeigt diesen Arbeitsumfang nicht vollständig. Für Search und Fetch sind separate Zähler erfolgreicher Anfragen sinnvoll. Außerdem sollte geprüft werden, ob Wiederholungsversuche und wiederholte Abfragen tatsächlich nützliche Arbeit leisten.

Der Termin verändert die Betriebsannahmen eines bestehenden Agenten; er ist kein Anlass, ihn neu aufzubauen. Vor dem Stichtag sollten die Werkzeugaufrufe sichtbar gemacht und ein zur Aufgabe passendes Anfragebudget festgelegt werden. Die einzelnen Tarife stehen im verlinkten Preisleitfaden.

Was wird überschätzt – und was ist jetzt zu tun?

Ein neuerer Name, ein größeres Kontextfenster und offene Modellgewichte beantworten jeweils eine andere Frage. Keines dieser Merkmale macht ein Modell automatisch zur richtigen Wahl für jede Aufgabe.

„Pro“ begründet keine allgemeingültige Qualitätsrangfolge. Ein großes Kontextlimit belegt keinen zuverlässigen Informationsabruf. Modellgewichte unter MIT-Lizenz ergeben weder ein fertiges Bereitstellungssystem noch kostenlose gehostete Inferenz. Und die Annahme eines älteren Alias bedeutet nicht, dass das frühere Modell weiter verfügbar ist.

Jetzt handeln sollten Teams, deren Produkt einen der beiden älteren Flash-Namen verwendet: die Abnahmetests erneut ausführen und das Verhalten unter der aktuell bereitgestellten Revision prüfen. Dasselbe gilt bei integrierten Search- oder Fetch-Aufrufen, denn die Nutzungserfassung muss den Beginn der Abrechnung berücksichtigen.

Mit dem Wechsel warten lässt sich, wenn ein bestehender Pro-Textworkflow seine Anforderungen erfüllt und kein gemessener Grund für einen Ersatz vorliegt. Die Umstellung der Flash-Aliasse verändert den konfigurierten Pro-Verarbeitungspfad nicht; seine aktuelle Zuordnung bleibt Pro-0813. Die üblichen Prüfungen für einen extern betriebenen Dienst bleiben angebracht.

Für die separate Anbieterentscheidung helfen DeepSeek vs Claude oder DeepSeek vs ChatGPT. Die Modellwahl sollte zum umgebenden Produkt und Workflow passen.

Der nächste praktische Schritt: Eine häufige, überprüfbare Aufgabe auswählen und gespeicherte Beispiele sowohl über den aktuellen Verarbeitungspfad als auch mit dem passenden Kandidaten erneut ausführen. Dazu gehören ein Bildbeispiel, falls das Produkt Bilder annimmt, eine lange Eingabe und ein fehlgeschlagener Werkzeugaufruf. Erfasst werden akzeptierte Ergebnisse, Prüfaufwand, Laufzeit, Modell-Token und Anfragen an Web-Werkzeuge. Der Kandidat sollte erst dann übernehmen, wenn diese Ergebnisse den Wechsel rechtfertigen.

Häufige Fragen

Der Newsletter liefert praktische Hinweise zur Auswahl und zum Betrieb von KI-Tools.