V4.1 Flash全面超越，开发者为何还在喷 DeepSeek：缺的不是能力，是软件工程思维

崔添翼最近在 X 上刷屏有点多。9 月 9 日，这位今年 3 月加入 DeepSeek、负责 Agent 运行和评估基础设施的 Harness 团队成员发推称，V4.1 Flash 在性能、费用、速度和总用时等方面全面超过 V4 Pro，因此 V4.1 Flash 上线后、V4.1 Pro 上线前，所有发往 V4 Pro 的请求都会被路由到 V4.1 Flash，按 Flash 的价格计费。

DeepSeek 当天在开放平台发了公告，至少部分客户也收到了邮件，但距离切换只有一天左右，没有新旧模型并行的迁移期。从评论区看，不少开发者是在刷到这条浏览量超过 70 万的推文后，才意识到自己调用的 V4 Pro 马上要被换掉。

DeepSeek 可能觉得，这是一笔很容易算清楚的账。

1

 更强、更快、更便宜，用户为什么不买账？

经内部和外部测试，V4.1 Flash 在性能、费用、速度和总用时上已经全面超过 V4 Pro。内测通知还提到，新模型采用了新的模型结构，原生支持多模态，能力更强、速度更快、成本更低。

这意味着，Flash 已经不再只是一个牺牲部分能力、换取低延迟和低价格的版本。用户花更少的钱，可以获得更快的响应和更短的任务耗时，最终效果甚至更好。如果同时把 V4.1 Flash 和 V4 Pro 摆在开发者面前，很多人可能也会主动选择 Flash。

从 DeepSeek 的角度看，继续维持 V4 Pro 确实不太划算。它占用更多算力，推理速度更慢，用户支付的价格更高，效果还可能不如 V4.1 Flash。把 Pro 流量转到 Flash，可以释放算力、降低成本，用户也能少花钱。

这笔账看起来对双方都有利，可很多用户并不买账。

评论区里，最先站出来反对的是已经把 V4 Pro 接进业务的开发者。有人直接回复：“请不要这样做。”用户可以接受旧模型退役，也愿意根据计划迁移，但平台不能在几乎没有缓冲时间的情况下替用户完成切换。

有网友提出，更合适的做法是让新旧模型使用不同的 model ID。旧模型准备停服时，至少预留两周缓冲期，让下游开发者在新模型上完成 Prompt、QC 和参数适配，测试通过后再迁移。不同模型的表现习惯和参数设置往往都有差异，直接替换很容易让原本稳定的任务出问题。

这段缓冲时间很有必要。很多生产环境里的 Prompt 都经过反复调试，逐渐摸清了一个模型的具体脾气。哪种说法容易被模型忽略，怎样要求它固定输出格式，工具调用失败后怎么让它重试，哪些场景需要多加一层检查，这些细节都可能与 V4 Pro 的行为有关。

换成 V4.1 Flash 后，平均能力或许更强，但它可能换一种方式理解指令，也可能改变回答长度、输出结构、拒答范围或者工具调用顺序。对于聊天用户，这类变化可能只是风格不同；放进已经上线的系统里，少一个字段、多一段解释，都可能让后面的程序报错。

除企业用户之外，还有科研团队表示，他们正在使用 DeepSeek-V4-Pro-0813 开展研究，一些论文工作还没有完成。旧模型撤掉后，后续实验无法继续沿用原来的条件，以前得到的结果也可能很难复现。他们希望 DeepSeek 至少保留一个独立的 V4-Pro-0813 端点，哪怕只开放一段时间，也能让现有研究做完，或者给转接第三方服务留下缓冲。

有海外开发者因此讽刺：“你们真的需要接受一些正规的软件工程培训。”模型进入 Agent 和生产流程后，版本变化会影响整条任务链。明确版本号、提前通知并保留回退能力，本就是软件工程的基本要求。

2

DeepSeek 一口气招 150 名工程师，几乎都不碰模型

这场争论发生前两天，崔添翼刚刚在 X 上发布过另一条引人关注的消息：DeepSeek 开放约 150 个资深后端和服务端工程师岗位，“好多好多新方向、新系统、新需求需要搞”。

这批工程师几乎都不会参与模型训练。他们要做的是操作系统、虚拟化、网络、存储、调度、容器、控制平面和 Agent 弹性计算。崔添翼解释，DeepSeek 的数据量、机器数量、训练任务、活跃用户和请求都在增长，已有后台系统需要持续升级和维护，有些部分还要重写。

对于一向以小团队和高人才密度著称的 DeepSeek，一次放出约 150 个工程岗位，规模并不算小。更值得注意的是，DeepSeek 这次没有把招聘重点放在新模型上，而是开始集中补充模型下面的系统工程。

其中一个用人重点是 DSec，即 DeepSeek Elastic Compute。这是 DeepSeek 为后训练和评估阶段执行 Agent 任务搭建的沙箱基础设施，单个集群已经能够并发运行数十万个 Agent 环境。

Agent 除了调用模型，还要运行代码、使用工具和修改文件，因此每个 Agent 都需要独立环境。DSec 通过同一套 Python SDK 提供四种选择：简单函数调用进入预热容器，需要持久环境的任务使用兼容 Docker 的容器，对隔离要求更高时使用 Firecracker 微型虚拟机，需要完整操作系统时则使用 QEMU 虚拟机。

为了避免在每台主机上复制完整镜像，DSec 接入了 DeepSeek 的分布式文件系统 3FS，按需加载容器和虚拟机所需的数据，从而减少存储、网络和启动开销。团队还优化了页缓存、内存回收和容器运行时，让单台主机能够承载更多沙箱。

DSec 还要处理 Agent 任务中断后的恢复。在强化学习和其他后训练任务中，大量 Agent rollout 会同时运行，算力被重新分配时，部分任务可能中断。恢复任务也不能简单地重新执行此前的命令，因为有些命令已经修改了文件或运行环境，再执行一次可能得到不同结果。

为此，DSec 使用全局有序的轨迹日志，同时记录命令和执行结果。任务恢复后，系统可以直接使用已经保存的结果，跳过完成的步骤，避免重复执行。随着数十万个沙箱并发运行，任务如何调度、环境如何隔离以及中断后如何恢复，都在给 DeepSeek 的后台系统带来更大压力。

3

写在最后

这些都不是随随便便做出来的工程。3FS、DSec、写时复制层、全局有序轨迹日志，说明 DeepSeek 在基础设施层面是有工程能力的，也愿意为规模化的 agent 工作负载投入资源。问题在于，这种工程能力被限定在“模型之下”的系统里，一旦涉及到“模型之上”的用户契约，就退回到了研究团队的思维模式：我们觉得新的更好，那就换。

从技术社区的反应来看，这次争议的核心并非 V4.1 Flash 本身的性能或价格，而是模型切换的决策权。开发者可以接受模型退役，也可以接受迁移，但很难接受只提前一天得到通知，没有并行过渡，也没有继续调用旧模型的入口。对于 To B 业务而言，模型的稳定性、可预期性和行为一致性，往往比单纯的性能提升和价格下降更重要。

DeepSeek 愿意招 150 个后端工程师，说明它清楚规模化的 agent 工作负载需要多少工程投入。那么同样值得投入的，是一套让用户能够安全迁移的工程流程：版本隔离、退役公告、过渡窗口、通知机制。这些不需要 150 个人，但需要同一种工程思维——把模型当成别人系统里的一个依赖项，而不是一个可以随时替换的组件。

如果希望在模型迭代上保持激进节奏，DeepSeek 至少需要在沟通机制上补齐短板。否则，每一次仓促切换都会消耗一分用户信任，而信任的流失，远比一次模型下架更难挽回。

参考链接：

1. https://x.com/i/trending/2097239901284802933
2. https://x.com/tianyi/status/2097584362770530674
3. https://thenewstack.io/deepseek-dsec-agent-hiring/

文章来自于"InfoQ"，作者 " Tina"。