DeepSeek V4 Flash oder Pro: die passende API je Aufgabe

Eine Textpipeline kann Extraktion, Dokumentprüfung oder Rollenspiel brauchen, jeweils mit anderem Ausgabebudget. Für eine neue Integration starten Sie mit deepseek/v4.1-flash/chat: $0.30 Input und $1.20 Output pro Million, bei einer Antwortobergrenze von 384.000 Tokens. Ist Ihre Integration an eine V4-ID gebunden, nutzen Sie V4 Flash für Routinearbeit; wählen Sie Pro wegen der expliziten Steuerung paralleler Tool-Aufrufe, bei einer Antwort über 65.536 Tokens oder für eine konkrete Aufgabe, bei der das Ergebnis den dreifachen Tokenpreis rechtfertigt. Beide V4-IDs lesen 1.048.576 Tokens, langer Input allein ist also kein Grund, für Pro zu zahlen.

Der Migrationsleitfaden zu V4.1 Flash behandelt den Weg für Neuprojekte. Die folgenden Vergleiche gelten für die beiden gehosteten V4-IDs.

Welches Modell für welche Aufgabe

Die Unterschiede im Vertrag

Die Seiten zu V4 Flash und V4 Pro zeigen die aktuellen gehosteten Felder. Beide erlauben bis zu 256 Nachrichten und 128 Tool-Definitionen bei bis zu 60 Minuten pro Anfrage, und keines stellt temperature oder top_p bereit. Die Gegenüberstellung von SpicyAPI zeigt dieselben Felder aus dem Live-Schema.

Beide Endpunkte lehnen Felder ab, die sie nicht aufführen. Ein vom Pro-Endpunkt kopierter Body mit parallel_tool_calls scheitert bei Flash an der Validierung, statt ignoriert zu werden. Halten Sie die modellspezifischen Felder daher getrennt, statt die Vereinigungsmenge zu senden.

Wo diese IDs bei DeepSeek stehen. Das aktuelle Änderungsprotokoll von DeepSeek stellt V4 Flash ein und leitet dessen alten Alias vorübergehend auf V4.1 Flash um, während der Dienst für V4 Pro bei unveränderter Abrechnung weiterläuft. SpicyAPI führt die oben genannten getrennten IDs; hinterlegen Sie bei der Pflege einer V4-Integration die vollständige gehostete ID statt eines Upstream-Alias. Die Ankündigung vom 10. September von DeepSeek beschreibt die nativen Alias-Weiterleitungen. Ein Forenergebnis mit nativen Aliasen vergleicht deshalb womöglich gar nicht die ursprünglichen V4-Versionen; unterscheiden Sie Modellnamen, versionierte IDs und beobachtete Ergebnisse, bevor Sie sich auf eine Seite zu „Flash vs Pro“ verlassen. Für einen Neubau sind der niedrigere Preis und die größere Antwortobergrenze von V4.1 Flash der praktische Grund, dort zu beginnen.

Was andere Entwickler mit dem Paar festgestellt haben

Ein Code-Review-Benchmark mit 18 Läufen auf einer Python-Codebasis, mit den datierten Snapshots 0731 für Flash und 0813 für Pro, ergab einen nützlichen Unterschied:

• Abdeckung: Pro lieferte 169 überprüfbare Aussagen gegenüber 70 bei Flash. Die Genauigkeit der Aussagen lag nah beieinander: 95,9 % gegenüber 95,7 %.
• Fehlersuche: Flash fand alle drei bekannten latenten Fehler, Pro einen. Flash erfand zudem einen Randfall, prüfen Sie vorgeschlagene Korrekturen also gegen den Quellcode.
• Konstanz: Die Berichtstiefe von Pro schwankte zwischen wiederholten Läufen um das 2,7-Fache. Ein Flash-Scan mit anschließender gezielter Pro-Prüfung schnitt in diesem Aufbau am besten ab.

Nutzen Sie Flash für den günstigen ersten Durchgang und geben Sie einen unklaren Befund, seine Quelle und eine präzise Frage an Pro weiter. Kein Bericht eines der beiden Modelle ersetzt Quellprüfungen oder Anwendungstests.

Zuerst im Playground ausprobieren

1. Öffnen Sie DeepSeek V4 Flash und wechseln Sie zum Playground.
2. Fügen Sie den Katalogfreigabe- und Inventar-Timeout-Eintrag aus dem Beispiel ein. Fragen Sie, ob Job E42 exportiert werden kann.
3. Wiederholen Sie das mit demselben Input auf V4 Pro. Beide Antworten sollten den Export blockieren, weil die aktuelle Inventarabfrage fehlgeschlagen ist.

Beide an einer Entscheidung mit einer richtigen Antwort testen

Angenommen, der Storefront-Export eines Creators hängt von einem freigegebenen Katalog und einer aktuellen Inventarabfrage ab. Das Modell muss benennen, was den Export blockiert, ohne einen ausstehenden Schritt als erledigt zu behandeln. Die Testvorlage ist günstig genug, um sie auf beiden Modellen auszuführen, bevor Sie ein großes Transkript senden.

Setzen Sie SPICY_API_KEY mit einem Schlüssel aus den API Keys. Die Anfrage nutzt die Chat-Completions-Schnittstelle von SpicyAPI.

cat > request.json <<'JSON'
{
  "model": "deepseek/v4-flash/chat",
  "messages": [
    {
      "role": "system",
      "content": "Return JSON with can_export (boolean), blockers (array of strings), and evidence (array of exact source quotes). Use only the supplied record. Every required dependency must be complete before export."
    },
    {
      "role": "user",
      "content": "Job E42 requires catalog approval and a current inventory lookup. Record: \"Catalog approved at 10:00. Inventory lookup timed out at 10:03. The last inventory snapshot is from yesterday.\" Can this job be exported now?"
    }
  ],
  "max_tokens": 2048,
  "reasoning_effort": "low",
  "response_format": {
    "type": "json_object"
  }
}
JSON

curl --fail-with-body https://api.spicyapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  --data-binary @request.json --output response.json

python3 - <<'PY'
import json
from pathlib import Path

response = json.loads(Path("response.json").read_text())
choice = response["choices"][0]
if choice.get("finish_reason") != "stop":
    raise SystemExit("FAIL: reply did not finish normally")
answer = json.loads(choice["message"]["content"])
quotes = {"Catalog approved at 10:00.",
          "Inventory lookup timed out at 10:03.",
          "The last inventory snapshot is from yesterday."}
blockers = answer.get("blockers")
evidence = answer.get("evidence")
valid = (
    answer.get("can_export") is False
    and isinstance(blockers, list) and bool(blockers)
    and all(isinstance(item, str) and item.strip() for item in blockers)
    and any("inventory" in item.lower() for item in blockers)
    and isinstance(evidence, list) and bool(evidence)
    and all(isinstance(item, str) and item in quotes for item in evidence)
    and "Inventory lookup timed out at 10:03." in evidence
)
if not valid:
    raise SystemExit("FAIL: decision, blocker or source evidence is incorrect")
print("PASS: export is blocked by the timed-out inventory lookup")
PY

Die richtige Entscheidung ist can_export: false, mit dem fehlenden aktuellen Inventar als Blocker. Der Snapshot von gestern ist nicht die geforderte aktuelle Abfrage, und das Array evidence sollte die Timeout-Zeile zitieren.

Das ist eine Prüfung der Testvorlage, kein allgemeiner Business-Validator: Echte Exporte sollten die tatsächlichen Abhängigkeitsstatus Ihrer Anwendung verwenden. Ein Modell kann einen echten Satz zitieren und trotzdem die falsche Schlussfolgerung ziehen, weshalb hier sowohl Entscheidung als auch Beleg geprüft werden.

Um Pro mit demselben Input auszuführen, ändern Sie nur die Modell-ID. Halten Sie Quelle, Anweisungen, Effort und Ausgabeobergrenze identisch und bewerten Sie jede Antwort nach zwei Fragen: Hat sie den Blocker benannt, und kommen die Zitate im Eintrag vor? Eine längere Erklärung ist keine bessere Entscheidung.

Besteht Flash, gibt Ihnen diese Testvorlage keinen Grund, für diese Aufgabe Pro zu bezahlen. Erfindet eines der Modelle einen Inventarerfolg, geben Sie seine Antwort nicht weiter, nur weil das JSON geparst wurde. Scheitern beide, prüfen Sie, ob die Anforderung klar formuliert war, bevor Sie einen höheren Preis als Lösung ansehen.

Einen Agent den Aufruf vorbereiten lassen

Für wiederholte Export-Entscheidungsprüfungen bitten Sie Ihren Coding-Agent, den SpicyAPI Skill zu nutzen: „Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it.“ Die Abfrage per CLI lautet spicyapi models get deepseek/v4-flash/chat --json; per MCP spicyapi_model_get mit model: "deepseek/v4-flash/chat". Chat-Aufrufe laufen über einen kompatiblen Client oder die Chat-API; die Befehle für Medien-Tasks erzeugen keine Chat-Antworten.

Welcher Workflow verdient den höheren Preis?

Um Veröffentlichungsdatum, Figurennamen und gewünschte Bildanzahl eines Creators aus einem vollständigen Briefing zu extrahieren, hat Flash die gängigen Steuerungen und ausreichend Ausgabekapazität. Die größere Ausgabeobergrenze von Pro bringt einem kurzen JSON-Objekt nichts. Beginnen Sie mit Flash und nutzen Sie explizite Fehlwerte, damit aus „no release date supplied“ kein erfundenes Datum wird.

Bei einer Abhängigkeitsprüfung über mehrere Datensätze machen Sie die Regeln des Jobs konkret. Eine freigegebene Figurenreferenz genügt nicht, wenn die Einstellung eine freigegebene zweite Figur und ein aktuelles Inventar-Asset braucht. Ein Modell sollte die fehlende zweite Freigabe erkennen, auch wenn das umgebende Produktionstranskript die Einstellung immer wieder als bereit bezeichnet. Die Testvorlage oben prüft diese Unterscheidung am Beispiel Inventar. Bei einem fehlgeschlagenen komplexen Job kann sich ein Vergleich mit Pro lohnen.

Bei einer sehr großen Transformation kann die Ausgabeanforderung die Wahl entscheiden, ohne dass eine Qualitätsbehauptung nötig ist. Muss das tatsächlich zurückgegebene Dokument in einer Antwort 65.536 Tokens überschreiten, passt die Obergrenze von Flash nicht, und Pro erlaubt mehr Ausgabe. Lassen sich unabhängige Datensätze in kleineren Gruppen zurückgeben, kann Batching Flash nutzbar halten und eine fehlgeschlagene Gruppe leichter wiederholbar machen. Teilen Sie keine Aufgabe auf, deren Antwort von Beziehungen zwischen diesen Gruppen abhängt, ohne diese Beziehungen mitzuführen.

Ein selektives Upgrade ist nur wirtschaftlich, solange es selektiv bleibt. Unter den Annahmen von 50.000 Input- und 3.000 Output-Tokens unten kosten 900 Flash-Aufrufe plus 100 Pro-Aufrufe $31.152, gegenüber $77.88 für alle 1.000 auf Pro. Läuft jeder Job zuerst über Flash und 100 brauchen anschließend Pro, beträgt die Summe $33.748. Das sind hypothetische Summen zur Erklärung des Retry-Kompromisses; der tatsächliche Tokenverbrauch wird abweichen.

Was eine Anfrage bei gleicher Nutzung kostet

Für eine Anfrage mit 50.000 nicht gecachten Input-Tokens und 3.000 abgerechneten Output-Tokens:

• Flash: 50.000 × $0.44/M + 3.000 × $1.32/M = $0.02596.
• Pro: 50.000 × $1.32/M + 3.000 × $3.96/M = $0.07788.

Tausend solcher Anfragen kosten $25.96 und $77.88. Wenn 40.000 der Input-Tokens aus dem Cache gelesen werden und 10.000 nicht, ergeben sich pro Anfrage $0.00892 für Flash und $0.02684 für Pro. Die Cache-Preise stehen nicht exakt im Verhältnis drei zu eins, rechnen Sie also die Summen aus, statt vom Listenpreis aus zu runden.

Zwei Dinge beeinflussen die Rechnung stärker als die Modellwahl:

• Reasoning wird als Output abgerechnet. Der Standard-Effort ist high. Testen Sie bei Extraktion und Klassifikation low oder none, um den Reasoning-Durchgang zu überspringen, und vergleichen Sie neben den Tokens auch die akzeptierten Ergebnisse.
• Wiederholungen zählen. Entscheidend sind die Kosten pro akzeptierter Antwort, nicht pro Aufruf.

Selektive Eskalation behält den größten Teil der Ersparnis. Schicken Sie alles an Flash und ein fehlgeschlagenes oder mehrdeutiges Ergebnis zusammen mit dem Beleg, warum es scheiterte, an Pro. Wird bei obiger Nutzung eine von zehn Anfragen eskaliert und zahlt eine eskalierte Anfrage sowohl den Flash- als auch den Pro-Aufruf, liegt der Durchschnitt bei etwa $0.03375 pro Anfrage, gegenüber $0.0779 für alles auf Pro. Ein zweites Modell kann denselben Fehler wiederholen, behalten Sie also die echte Korrektheitsprüfung der Aufgabe bei.

Wann die größere Ausgabe von Pro zählt

Die Obergrenze von 384.000 Tokens zählt nur, wenn die benötigte Antwort wirklich 65.536 Tokens übersteigt, etwa bei einem geordneten Migrationsplan mit SQL und Rollback für jeden Schritt, der gemeinsam zurückkommen muss. Ein kurzer Bericht über einen langen Input erfüllt das nicht; die Eingabekapazität ist identisch.

Bevor Sie eine riesige Antwort anfordern, prüfen Sie, ob Ihr Konsument sie validieren und speichern kann. Eine kapitelweise Bearbeitung oder in unabhängige Gruppen geteilte Datensätze lassen sich nach einer Unterbrechung leichter wiederherstellen. Behalten Sie nur dann eine einzige Antwort bei, wenn die Teile von einer gemeinsamen Struktur abhängen.

Verwechseln Sie das Maximum nicht mit dem Standard. Beide haben standardmäßig 32.768 Output-Tokens, und eine Antwort, die das Limit erreicht, wird ohne Fehler abgeschnitten. Setzen Sie für kurze Aufgaben wie die Testvorlage oben einen kleinen expliziten Wert und einen größeren nur dort, wo das Ergebnis ihn braucht.

Wann parallele Tool-Aufrufe zählen

Pro akzeptiert parallel_tool_calls, Flash nicht. Das sagt Ihnen, welchen Request-Body Sie senden dürfen, nicht, dass Flash keine Tools nutzen kann: Beide akzeptieren Tool-Definitionen und tool_choice.

Unabhängige Lesezugriffe kommen für parallele Aufrufe infrage, etwa das gleichzeitige Abrufen eines freigegebenen Katalogs und eines Inventareintrags. Die Export-Aktion hängt von beiden Ergebnissen ab und muss warten. Erzwingen Sie diese Abhängigkeit in Ihrer Anwendung, statt eine vorgeschlagene Tool-Abfolge als Erlaubnis zum Handeln zu behandeln. Setzen Sie parallel_tool_calls bei Pro auf false, ergibt das höchstens einen Aufruf pro Runde, wenn jeder Aufruf das vorherige Ergebnis braucht.

Braucht Ihre Schleife die explizite Steuerung, ist das ein konkreter Grund für Pro. Führt sie sequenzielle Abfragen aus und gibt eine kurze Antwort zurück, starten Sie mit Flash und ergänzen Nebenläufigkeit erst, wenn die Basisschleife funktioniert.

Schreiben und Rollenspiel ohne Zensur

Beide Modelle haben bei SpicyAPI die Stufe „Uncensored“: kein Inhaltsfilter der Plattform, übrig bleibt das eigene Verhalten des jeweiligen Modells. In unseren Content-Ladder-Tests vom September 2026 lehnten beide eine direkte Anfrage der Kategorie Erwachsenenszene mit höherer Intensität (in den Reviews L4) ab, wenn sie ohne Kontext kam, und beide schrieben sie, sobald ein System-Prompt einen fiktionalen Schreibrahmen setzte:

Auf L5 schloss jedes Modell drei Formulierungen des Erwachsenenfiktion-Briefings und drei eines separaten Briefings für nicht-erwachsene drastische Fiktion ab. Flash schwächte einen Lauf in der mildesten andeutenden Kategorie ab; die übrigen Tests auf niedrigeren Stufen liefen durch. Für Erwachsenenfiktion gilt also: Rahmen Sie den Job bei beiden Modellen im System-Prompt, und zahlen Sie nicht für Pro in der Hoffnung, dass es seltener ablehnt. Unsere Reviews zu V4 Flash und V4 Pro führen jeden Lauf auf.

Rollenspiel ist ausgabelastig, und genau dort zeigt sich das Preisverhältnis drei zu eins: etwa $0.57 pro 100 Züge bei Flash gegenüber $1.72 bei Pro, bei angenommenen 10.000 nicht gecachten Input-Tokens und 1.000 abgerechneten Output-Tokens pro Zug, einschließlich Reasoning.

FAQ

Genügt V4 Flash fürs Programmieren?

Es ist der günstigere Einstieg, und der Benchmark mit einer Codebasis fand mit Flash alle drei bekannten Fehler. Prüfen Sie vor einer vorgeschlagenen Änderung die zitierte Quelle und führen Sie die betroffenen Tests aus. Ein gezielter Pro-Durchgang ist eine Eskalationsoption, kein Ersatz für diese Prüfungen.

Ist Flash langsam?

Der SpicyAPI-Test erfasste 40 Output-Tokens pro Sekunde für Flash und 46 für Pro. Dieser kleine Abstand ist für sich genommen kein Grund, das Tokenbudget zu verdreifachen, und die tatsächliche Latenz hängt von Reasoning und Antwort ab. Senken Sie bei kurzen Aufgaben den Effort, statt diese Momentaufnahme als aktuelle Geschwindigkeitsgarantie zu betrachten.

Warum Flash wählen, wenn Pro das größere Modell ist?

Beide gehosteten IDs akzeptieren denselben langen Input, während Flash bei nicht gecachten Tokenpreisen etwa ein Drittel kostet. Bei kurzen Extraktions- oder Klassifikationsantworten bringt die größere Ausgabeobergrenze von Pro für sich genommen nichts. Eskalieren Sie ein mehrdeutiges Ergebnis, wenn Sie eine konkrete Frage für den teureren Durchgang haben.

Soll ich eine neue Integration auf V4 oder V4.1 Flash starten?

Starten Sie mit V4.1 Flash, es sei denn, Sie brauchen einen bestimmten V4-Vertrag oder pflegen eine fest gebundene Integration. Nur der eingestellte V4-Flash-Alias leitet auf V4.1 um; V4 Pro läuft weiter, und diese gehosteten Verträge bleiben getrennt aufgeführt. Prüfen Sie jedes Verhalten, auf das sich Ihre Anwendung stützt, erneut, bevor Sie Produktionsverkehr umstellen.