AIGC标识 Mercury 3 拆解：40 倍参数下，速度与 1M 上下文怎么兼得

三个数字里，最该看的是「40 倍」

Inception 在 2026 年 10 月 19 日发布 Mercury 3，官方口径给出三个数字：NVIDIA GPU 上 1,068 tok/s、100 万 token 上下文、每百万 token 输入 $0.20 / 输出 $0.70（发布期五折到 $0.10 / $0.35）。但真正反直觉的是第三个：总参数量是 2025 年 6 月 Mercury 1 的 40 倍以上，速度却基本没降。

原因是扩散 LLM（dLLM）的 scaling 一直有个悬而未决的问题：早期的并行生成优势，靠的是「大部分位置很容易填」，模型越大、每个位置的精度门槛越高、需要的去噪步数往往越多，速度优势正是最难保住的东西。Mercury 3 的主张就是：这条曲线没有崩，扩散的 scaling law 和自回归一样成立。Inception 没公布绝对参数量，创始人 Volodymyr Kuleshov 在 Hacker News 上明确说「目前不公开模型规模」，也没有权重可下载。

要判断它到底解决了什么，得把「1000 tok/s」「1M 上下文」和「40 倍参数」三件事拆开看，它们不是同一套机制在支撑。

原理：把「每个 token 一次前向」换成「每块一次前向」

自回归模型生成 500 个 token 就是 500 次串行前向，每次只产出 1 个 token，GPU 的宽向量算力大部分时间在等依赖链。掩码扩散（masked diffusion）反过来：先给出一整段全掩码的画布，然后分 K 步并行去噪，每一步同时确定一批位置，后面的步骤可以回头改前面写下的内容。

所以 dLLM 的吞吐上限不由输出长度决定，而由「块大小 × 去噪步数」决定。输出越长，自回归的线性劣势越明显——Kuleshov 在 HN 上的说法就是这个：推理模型想得越久，扩散相对同规模自回归的速度差越大。

这套机制的代价在研究文献里写得很清楚。Fast-dLLM v2 的论文在动机部分直接点名了早期 dLLM 的三个结构性缺陷：因为注意力是双向的，通常无法有效使用 KV cache；推理延迟经常反而超过自回归；很多实现要求固定序列长度、无法灵活控制生成长度。换句话说，纯全注意力扩散模型「快」是理论上的，工程上会被 KV 复用和变长生成拖回去。

那 1M 上下文和 1000 tok/s 是怎么并存的

Inception 没有公开 Mercury 3 的架构细节，也没发论文，所以下面四点里，前两点是公开文献能解释的机制，后两点是发布材料本身透露的账目，需要区分着看。

第一，块扩散 + 块级 KV 缓存。 目前唯一被验证能把「并行解码」和「KV 复用」装进同一个模型的路线是块扩散（block diffusion）：块内双向注意力并行去噪，块间保持因果、按块向后推进。块间因果意味着已解码块的 KV 可以直接复用，1M 的提示词只需 prefill 一次，后续每个块只做增量注意力；块内双向则保证了并行的收益。Fast-dLLM v2 在 7B 规模上验证了这条路（用约 1B token 微调把 Qwen2.5-Instruct 改造成块扩散解码器，端到端吞吐最高 2.5× 于自回归，质量无损）。Mercury 3 是不是这一族实现，官方没说；但「大上下文还能高速出字」在结构上必须依赖这一层缓存复用，否则 1M 前缀要在每个去噪步重算，速度不可能站在四位数。

第二，硬件换代被算进了同速叙事。 Mercury 1 论文里的 1,109 tok/s（Coder Mini）是 Artificial Analysis 在 H100 上测的第三方数字；Mercury 3 的 1,068 tok/s 标注的是 NVIDIA Blackwell。参数涨 40 倍、吞吐持平，其中一部分账是硬件制程和带宽还的，不全是算法红利。这一点官方材料没有强调，但两次测量的基线不同是事实。

第三，默认推理档被调低了。 Mercury 3 的 reasoning_effort 有四档（instant / low / medium / high），省略参数时默认 low；Mercury 2.5 和 Mercury 2 的默认是 medium。而厂商的 12 项对比表是在 medium 档跑的。同一份发布材料里，速度数字和质量数字不在同一档上，这是自查基准时最容易踩的坑：如果你直接调 API 测速，拿到的是 low 档的结果，跟官方表格没法对齐。

第四，「1M 上下文」和「1,000 tok/s」不是同一次请求里同时拿满的。 1,068 tok/s 是解码阶段的输出速率，不含 prefill。1M token 的前缀要先做一遍前向，这部分时间与输出速度无关；单次输出上限也只有 131,072 token。开发者反馈里最集中的抱怨恰好是首 token 时间（TTFT）：「在 OpenRouter 上，DeepSeek V4.1 Flash 经 together/baseten/fireworks 路由，延迟和智力都还压着 Mercury 3」「速度的问题在于 TTFT 还是偏高」。Simon Willison 用他惯常的 pelican 测试后也认为速度「有点令人失望」，直连 Inception API 也没变快。真正稳妥的说法是：长上下文是容量，高吞吐是解码斜率，两者可以同时存在，但长提示下的端到端时间由 prefill 主导，不是 1,068 这个数字能覆盖的。

基准：8/12 项第一，但全是一手自测

Inception 给了一张 12 项的对比表，全部在 medium 档，对手是 GPT-6 Luna 和 Claude Haiku 5.5（都是速度优化档，不是旗舰）：

基准 测什么 Mercury 3 GPT-6 Luna Haiku 5.5
τ³-bench Banking 客服型 agent 30.24 23.00 13.06
IFBench 指令遵循 76.84 61.82 54.65
GPQA Diamond 研究生级科学 89.23 86.36 84.51
SWE-Bench Atlas agentic 编码 51.08 33.33 32.26
DeepSWE v1 agentic 编码 46.31 37.76 51.62
MRCR v2 长上下文召回 75.50 62.72 78.40
AA-LCR v1.1 长上下文推理 77.67 78.30 74.70

Mercury 3 在 12 项里拿下 8 项第一，对每个对手都是 10:2。输的三处值得记住：DeepSWE（长链路编码，落后 Haiku 5.5 五个点）、MRCR v2（长上下文精确召回，也落后 Haiku）、AA-LCR 与 AA-Omniscience（落后 Luna）。也就是说，它的强项集中在 agent 工具调用与指令遵循，弱项恰好是「1M 上下文」这个卖点所对应的精确检索能力——上下文窗口不等于上下文能力。

三件事必须一起读：全部是 Inception 自己跑的；全部只有 medium 一档，没有 low→high 的曲线，看不出对手多思考几步能否追平；截至 10 月 20 日，Artificial Analysis 还没有 Mercury 3 的页面。Kuleshov 在 HN 上承认第三方评测「仍在进行中」。

唯一的 agent 级结果是官方自建 harness 上跑的 50 个真实 Mind2Web 导航任务，完成率 50%，「显著高于 GPT-6.1-Sol」，且 token 量和步数与前沿模型相同。50 个样本、自家 harness、对手只报名字不报分——这是信号，不是可写进采购文档的测量值。

速度的另一面：第三方与实盘数字

官方 1,068 tok/s；OpenRouter 单一供应商（就是 Inception 自己）的实盘中位数在发布次日被记录为 160–254 tok/s 区间，一周均值约 203，延迟中位数约 1 秒。差了四到六倍。

这个差距有正常解释：厂商数字通常是专用硬件、特定 prompt 长度、理想并发下的测量；路由层中位数混着长提示、冷缓存和首发日负载。历史折扣率也有参照——Mercury 2.5 在 Artificial Analysis 上约 706 tok/s、Mercury 2 约 680，都低于各自发布时的厂商口径。所以对 1,068 的合理处理是：当成上限，不是容量规划依据。

还有一个绕不开的经济学问题。HN 上有人回顾 Google 的 Gemini Diffusion demo，认为Google 放弃的原因之一是「扩散不像标准自回归那样能通过批处理摊薄显存带宽」，结果是「单用户/低并发延迟很好，但规模化后每 token 更贵」。Kuleshov 回应说 Mercury 在 batch 上扩展得不错，目前也没看到反驳数据；但在你按 1,068 tok/s 推导单位成本之前，这条质疑还没有被公开证据关掉。

与同类方案比，取舍在哪

对自回归快速档（Luna / Haiku 5.5）。 Mercury 3 赢在输出速度与 agent 类基准，输在生态成熟度：KV cache 策略、投机解码、各家推理框架的调度优化都是为自回归写的；扩散的解码 kernel 模式不同，工具链不成熟，失败模式也更陌生。另外流式体验不一样——输出可能以「块」为单位跳变，而不是平滑逐字出现，前端要做适配。

对开源扩散路线（DiffusionGemma）。 这是目前唯一能自己部署的扩散文本模型，但规模小；Mercury 3 闭源、不公布参数量、无权重，Kuleshov 表示暂无开源计划。要做架构研究，只能看 Fast-dLLM v2 这类论文与 NVlabs 的代码。

对「用更大模型 + 更多并行」的常规解法。 如果你的瓶颈是单次长回答，把每步 0.1 秒优化到 0.02 秒没有意义；瓶颈在多步串联时，速度才会复利。按官方默认参数（12 次调用 × 每次 600 输出 token）估算：1,068 tok/s 下生成总耗时约 6.7 秒；按 OpenRouter 中位数约 45 秒；同等任务 Luna 约 55 秒。也就是说实盘速度下仍然省时间，但省的是「几十秒」级别，不是「接近即时」。

适合谁用，以及迁移时该怎么验

适合：多步工具调用的 agent（浏览器导航、搜索、日志排查）、语音与实时辅导这类有人盯着等的场景、以及大批量低风险调用（分类、抽取、改写）。不适合：需要精确长文召回（MRCR 落后 Haiku）、长链路硬编码（DeepSWE 落后）、需要视觉输入（纯文本）、需要自托管或审计权重。

创始人自己的定位也很直接：日常使用是 Haiku/Luna 水平，「还不能替代 Opus 或 Fable 当 harness 的主控模型，但已经能用作 subagent」。这句话基本就是最靠谱的用法建议。

迁移成本很低，因为它就是 OpenAI 兼容接口，换 base_url 和 model id：

curl https://api.inceptionlabs.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $INCEPTION_API_KEY" \
  -d '{
    "model": "mercury-3",
    "messages": [{"role":"user","content":"把这段日志归纳成五条"}],
    "reasoning_effort": "medium",
    "max_completion_tokens": 2048
  }'

验证时至少固定这几件事（否则数据无法与别人对齐）：

import time, openai
c = openai.OpenAI(base_url="https://api.inceptionlabs.ai/v1", api_key=KEY)

t0 = time.time(); first = None; n = 0
s = c.chat.completions.create(
    model="mercury-3",
    messages=msgs,
    reasoning_effort="medium",   # 显式固定，别用默认 low
    stream=True, stream_options={"include_usage": True})
for ch in s:
    if ch.choices and ch.choices[0].delta.content:
        if first is None: first = time.time()
        n += len(ch.choices[0].delta.content)
ttft, total = first - t0, time.time() - t0
print(f"TTFT {ttft:.2f}s  端到端 {total:.2f}s  ≈{n/total:.0f} 字符/s")

评估清单：

  1. 从自己产品里抽 30–50 条真实 prompt，必须包含长上下文样本；分别对 Mercury 3、现用快速档、一个前沿模型各跑一遍。
  2. 四个指标分开记：TTFT、端到端耗时、任务通过率、单位任务成本。tok/s 单独看几乎没有决策价值。
  3. 上下文按 4K / 32K / 128K / 1M 分档画耗时曲线——标称吞吐和长上下文几乎肯定不能同时拿满。
  4. 强化它结构性占优的场景：改代码中间段、修坏掉的 JSON、写一半的文档重写。这些是并行细化天然擅长的，也是自回归要靠 fill-in-the-middle 补丁凑的。
  5. 结构化输出留 schema 校验：OpenRouter 上该模型的结构化输出错误率约 2.78%，首发周 3 天可用性 91.76%。
  6. 成本按 list price（$0.20 / $0.70）复算一遍，别按五折价做事后预算——官方没给折扣结束日期。
  7. 顺手算一段缓存账：缓存输入是输入价的 1 折（list $0.02/M）。一个 1M token 的固定前缀，list 价下每次调用 $0.20、命中缓存后 $0.02；按 eesel 整理的对手价目，Haiku 5.5 超过 100K 后输入单价 ×5，1M 前缀约 $0.50。长前缀场景里，缓存策略比 tok/s 更直接影响账单。

还有一件事值得单独留意：Ermon 对媒体说，他们用成群的 Mercury 3 agent 反过来改进模型本身，这部分「递归自我改进」带来约 16% 的速度提升。这属于厂商自述、细节未公开，但它暗示了一个方向——扩散模型的去噪步数、块大小这类解码超参，可能比自回归的解码参数更适合用搜索/agent 自动调。如果这个方法真的可复用，它对速度的意义可能比这次 40 倍参数更大。

参考资料

  1. Inception, Diffusion at Scale: Introducing Mercury 3 — https://www.inceptionlabs.ai/blog/introducing-mercury-3
  2. Khanna et al., Mercury: Ultra-Fast Language Models Based on Diffusion, arXiv:2506.17298 — https://arxiv.org/abs/2506.17298
  3. Wu et al., Fast-dLLM v2: Efficient Block-Diffusion LLM, arXiv:2509.26328 — https://arxiv.org/abs/2509.26328
  4. Hacker News, Mercury 3: Diffusion at scale（含创始人答疑） — https://news.ycombinator.com/item?id=50155245
  5. eesel, Inception Mercury 3 explained: speed, benchmarks, price, access（含 OpenRouter 实盘数据） — https://www.eesel.ai/blog/inception-mercury-3
  6. OrcaRouter, Mercury 3: 1,068 Tokens a Second, and No Benchmarks — https://www.orcarouter.ai/blog/inception-mercury-3
  7. Baseten, Mercury 3 model library — https://www.baseten.co/library/mercury-3/

创作说明：本文在资料整理与成文中使用了 AI 辅助（DeepSeek），经作者审阅后发布，作者对内容负责。

posted @ 2026-10-21 10:23  frankzch  阅读(24)  评论(0)    收藏  举报