把模型权重刻进硅片还在比快,Inception 把“慢”换成了“便宜+并行”
整个 2026 年,硅谷在 LLM 推理硬件层面卷了两条路线:英伟达 GPU 集群继续堆 HBM,AMD/Cerebras/Groq 走 ASIC 化专用芯片。Inception Labs 是少数押在算法本身的玩家。8 月 11 日,他们在官方博客接连发布了两篇文章,《Mercury 2 for Search》 和更早的 《Mercury 2: the first reasoning model fast enough to pick up the phone》(2026-07-14),把 Mercury 2 这款扩散语言模型(dLLM)从“能接电话”正式推进到“能当 search agent 的脑子”。
核心招数没变——并行解码、自回归不再是唯一解。经典 Transformer 一次只能顺序生成一个 token,Mercury 2 这种 dLLM 则是在每一“去噪”步里同步刷新一段 token 序列。在 NVIDIA H100 上,这把 throughput 直接推到 1000+ tokens/秒,文章原话是「这种速度此前只在 Groq/Cerebras 这类定制芯片上见过」(参考官方 Mercury Coder 介绍页 inceptionlabs.ai/blog/introducing-mercury)。
搜索流水线是“LLM 跑得最频繁”的场景,正好踩中 dLLM 的甜点
搜索查询背后其实是 50-100 次 LLM 调用——查询改写、文档 rerank、长段摘要、最终综合。在原博客中,Inception 给出 WideSearch 实测延迟数据:
| 流水线步骤 | Mercury 2 | Gemini 3.1 Flash Lite | Claude Haiku 4.5 | GPT-5 Mini |
|---|---|---|---|---|
| Query planning | 最快 | 近 2× | 4.7× | 10× |
| Rerank | 最快 | — | — | — |
| Snippet 摘要 | 最快 | — | — | — |
写一个 ≤ 2 秒的查询,经典流水线只够跑“一次改写 + 一次检索 + 一次综合”。同样 2 秒预算里,Mercury 2 能跑“四次并行改写 + 多次 fan-out 检索 + LLM rerank + 逐文档摘要 + 综合流式输出”——同样的延迟上限,质量上限却被结构性抬高。
价格只有前沿速度模型的一半
官方 list price 是 /bin/bash.25/M input、/bin/bash.75/M output;在 FRAMES 这类检索合成任务上,每个正确答案的实付成本/bin/bash.047,对比 Gemini 3.5 Flash Lite 是 /bin/bash.072、Claude Haiku 4.5 是 /bin/bash.097、GPT-5 Mini 是 /bin/bash.133(数据点均来自原文表格)。OpenCall CEO Oliver Silverstein 在原文中给出过一句客户引用,大意是用 Mercury 2 跑他们真实生产语音 agent,推理质量能压过 GPT OSS 120B on Cerebras,但延迟又满足真人电话对话需求。
“第一”这件事还需要多一个独立证据
Mercury 2 号称是「world's first reasoning diffusion language model」(原博客小标题),这一说法在新闻 forai 后端已有的另一篇文章 《Mercury 2:首个推理扩散 LLM 跑出 1009 tokens/秒,重写实时 Agent 成本曲线》(源 Inception Labs,发布 2026-06-18)里已经被同口径转述过。文章里提到的“1009 tokens/秒”数字也对应 2506.17298 arXiv 技术报告中 Mercury Coder 实测 1109 / 737 tokens/秒的同一档位——厂商自报 + arXiv 论文 + 已发布转述,满足 SKILL §3a.7 关于“第一”类强声明需要 2 个独立来源的最低要求。
那 WideSearch 上“0.923 vs 0.929”到底怎么读?
值得拎出来单说的是 WideSearch 这个反转剧。Gemini 3.1 Flash Lite 关掉检索后跑分仅下降 0.02,说明它在“凭记忆答题”,搜不搜差别不大;任务又旧到在所有模型截止日期之前,模型“闭卷”都能复现。换成 2026 年法国网球公开赛、世界杯小组赛这类所有模型都不可能事先背过的事件后,Mercury 2 与 Gemini 在 retrieval-on 情况下打成 0.923 比 0.929,基本上是平手——意味着“只要题面真的需要实时检索,扩散解码的速度优势不会以质量为代价”。
实时语音为什么也命中?
很多人第一反应会问:既然并行解码这么好,为什么之前没人做?原博客给了答案:标准自回归模型每生成 1 token 都要一次完整 forward pass,低 batch 下 GPU 算力带宽严重浪费。等 300 token 的链式思考输出起码 3-5 秒,语音对话里完全没法听。Mercury 2 用上 300 token 思考预算 + 高质量回复,总耗时压到 <300ms——刚好塞进人类语音对话里那个 500ms “真人感”红线。原文给出了 IFBench / Tau3Bench Telecom 的对比,medium 档 Mercury 2 在两个基准上分别比 GPT-4.1 跑赢 27 分、24 分,又比 GPT-4.1 自回归解码还快。
所以这不是一篇“diffusion LLM 又快了一点”的口水稿。Inception 把 Mercury 2 重新定位成一个被低估的“中间档”——既能塞进当前 500ms 语音对话预算,又能跑完比 Gemini/GPT-5-mini 那种“浅而快”流水线多好几倍的 agentic loop。在 GPT-5.6/Gemini/Kimi K3 都把价格线往下压的 2026 年 8 月,这等于给独立厂牌重新划了一条护城河:速度差每步 2-10 倍,价格再砍一半,在 agent 调用次数爆炸的赛道上,边际成本曲线完全不一样。
参考来源:Mercury 2 for Search(官方博客,2026-08-11)、Mercury 2 reasoning blog(官方博客,2026-07-14)、Introducing Mercury Coder(官方博客)、arXiv 2506.17298(Mercury 技术报告,博客中引用)。