V4.1 Flash ist in jeder Hinsicht überlegen, warum kritisieren Entwickler DeepSeek nach wie vor: Es fehlt nicht an Fähigkeiten, sondern an softwareingenieurlichem Denken

Cui Tianyi war in letzter Zeit ziemlich häufig auf X zu sehen. Am 9. September veröffentlichte das Mitglied des Harness-Teams, das im März dieses Jahres zu DeepSeek kam und für die Infrastruktur für den Betrieb und die Bewertung von Agenten zuständig ist, einen Tweet, in dem es heißt, dass V4.1 Flash V4 Pro in allen Aspekten wie Leistung, Kosten, Geschwindigkeit und Gesamtzeit vollständig übertrifft. Daher werden nach der Veröffentlichung von V4.1 Flash und vor der Veröffentlichung von V4.1 Pro alle Anfragen, die an V4 Pro gesendet werden, zu V4.1 Flash weitergeleitet und nach dem Preis von Flash abgerechnet.

DeepSeek veröffentlichte am selben Tag eine Ankündigung auf seiner offenen Plattform, und zumindest einige Kunden erhielten auch E-Mails, aber es blieb nur etwa ein Tag bis zur Umstellung, es gab keine Übergangsphase, in der das alte und das neue Modell parallel betrieben wurden. Aus den Kommentaren geht hervor, dass viele Entwickler erst nachdem sie diesen Tweet mit mehr als 700.000 Aufrufen gesehen haben, realisierten, dass das von ihnen aufgerufene V4 Pro bald ersetzt wird.

DeepSeek ist möglicherweise der Meinung, dass dies eine sehr einfach zu berechnende Rechnung ist.

1  Leistungsstärker, schneller und günstiger – warum akzeptieren die Nutzer das nicht? 

Nach internen und externen Tests übertrifft V4.1 Flash V4 Pro in Bezug auf Leistung, Kosten, Geschwindigkeit und Gesamtzeit vollständig. In der Ankündigung für den internen Test wurde außerdem erwähnt, dass das neue Modell eine neue Modellstruktur verwendet, nativ Multimodalität unterstützt, leistungsfähiger, schneller und kostengünstiger ist.

Das bedeutet, dass Flash nicht mehr nur eine Version ist, die einen Teil der Fähigkeiten opfert, um niedrige Latenz und niedrige Preise zu erreichen. Die Nutzer zahlen weniger Geld, erhalten schnellere Antworten und kürzere Aufgabenzeiten, und das Endergebnis ist sogar besser. Wenn Entwicklern gleichzeitig V4.1 Flash und V4 Pro angeboten werden, würden viele wahrscheinlich freiwillig Flash wählen.

Aus der Sicht von DeepSeek ist es tatsächlich nicht sehr rentabel, V4 Pro weiter zu betreiben. Es verbraucht mehr Rechenleistung, die Inferenzgeschwindigkeit ist langsamer, der Preis, den die Nutzer zahlen, ist höher, und das Ergebnis ist möglicherweise nicht so gut wie bei V4.1 Flash. Wenn der gesamte Datenverkehr von Pro zu Flash umgeleitet wird, kann Rechenleistung freigesetzt und Kosten gesenkt werden, und die Nutzer können auch weniger Geld ausgeben.

Diese Rechnung scheint für beide Seiten vorteilhaft zu sein, aber viele Nutzer akzeptieren das nicht.

In den Kommentaren waren die ersten, die sich dagegen aussprachen, Entwickler, die V4 Pro bereits in ihre Geschäftsprozesse integriert haben. Jemand antwortete direkt: „Bitte tun Sie das nicht.“ Die Nutzer können die Stilllegung des alten Modells akzeptieren und sind bereit, nach Plan zu migrieren, aber die Plattform darf die Umstellung für die Nutzer ohne nahezu keine Pufferzeit durchführen.

Einige Nutzer schlugen vor, dass es angemessener wäre, wenn das alte und das neue Modell unterschiedliche Modell-IDs verwenden würden. Wenn das alte Modell stillgelegt werden soll, sollte mindestens eine zweiwöchige Pufferzeit vorgesehen werden, damit die nachgelagerten Entwickler die Anpassung von Prompt, QC und Parametern am neuen Modell abschließen und nach bestandenen Tests migrieren können. Die Leistungsgewohnheiten und Parametereinstellungen verschiedener Modelle unterscheiden sich oft, ein direkter Austausch kann leicht Probleme bei ursprünglich stabilen Aufgaben verursachen.

Diese Pufferzeit ist sehr notwendig. Viele Prompts in Produktionsumgebungen wurden wiederholt optimiert, und die spezifischen Eigenschaften eines Modells wurden allmählich verstanden. Welche Aussagen leicht vom Modell ignoriert werden, wie es angewiesen werden kann, ein festes Ausgabeformat zu verwenden, wie es nach einem fehlgeschlagenen Toolaufruf zu einem Wiederholungsversuch gebracht werden kann, welche Szenarien eine zusätzliche Prüfung erfordern – all diese Details hängen möglicherweise mit dem Verhalten von V4 Pro zusammen.

Nach dem Wechsel zu V4.1 Flash ist die durchschnittliche Fähigkeit möglicherweise stärker, aber es kann Anweisungen auf andere Weise verstehen, und es kann sich die Antwortlänge, die Ausgabestruktur, der Bereich der verweigerten Antworten oder die Reihenfolge der Toolaufrufe ändern. Für Chat-Nutzer sind solche Änderungen möglicherweise nur stilistische Unterschiede; in einem bereits eingeführten System kann das Fehlen eines Feldes oder das Hinzufügen einer Erklärung dazu führen, dass das nachfolgende Programm einen Fehler auslöst.

Neben Unternehmenskunden gaben auch Forschungsteams an, dass sie DeepSeek-V4-Pro-0813 für ihre Forschung verwenden und einige Arbeiten zu wissenschaftlichen Arbeiten noch nicht abgeschlossen sind. Nach der Stilllegung des alten Modells können nachfolgende Experimente nicht mehr unter den ursprünglichen Bedingungen fortgesetzt werden, und die zuvor erzielten Ergebnisse sind möglicherweise schwer zu reproduzieren. Sie hoffen, dass DeepSeek mindestens einen unabhängigen V4-Pro-0813-Endpunkt beibehält, auch wenn er nur für eine begrenzte Zeit verfügbar ist, damit die laufende Forschung abgeschlossen werden kann oder eine Pufferzeit für die Umstellung auf Dienste von Drittanbietern verbleibt.

Einige ausländische Entwickler spotteten deshalb: „Sie müssen wirklich eine reguläre Ausbildung in Software-Engineering absolvieren.“ Nachdem Modelle in Agenten und Produktionsprozesse integriert sind, wirken sich Versionsänderungen auf die gesamte Aufgabenkette aus. Die klare Angabe der Versionsnummer, die rechtzeitige Benachrichtigung im Voraus und die Beibehaltung der Rückgängigmachungsfunktion sind grundlegende Anforderungen des Software-Engineerings.

2  DeepSeek stellt auf einmal 150 Ingenieure ein, von denen fast keine an Modellen arbeiten 

Zwei Tage vor diesem Streit veröffentlichte Cui Tianyi gerade eine weitere aufmerksamkeitsstarke Nachricht auf X: DeepSeek schafft etwa 150 Stellen für erfahrene Backend- und Server-Ingenieure, „es gibt sehr viele neue Richtungen, neue Systeme und neue Anforderungen, die umgesetzt werden müssen“.

Diese Ingenieure werden fast nicht am Modelltraining beteiligt sein. Sie werden an Betriebssystemen, Virtualisierung, Netzwerken, Speicherung, Planung, Containern, Steuerungsebenen und elastischer Berechnung von Agenten arbeiten. Cui Tianyi erklärte, dass die Datenmenge, die Anzahl der Maschinen, die Trainingsaufgaben, die aktiven Nutzer und die Anfragen von DeepSeek alle wachsen, die vorhandenen Backend-Systeme ständig aktualisiert und gewartet werden müssen, und einige Teile müssen neu geschrieben werden.

Für DeepSeek, das für sein kleines Team und seine hohe Personalqualität bekannt ist, ist die gleichzeitige Veröffentlichung von etwa 150 Ingenieurstellen nicht klein. Noch bemerkenswerter ist, dass DeepSeek den Schwerpunkt der Einstellung diesmal nicht auf neue Modelle legt, sondern sich darauf konzentriert, die Systemtechnik unterhalb der Modelle zu ergänzen.

Einer der Schwerpunkte der Personaleinstellung ist DSec, also DeepSeek Elastic Compute. Dies ist eine Sandbox-Infrastruktur, die DeepSeek für die Ausführung von Agentenaufgaben in den Phasen des Nach-Trainings und der Bewertung aufgebaut hat, ein einzelner Cluster kann bereits Hunderttausende von Agentenumgebungen gleichzeitig ausführen.

Agenten müssen neben dem Aufruf von Modellen auch Code ausführen, Tools verwenden und Dateien ändern, daher benötigt jeder Agent eine unabhängige Umgebung. DSec bietet vier Optionen über dasselbe Python-SDK: Einfache Funktionsaufrufe greifen auf vorgewärmte Container zu, Aufgaben, die eine persistente Umgebung erfordern, verwenden Docker-kompatible Container, für Aufgaben mit höheren Isolationsanforderungen werden Firecracker-Mikro-VMs verwendet, und wenn ein vollständiges Betriebssystem benötigt wird, werden QEMU-VMs verwendet.

Um zu vermeiden, dass vollständige Images auf jedem Host dupliziert werden, verbindet sich DSec mit dem verteilten Dateisystem 3FS von DeepSeek, lädt die für Container und VMs benötigten Daten bei Bedarf und reduziert so den Speicher-, Netzwerk- und Startaufwand. Das Team hat auch den Seitencache, die Speicherbereinigung und die Container-Laufzeit optimiert, sodass ein einzelner Host mehr Sandboxes hosten kann.

DSec muss auch die Wiederherstellung von unterbrochenen Agentenaufgaben verarbeiten. Bei Aufgaben des verstärkenden Lernens und anderen Nach-Trainingsaufgaben laufen gleichzeitig eine große Anzahl von Agenten-Rollouts. Wenn die Rechenleistung neu zugewiesen wird, können einige Aufgaben unterbrochen werden. Die Wiederherstellung von Aufgaben kann nicht einfach durch erneutes Ausführen der vorherigen Befehle erfolgen, da einige Befehle bereits Dateien oder die Ausführungsumgebung geändert haben und eine erneute Ausführung zu unterschiedlichen Ergebnissen führen kann.

Dazu verwendet DSec global geordnete Ablaufprotokolle, die gleichzeitig Befehle und Ausführungsergebnisse aufzeichnen. Nach der Wiederherstellung der Aufgabe kann das System die bereits gespeicherten Ergebnisse direkt verwenden, die abgeschlossenen Schritte überspringen und eine erneute Ausführung vermeiden. Mit Hunderttausenden gleichzeitig laufender Sandboxes stellen die Planung von Aufgaben, die Isolierung von Umgebungen und die Wiederherstellung nach Unterbrechungen das Backend-System von DeepSeek vor größere Herausforderungen.

3 Schlussbemerkungen 

Diese Funktionen sind keine zufällig entwickelten Ingenieurarbeiten. 3FS, DSec, die Copy-on-Write-Schicht und die global geordneten Ablaufprotokolle zeigen, dass DeepSeek über technische Fähigkeiten auf Infrastrukturebene verfügt und bereit ist, Ressourcen für skalierbare Agenten-Workloads einzusetzen. Das Problem besteht darin, dass diese technischen Fähigkeiten auf Systeme „unterhalb der Modelle“ beschränkt sind. Wenn es um die Nutzervereinbarungen „oberhalb der Modelle“ geht, fällt es wieder in das Denkmuster eines Forschungsteams zurück: Wir finden, das Neue ist besser, also tauschen wir es aus.

Aus den Reaktionen der technischen Community geht hervor, dass der Kern dieses Streits nicht die Leistung oder der Preis von V4.1 Flash selbst ist, sondern die Entscheidungsbefugnis über die Modellumstellung. Entwickler können die Stilllegung von Modellen und die Migration akzeptieren, aber es ist schwer zu akzeptieren, dass sie nur einen Tag im Voraus benachrichtigt werden, es keine parallele Übergangsphase gibt und keinen Zugriff mehr auf das alte Modell haben. Für das To B-Geschäft sind die Stabilität, Vorhersehbarkeit und Verhaltenskonsistenz von Modellen oft wichtiger als reine Leistungssteigerungen und Preisnachlässe.

Dass DeepSeek bereit ist, 150 Backend-Ingenieure einzustellen, zeigt, dass es sich bewusst ist, wie viel technischer Aufwand für skalierbare Agenten-Workloads erforderlich ist. Ebenso lohnt es sich, in einen technischen Prozess zu investieren, der den Nutzern eine sichere Migration ermöglicht: Versionsisolation, Stilllegungsankündigungen, Übergangsfenster und Benachrichtigungsmechanismen. Dafür werden keine 150 Personen benötigt, aber es erfordert dieselbe Denkweise des Software-Engineerings – das Modell als eine Abhängigkeit im System anderer zu betrachten, nicht als eine Komponente, die jederzeit ausgetauscht werden kann.

Wenn DeepSeek bei der Iteration von Modellen