Mercury 2.5 把推理做快了，Agent 能省下多少等待仍要算整条链
据 Inception 9 月 8 日公告，Mercury 2.5 已发布，新增版本提供可调推理、并行工具调用和符合 schema 的 JSON 输出。公司公布的生成速度为每秒 1,107 tokens，上下文窗口为 260K；这些是厂商披露的能力与测试口径，不是所有请求的服务保证。
作者：林岚｜OC 开发者生态编辑
据 Inception 9 月 8 日公告，Mercury 2.5 已发布，新增版本提供可调推理、并行工具调用和符合 schema 的 JSON 输出。公司公布的生成速度为每秒 1,107 tokens，上下文窗口为 260K；这些是厂商披露的能力与测试口径，不是所有请求的服务保证。
一句话结论：Mercury 2.5 的机会不只是便宜地回答问题，而是缩短 Agent 反复调用模型的等待；但模型吐字速度，不能直接换算成整个任务的完成速度。
此前 OC 在扩散语言模型报道中讨论过并行生成与重复计算的取舍。这次新增的是具体生产版本、价格和工具能力，可以开始把架构讨论落到请求预算上，而不是再讲一遍“文本也能扩散”。
真正值得替换的，可能是那些不起眼的小调用
一次代码任务里，最显眼的步骤是写补丁，旁边却有很多反复发生的小动作：压缩上下文、识别工具、整理搜索结果、判断下一步交给谁。它们未必需要最强模型，却都会占用时间。如果每个环节多等一点，串起来就变成用户看着进度条发呆。
因此，OC 更看重的是拆分工作负载的可能性。让强模型处理困难决策，把可验证、重复量大的辅助步骤交给低延迟模型，是一种值得测试的系统设计；它不是“用便宜模型替换所有东西”。上下文压缩若漏掉约束，后面的代码即使生成得再快，也可能把错误放大。
可以用一个假设算清边界。假如任务原本花 10 秒，其中只有 2 秒在模型生成上，其余时间等待数据库和外部工具，即便把生成部分完全消除，也只能降到 8 秒。反过来，如果十几次小调用都在关键路径上，缩短每次等待就会更明显。这是时间分解的结果，并非 Mercury 的实测收益。
1,107 tokens/s 之外，还有三块时间
第一块是首个有效输出之前的等待。用户问一句话时，感受到的是多久开始得到回应；一大段文本连续输出时，才更容易感知生成吞吐。长输出吞吐漂亮，不自动代表短请求反应快。
第二块是推理与工具执行。模型可以同时提出多个工具调用，但系统必须先判断它们是否独立。查询三个不同资料库可以并行；付款前的库存确认和金额批准，就不能因为模型支持并行而随意重排。更快的调用接口不会替业务做依赖分析。
第三块是失败后的返工。格式正确的 JSON 仍可能填错订单号，合法工具名仍可能配上不合适的参数。只比较成功请求的生成速度，会漏掉重试、人工修正和回滚成本。对于 Agent，更有意义的分母是“一个被验收的任务”，而不是“一个已经吐出的 token”。
发布价格和长期预算要分开
公告列出的常规定价是每百万输入 tokens 0.20 美元、输出 0.75 美元；上线优惠为其两折，即 0.04 和 0.15 美元。同期公布的 Mercury Voice、Mercury Router 则仍是预览产品，不能把它们的宣传指标直接当成本次模型的统一表现。来源：Inception
对一个小团队而言，优惠可以降低试验门槛，却不适合直接作为全年采购预算。评估至少应同时记录常规价格下的费用、并发时的等待分布，以及任务质量下降时的补救开销。尤其是长上下文场景，窗口能装下材料，不等于每次都值得把整个历史重新送进去。
比较方案时，也别只挑一个漂亮演示。可以拿同一组真实请求，固定工具返回内容，先比较模型本身；再放回完整系统，看慢请求和失败请求去了哪里。如果换模型后总体变快，却更经常漏掉引用或压缩掉用户要求，就需要把这笔损失记入结果。
关键事实
- 来源：Inception 官方版本公告，发布于 9 月 8 日。
- 核心变化：扩散模型新版本，面向工具调用和结构化输出等工作负载。
- 关键口径：260K 上下文；吞吐数字来自公司；上线折扣与常规价格分列。
- 产品边界：Voice、Router 为预览，不是所有接口已经共享的能力承诺。
OC 判断
推理市场不一定只由一个“最聪明模型”吃掉。只要 Agent 仍要在大量辅助步骤中消耗时间，速度、价格与可验证性之间就有独立市场。Mercury 2.5 值得关注，但采购理由应该是某一类步骤被可靠地做便宜了，而不是一张速度图看起来最靠前。
为什么重要
- 对开发者：可以重新拆分模型分工，但要保留相同输入下的质量回归测试。
- 对企业：把费用统计落实到验收任务和常规价格，避免被上线补贴掩盖长期成本。
- 对用户：真正的改进是更少等待和更少返工，而不是屏幕上的文字滚得更快。
评论
围绕这篇文章补充信息、提出问题或分享观察。