你让 AI 搜资料、打开网页、整理结果，它不会只回答一次。它要反复规划、调用工具、读取结果，再决定下一步。每一轮哪怕只慢一点，最后也会积成明显的等待。Inception 推出的 Mercury 3，瞄准的正是这笔不断累加的“时间账”：它试图改变语言模型逐个片段生成文字的方式，让多个文本片段同时成形。
不过，目前公开材料只有 OpenRouter 的模型页面，介绍文字署名 Inception。下文的定位、规模和性能数字均来自这一单一页面，尚缺公开基准与第三方复现。
不再像打字机，而更像编辑
主流的自回归语言模型，会根据已经写出的内容，一次预测下一个 token。Token 是模型处理文字的基本片段，可能是一个字、半个词或一个标点。这个过程像打字机：前一个片段没有生成，后一个就无法开始，天然需要串行等待。
Mercury 3 采用扩散语言模型（diffusion-based language model）路线。它从一份不完整或带噪的文本表示出发，同时生成并反复修正多个 token。直观地说，它不是从左到右一字不改地往下写，而是先铺开一片候选内容，再像编辑一样多轮润色。
据 Inception 的介绍，Mercury 3 是该实验室迄今能力最强的模型，规模比第一代 Mercury 大 40 倍以上，却保持相同吞吐量。这里的吞吐量，指单位时间能生成多少 token。但页面没有解释“规模”究竟是参数量、计算量还是其他指标，也没有给出硬件、上下文长度、输出长度和批量设置，因此不能把这句话直接理解为所有场景下都能实现同样速度。
为什么 Agent 特别在意这点？
Agent 工作流，是让模型反复思考、使用工具并根据结果继续行动。搜索 Agent 可能先拆问题，再发起多次检索；语音流水线需要尽快接上用户的话；编码子 Agent 则要读代码、修改、运行并继续排错。这些任务都不是“一问一答”，单次延迟会被循环次数放大。
OpenRouter 页面把 Mercury 3 定位于这类实时应用，并显示其 P50 首响应延迟为 0.61 秒、生成速度为每秒 180 tokens。P50 可以理解为观测结果的中位数：一半请求快于它，一半慢于它。页面同时注明，这些数字取各提供商中的最佳值。因此，它们更像平台当前展示的理想观测，而不是官方实验结论，也不代表每种部署条件都能稳定达到。
这条路线并非临时追逐 Agent 热点。据 Inception 与 Mayfield 的材料，三位联合创始人 Stefano Ermon、Aditya Grover 和 Volodymyr Kuleshov 在创业前已共同研究生成式 AI 十余年。2025 年 2 月，首代 Mercury Coder 以商用扩散语言模型亮相。如今把搜索、语音和编码 Agent 放到中央，更像是在为这条“先铺开、再修正”的路线寻找最需要低延迟的应用场景。
真正的问题不是快，而是快得是否划算
Mercury 3 值得关注，因为它挑战的不是某个排行榜名次，而是语言模型长期沿用的逐 token 生成范式。如果并行修正确实能在更大模型上维持高吞吐量，那么多轮 Agent 的累计等待可能明显下降。它也提醒行业：Agent 体验不只取决于模型能否完成任务，还取决于每一步是否足够及时。
但这仍是一项需要证据补齐的主张。速度只是 Agent 系统的一部分；现有材料没有提供任务质量、复杂工具调用成功率，或与同级自回归模型的直接对照。Mercury 3 是否真正改写生成范式，最终要看它能否在“更快”的同时，稳定完成那些需要多轮判断和修正的工作。
局限与未知
- “大 40 倍以上”没有说明规模口径，相同吞吐量也缺少测试条件。
- 0.61 秒和 180 tokens/s 是 OpenRouter 标注的 P50 与各提供商最佳值，尚无第三方复现。
- Mercury 3 当前不支持 OpenRouter 的欧盟区内路由；材料也未披露公开基准、质量对照和稳定性数据。