Mercury 3 发布：扩散语言模型的速度，能怎样改善实时 AI 应用？

2026 年 10 月 19 日，Inception 发布 Mercury 3。官方给出的主要指标是每秒 1,068 tokens、1M tokens 上下文，并称其在一组基准中接近或超过面向速度优化的前沿模型。这些是厂商公布的数据，尚不能直接回答产品团队更关心的问题：用户究竟能少等多久？官方发布说明

对实时应用而言，Mercury 3 的意义在于增加了一种可评估的技术路线。要让速度变成体验优势，需要把模型吞吐量放回完整业务链路。

扩散生成改变了哪段等待？

传统自回归语言模型逐个生成 token。Inception 描述的扩散路线通过迭代修正文段，在若干步骤中并行完善输出。这种方式有机会加快生成，但实际产品仍需等待输入处理、推理和可用文本出现。技术路线介绍

Mercury 的普通流式接口按已修订的文本块返回内容；额外的 diffusing 模式展示反复变化的中间文本。因此，最早看见字符、收到第一段可用答案、得到完整结果，是三个不同时间点。语音播报尤其需要稳定的内容，过早朗读仍在修订的文本，会增加回滚和打断成本。流式机制

用端到端模型判断收益

对一个串行执行的智能体任务，可以先做如下拆分：

总耗时 ≈ 网络与排队时间 + 各轮模型的输入处理、推理及生成时间之和 + 各轮工具等待时间之和 + 最终渲染时间。

各项应按实际链路计时，避免重复计算；若工具、生成或语音处理互相重叠，应看关键路径，不能直接相加。

举一个纯粹用于说明的假设：任务原来耗时 6 秒，其中模型占 2 秒，检索、工具和网络占 4 秒。即使模型部分缩短到四分之一，总时间仍为 4.5 秒，整体减少 25%。这个算例不是 Mercury 的测试结果。它说明：模型加速的价值，取决于模型原来占了多少等待。

反过来，多轮规划、逐步检查与反复生成都可能累积模型延迟。此时每轮节省一小段时间，最终收益会更明显。不过，若换模型后工具选错、重试增加，额外轮次又会吃掉节省。应同时记录成功率、调用次数和总耗时。Mercury 3 支持并行工具调用，互不依赖的查询可以并行处理；这部分收益也应与模型本身的速度分开计算。工具调用机制

三类应用值得怎样试？

文字客服可以先观察首段有效回答时间。简短回应若依旧要等待后端查单，单纯提高输出吞吐量的帮助有限；而解释复杂规则、汇总多条记录时，生成速度可能更重要。回复短、信息正确、用户能继续操作，通常比屏幕上瞬间出现大量文字更有价值。

语音助手要把终点检测、语音识别、语言模型、语音合成和音频播放一起测量。Mercury 3 在官方方案中承担 ASR → LLM → TTS 的语言处理环节，并非原生音频到音频模型。文档建议针对首段答案等待尝试 low 推理强度与 realtime 参数，实际是否改善交谈节奏，还取决于语音组件和网络。语音接入指南

搜索和长文助手可利用较大的上下文容纳更多材料，但输入容量不能保证关键信息都被正确使用。应该同时测长文定位、引用是否支持结论，以及上下文变长后首段响应是否恶化。对只需少量证据的问答，先检索、再压缩输入，仍是值得比较的方案。

速度之外，三个条件不能省

首先是推理配置。Mercury 3 支持 instant、low、medium、high，默认值为 low；此前 Mercury 2.5 的默认值为 medium。直接换模型名而不固定配置，可能把推理预算变化误读成模型进步。推理强度文档

其次是成功任务的成本。推理 tokens 计入输出费用，缓存命中按单独费率计费。一次请求更便宜，如果需要更多次重试，整项任务仍可能更贵。应统计包含失败和重试的总费用，再除以成功任务数。计费口径

第三是服务边界。模型表明确 Mercury 3 接受文本输入；不能把 Decide 的图片能力或 Voice 的产品命名扩展为 Mercury 3 的多模态承诺。生产链路还要处理限流、过载和工具故障。型号能力、错误码

一份可以执行的评估计划

以下是建议方案，尚未执行：

1. 从经过脱敏的业务材料中准备 90 项任务，短对话、结构化提取、工具调用各 30 项；覆盖中文、英文、短输入和长上下文。预先写明正确答案、必要证据及允许的工具行为。
2. 让 Mercury 3 与现有模型处理相同任务，固定工具、部署地区、输出要求和总调用预算。先分别调到可接受的质量，再比较速度；不要假定不同厂商同名的推理档位具有相同含义。
3. 每种配置重复三次，交错请求顺序，区分冷缓存与热缓存，在账户允许的配额内测试单请求和目标并发。保留失败、超时及重试记录，避免只统计成功样本。
4. 记录首段有效答案、完整任务耗时、P50/P95、任务成功率、格式合规率、工具误调用和每项成功任务成本。语音场景另外统计用户说完到听见首段回答的时间。
5. 在测试前约定采用门槛：关键任务正确率不能下降，高风险误操作不得增加，端到端 P95 和成本需达到业务目标。小样本只用于筛选，正式切换前还要扩大样本、低比例试运行，并保留回退方案。

Mercury 3 值得进入低延迟应用的候选名单。最有说服力的结果，应是相同质量要求下，真实用户的等待缩短、任务成功率保持稳定，同时团队能解释节省发生在哪一段。这样的证据，才足以支撑一次模型迁移。