文字不一定要从左往右写（Inception Mercury 3：扩散式大模型跑到每秒 1,068 个 token）
Inception 发布扩散式大模型 Mercury 3：官方称每秒 1,068 个 token、1M 上下文，不再一个字一个字往外吐。
大多数人默认，语言模型就该一个字一个字往外吐。
这个默认值，很少有人质疑。
因为我们自己就是这么说话的，这么打字的，这么读书的。
从左到右，一个接一个。
但这只是人类的习惯，不是文字本身的规律。
10 月 19 日，Inception 在官方博客发布了 Mercury 3。
这是一个扩散式大语言模型。
它不按顺序一个个吐 token，而是把一整段文字并行地“去噪”出来。
官方给出的速度是：在 NVIDIA GPU 上，每秒 1,068 个 token。
如果你只把它当成“又一个更快的模型”，你就错过了真正值得想清楚的东西。
默认路径的代价
先说清楚主流做法。
今天你用的大部分聊天模型，是自回归的。
意思是：先生成第一个 token，再根据它生成第二个，再根据前两个生成第三个。
每一步都要等上一步。
这条路走了很多年，也确实走得通。
问题在于，它把“慢”写进了结构里。
回答越长，你等得越久。
Agent 跑的步骤越多，等待就一层层叠上去。
大家的应对方式，通常是在这条路上继续优化：更好的硬件，更巧的推理技巧，更小的模型。
这些都有用。
但它们都没有动那个最底层的假设。
扩散换掉的是什么
扩散模型的思路，你可能在图像生成里见过。
先有一团噪声，然后一轮一轮把它修干净，直到图像浮现出来。
把这个思路搬到文字上，大意是这样：
不是一个字一个字往后接，而是先给出一段粗糙的草稿，再并行地把整段修正到位。
（这是对扩散 LLM 思路的通俗解释，Mercury 3 的具体实现细节以 Inception 官方说明为准。）
换句话说：
自回归是排队过闸机，一个人过完下一个人才能过。
扩散更像是一群人同时从几道门进场，然后各自找到座位。
这个比喻不精确，但它说明了一件事：
速度不是从“更用力地跑”里来的。
是从“换一种走法”里来的。
当你一直在优化一条路径，很容易忘了问，这条路是不是唯一的路。
为什么这次值得认真看
扩散 LLM 不是新概念。
过去它的问题很直接：快是快，但不够聪明。
快而笨的工具，没人真的愿意拿来干活。
Inception 这次给出的说法，正是在回应这一点。
以下全部是 Inception 官方自报，我没有看到第三方复现：
- 参数规模比 Mercury 1 大 40 倍以上
- 基准测试上的智力水平约为 Mercury 1 的 3 倍
- 上下文窗口 1M，而 Mercury 2.5 是 260K
- 在 IFBench、GPQA Diamond、SWE-Bench Atlas 上，优于 GPT-6 Luna 和 Claude Haiku 5.5
- 同时快 4–8 倍
如果这些数字站得住，那意味着扩散 LLM 第一次在能力上追到了主流快模型那一档。
注意那个“如果”。
厂商自己报的成绩，是起点，不是结论。
startupfortune 的报道标题用的也是“claims”，这个用词很准确。
速度到底改变了什么
很多人看到速度，第一反应是：省时间。
这没错，但太浅了。
速度真正改变的，是什么样的产品变得可以做。
Inception 自己列的场景是：语音和聊天客服、实时辅导、数据工程、浏览器 Agent。
你会发现，这几件事有一个共同点：
人在等。
或者，下一步在等。
1) 语音和实时对话
在语音场景里，延迟不是体验问题，是生死问题。
对方说完一句话，你停顿太久，对话就不像对话了。
所以对语音产品来说，模型快一点，不是锦上添花，而是能不能上线的分界线（这是我的判断，不是官方原话）。
2) 实时辅导
辅导的价值，在于即时反馈。
学生刚卡住，提示就该到了。
等太久，注意力就散了。
3) 数据工程
数据工程往往不是一次调用，而是一批又一批。
单次快一点，乘上批量，节省的就不是几秒钟。
4) 浏览器 Agent
浏览器 Agent 要看页面、做判断、点下一步、再看页面。
每一步都要调一次模型。
步骤越多，模型的延迟就越像是整个系统的天花板。
换句话说：
当生成足够快，你设计产品时就可以假设“模型几乎不用等”。
这个假设一旦成立，很多以前不划算的交互方式，就开始划算了。
价格和入口
速度之外，Inception 这次把门槛也放得很低。
据官方博客：
- 标价为每百万 token 输入 $0.20、输出 $0.70
- 首发期间五折，即 $0.10 / $0.35
- 缓存输入在此基础上再打一折
- 新 key 赠送 1 亿免费 token
入口也很多：Inception 自己的 API、OpenRouter、Baseten，以及 Vercel AI Gateway。
据 Vercel 的更新日志，在 AI Gateway 上的模型名是 inception/mercury-3。
接口兼容 OpenAI API。
这意味着，如果你的代码本来就在调 OpenAI 格式的接口，切过来试一试的成本很低。
还有一个容易被忽略的细节：
Mercury 2 和 Mercury 2.5 已经对新用户下架，老客户可以用到 11 月 15 日。
如果你的产品现在跑在旧版本上，这个日期值得写进日历。
快的陷阱
这里有一个容易踩的坑。
速度是最容易被感知的指标。
你一打开就能看到字刷地出来，那种爽感很直接。
但速度也是最容易让人放松警惕的指标。
一个快速给出错误答案的模型，只是让你更快地犯错。
所以，评估一个快模型，至少要分开看三件事：
- 它快不快：这个最容易测，也最不需要你操心
- 它对不对：在你自己的任务上，答案质量有没有掉
- 它稳不稳：同样的输入，结果会不会忽好忽坏
官方的说法覆盖了第一件，也用基准测试回应了第二件。
第三件，只有你自己跑了才知道。
换句话说：
别让速度替你做判断。
速度应该是你做完判断之后，才拿来享受的东西。
真正的问题
所以，你应该马上把所有调用都换成 Mercury 3 吗？
不。
那是另一种形式的默认路径：看到新东西就追。
更好的问题是：
你的产品里，哪些环节是因为“模型太慢”才被设计成现在这个样子的？
- 你是不是因为延迟，把一次对话拆成了好几个按钮？
- 你是不是因为等待，给 Agent 设了很少的步数？
- 你是不是因为慢，放弃了某个本来想做的实时功能？
如果答案是有，那就拿你自己的真实任务去测一遍。
不是测官方的基准，是测你的任务。
看它在你的场景里，快多少，错多少。
速度本身不是护城河。
能看清“速度改变了什么”，然后重新设计产品的人，才有护城河。
大多数人会继续沿着默认路径优化。
少数人会停下来问：这条路是不是唯一的路。
Mercury 3 能不能兑现它的承诺，现在还说不准。
但它至少提醒了一件事：
文字从来没有规定，必须从左往右写。
来源：Inception 官方博客（2026-10-19）；Vercel 更新日志；startupfortune。速度、参数规模、基准对比与价格均为 Inception 自报，未见第三方复现；首发折扣与 Mercury 2 / 2.5 下架时间以官方为准。