V4.1 Flash has outperformed across the board, so why are developers still bashing DeepSeek? What it lacks is not capability, but software engineering mindset.

Cui Tianyi has been popping up frequently on X recently. On September 9, this member of the Harness team, who joined DeepSeek in March this year and takes charge of the Agent operation and evaluation infrastructure, posted on X that V4.1 Flash has comprehensively outperformed V4 Pro in performance, cost, speed and total latency. Therefore, after V4.1 Flash is launched and before V4.1 Pro goes live, all requests sent to V4 Pro will be routed to V4.1 Flash and billed at the price of the Flash tier.

DeepSeek released an announcement on its open platform the same day, and at least part of its customers also received relevant emails. However, there was only about one day left before the switch, leaving no parallel migration period for the old and new models. Judging from the comment section, many developers did not realize that the V4 Pro they were calling would be replaced soon until they saw this tweet with over 700,000 views.

DeepSeek probably believes this is a very simple and clear deal.

1 Stronger, Faster, Cheaper — Why Don't Users Accept the Arrangement? 

According to internal and external tests, V4.1 Flash has fully surpassed V4 Pro in performance, cost, speed and total latency. The internal beta notice also mentioned that the new model adopts a new model architecture, natively supports multimodality, with stronger capabilities, faster speed and lower cost.

This means that Flash is no longer just a version that sacrifices partial capabilities in exchange for lower latency and lower prices. Users can get faster responses and shorter task completion time with less money, and the final effect is even better. If V4.1 Flash and V4 Pro are presented to developers at the same time, many of them may take the initiative to choose Flash.

From DeepSeek's perspective, continuing to maintain V4 Pro is indeed not cost-effective. It consumes more computing power, has slower inference speed, requires users to pay higher prices, and its performance may even be inferior to V4.1 Flash. Redirecting Pro traffic to Flash can release computing resources, reduce costs, and allow users to pay less.

This deal seems beneficial to both sides, but many users do not buy it.

In the comment section, the first group of people who stood up to oppose are developers who have already integrated V4 Pro into their business. Some users replied directly: "Please don't do this." Users can accept the retirement of old models and are willing to migrate according to the plan, but the platform cannot complete the switch for users with almost no buffer time.

Some netizens pointed out that a more appropriate approach is to let the old and new models use different model IDs. When the old model is about to be shut down, a buffer period of at least two weeks should be reserved to allow downstream developers to complete the adaptation of prompts, QC and parameters on the new model, and migrate after the test is passed. The performance habits and parameter settings of different models are often different, and direct replacement is very likely to cause problems for originally stable tasks.

This buffer period is very necessary. Many prompts in the production environment have been debugged repeatedly, and the specific characteristics of a certain model have been gradually figured out. Details including which expressions are easily ignored by the model, how to require it to fix the output format, how to make it retry after tool call failure, and which scenarios require an extra layer of check, are all related to the behavior of V4 Pro.

After switching to V4.1 Flash, the average capability may be stronger, but it may understand instructions in a different way, or change the answer length, output structure, refusal scope or tool call sequence. For chat users, such changes may only lead to different styles; but in the already launched system, missing a field or adding an extra paragraph of explanation may cause errors in the subsequent program.

In addition to enterprise users, some research teams also stated that they are currently using DeepSeek-V4-Pro-0813 to carry out research, and some paper-related work has not been completed. After the old model is removed, subsequent experiments cannot continue to use the original conditions, and the previously obtained results may also be difficult to reproduce. They hope that DeepSeek can at least retain an independent V4-Pro-0813 endpoint, even if it is only open for a period of time, it can allow the ongoing research to be completed, or leave a buffer period for switching to third-party services.

Some overseas developers satirized for this: "You guys really need to receive some formal software engineering training." After the model is integrated into Agent and production workflows, version changes will affect the entire task chain. Clarifying the version number, notifying in advance and retaining the rollback capability are the basic requirements of software engineering.

2 DeepSeek Recruits 150 Engineers at Once, Almost None of Them Work on Model Training 

Two days before this controversy broke out, Cui Tianyi just posted another eye-catching message on X: DeepSeek is opening about 150 senior backend and server engineer positions, as "there are so many new directions, new systems and new requirements to be developed".

Almost none of these engineers will participate in model training. Their work covers operating systems, virtualization, networks, storage, scheduling, containers, control planes and Agent elastic computing. Cui Tianyi explained that DeepSeek's data volume, number of machines, training tasks, active users and requests are all growing, and the existing backend systems need continuous upgrade and maintenance, with some parts even needing to be rewritten.

For DeepSeek, which has always been known for its small team and high talent density, releasing about 150 engineering positions at one time is a fairly large scale. It is more noteworthy that DeepSeek did not focus this recruitment on new model development, but began to supplement the system engineering work underlying the models.

One of the key recruitment directions is DSec, short for DeepSeek Elastic Compute. It is a sandbox infrastructure built by DeepSeek for executing Agent tasks in the post-training and evaluation stages, and a single cluster is already capable of running hundreds of thousands of Agent environments concurrently.

In addition to calling models, Agents also need to run code, use tools and modify files, so each Agent requires an independent environment. DSec provides four options through the same set of Python SDK: simple function calls are executed in pre-warmed containers, tasks requiring persistent environments use Docker-compatible containers, Firecracker micro virtual machines are used when higher isolation is required, and QEMU virtual machines are adopted when a complete operating system is needed.

To avoid copying the full image on each host, DSec is connected to DeepSeek's distributed file system 3FS, which loads the data required by containers and virtual machines on demand, thus reducing storage, network and startup overhead. The team also optimized page cache, memory reclamation and container runtime, so that a single host can carry more sandboxes.

DSec also needs to handle the recovery after Agent task interruption. In reinforcement learning and other post-training tasks, a large number of Agent rollouts run at the same time. When computing resources are reallocated, some tasks may be interrupted. Task recovery cannot simply re-execute the previous commands, because some commands have already modified files or the running environment, and re-execution may get different results.

To solve this problem, DSec uses globally ordered trace logs to record both commands and execution results. After the task is recovered, the system can directly use the saved results, skip the completed steps, and avoid repeated execution. With hundreds of thousands of sandboxes running concurrently, issues including task scheduling, environment isolation and recovery after interruption are all bringing greater pressure to DeepSeek's backend systems.

3 Final Notes 

None of these are casually built engineering systems. 3FS, DSec, copy-on-write layer, and globally ordered trace logs prove that DeepSeek has strong engineering capabilities at the infrastructure level, and is willing to invest resources for large-scale Agent workloads. The problem is that such engineering capabilities are limited to the systems "under the models". When it comes to the user contracts "on top of the models", DeepSeek falls back to the thinking pattern of a research team: we think the new version is better, so we just replace it.

Judging from the reaction of the technical community, the core of this controversy is not the performance or price of V4.1 Flash itself, but the decision-making right of model switching. Developers can accept model retirement and migration, but it is difficult for them to accept being notified only one day in advance, with no parallel transition period and no entry to continue calling the old model. For To B business, the stability, predictability and behavior consistency of the model are often more important than pure performance improvement and price reduction.

The fact that DeepSeek is willing to recruit 150 backend engineers shows that it clearly understands how much engineering investment is required for large-scale Agent workloads. Then a set of engineering processes that allow users to migrate safely is also worthy of investment: version isolation, retirement announcement, transition window, and notification mechanism. These do not require 150 people, but require the same kind of engineering thinking — treating the model as a dependency in other people's systems, rather than a component that can be replaced at any time.

If DeepSeek wants to maintain an aggressive pace in model iteration, it at least needs to make up for the shortcomings in the communication mechanism. Otherwise, every hasty switch will consume a little user trust, and the loss of trust is far more difficult to recover than a single model delisting.

Reference Links:

https://x.com/i/trending/2097239901284802933

https://x.com/tianyi/status/2097584362770530674

https://thenewstack.io/deepseek-dsec-agent-hiring/

This article is from the WeChat official account "InfoQ" (ID: infoqchina), written by Tina, and republished with authorization from 36Kr.