Mercury 2.5

1. 扩散式生成，速度拉得很高

Mercury 2.5 的核心是扩散式生成。自回归模型要等前一个 token 出来才能生成下一个，它可以同时修改输出中的多个位置，少了严格串行等待。Inception 公布 1107 token/秒，首 token 延迟低于 300 毫秒。

OpenCall 的案例更直观：接入后，P99 从数分钟降到约 1 秒，P50 从 0.4 秒降到 0.2 秒以内。一次请求只跑一轮，差别未必夸张；Agent 连续调用十几次、几十次，等待会一层层叠上去。

2. 工具调用和 JSON 输出

支持并行工具调用，也能按 schema 返回 JSON。做搜索 Agent 时，可以同时发起多个查询，再把结果按固定结构交给下一步程序。推理等级可调，简单任务用低档减少等待，复杂任务再提高档位。没有太多花活，都是开发者实际会用的接口能力。

3. 上下文翻倍

Mercury 2 的上下文窗口是 12.8 万 token，2.5 提到 26 万，最大输出 6.6 万 token。长文档、搜索结果集合、一部分规模不小的代码，基本放得下。摘要、资料整合够用。窗口大只解决容量，能不能一直抓住关键内容，还得看具体任务。

4. 和 Mercury 2 比，变化不只在速度

Mercury 2 在 2026 年 2 月发布，官方速度约 1009 token/秒。2.5 把速度提到 1107，上下文从 12.8 万扩大到 26 万，官方称智能水平提升约 40%，编码、指令遵循、数学推理有所增强。速度提升幅度不算大，上下文翻倍更明显。

编程要单独看。第三方测试跑了 40 次编程任务，28 次完全通过。另有 11 次任务实际失败，模型仍判断为完成。代码写错还能被测试拦住；任务状态判断错了，后面的自动化流程可能直接往下一步走。

Mercury 2.5 的快和便宜是实打实的，拿它跑搜索、语音、Agent 里的高频小任务很合适，调用次数越多越划算。但第三方测试里那 11 次“没做成却说做完了”说明它在复杂编程上还靠不住。想让它独立改完整个项目，我不会只看速度就放手。