Inception 在 2026 年 10 月 19 日发布的 Mercury 3 给出一组漂亮数字：NVIDIA GPU 上 1068 tok/s、100 万 token 上下文、输入每百万 token 0.20 美元。最反直觉的是参数量比上一代涨了 40 倍以上，速度却几乎没掉。扩散语言模型的 scaling 一直被认为撑不住速度优势——模型越大，每个位置的精度门槛越高，去噪步数越多。Mercury 3 想证明这条曲线没有崩。但把三个数字拆开看，故事没有发布会讲得那么整齐。
机制先立住：每块一次前向，而非每词一次
自回归模型生成 500 个 token 就是 500 次串行前向，GPU 的宽向量算力大部分时间在等依赖链。掩码扩散反着来：先铺一整段全掩码画布，分 K 步并行去噪，每步同时确定一批位置，后面的步骤还能回头修改前面写下的内容。吞吐上限不由输出长度决定，而由块大小乘以去噪步数决定。
这条路线的历史包袱写在了文献里：早期扩散模型因为双向注意力无法有效使用 KV cache，推理延迟常常反超自回归，还普遍要求固定序列长度。Fast-dLLM v2 验证了解法——块扩散：块内双向并行去噪，块间保持因果、按块推进。块间因果意味着已解码块的 KV 可以复用，超长前缀只需 prefill 一次。Mercury 3 官方没公布架构细节，但"百万上下文还能高速出字"在结构上必须依赖这一层缓存复用，否则每个去噪步都要重算整个前缀。
真相一：同速叙事里有硬件换代的水分
Mercury 1 的 1109 tok/s 是 H100 上的第三方实测，Mercury 3 的 1068 tok/s 标注的是 Blackwell。参数涨 40 倍、吞吐持平，其中一部分账是制程和带宽还的，不全是算法红利。两次测量的基线不同，官方材料没有强调这一点。
真相二：默认档位被悄悄调低
Mercury 3 的 reasoning_effort 有四档，省略参数时默认 low；上一代默认是 medium。而官方那 12 项对比表是在 medium 档跑出来的。速度数字和质量数字不在同一档上——你直接调 API 测速，拿到的是 low 档结果，跟官方表格对不上。自查基准时这是最容易踩的坑。
真相三：1M 上下文和千级吞吐不同时兑现
1068 tok/s 是解码阶段的输出速率，不含 prefill；百万 token 的前缀要先完整前向一遍，这段时间与解码速度无关，且单次输出上限只有 131072 token。开发者反馈最集中的抱怨恰好是首字时间偏高，有用户实测 DeepSeek V4.1 Flash 经其他路由的延迟和智力双双占优。长上下文是容量，高吞吐是解码斜率，两者可以并存，但长提示下的端到端时间由 prefill 主导。
真相四：1068 是上限，不是容量规划依据
官方口径与实盘差距明显：OpenRouter 上发布次日的吞吐中位数在 160 到 254 tok/s 区间，一周均值约 203，差了四到六倍。合理解释包括长提示混入、冷缓存、首发负载，参照系也有——上一代产品发布后同样低于厂商口径。另外 batching 经济性还存在公开质疑：扩散不像自回归那样靠批处理摊薄带宽，规模化后单 token 成本可能更高，创始人的回应尚无第三方数据背书。
基准的强与弱
官方 12 项对比里拿下 8 项第一，强项集中在 Agent 工具调用与指令遵循（IFBench 76.84、SWE-Bench Atlas 51.08），对手是两家速度优化档模型。输的三处值得记住：长链路编码（DeepSWE 落后 Haiku 5.5 五个点）、长上下文精确召回（MRCR v2 也落后）——上下文窗口不等于上下文能力，这个卖点和它的弱项恰好撞在一起。所有成绩均出自厂商自测，第三方评测截至发布后一天仍未上线。
迁移与验证
接口是 OpenAI 兼容的，换 base_url 和模型名即可：
curl -H "Content-Type: application/json" \
-H "Authorization: Bearer $INCEPTION_API_KEY" \
-d '{"model":"mercury-3","messages":[{"role":"user","content":"把这段日志归纳成五条"}],"reasoning_effort":"medium"}'
实测吞吐时固定四件事，否则数据没法和别人对齐：显式传 reasoning_effort（别吃默认 low）、开流式并记首字时间、统计口径统一为 token 而不是字符（不同 tokenizer 折算差异能到两成）、标注提示长度。前端还要注意一点：块状输出可能成段跳变而不是平滑逐字出现，打字机动画要做适配。
选型建议可以压缩成一句创始人的原话式判断：日常水平对齐 Haiku/Luna 档，适合多步工具调用的 Agent、有人盯着等的实时场景、大批量低风险调用；需要精确长文召回、长链路硬编码、视觉输入或自托管审计的，现在还不是它的场。
评论0