Mercury 3 的每秒 1068 个词元不能直接拿来比：同一把尺子下它和上一代一样快，更聪明还没人测过

扩散模型放大四十倍后真实速度与上一代持平，悬而未决的变成了它有多聪明。Inception 10 月 19 日发布扩散语言模型 Mercury 3，自称在英伟达 GPU 上每秒生成 1068 个词元；第二天，CTOL 的报道就拿 OpenRouter 上约 240 的实测值，说真实流量下它比宣称的慢得多。

先给结论：这两个数不是同一种测法，不能直接相减。用同一把尺子，也就是 OpenRouter 的真实流量中位数，Mercury 3 和上一代 Mercury 2.5 几乎一样快。Inception 说的「大了 40 多倍、速度不变」，目前的公开数据大体支持；它说的「比 GPT-6 Luna、Claude Haiku 5.5 更强」，还没有一个第三方读数。

发生了什么

据 Inception 的发布文章，Mercury 3 总参数是 Mercury 1 的 40 多倍，上下文从 Mercury 2.5 的 26 万词元扩到 100 万；标价每百万输入词元 0.20 美元、输出 0.70 美元，上线期间打五折，缓存命中的输入再便宜九成。速度写的是「在英伟达 GPU 上每秒 1068 个词元」，没有写批量、提示长度和输出长度。

扩散模型和常见的聊天模型写字方式不同：后者一个词元接一个词元往下写，扩散模型先起草一整段，再反复修改几轮，所以单次生成的吞吐可以很高。这是 Mercury 系列的全部卖点。

两个速度数字，测的不是一回事

我们在 10 月 20 日上午约 11 时 20 分（北京时间）打开 OpenRouter 的 Mercury 3 页面：只有 Inception 一家提供方，最近一周中位吞吐每秒 238 个词元，中位时延 0.94 秒，三天可用率 99.20%。CTOL 的报道稍早读到的是 243 和 1.40 秒，并据此写「不到宣称的四分之一」。这类页面是滚动统计，数字会随流量变化，两次读数接近，可以当作同一个量级。

关键在对照组。同一时间我们打开 OpenRouter 的 Mercury 2.5 页面：中位吞吐每秒 222 个词元，中位时延 1.18 秒。而 Artificial Analysis 的 Inception 页面在统一条件下测得 Mercury 2.5 每秒 706 个词元。也就是说，同一个 Mercury 2.5，在 Artificial Analysis 的固定测法里是 706，在 OpenRouter 的混合真实流量里是 222，差了三倍多。分析推断：这个落差主要来自测法，真实流量里有长提示、冷缓存和各种输出长度，统计也不分推理档位；依据是同一个模型在两处的读数相差三倍，所以它不是 Mercury 3 才有的问题。

分析推断：把 Mercury 3 的 238 放回 OpenRouter 这把尺子，它与 Mercury 2.5 的 222 基本持平，略快一点。模型大了 40 多倍、真实流量下速度没有变慢，这和 Inception「just as fast」的说法相符。1068 和 238 之间的差距，大部分应当算在「厂商最优条件」与「混合真实流量」的口径差上，而不是算成 Mercury 3 的缩水。依据是上面两组同平台、同口径的读数；前提是两个模型在 OpenRouter 上的流量构成相近，这一点我们无法核对。

真正缺证据的是另一半

速度这一半有了对照，「更聪明」这一半什么都没有。

据 Inception 发布文章，Mercury 3「在一系列基准上超过 GPT-6 Luna 和 Claude Haiku 5.5」，同一页的速览栏又写成「持平或更好」，两处措辞不一致；文字部分没有给出任何一项基准的分数和测试条件。文中最具体的一条结果来自合作方 TinyFish：在它自己的生产环境里跑 50 个实时 Mind2Web 网页导航任务，Mercury 3 完成一半，「明显多于 GPT-6.1-Sol」，但没有给出对手的数字。50 个任务、合作方自测、对照缺数，这只能按企业宣称读。

第三方这边，截至 10 月 20 日，Artificial Analysis 的 Inception 页面只列 Mercury 2.5 和 Mercury 2，还没有 Mercury 3 的数据。上一代 Mercury 2.5 在它的智能指数上是 12 分。Inception 说 Mercury 3 的基准智能是 Mercury 1（mini）的 3 倍，可这是厂商自己的口径，也没说用的哪组基准，不能换算成第三方分数。

所以对选型的人来说，现在能写进评估文件的只有三件事：价格、100 万上下文、OpenRouter 上和上一代持平的真实速度。至于它在你的任务上答得对不对，只能自己测。

最强反方

反方会说：拿 OpenRouter 的中位数替 Inception 解释，本身就偏袒厂商。客户买的就是真实流量下的速度，238 就是 238，厂商把 1068 放在标题里，读者自然会以为能拿到每秒一千个词元；再说，对实时语音这类场景，首字等待比吞吐更要紧，Mercury 3 在 OpenRouter 上近一秒的中位时延，未必比自回归的快模型占优。

这一条我们部分接受。1068 确实不能当作容量规划的依据，时延预算应按真实读数算，这一点和 CTOL 的结论一致。我们不同意的是把差距全部记成 Mercury 3 的问题：Mercury 2.5 在同一平台上也只有约 222，差距是这家厂商在这个平台上一直存在的口径差。至于和自回归快模型比时延，需要同一平台、同一时段、同类提示的对照，我们手上没有，因此不下结论。

我们不知道什么

• 1068 的测试条件：批量、提示长度、输出长度、推理档位都没写。
• OpenRouter 上两代模型的流量构成是否可比：Mercury 2.5 正打两折，用它的应用和请求长度可能与 Mercury 3 不同。
• Mercury 3 的推理档位分布：OpenRouter 的统计含各档位请求，档位越高，计入的等待可能越长。
• 任何一项基准的具体分数，以及 Artificial Analysis 何时上架、给出多少分。
• 上线五折何时结束；结束后单价回到每百万输出词元 0.70 美元，是 Mercury 2.5 目前折后价的四倍多。

接下来看什么

一是 Artificial Analysis 或其他第三方的智能指数与固定条件测速，那时 Mercury 3 才能和 Haiku 5.5、GPT-6 Luna 放在同一张表里。二是 OpenRouter 上的中位吞吐在流量放大后能否稳住在两百多的水平。三是 Inception 是否补出基准分数表和测试条件。在这三样出来之前，我们的看法是：Mercury 3 的速度承诺可以信一半，聪明程度还没有证据，如果第三方指数出来明显低于同价位快模型，我们会改口。