DeepSeek新模型全面超越，开发者为何不买账？

崔添翼9月9日在X发推称，V4.1 Flash在性能、费用、速度和总用时上全面超过V4 Pro，因此V4.1 Flash上线后、V4.1 Pro上线前，所有发往V4 Pro的请求将路由到V4.1 Flash，按Flash价格计费。DeepSeek当天在开放平台发布公告，部分客户收到邮件，但距切换仅一天左右，没有新旧模型并行迁移期。不少开发者是在刷到浏览量超70万的推文后，才意识到调用的V4 Pro即将被替换。

内部和外部测试显示，V4.1 Flash已全面超过V4 Pro，新模型采用新结构，原生支持多模态，能力更强、速度更快、成本更低。从DeepSeek角度看，维持V4 Pro不划算：占用更多算力、推理更慢、价格更高、效果可能还不如Flash。将Pro流量转到Flash可释放算力、降低成本，用户也能少花钱。但这笔账用户并不买账。

评论区最先反对的是已将V4 Pro接入业务的开发者。有人直接回复“请不要这样做”。用户可接受旧模型退役并愿意按计划迁移，但平台不能在几乎没有缓冲时间下替用户切换。有网友建议新旧模型使用不同model ID，旧模型停服前至少预留两周缓冲期，让下游完成Prompt、QC和参数适配后再迁移。不同模型表现习惯和参数设置差异大，直接替换容易让稳定任务出问题。生产环境中的Prompt经过反复调试，摸清了模型脾气，换成V4.1 Flash后可能改变指令理解、回答长度、输出结构、拒答范围或工具调用顺序，少一个字段、多一段解释都可能让程序报错。

科研团队也表示，正在使用DeepSeek-V4-Pro-0813开展研究，一些论文尚未完成。旧模型撤掉后，后续实验无法沿用原条件，已有结果也难以复现。他们希望至少保留独立端点一段时间。有海外开发者讽刺：“你们真的需要接受一些正规的软件工程培训。”模型进入Agent和生产流程后，版本变化会影响整条任务链，明确版本号、提前通知并保留回退能力是软件工程基本要求。

争论前两天，崔添翼还发布消息称DeepSeek开放约150个资深后端和服务端工程师岗位，几乎都不参与模型训练，方向包括操作系统、虚拟化、网络、存储、调度、容器、控制平面和Agent弹性计算。对于以小团队和高人才密度著称的DeepSeek，一次放出约150个工程岗位规模不小，重点不是新模型，而是模型下面的系统工程。

用人重点是DSec，即DeepSeek Elastic Compute，为后训练和评估阶段执行Agent任务搭建的沙箱基础设施，单集群已能并发运行数十万个Agent环境。DSec通过同一套Python SDK提供四种选择：简单函数调用进入预热容器，持久环境用兼容Docker的容器，高隔离要求用Firecracker微型虚拟机，需要完整操作系统则用QEMU虚拟机。为避免每台主机复制完整镜像，DSec接入分布式文件系统3FS，按需加载数据，减少存储、网络和启动开销，并优化页缓存、内存回收和容器运行时，让单主机承载更多沙箱。

DSec还要处理任务中断后的恢复。强化学习等后训练中大量Agent rollout同时运行，算力重新分配时部分任务可能中断。恢复不能简单重跑命令，因为有些命令已修改文件或环境。DSec使用全局有序轨迹日志，同时记录命令和执行结果，恢复后直接使用已保存结果，跳过完成步骤。随着数十万沙箱并发，调度、隔离和恢复都在给后台系统带来更大压力。

这些工程说明DeepSeek在基础设施层面有能力，也愿为规模化Agent负载投入资源。但工程能力被限定在“模型之下”，一旦涉及“模型之上”的用户契约，就退回研究团队思维：觉得新的更好就换。争议核心并非V4.1 Flash性能或价格，而是模型切换的决策权。开发者可接受退役和迁移，但难接受只提前一天通知、没有并行过渡、没有继续调用旧模型的入口。对To B业务而言，稳定性、可预期性和行为一致性往往比性能提升和价格下降更重要。

DeepSeek愿招150个后端工程师，说明清楚规模化Agent负载需要多少工程投入。同样值得投入的，是一套让用户安全迁移的工程流程：版本隔离、退役公告、过渡窗口、通知机制。这些不需要150个人，但需要同一种工程思维——把模型当成别人系统里的依赖项，而不是可随时替换的组件。若希望在模型迭代上保持激进节奏，DeepSeek至少需在沟通机制上补齐短板，否则每次仓促切换都会消耗用户信任，而信任流失远比一次模型下架更难挽回。