DeepSeek 把三种模式合成一个，为什么速度反而更快了

DeepSeek 把三种模式合成一个，为什么速度反而更快了

摘要

我翻了下 DeepSeek 近几版的更新记录，这次 V4.1 把原本分开的模式收进了一个入口，Flash 被放在发布页最显眼的位置。圈内真正关心的不是命名，而是合并后首 token 延迟、长上下文吞吐这些指标到底动了多少——官方给的是区间值，第三方实测还得等几天。这篇不聊发布会话术，只看三种模式原先各自在算什么，合成一条推理路径后省掉的是哪部分开销，以及国产大模型这轮集体拼响应速度，成本压力最终会落到哪一环。

正文

同一个问题，走直答入口，首 token 常常一秒内就出来了；切到深度思考，得先看它吐几百字思维链，三到五秒才见到第一个正经字。这个落差靠用户自己点开关来填——简单问题点错，白等；难问题忘了开，答案又浅。那为什么 DeepSeek V4.1 要把三种模式合成一个，速度反而更快了？它到底省掉了哪部分开销？V4.1 这次把这道开关收了回去，让模型自己决定要不要想，这才是本次更新里最值得琢磨的动作，比命名和发布页排版重要得多。

先说清楚三种模式原先各自在算什么。直答模式是单次前向解码，输出 token 数基本等于答案长度，适合改写、抽取、格式转换这类没有中间步骤的活。深度思考模式在答案之前先产出一段思维链，长度经常是最终答案的三到十倍，而推理服务是按 token 计时的，思维链就是首 token 延迟的直接来源。联网与工具调用模式则是另一套账：瓶颈在检索、重排和上下文拼接，网络往返占大头，模型自身推理只占一小块。三者的优化目标根本不一致，一个拼吞吐，一个拼链路长度，一个拼外部依赖。

合并之后省掉的其实不是模型，是调度。用户侧少了一次判断，服务侧少维护几套并发配额和 KV cache 策略，中间还多了一道很轻的路由信号，由它决定要不要进思维链分支。这部分开销远小于把长上下文来回搬运。Flash 这个词大概率落在解码侧：投机解码提高接受率、KV cache 更激进的量化、prefill 与 decode 分离后按负载重新配比资源。这些细节不会写进发布页，但会体现在首 token 那条曲线上。

但这里需要泼一盆冷水：首 token 变快，不等于单位 token 变便宜。思维链该吐的 token 一个不少，账单照旧。真正压成本的是前缀缓存命中率——系统提示和长文档命中缓存时不必重算，以及量化精度和批大小这两项。所以官方给的区间值要拆开读，下限往往对应缓存命中的理想情况，上限是冷启动。我查到的资料有限，第三方在长上下文和高并发下的复测数字，这几天才会陆续出来，现在下结论偏早。

横向看，不给用户开关是共同方向。OpenAI 把推理强度做成档位，Gemini 给 thinking budget，Qwen 也在做思考与非思考的混合权重。我在几家厂商的文档里翻过它们的口径，措辞不同，实质一致：把选择权从用户手里拿回服务端。代价随之转移到路由准确率上——简单问题被误判进思维链，延迟反而比手动关掉更差；难题被误判成直答，答案质量下滑。这条路线能不能站住，取决于误判率，而不是峰值速度。国产大模型这轮集体拼响应速度，拼的也是同一件事：谁更少让用户为不需要的计算付费。

回到最实际的问题：这次更新该怎么用、怎么评。对普通用户，模式命名可以完全忽略，只看两点——复杂任务的答案有没有变浅，首 token 稳不稳定。对做接入的一方，建议按场景分层测：短问答盯 P95 首 token，长文档盯缓存命中后的单位成本，多轮对话盯上下文增长时的延迟斜率，别拿发布页上最好看的那个数字当结论。

标签

#DeepSeek V4.1 #DeepSeek Flash #DeepSeek 三种模式合一 #国产大模型 #DeepSeek 最新版本发布 #大模型推理速度 #AI 模型对比 #DeepSeek 使用体验