DeepSeek V4 怀胎十月，马上要分娩了吗？

DeepSeek V4 怀胎十月马上要分娩了吗先说清楚这是一篇基于灰测信号的分析不是官方公告在正文开始之前需要说明信息来源的局限性。目前网上流传的关于 DeepSeek V4 的信息来源是二手截图和社交媒体传播并非 DeepSeek 官方发布的 release note 或技术报告。这些信号的可信度介于「有人在瞎编」和「官方确认」之间——它们是 strong signal但不是 final spec。作为工程师和产品从业者我们当然可以对这些信号做推演和分析但我们也应该对自己的结论保持适当的谦逊任何基于灰测截图的判断都有被正式版本推翻的可能。带着这个前提我们来看这次灰测到底透露了什么。灰测里出现的不是你以为的那些东西很多人的直觉预期是这样的DeepSeek V4 更强的 Deep Think 更快的 Deep Search 某个新能力。但灰测截图里出现的是三个完全不同维度的 modeFast支持 file upload但仅做 text-only extraction偏轻量、低延迟Expert不支持 file upload更强的 reasoning更严格的 compute cost controlVision支持 multimodal input即图文混合输入这个分层结构和很多人预期的「Deep Think / Deep Search」的功能迭代路径完全不同。这不是一个功能列表的更新这是一次产品架构的重新设计。三个 Mode 的工程含义逐一拆解Fast轻量不等于简陋Fast mode 的关键词是「低延迟」和「file uploadtext-only extraction」。文件上传支持 text-only extraction说明 Fast 并没有做完整的多模态理解——它更像一个增强版的文档问答入口适合处理「给我总结一下这份 PDF」「这个合同有没有问题」这类任务。这背后的工程逻辑是把文件内容降维成文本送入一个轻量推理路径换取更低的 latency 和更低的 cost。对于大多数日常使用场景来说这个 trade-off 是合理的。用户上传一份报告要的是摘要和问答不需要理解表格里的图表——那就没必要走 Vision 路径浪费算力。Expertreasoning 的成本边界Expert mode 不支持 file upload这个设计初看有点反直觉——「更强」的模式反而限制了功能但从 cost control 的角度来看这完全说得通。Expert 面向的是需要深度推理的任务数学证明、代码调试、复杂逻辑推演。这类任务的 token consumption 本来就很高如果再叠加文件解析成本会进一步失控。不支持 file upload是在用功能约束来划定 compute 边界。这也说明 DeepSeek 在做一件很多大模型厂商没有认真对待的事对用户的使用意图做主动路由而不是让用户自己去猜该用哪个参数。Expert 的「严格 compute cost control」在商业层面意味着什么意味着这个 mode 可能对应更高的定价层级或者更严格的 rate limit——但反过来它也保证了高价值任务的推理质量不会因为资源争抢而降级。Visionmultimodal 走向 end usersVision mode 的出现是这次灰测里最值得关注的信号之一。DeepSeek 此前已有多模态能力Janus 系列、VL 系列但那些大多是研究向产品或者 API 形态。把 Vision 作为一个独立的用户侧 mode 推出说明 DeepSeek 正在把 multimodal 能力推向普通终端用户而不只是留给调用 API 的开发者。这个方向和 OpenAI 的 GPT-4o、Google 的 Gemini 是对齐的——multimodal 不再是「高级功能」而是成为基础交互层的一部分。但 DeepSeek 的做法是把它单独列为一个 mode而不是融合进所有模式。这说明他们在有意识地控制 Vision 的使用场景和成本暴露而不是无差别地对所有用户开放全量多模态能力。核心判断这次不只是「更强的模型」到这里我想说一个可能让很多人失望的判断如果这次灰测的信息属实DeepSeek V4 的核心突破不太可能是「benchmark 上又领先了」而是在做一件更难、也更重要的事——能力分层产品化。让我解释这个区别。「更强的模型」是一个研究命题在标准测试集上得分更高在某些 capability 评测上超越竞争对手。这件事 DeepSeek 已经证明过自己能做到R1、V3 都是很好的例子。但「能力分层产品化」是一个工程和产品命题难度完全不同你需要理解用户的真实意图而不只是接受用户的显式请求你需要设计合理的路由逻辑把不同意图导向不同的计算路径你需要在 capability、cost、latency 三者之间做精确的 trade-off你需要把这套逻辑打包成用户可以理解的产品形态而不是暴露一堆技术参数Fast / Expert / Vision 这三个 mode本质上是 DeepSeek 在做用户意图分类 计算资源调度 产品包装的一体化设计。这比「在 MMLU 上再高两个点」要难得多也对商业化更重要。和竞争对手横向比较这条路有多少人在走OpenAI 的 GPT-4o / o3 / o4-mini也在做类似的能力分层。o3 偏向深度 reasoningo4-mini 偏向 cost efficiencyGPT-4o 是综合体。但 OpenAI 的分层更多是以独立模型的形式呈现用户需要自己选择调用哪个。Anthropic 的 Claude 3.5 / 3.7 系列也有 Sonnet / Haiku / Opus 的层级本质上也是 cost-capability 的分层。Google 的 Gemini 系列Ultra / Pro / Flash / Nano是目前分层最细的而且明确对应不同的 deployment targetcloud、on-device、API。DeepSeek 这次做的如果属实是把类似的分层逻辑做进了一个统一的产品入口——用户不需要切换模型只需要选择 mode。这在 UX 层面的简洁度上可能比「一堆不同名字的模型」更友好。当然这也对路由层的准确性提出了更高要求——如果 mode 的边界不清晰用户会感到困惑甚至选错 mode 导致结果质量下降。还有一个值得注意的细节Vision 没有 file uploadFast 有 file uploadtext-onlyExpert 没有Vision 也没有明确提及 file upload 支持。这个细节说明Vision 的 multimodal 入口可能是图片直接输入而不是文件系统上传的图片。这两者的区别在于直接输入图片粘贴、拖拽是更轻量的交互路径而 file upload 涉及服务端存储、文件解析、权限管理等更重的工程链路。把两者分开是一个合理的工程决策——先把 multimodal 交互跑通再考虑文件系统集成。我们还不知道什么基于灰测信号做分析有几个关键问题是无法回答的定价结构三个 mode 是否对应不同的 token 价格或订阅层级API 开放程度这套分层逻辑会不会暴露给 API 调用方还是只在产品层面存在路由逻辑用户手动选择 mode还是系统自动路由还是两者都有Expert mode 的 reasoning 质量相比 R1/V3具体有多大提升发布时间线灰测阶段到正式发布距离还有多远这些问题只有等官方公告才能回答。最后的判断回到标题的问题DeepSeek V4 马上要分娩了吗灰测出现了信号很强但「马上」这个词还是要打问号。从灰测到正式发布中间可能还有几轮内部测试、定价决策、技术文档准备。历史上不乏灰测出现后几个月才正式发布的案例。但更重要的判断是这个如果这次灰测的信号属实DeepSeek V4 的突破更可能在 productization而不只是 benchmark。Fast / Expert / Vision 这套分层不是在说「我们有更强的模型」而是在说「我们知道怎么把能力打包成产品知道怎么在 cost、latency、capability 之间做路由知道怎么让不同用户意图匹配不同的计算资源」。这是一个从「AI 研究院」走向「AI 产品公司」的信号。对于整个行业来说这可能比「benchmark 又刷新了」更值得关注。因为能在 benchmark 上领先的团队越来越多但能把能力分层做成流畅产品体验的依然是少数。本文基于社交媒体流传的灰测截图进行推演分析所有结论均属作者个人判断不代表 DeepSeek 官方立场。如有出入以官方发布为准。