DeepSeek V4 怀胎十月，马上要分娩了吗？
先说清楚：这是一篇基于灰测信号的分析，不是官方公告
在正文开始之前，需要说明信息来源的局限性。
目前网上流传的关于 DeepSeek V4 的信息，来源是二手截图和社交媒体传播，并非 DeepSeek 官方发布的 release note 或技术报告。这些信号的可信度介于「有人在瞎编」和「官方确认」之间——它们是 strong signal，但不是 final spec。
作为工程师和产品从业者，我们当然可以对这些信号做推演和分析；但我们也应该对自己的结论保持适当的谦逊：任何基于灰测截图的判断，都有被正式版本推翻的可能。
带着这个前提，我们来看这次灰测到底透露了什么。
灰测里出现的，不是你以为的那些东西
很多人的直觉预期是这样的：DeepSeek V4 = 更强的 Deep Think + 更快的 Deep Search + 某个新能力。
但灰测截图里出现的，是三个完全不同维度的 mode：
- Fast：支持 file upload，但仅做 text-only extraction；偏轻量、低延迟
- Expert：不支持 file upload；更强的 reasoning，更严格的 compute & cost control
- Vision：支持 multimodal input，即图文混合输入
这个分层结构，和很多人预期的「Deep Think / Deep Search」的功能迭代路径完全不同。
这不是一个功能列表的更新，这是一次产品架构的重新设计。
三个 Mode 的工程含义，逐一拆解
Fast：轻量不等于简陋
Fast mode 的关键词是「低延迟」和「file upload（text-only extraction）」。
文件上传支持 text-only extraction，说明 Fast 并没有做完整的多模态理解——它更像一个增强版的文档问答入口，适合处理「给我总结一下这份 PDF」「这个合同有没有问题」这类任务。
这背后的工程逻辑是：把文件内容降维成文本，送入一个轻量推理路径，换取更低的 latency 和更低的 cost。
对于大多数日常使用场景来说，这个 trade-off 是合理的。用户上传一份报告，要的是摘要和问答，不需要理解表格里的图表——那就没必要走 Vision 路径，浪费算力。
Expert：reasoning 的成本边界
Expert mode 不支持 file upload，这个设计初看有点反直觉——「更强」的模式，反而限制了功能？
但从 cost control 的角度来看，这完全说得通。
Expert 面向的是需要深度推理的任务：数学证明、代码调试、复杂逻辑推演。这类任务的 token consumption 本来就很高，如果再叠加文件解析，成本会进一步失控。不支持 file upload，是在用功能约束来划定 compute 边界。
这也说明 DeepSeek 在做一件很多大模型厂商没有认真对待的事：对用户的使用意图做主动路由，而不是让用户自己去猜该用哪个参数。
Expert 的「严格 compute & cost control」，在商业层面意味着什么？意味着这个 mode 可能对应更高的定价层级，或者更严格的 rate limit——但反过来，它也保证了高价值任务的推理质量不会因为资源争抢而降级。
Vision：multimodal 走向 end users
Vision 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 偏向深度 reasoning，o4-mini 偏向 cost efficiency，GPT-4o 是综合体。但 OpenAI 的分层更多是以独立模型的形式呈现，用户需要自己选择调用哪个。
Anthropic 的 Claude 3.5 / 3.7 系列，也有 Sonnet / Haiku / Opus 的层级，本质上也是 cost-capability 的分层。
Google 的 Gemini 系列（Ultra / Pro / Flash / Nano）是目前分层最细的，而且明确对应不同的 deployment target（cloud、on-device、API）。
DeepSeek 这次做的，如果属实，是把类似的分层逻辑做进了一个统一的产品入口——用户不需要切换模型，只需要选择 mode。这在 UX 层面的简洁度上，可能比「一堆不同名字的模型」更友好。
当然，这也对路由层的准确性提出了更高要求——如果 mode 的边界不清晰，用户会感到困惑，甚至选错 mode 导致结果质量下降。
还有一个值得注意的细节：Vision 没有 file upload
Fast 有 file upload（text-only），Expert 没有，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 官方立场。如有出入，以官方发布为准。
