先说结果：Mercury 3 的速度优势真实存在，但稳定性缺陷同样突出。本文不预设立场，仅整理第三方独立测试的原始数据。
Mercury 3 是什么？为何号称快 4 至 8 倍
10 月 19 日，Inception Labs 对外发布 Mercury 3，官方口径是基准成绩超过 OpenAI 的 GPT-6 Luna 与 Anthropic 的 Claude Haiku 5.5，生成速度达到后两者的 4 至 8 倍。该模型的技术路线与主流产品存在根本差异：常规自回归模型逐字输出，每次只产生一个 token；扩散式方案则先给出粗糙的文本块，再经过若干轮并行精炼，逐步处理多个 token，最终收敛成完整答案。
第三方实测：领先幅度有多大
10 月 23 日，hackerNoon 公布了独立测试报告。先看表现正面的数据：原始生成速率为每秒 850 至 900 个 token，约为 Google Gemini 3.5 Flash-Lite 的 2 倍、Claude Haiku 5.5 的 2.8 倍，相对 GPT-6 Luna 则达到 6 倍。在代码生成任务的低设置条件下，通过率录得 86.0%，平均响应耗时 0.83 秒，小幅领先 Haiku 5.5（准确度 86.1%、耗时 0.97 秒）和 GPT-6 Luna（83.2%、1.28 秒）。SQL 代理任务中位完成时间为 2.06 秒，同样处于靠前位置。
调高推论设置后暴露的四类问题
报告后半段才是关键。当推论设置切到中档或高档，情况明显变化：
其一，代码生成准确率不升反降。低档下 86.0% 的通过率，在高档反而更差，投入更多推理预算并未换来更好结果。
其二，约一成呼叫拿不到返回值。7.5% 至 8.6% 的请求因输出超出 32768 个 token 的上限而失败。在高档设置下，这类失控请求吞掉了代码测试全部输出 token 的 61%，最慢的 5% 响应被拖到 50 秒以上。
其三，严格 JSON 模式下格式失守。150 项任务中有 6 项不合规，模型会把内部工具调用标记的片段拼接在合法 JSON 之后。对于需要接入生产环境的团队而言，这一风险的优先级高于速度指标。
其四，它既非最快也非最便宜。报告提到，跑在 Cerebras 硬件上的自回归模型 gpt-oss-120b，原始速度达到每秒 2400 至 2500 个 token，代码任务平均响应只需 0.34 秒。架构选择与硬件优化是两个维度，「采用扩散式架构所以更快」的因果链并不成立。
厂商宣传与实测数据的差距
Inception Labs 将速度优势归因于扩散式架构这一单一因素，但 hackerNoon 10 月 23 日的测试报告并不支持该结论。报告披露的速度、通过率、响应时长与故障比例均为第三方实测，厂商「击败 GPT-6 Luna 与 Haiku 5.5、快 4 到 8 倍」的说法属于其自身宣传口径。需要说明的是，86.0% 这一代码通过率对应报告的低设置测试条件，不同任务与参数下数值会变化，不应作为通用排名解读。
接入生产前应关注哪三项指标
对实际使用者而言，评判标准可以归纳为三条：高档设置下准确率是否稳定、超长输出会不会丢失答案、JSON 格式是否可靠。这三点决定了模型能否进入真实业务流程。Mercury 3 给出的并非「新架构全面取代旧架构」的叙事，而是一道取舍题：追求速度，就要承担高档设置下的波动与格式风险；追求稳定，则需停留在低档配置，放弃其宣传中的那部分性能。
小结：Mercury 3 的扩散式路线在低设置下确有速度与响应优势，但高设置准确率回落、8.6% 呼叫超限、JSON 破格式等问题表明其距离生产可用仍有距离。选型时应以高档稳定性、长输出完整性与格式合规性为准，而非单纯比较每秒 token 数。