扩散模型能 scale 了：Inception Mercury 3 以 1068 tok/s 跑赢 GPT-6 Luna 和 Haiku 5.5

10 月 19 日，Inception Labs 通过 Business Wire 官宣 Mercury 3——"the most capable diffusion LLM ever released"（迄今最强的扩散大语言模型）。核心数字只有三个，但每一个都够分量：1068 tokens/秒的推理速度、100 万 tokens 上下文、基准质量追平甚至超过 GPT-6 Luna 和 Claude Haiku 5.5。

如果你没听过 Inception Labs，这家公司值得单独介绍：它由斯坦福教授 Stefano Ermon 联合创办，是"第一家把扩散大语言模型（dLLM）做成商业产品的公司"。背后的投资人名单豪华得离谱——Menlo Ventures、Mayfield、M12（微软风投）、Snowflake Ventures、Databricks Ventures，以及个人投资者 Andrew Ng、Andrej Karpathy、Eric Schmidt。当吴恩达和 Karpathy 同时下注一家公司做的事，你就知道这不是小打小闹。

而 Mercury 3 真正重要的，不是"又一个新模型"，而是它回答了 AI 社区争论了一年多的那个问题：扩散模型，到底能不能 scale？

扩散 vs 自回归：一场"并行"对"串行"的战争

先花 30 秒讲清技术背景。今天几乎所有大语言模型（GPT、Claude、Gemini、DeepSeek）都是 自回归（autoregressive）的：一次生成一个 token，像打字机一样从左往右敲。这种方式的优点是质量稳定，缺点是——再聪明的模型，打字速度也有上限。token 必须一个一个蹦出来，前一个没生成完，后一个就开不了工。

扩散模型（diffusion）走的是另一条路：从一张"噪声草稿"开始，并行地去噪、精炼，一次生成多个 token。Business Wire 通稿里的原话是："Unlike traditional autoregressive models, which generate text sequentially, one token at a time, diffusion models can generate multiple tokens in parallel, offering a fundamentally different path to faster inference."（与一次生成一个 token 的传统自回归模型不同，扩散模型可以并行生成多个 token，为更快推理提供了根本不同的路径。）

扩散做图像（Stable Diffusion、DALL-E）已经证明了自己，但做文本一直有个心结：学术界的扩散文本模型长期只能干"代码补全"这种简单活。2025 年 6 月 Inception 发布 Mercury 1，第一次证明扩散 LLM 可以商用；Mercury 2 给扩散模型加上了推理能力；Mercury 2.5 加了可调推理和 26 万上下文；Mercury 3 则是"扩散能不能 scale"的终极答辩——它比 Mercury 1 大了 40 多倍，速度却一点没掉，还是 1000+ tok/s。

Stefano Ermon 在官宣中的原话值得逐字读："Since we launched Mercury 1, the question we've heard most is whether diffusion can scale. Mercury 3 is over 40 times larger, significantly more capable, and still runs at over 1,000 tokens per second. We're showing that the limits to scaling diffusion models are compute and data, not fundamental algorithmic barriers."（自 Mercury 1 发布以来，我们被问得最多的问题就是扩散能不能 scale。Mercury 3 大了 40 多倍、强得多，依然跑在 1000 tok/s 以上。这说明扩散模型的 scaling 瓶颈是算力和数据，而不是根本性的算法障碍。）

注意最后一句的潜台词：自回归模型的 scaling law（越大越强），在扩散路线上同样成立。如果这是真的，意味着 AI 行业过去三年All-in 的"自回归 scaling"不是唯一的路——第二条路被实证打通了。

硬数据：1068 tok/s 是什么概念

1068 tokens/秒，什么概念？按官方口径，Mercury 3 比 GPT-6 Luna 和 Claude Haiku 5.5 快 4-8 倍，而基准质量"持平或更好"。定价：标准价 $0.20/1M 输入、$0.70/1M 输出，发布期半价（$0.10/$0.35），缓存 token 再打一折。上下文从 Mercury 2.5 的 26 万直接拉到 100 万。

但比数字更重要的是 Inception 对"速度"的论述。通稿里有一段是写给 agent 开发者的："In agentic systems, where a model makes repeated calls to finish one task, delays add up at every step."（在 agent 系统里，模型要反复调用才能完成一个任务，每一步的延迟都会累积。）这句话点破了 2026 年 agent 开发的一个隐性痛点：延迟是会复利的。一个 agent 任务调 30 次模型，每次慢 2 秒， total 就多出一分钟；用户能忍一次 2 秒，忍不了 30 次。而 Mercury 3 的 1000+ tok/s，就是冲着"把每一步都压到无感"去的。

早期客户已经在四个场景跑生产流量了：browser use agents（浏览器操作 agent）、interactive education（互动教育）、real-time search agents（实时搜索 agent）、customer support（客服）。RevisionDojo（General Learning）的联合创始人兼 CTO Michael Tong 给了一句很实在的评价："Mercury 3 allowed us to give every student instant feedback without giving up reasoning. Hints, marked answers and definitions now come back in about a second, with quality as good as or better than the models we ran before."（Mercury 3 让我们能给每个学生即时反馈而不牺牲推理质量。提示、批改和定义现在一秒左右就回来，质量不比以前的模型差。）"一秒左右"——这就是 1000+ tok/s 在产品里的体感。

对 vibe 开发者的意义：延迟、成本、架构的三重冲击

第一，实时 agent 的门槛被砸穿了。语音 agent、结对编程 agent、实时翻译——这些场景对延迟极度敏感，以前不得不在"用小模型（快但笨）"和"用大模型（聪明但慢）"之间二选一。Mercury 3 的官方定位就是"鱼和熊掌兼得"：旗舰级智能 + 小模型级速度。对独立开发者来说，这意味着以前"做不起"的实时交互产品，现在有了现成的底座。而且它是 OpenAI API 兼容的，已经上了 OpenRouter、Baseten、Vercel——"drop-in swap"（无痛替换），不用重写代码就能试。

第二，agent loop 的经济学变了。MiniMax M3.1 Flash（本轮 N1）是从"价格"端压低 agent 成本，Mercury 3 是从"速度"端。一个 agent 任务如果调 50 次模型，Mercury 3 的 4-8 倍速度优势直接转化为"同样时间能多试 4-8 种方案"。Inception 通稿里的原话："Agents finish sooner and have time to try more approaches before answering."（Agent 更快完成，并且有时间在回答前尝试更多方案。）——速度在这里转化成了"思考预算"：跑得快，agent 就敢多做几轮自我修正，成功率自然上去。这是对"慢工出细活"的颠覆：快，也是一种细活。

第三，扩散路线的"可编辑性"红利还没释放。这是我的一个判断：扩散模型"从噪声草稿并行精炼"的生成方式，天然适合"生成后编辑"——比如先出一版、再定向改某几段，而不需要从头重写。自回归模型改一个字，后面全得重算；扩散模型理论上可以只 refine 局部。这个特性在 Mercury 3 的通稿里没提，但它是扩散架构的内禀优势。如果未来 Inception（或跟进者）开放"局部重精炼"API，写作、代码重构这类"改比写多"的场景会被重塑。先埋个伏笔。

扩散简史：从学术玩具到 40 倍 scale 的三年

要理解 Mercury 3 的分量，得先知道扩散文本模型这条路走得有多难。2024 年之前，diffusion LM 基本是学术圈的"玩具"：在受控数据集上能跑，但一到开放域生成就崩——连贯性差、长文本失控。转折点是 2025 年 6 月的 Mercury 1：Inception 第一个把它做成"能卖钱"的产品，证明扩散 LLM 可以服务真实商业流量。那一刻，扩散从论文变成了产品。

Mercury 2 解决的是"笨"的问题：给扩散模型加上推理（reasoning）能力。此前扩散模型的短板是"快但浅"——适合代码补全这种短平快任务，搞不定需要多步思考的复杂任务。Mercury 2 证明扩散架构也能做 chain-of-thought 式的推理。Mercury 2.5 则加了可调推理（tunable reasoning）和 26 万上下文，把"快"和"深"的旋钮交到开发者手里。

Mercury 3 的答辩题是"大"：40 倍于 Mercury 1 的规模，速度不掉、质量反超。这在工程上为什么难？因为扩散模型的并行生成有个天然矛盾——并行度越高，单步计算量越大；模型越大，每步越慢。Inception 能做到"40 倍规模、1000+ tok/s"，说明它在"并行步数 vs 模型规模"的 trade-off 上找到了新的甜点。通稿没披露技术细节（这是商业机密），但 Ermon 的表态很明确：瓶颈是算力和数据，不是算法——意思是"给够卡、给够数据，扩散还能更大"。他还补了一句"已经在训练下一代"，野心不加掩饰。

这条路线的跟进者也在变多。学术界的 LLaDA、Dream 等扩散文本模型 2025-2026 年持续刷榜，证明"扩散做文本"不是 Inception 一家的独门秘籍。但 Inception 的领先在于"商业闭环"：Mercury 1 到 3，每一代都在真实生产流量里验证，每一代都解决一个具体的短板（商用→推理→可调→规模）。这种"一代一坎"的迭代节奏，是学术界给不了的。

质疑与冷水：先别急着把香槟打开

话说回来，Mercury 3 的通稿也有几处值得打问号的地方，负责任的报道得摆出来。

第一，benchmark 是"公司宣称"。"在多项标准基准上超过 GPT-6 Luna 和 Claude Haiku 5.5"——注意，是 Inception 自己测的、自己说的。历史上，厂商自测榜单"选择性披露"是常态：挑对自己有利的榜、不利的不提。Mercury 3 的真实水平，要等 Artificial Analysis、LMArena 这些第三方独立评测上线才知道。在那之前，"持平或更好"后面要加个星号。

第二，生态成熟度。自回归生态有三年的工具链积累：vLLM、llama.cpp、Ollama、各种量化方案，开箱即用。扩散模型的推理栈是另一套东西——并行去噪的调度、KV 缓存的复用逻辑都不同。虽然 Mercury 3 兼容 OpenAI API（调用端无痛），但想"自己部署"的团队会发现：扩散模型的本地推理生态还处在早期。Inception 目前主推的是自家 API + OpenRouter/Baseten/Vercel，私有化部署的选项不如自回归阵营丰富。

第三，1068 tok/s 的"体感"不等于"好用"。token 吐得快，不代表任务完成得快。agent 场景的端到端延迟 = 模型推理 + 工具调用 + 网络往返，模型推理只是其中一环。如果你的 agent 瓶颈在工具调用（比如调一个慢 API），Mercury 3 的速度优势会被稀释。选模型之前，先 profile 你的 agent loop，找到真正的瓶颈再下单——这是 2026 年 agent 开发的基本功。

顺带一提，Mercury 3 的发布时机也很讲究：选在 MiniMax M3.1 Flash 同一天。两家一个讲"成本"、一个讲"速度"，联手把 10 月 19 日变成了 agent 基础设施的"双十一"。这种"隔空呼应"与其说是巧合，不如说是行业共识的体现——2026 年下半场的模型竞争，胜负手不在"谁更聪明"，在"谁让 agent 跑得更顺"。但公允地说，这三盆冷水浇不灭 Mercury 3 的核心价值：它用产品证明了"第二条路"走得通。即使 benchmark 有水分、即使生态还早期，"40 倍规模、速度不掉"这个事实本身，就足以让所有自回归阵营的团队重新评估技术路线。历史上，每一次"范式被证伪"的时刻，都是创新的起点。

coding agent 的视角：并行生成意味着什么

对 VibeFix 的核心读者——用 AI 写代码的人——扩散模型还有一层特殊意义。想想你每天的真实工作流：让 agent 写一个函数，它从第一行敲到最后一行；你想改中间某段，它得把后面全重写一遍。这是自回归的"宿命"：严格的从左到右。

扩散模型的"并行精炼"在理论上打破了这个宿命：它可以只改局部。想象一下未来的 coding agent：生成初版后，你指着第 37 行说"这里逻辑反了"，模型只对第 30-45 行做去噪重精炼，其他部分原样保留——又快又准，不会引入新的 bug。这就是"可编辑性"红利。现在的 Mercury 3 还没开放这种 API（通稿里没提），但架构上它是顺手的。一旦开放，"重构"这个最高频的 coding 场景会被重塑：改代码不再是"推倒重来"，而是"精准手术"。

更进一步，扩散的并行性还可能改变"采样"逻辑。自回归模型想多试几种方案，得完整生成 N 遍；扩散模型可以在一次去噪过程里并行探索多个候选（类似 beam search 的天然形态）。Inception 通稿里那句"有时间在回答前尝试更多方案"（have time to try more approaches before answering），说的就是这个方向：速度换来的不是"更快地给出一个答案"，而是"在同样时间里比较更多答案"。对 coding 这种"试错密集型"工作，这比单纯的速度数字更有价值。

10 月 19 日：AI 的"速度与成本日"

把 Mercury 3 和同一天发布的 MiniMax M3.1 Flash 放在一起看，10 月 19 日成了 2026 年 AI 圈的"速度与成本日"：MiniMax 用 $0.15/$0.60 的定价和 200+ tok/s 重新定义 agent 任务成本，Inception 用 1068 tok/s 和半价发布重新定义推理速度上限。两家公司，一家中国、一家美国，同一天，同一个主题：让 agent 跑得更快、更便宜。

这不是巧合，而是 2026 年下半年模型竞争的主线转移：旗舰模型的"智能竞赛"进入平台期（大家都在 90 分上下卷），竞争重心下沉到"效率竞赛"——谁能让 agent 以更低的延迟、更低的成本跑起来，谁就拿走开发者的生产流量。Mercury 3 的"40 倍规模、速度不掉"，M3.1 Flash 的"成本砍 70%、速度翻 3 倍"，说的都是同一件事：效率正在成为新的智能。

对 vibe 开发者的实战建议：第一，去 OpenRouter 上亲手试 Mercury 3，重点测你的 agent loop 场景——同样的任务，数一下调用次数和总耗时，算一笔"速度账"；第二，对比 M3.1 Flash 算一笔"成本账"，看你的工作流是延迟敏感还是成本敏感；第三，关注扩散模型的生态跟进——如果 Qwen、DeepSeek 这些开放权重玩家也下场做扩散，本地部署的实时 agent 就指日可待了。

行业反响：HN 与投资人的双重投票

Mercury 3 发布当天，HN 讨论帖 4 小时冲到 200 points、78 条评论——在"模型发布疲劳"的 2026 年下半年，这个热度说明开发者是真的在乎"第二条路"。评论区的高赞观点很典型："自回归的优化已经到头了（speculative decoding、KV cache 各种压榨），扩散是为数不多还能带来'数量级'变化的架构。"也有人泼冷水："等独立评测出来再说，厂商的 benchmark 看看就好。"两种声音都对，这就是 2026 年开发者社区的成熟度：既为新架构兴奋，又坚持让子弹飞一会儿。

投资人则用另一种方式投票。Inception 的股东名单——Menlo、Mayfield、M12、Snowflake、Databricks——清一色是"基础设施派"VC，再加上 Andrew Ng、Karpathy、Eric Schmidt 三位"教父级"个人投资者。这个组合透露的信号是：资本市场赌的不是"某一个模型"，而是"扩散推理栈"本身。Snowflake 和 Databricks 的入场尤其意味深长——这两家是数据基础设施巨头，它们要的是"更快、更便宜的模型推理"来服务自己的数据云客户。Mercury 3 的 1068 tok/s，对它们来说是"降本增效"的直接工具。

接下来值得盯的几件事：第一，独立第三方评测（Artificial Analysis、LMArena）何时上线 Mercury 3，成绩能否复现官方口径；第二，自回归阵营的回应——OpenAI、Anthropic、Google 会不会也下场做扩散，或者用"混合架构"吸收扩散的优点；第三，Ermon 口中的"下一代"到底有多大，如果扩散的 scaling law 真的成立，下一代可能会直接冲击旗舰模型的"智能"定义本身；第四，开源/开放权重玩家的跟进——扩散模型一旦有了高质量开放权重，本地实时 agent 的时代就真的来了。

最后回到开头那个问题：扩散到底能不能 scale？Mercury 3 的回答是"能，至少到 40 倍"。这个答案的价值不在于 Mercury 3 本身有多强，而在于它把 AI 行业从"单行道"变成了"双车道"。单行道上，所有人只能比谁跑得快；双车道上，有人开始问"要不要换条道"。而历史反复证明：范式竞争的红利，永远比范式内卷的红利大得多。对 vibe 开发者来说，最好的策略不是"选边"，而是"两边都试"——你的 agent loop，应该同时跑得通自回归和扩散。

补一句实操建议：如果你现在就想试 Mercury 3，最省事的路径是 OpenRouter——它和 Baseten、Vercel 一起首发上线，API 兼容 OpenAI 格式，意味着你现有的 agent 代码改个 base_url 和 model 名就能跑。先拿一个"延迟敏感"的真实任务（比如实时客服、语音交互）做 A/B：同一任务分别跑 Mercury 3 和你现在的主力模型，对比端到端耗时、成功率和账单。数据比感觉诚实，跑完你就知道扩散路线值不值得押注。

透明度说明

本文核心事实（Mercury 3 发布、1068 tok/s、100 万上下文、40 倍于 Mercury 1、4-8 倍速度、$0.20/$0.70 标准定价及发布期半价、OpenAI API 兼容、OpenRouter/Baseten/Vercel 上线、早期客户四场景、投资人名单）全部引自 Inception 官方 Business Wire 新闻稿亲开全文（通稿编号 20261019090400；页内未见独立日期戳，日期 2026-10-19 取自通稿编号与 Unite.AI/RuntimeWire/DailyAIBrief 三方一致报道）。基准对比（超 GPT-6 Luna/Claude Haiku 5.5）为公司单方面宣称，未经独立验证。Stefano Ermon 与 Michael Tong 引语为通稿原文。"扩散模型局部重精炼 API"为笔者基于架构特性的推断，非官方口径，正文已标注。