DeepSeek V4.1 Flash migrieren: Die API-Checkliste für Agenten

Kurzfassung: DeepSeeks aktuelle API akzeptiert deepseek-flash für V4.1 Flash. Die eingestellten Namen deepseek-v4-flash und deepseek-v4-flash-vision-exp leiten weiterhin auf Flash weiter und werden zu Flash-Preisen abgerechnet.^[1] V4 Pro läuft nach dem 14. September mit unveränderter Abrechnung weiter, nachdem DeepSeek die geplante Umleitung zurückgenommen hat.^[2] Eine Migration ist deshalb eine Prüfung des API-Verhaltens: Route, Tool-Trajektorie, Cache-Abrechnung, Ausgabelimit und Nutzerisolation müssen geprüft werden, bevor ein unveränderter Modellstring als sicheres Upgrade gilt.

DeepSeek V4.1 Flash ist nicht bloß ein günstigerer Endpunkt. Hinter einem vertrauten Namen kann ein Agent jetzt native Vision, eine neue aktuelle Modell-ID, ein Kontextlimit von einer Million Token und maximal 384K Output erhalten.^[1] Daraus folgt nicht, dass ein bestehender Workflow gleich bleibt.

Die eigentliche Geschichte ist keine Umbenennung. Eine Routing-Schicht kann Quellkompatibilität bewahren und zugleich den Betriebsvertrag darunter verändern. Das ist praktisch für eine Demo, aber riskant für Agenten mit Tools, langer Historie oder mehreren Nutzern.

Dies ist eine Analyse von DeepSeeks Release vom 10. September und der am 20. September geprüften Dokumentation.^[3] Das folgende Akzeptanzprotokoll ist eine empfohlene Deployment-Prüfung. LLM Rumors hat es nicht ausgeführt und berichtet keine Testergebnisse.

Titelbild: KI-generierte konzeptionelle redaktionelle Illustration. Die Prüfvorrichtung steht für eine API-Vertragsprüfung, nicht für eine DeepSeek-Oberfläche, einen Benchmark oder ein Messergebnis.

Die gewünschte Route festlegen: Ein Alias ist eine Kompatibilitätsschicht

Der Changelog vom 10. September sagt: V4 Flash und V4 Flash Vision Exp sind eingestellt, ihre alten IDs werden aber weiter akzeptiert und von V4.1 Flash bedient. Die dokumentierte aktuelle ID lautet deepseek-flash.^[2] Derselbe Changelog hält fest, dass DeepSeek die geplante V4-Pro-Umleitung nach Nutzernachfrage zurückgenommen hat und V4 Pro bis auf Weiteres unverändert abrechnet.

Damit gibt es zwei Entscheidungen. Wer bewusst zu Flash wechselt, ruft deepseek-flash auf, notiert das Dokumentationsdatum und behält eine Regressionssuite. Wer das dokumentierte Verhalten von V4 Pro benötigt, ruft deepseek-v4-pro ausdrücklich auf. Ein alter Flash-Alias kann während eines gestaffelten Rollouts sinnvoll sein, pinnt aber keine stabile Modellversion.

Den gesamten Tool-Loop testen: Thinking gehört zur Historie

DeepSeek dokumentiert Tool-Aufrufe im Thinking-Modus.^[7] Ein Detail der Thinking-Anleitung wird bei Migrationen leicht übersehen: Enthält eine Anfrage tools, muss reasoning_content aus vorherigen Turns zurückgegeben werden und wird an den Kontext angehängt. Ohne Tools muss der Inhalt nicht zurückgegeben werden; selbst dann wird er nicht an den Kontext angehängt.^[5]

Das ist keine Aufforderung, verdecktes Reasoning Endnutzern zu zeigen. Es ist eine Integrationsanforderung für die vom Anbieter beschriebene API-Trajektorie. Testen Sie genau die Nachrichtenhistorie, die Ihr Harness speichert, die Tool-Call-ID, das Tool-Ergebnis, einen Folgeturn und die Endantwort. Ein erfolgreicher erster Tool-Aufruf beweist weit weniger als ein erfolgreicher zweiter Turn nach Fehler, Retry oder großem Tool-Payload.

DeepSeek ordnet angeforderte Reasoning-Stufen je nach Schnittstelle unterschiedlich zu. Im OpenAI-Format akzeptiert die Anleitung low, high und max für reasoning_effort; andere Werte werden auf unterstützte Stufen abgebildet.^[5] Verwenden Sie pro Akzeptanztest eine feste Stufe. Ein Tool-Run mit high und ein Chat-Run mit low sind kein Modellvergleich.

Wenn Ihre Anwendung Bilder annimmt, ergänzen Sie einen eigenen Abnahmetest mit der dokumentierten Vision-Schnittstelle von Flash. Prüfen Sie ein gut lesbares Bild, ein mehrdeutiges Bild und eine fehlerhafte Eingabe. Eine erfolgreiche Textmigration belegt noch keine funktionierende Bildverarbeitung.^[9]

Repräsentative Tool-Trajektorie: IDs erhalten, nicht nur Text

Das folgende Beispiel ist illustrative Pseudodaten, zusammengestellt aus DeepSeeks dokumentierter Tool-Call-Sequenz für Chat Completions. Es ist kein API-Test und keine Aussage darüber, was V4.1 Flash auswählen wird. Ein Nutzer fragt nach einer wetterabhängigen Antwort. Das Modell liefert eine Assistant-Nachricht mit einem tool_calls-Element, einer ID und JSON-Argumenten. Die Anwendung hängt diese vollständige Assistant-Nachricht an die Historie an, führt ihren eigenen Wetterdienst aus und ergänzt danach eine role: "tool"-Nachricht mit derselben tool_call_id und einem begrenzten Ergebnis. Erst dann wird der Folgeturn gesendet.^[7]

Bei einer Thinking- und Tool-Trajektorie ist der Vertrag strenger. Die vom Anbieter verlangten Reasoning-Inhalte müssen gemeinsam mit dem vorherigen Assistant-Turn, der Tool-Call-ID, dem Tool-Ergebnis und ihrer Reihenfolge exakt erhalten bleiben. Die kurze Sequenz unten ist illustrative Pseudodaten, kein ausgeführtes Request-Transkript.

Einen alten Tool-Aufruf darf man nicht allein wegen eines Netzwerk-Retry wiederholen. Ein vor einem zustandsverändernden Tool gespeicherter Request- oder Idempotenzschlüssel garantiert nach einem Absturz keine genau einmalige Ausführung. Der nachgelagerte Dienst muss einen Idempotenzschlüssel unterstützen, sofern möglich. Andernfalls muss die Anwendung den Zustand beim externen Anbieter abstimmen, bevor sie wiederholt, ein protokolliertes Ergebnis zurückgibt oder menschliche Prüfung verlangt. Das ist Anwendungsdesign, keine DeepSeek-Zusage.

Cache-Grenzen messen: Wiederverwendung muss vollständig passen

Unsere frühere Analyse zu V4.1 Flash, Preisen und Agentenspeicher erklärt, weshalb Cache-Hit-Preise die Ökonomie verändern. Zuerst muss jedoch die Umsetzung stimmen. DeepSeek sagt, Kontext-Caching sei standardmäßig aktiv, erzeuge Cache-Einheiten am Ende der Nutzereingabe und der Modellausgabe und verlange für einen Hit eine vollständige Übereinstimmung mit einer persistierten Präfixeinheit.^[6]

Ein sicherer Versuch bleibt klein: Stabile Systeminstruktion und festen Repository- oder Kontextblock beibehalten. Eine erste Anfrage senden, dann einen kontrollierten Folgeturn mit identischem Präfix. Die Usage-Felder für Cache-Hit- und Cache-Miss-Input aufzeichnen. Danach genau eine Präfixänderung vornehmen. Erwartet wird kein Leistungsscore, sondern der Nachweis, dass abgerechneter und gespeicherter Kontext dem Produktdesign entspricht. Caching erfolgt bestmöglich: Ein wiederholtes Präfix erfüllt eine Voraussetzung für einen Hit, garantiert aber nicht, dass die unmittelbar folgende Anfrage trifft.

Die unbequeme Wahrheit: Ein Cache-Miss kann von der Anwendung kommen, nicht von einem schlechteren Modell. Umgeordnete Richtlinien, Mandantentext vor dem gemeinsamen Präfix, neu erzeugte Zeitstempel und uneinheitliche Serialisierung können die Vollübereinstimmung zerstören. Ein veränderter Abschnitt kann nicht durch die alte vollständige Präfixübereinstimmung qualifizieren, doch eine frühere persistierte Cache-Einheit kann weiterhin gelesen werden. Prüfen Sie die zurückgegebenen Tokenzahlen für Cache-Hits und Cache-Misses, abgeglichen mit dem gesamten Input-Verbrauch, statt pauschal „kein Cache-Hit“ zu behaupten.

Output vor dem Produktivbetrieb begrenzen: 384K sind kein Budget

V4.1 Flash nennt maximal 384K Output und eine Million Token Kontext. Die Peak-Listenpreise liegen bei $0,006/M Cache-Hit-Input, $0,30/M Cache-Miss-Input und $1,20/M Output. Off-Peak kostet die Hälfte.^[1] Output ist damit je Token 200-mal so teuer wie Peak-Cache-Hit-Input. Das rechnet keine Agentenrechnung voraus, zeigt aber: Cache-Optimierung ersetzt keine Kontrolle der Ausgaben.

Setzen Sie aufgabenspezifische Maximalwerte, Stoppbedingungen und ein Limit für Tool-Ergebnisse. Beobachten Sie unvollständige Responses-API-Events. DeepSeek dokumentiert response.incomplete, wenn Output abgeschnitten wird, auch bei max_output_tokens.^[4] Ein großes Limit gehört zu einem geprüften Artefakt oder begrenzten Wiederherstellungspfad, nicht in jeden Planungsturn.

Beispielrechnung: Cache-Ersparnis ersetzt weder Output noch Retries

Nehmen wir eine absichtlich einfache Peak-Preisillustration, keine Schätzung eines realen Agenten. Ein Agent sendet ein stabiles Präfix von 100.000 Token, 10.000 frische Input-Token und erhält 20.000 Output-Token. Die erste Anfrage ist ein Cache-Miss: 110.000 Input-Token zu $0,30/M kosten $0,033, 20.000 Output-Token zu $1,20/M kosten $0,024. Zusammen sind das $0,057, bevor Tools oder weitere Kosten zählen. Eine zweite Anfrage, die das gesamte Präfix von 100.000 Token wiederverwendet, erneut 10.000 frische Input-Token hinzufügt und denselben Output erzeugt, kostet $0,0006 für Cache-Hit-Input, $0,003 für frischen Input und $0,024 für Output: $0,0276.

Der Cache spart bei diesem Folgeturn $0,0294 beim Input. Er macht die Antwort mit 20.000 Token nicht kostenlos. Wenn der Agent nach einem unsicheren externen Tool-Ergebnis wiederholt und erneut dieselbe Antwort erzeugt, kommen unter diesen Annahmen weitere $0,0276 Modellkosten hinzu, noch vor dem externen Seiteneffekt. Die Rechnung verwendet DeepSeeks dokumentierte Listenpreise und setzt einen vollständigen Hit voraus. Tatsächliche Rechnungen hängen von Zeitfenster, Tokenzahl, Hit-Abrechnung, Output-Länge und produktspezifischen Kosten ab.^[1] Kostenlimits gehören dorthin, wo die Varianz liegt: Output, Retries und Umfang von Tool-Ergebnissen.

Nutzergrenzen bewahren: Cache-Isolation ist eine Anwendungsentscheidung

Laut Rate-Limit-Anleitung isoliert user_id den KV-Cache anhand der Nutzer-ID auf Geschäftsseite. Die gewöhnlichen Parallelitätslimits von 2.500 beziehungsweise 500 gelten weiterhin kontoweit. Separate Limits je Nutzer beschreibt DeepSeek nur für Nutzer mit gewährten erhöhten Parallelitätsquoten. Eine leere ID wird als besondere ID behandelt; bei Überschreitung eines anwendbaren Limits gibt die API HTTP 429 zurück.^[8] Verwenden Sie eine stabile, datensparsame Anwendungskennung und testen Sie zwei verschiedene Nutzer mit ähnlichen Prompts. Ihre Session- und Berechtigungsschicht darf niemals die gespeicherte Unterhaltung oder Tool-Ausgabe eines Nutzers an einen anderen liefern.

DeepSeeks Vorgaben beschreiben Cache-Isolation und Parallelität. Sie ersetzen weder Mandantenautorisierung noch Klassifizierung sensibler Daten, Löschpflichten oder menschliche Freigabe. Die Cache-Grenze des Anbieters ist ein Kontrollpunkt in einem größeren System.

Mit Gates ausrollen: Ein Fallback muss bewusst sein

Beginnen Sie mit schreibgeschützten, reversiblen Aufgaben und einem festen Testkorpus. Ein Kandidat besteht erst, wenn die explizite Flash-Route beobachtet wird, die Akzeptanzfälle die vorher formulierten Assertions erfüllen und sich die zurückgegebenen Usage-Felder mit der Anfrage abstimmen lassen.

Zwei Anwendungs-IDs müssen außerdem in Logs und Autorisierungsprüfungen getrennt bleiben. Die erwartete Modell-ID sollte für jeden Fall protokolliert werden. Diese Assertions prüfen ein Harness, nicht DeepSeeks Intelligenz oder ein garantiertes Service-Level.

Ein Cache-Miss allein ist kein Rollback-Grund, ein einzelner erfolgreicher Prompt kein Freigabegrund. Pausieren oder zurückrollen sollten Teams, wenn die Modellroute vom Releaseplan abweicht, ein Seiteneffekt nicht abgestimmt werden kann, Output-Trunkierung die Wiederherstellung umgeht, eine Berechtigungsgrenze unklar ist oder die Fehler- und 429-Politik nicht getestet wurde. deepseek-v4-pro bleibt nur für den Zeitraum und den Workload eine bewusst konfigurierte Rollback-Route, für den seine dokumentierte Fortführung relevant ist. Ziel ist Wiederherstellbarkeit, nicht der Mythos, APIs änderten sich nie.

Akzeptanzmatrix: Begrenzte Prüfungen für V4.1 Flash

Dies sind empfohlene Prüfungen, keine vom Anbieter gemeldeten Testergebnisse. Für jeden Fall sollten exakte API-Version, Modell-ID, Effort, Zeitpunkt und Usage festgehalten werden.

DeepSeek macht den Start einer Migration leicht. Die schwierige Arbeit bleibt dort, wo Produktionssysteme scheitern: nachweisen, dass ein Alias wirklich die beabsichtigte Route nahm, eine Tool-Historie gültig blieb, der Cache traf, langer Output sicher stoppte und Nutzer getrennt blieben. Dieser Vertrag ist wertvoller als ein Modellstring, der zufällig keinen Fehler auslöst.

Quellen: Dokumentation und Anbieterangaben

Schlüsselquellen: 1, 2, 4 und 6. Die Dokumentation wurde am 20. September 2026 geprüft.

Zuletzt aktualisiert: 20. September 2026