DeepSeek beginnt, die ultimative „intelligente Dichte“ anzustreben
DeepSeek stellt dem neuen Flash eine Aufgabe: Kann es das eigene Pro-Modell ablösen?
Gestern wurde die Zwischenversion V4.1 Flash für die interne Testphase freigegeben. Eine neue Modellarchitektur, native Multimodalität und höhere Geschwindigkeit sind die Highlights in der offiziellen Ankündigung. Im zugehörigen Feedback-Fragebogen fragt DeepSeek die Nutzer direkt: „Glauben Sie, dass dieses Modell das online verfügbare DeepSeek V4 Pro vollständig ersetzen kann?“
Na also, man greift sich selbst an. DeepSeek testet gerade, ob Flash in der Leistung das Pro-Modell übertreffen kann und ob das günstigere, für häufige Aufrufe besser geeignete Modell eingesetzt werden kann.
Zwischen Pro und Flash besteht ohnehin ein deutlicher Preisunterschied. Derzeit kostet Flash in Spitzenzeiten 9 Yuan pro Million Ausgabe-Token, während Pro 27 Yuan kostet.
Aber gerade eben hat DeepSeek auf seiner Open-Plattform angekündigt, dass die Preise für die Flash-Serie ab Mittag des 10. Septembers gesenkt werden: In Nebenzeiten sinken die Eingabekosten bei Cache-Treffern auf 0,02 Yuan pro Million Token, bei Cache-Fehlern auf 1 Yuan und die Ausgabekosten auf 4 Yuan; der Preis in Spitzenzeiten bleibt doppelt so hoch wie in Nebenzeiten. Die drei Senkungen betragen 60 %, ca. 33 % bzw. ca. 11 %.
Der neue Flash wird noch darauf getestet, ob er das Pro-Modell ablösen kann – die Nutzungshürden für die Flash-Serie sind bereits gesenkt worden.
Entwickler können gelegentlich den dreifachen Preis zahlen, um bessere Ergebnisse zu erzielen. Bei der täglichen Nutzung rückt jedoch die Notwendigkeit von Flash in den Vordergrund, insbesondere bei Schritten, bei denen das Ergebnis nicht unbedingt perfekt sein muss.
DeepSeek möchte, dass die neue Version die Vorteile beider Modelle vereint: Flash ist schnell, Pro ist leistungsstark – Flash V4.1 soll sowohl schnell als auch leistungsstark sein.
Vor etwas mehr als einem Jahr hat der Aufstieg von R1 die Menschen dazu gebracht, der KI mehr Zeit zu geben, um zu sehen, welche Lösungen sie entwickeln kann. Heute muss DeepSeek die Frage beantworten: Wie können die bereits erreichten Schlussfolgerungsfähigkeiten häufiger eingesetzt werden?
„Intelligenzdichte“ gewinnt an Bedeutung
Als R1 Anfang 2025 populär wurde, lag seine Anziehungskraft auch darin, dass diese Fähigkeit endlich leicht zugänglich war. DeepSeek veröffentlichte gleichzeitig die Modellgewichte, integrierte R1 in die offizielle Website, die App und die API – normale Nutzer können es über die Funktion „Tiefes Denken“ nutzen, und Entwickler können die Ausgaben von R1 nutzen, um ihre eigenen Modelle zu destillieren.
Hochwertige Schlussfolgerungsfähigkeiten sind nicht mehr etwas, das nur wenige Labore vorführen können. Sie sind in Chat-Fenster eingezogen und fließen auch in die Produktentwicklung anderer Unternehmen ein.
Im Mai 2025 hat DeepSeek bei der Aktualisierung von R1 das „tiefere Denken“ als wichtigsten Fortschritt hervorgehoben.
Beim AIME-2025-Test nutzte die alte Version von R1 durchschnittlich etwa 12.000 Token pro Aufgabe, die neue Version stieg auf 23.000; die Genauigkeit verbesserte sich von 70 % auf 87,5 %. Diese Aktualisierung führte dazu, dass R1 genauer antwortete, wobei der durchschnittliche Schlussfolgerungsverbrauch pro Aufgabe fast verdoppelt wurde.
Dieser Ansatz hat seine Berechtigung. Für schwierige Aufgaben gibt es keine fertigen Antworten – das Modell muss verschiedene Methoden ausprobieren, Zwischenschritte überprüfen und nach Entdeckung von Fehlern neu berechnen. Wenn das Ergebnis wertvoll ist, wird die zusätzliche Wartezeit akzeptiert.
Aber im V3.2-Bericht, der im Dezember 2025 veröffentlicht wurde, stellte DeepSeek sich selbst eine weitere Anforderung: Die „Intelligence Density“, also die Intelligenzdichte der Schlussfolgerungskette, zu erhöhen. Der Grund ist klar: Um die Ausgabequalität von Modellen wie Gemini 3.0 Pro zu erreichen, muss es normalerweise einen längeren Schlussfolgerungsprozess generieren.
Die Wartezeit bei der Ausgabe wird inzwischen immer wichtiger. Die Unterschiede zeigen sich in der Geschwindigkeit, aber auch in den Kosten pro Aufruf.
Dieses Problem tritt bei der Arbeitsteilung zwischen großen und kleinen Modellen noch deutlicher hervor. Aus den frühen Modellkarten von V4 geht hervor, dass Flash bei einem größeren Denkbudget eine Schlussfolgerungsleistung erreichen kann, die der von Pro nahekommt, aber in Bezug auf Wissen und die komplexesten Agent-Arbeitsabläufe noch zurückliegt.
Kleine Modelle sind bei jedem Rechenschritt günstiger, benötigen aber möglicherweise mehr Schritte, um das Ergebnis eines großen Modells zu erzielen. Wie viel von dem Preisvorteil, den Entwickler sehen, am Ende übrig bleibt, hängt davon ab, wie die Aufgabe tatsächlich ausgeführt wird.
Damit Flash Pro ersetzen kann, müssen sowohl die Fähigkeiten als auch die Effizienz verbessert werden. Eine schnellere Generierung langer Schlussfolgerungen reduziert einen Teil der Wartezeit; wenn das Modell früher eine effektive Methode findet, können sogar die nachfolgenden Rechenschritte eingespart werden. Für Personen, die KI häufig nutzen, ist das Letztere ebenso wichtig.
In der Wissenschaft wird die Wartezeit der Nutzer bereits in die Optimierungsziele einbezogen. Eine Studie der EMNLP 2025 weist darauf hin, dass die rechenoptimale Erweiterungslösung während des Tests nicht unbedingt die geringste Latenz bringt; Forscher müssen parallele Berechnungen und Spekulative Dekodierung neu anordnen, um innerhalb einer festgelegten Zeit bessere Ergebnisse zu erzielen.
DeepSeek arbeitet ebenfalls an der Verbesserung der Generierungsgeschwindigkeit. Das Team berichtete im im Juli veröffentlichten DSpark-Papier, dass bei der Auslastung durch Online-Nutzer von V4-Flash die Generierungsgeschwindigkeit pro Nutzer im Vergleich zum MTP-1-Basismodell bei gleichbleibendem Durchsatz um 60 % bis 85 % gesteigert werden konnte. Das Team adressiert die Verschwendung bei der Überprüfung im Rahmen der spekulativen Dekodierung, sodass Nutzer die Ausgaben schneller erhalten und gleichzeitig die Anzahl der Anfragen, die der gesamte Dienst verarbeiten kann, berücksichtigt wird.
Abbildung 3｜Offizielle Architekturübersicht von DSpark: Zuerst werden Kandidaten-Token generiert, dann die Enden mit niedriger Konfidenz entfernt, zuletzt erfolgt die Überprüfung durch das Zielmodell. Quelle: DSpark-Papier Abbildung 1 (Juli 2026, CC BY 4.0)
Dies ist wichtig für DeepSeek als Anbieter von APIs. Eine schnellere Beendigung von Anfragen ist nur dann effektiv, wenn die Gesamtleistung des Dienstes nicht erheblich beeinträchtigt wird. Entwickler brauchen kürzere Wartezeiten, und DeepSeek muss die gleiche Menge an Rechenressourcen effizienter für die Nutzer einsetzen.
„Kann das Problem gelöst werden?“ und „Ist der Nutzer bereit, auf die Problemlösung zu warten?“ werden zu zwei unterschiedlichen Prüfungsfragen.
Sie entsprechen auch zwei verschiedenen Märkten: Forscher können viel Rechenleistung für eine schwierige Aufgabe aufwenden, während Assistenten für den täglichen Einsatz ständig auf neue Anfragen reagieren müssen. Nachdem die erstgenannte Fähigkeit vorangetrieben wurde, müssen die Hersteller sie zu einem Dienst für den täglichen Gebrauch weiterentwickeln, damit sie in größerem Maßstab eingesetzt werden kann.
Die Intelligenzdichte, die DeepSeek in seinem Bericht vorschlägt, wird sich letztendlich hier bewähren müssen: Können Aufgaben, für die früher teure Modelle und langwierige Berechnungen erforderlich waren, allmählich zu gewöhnlichen Aufrufen werden?
Agenten müssen die Kosten für erledigte Arbeiten berücksichtigen
Am Tag des Starts dieser internen Testphase hatte der LINUX-DO-Nutzer „Jianqian“ zufällig eine Wartungsseite erstellen müssen, und hat den neuen Flash direkt in sein Programmierwerkzeug integriert.
Die Leistung des Modells hat ihn überrascht: Es hat eine Anforderung an Protokolle zur Entscheidungsfindung gelesen, die in den Projektrichtlinien längst veraltet war, aber nicht gelöscht wurde, und hat sorgfältig Vorkehrungen für die Dokumentationspflege, Code-Übermittlung und Überprüfung aufgelistet. Nachdem die Seite generiert wurde, wies er darauf hin, dass der Stil nicht vom ursprünglichen Projekt abweichen soll – das Modell fand daraufhin bereits vorhandene Illustrationen im Repository, um diese anzupassen.
Er war mit der Ausführungsfähigkeit des Modells zufrieden, fand es aber teuer: Die Erstellung dieser Wartungsseite hat 15,5 Yuan gekostet.
Das ist auch der Unterschied zwischen Agenten und normalen Chats: Der Nutzer gibt nur eine Aufgabe an, aber das Modell läuft möglicherweise viele Runden im Hintergrund: Zuerst liest es die Projektrichtlinien, dann durchsucht es Dateien und ändert den Code, nach Erhalt der Ergebnisse aus den Werkzeugen prüft es weiter. Jeder Aufruf kann neue Kosten für Eingaben und Ausgaben verursachen. Ein niedriger Stückpreis des Modells bedeutet nicht, dass die gesamte Arbeit zwangsläufig günstig ist.
Damit Agenten wirtschaftlich genutzt werden können, muss neben der Senkung des Modellstückpreises auch überprüft werden, ob diese Aufrufe notwendig sind. Einige Schritte erfordern eine Beurteilung durch das Modell, andere bestehen nur darin, Materialien nach festgelegten Regeln zu lesen, zu filtern und zu ordnen. Wenn auch diese Schritte schrittweise an das Modell zurückgegeben werden, erhöht dies die Anzahl der Aufrufe und die Wartezeit, und Zwischenergebnisse belegen ständig den Kontext.
Das quelloffene Harness von DeepSeek kann an der Organisation dieses Ausführungsablaufs beteiligt werden. Auf der offiziellen Website von DeepSeek wird die Beziehung mit „Agent = Modell + Harness“ erklärt: Das Modell ist für die Beurteilung zuständig, Harness stellt Werkzeuge zur Verfügung, verwaltet Sitzungen und Laufzeitumgebungen, sodass die Entscheidungen des Modells zu tatsächlichen Aktionen werden.
Der darin enthaltene PTC-Modus erlaubt es dem Modell, ein Programm auf einmal zu schreiben, um mehrere Schritte von Werkzeugoperationen miteinander zu verbinden. Wenn das Modell zum Beispiel Inhalte finden muss, die bestimmten Bedingungen aus einer Reihe von Dateien entsprechen, kann es das Programm die Dateien stapelweise lesen und filtern lassen, bevor es die relevanten Ergebnisse zurückgibt. Das Modell muss nicht nach dem Lesen jeder Datei neu entscheiden, was als Nächstes zu tun ist, und es muss auch nicht alle ursprünglichen Inhalte empfangen.
Auf diese Weise können wiederholte Aufrufe und unnötige Eingaben während der Aufgabenbearbeitung eingespart werden. In der offiziellen Dokumentation zum PTC-Design listet DeepSeek diese beiden Arten von Kosten ebenfalls als Probleme auf, die gelöst werden müssen. Für Entwickler kommt es am Ende darauf an, zu vergleichen, ob eine Aufgabe gut erledigt werden kann und wie hoch die Gesamtkosten nach Abschluss sind.
Auf diese Weise können Prozesse eingespart werden, bei denen das Modell nicht wiederholt eingreifen muss. Für eine Reihe von Materialien, deren Verarbeitung bereits bekannt ist, kann das Programm den vollständigen Ablauf ausführen, bevor das Modell nur die verbleibenden Informationen beurteilt.
Abbildung 4｜Mechanismus zur Beibehaltung der Schlussfolgerung bei Werkzeugaufrufen in V3.2: Kontinuierliche Werkzeuginteraktionen, die durch eine einzelne Nutzernachricht ausgelöst werden, behalten die bereits erstellten Schlussfolgerungen bei; bei Eintreffen einer neuen Nutzernachricht werden die vorherigen Schlussfolgerungen entfernt. Quelle: Abbildung im technischen Bericht zu V3.2
Die Behandlung von wiederholten Berechnungen durch DeepSeek kann noch weiter zurückverfolgt werden. Im V3.2-Bericht wurde darauf hingewiesen, dass das Verwerfen bereits erstellter Schlussfolgerungen während kontinuierlicher Werkzeuginteraktionen das Modell zwingt, das gesamte Problem neu zu analysieren. Daher hat das Team die Kontextverwaltung angepasst, sodass die vorherigen Schlussfolgerungen in diesem Prozess beibehalten werden.
Von der Art, wie das Modell denkt, bis zur Ausführung durch Werkzeuge – Effizienzverluste lassen sich nicht mehr nur in den Modellparametern suchen.
Harness zeichnet zudem Prompts, Werkzeugaufrufe und deren Ergebnisse auf, sodass Entwickler die Aufgaben nachvollziehen und überprüfen können, wo wiederholte Verarbeitungen oder Ausführungsfehler aufgetreten sind.
Eine offizielle Entwicklungsdokumentation vom 10. August zeigt, dass DeepSeek die Konfiguration von Werkzeugen und Prompts im Minimalmodus korrigiert hat, sodass es eine persistente Bash-Umgebung nutzt, die mit der Laufzeitumgebung für Verstärkungslernen übereinstimmt, um den Arbeitszustand bei fortlaufenden Operationen beizubehalten.
Diese Details erklären, warum Modellanbieter auch selbst Ausführungsframeworks entwickeln müssen. Wenn das Modell gelernt hat, Werkzeuge zu nutzen, braucht es bei der tatsächlichen Ausführung auch geeignete Werkzeuge und Umgebungen. DeepSeek hat eine dieser klar definierten Ausführungsmethoden offenlegt – Anwendungsentwickler erhalten damit eine Referenz, die sie direkt übernehmen, prüfen und anpassen können.
Diese Verbesserungen fließen nach und nach in dieselbe Aufgabe ein: Der Server beschleunigt die Generierung, das Modell reduziert wiederholte Schlussfolgerungen, das Ausführungsframework reduziert unnötige Aufrufe. Früher haben Nutzer dem KI beim Denken zugesehen – heute muss das KI kontinuierlich arbeiten, ohne dass Kosten und Wartezeit übermäßig ansteigen.