Mercury 3 上线 AI Gateway：扩散模型文本生成速度破千 token/s

当文本生成不再逐字进行：Mercury 3 的扩散路线

Inception 的 Mercury 3 模型现已登陆 Vercel AI Gateway，并附带 50% 的发布期折扣。这款模型最引人注目的地方，不在于参数规模，而在于它生成文本的方式——用扩散（diffusion）做并行精炼，而不是传统大模型逐 token 自回归输出。

据 Inception 公布的数据，Mercury 3 在多个基准测试上表现强劲，生成速度超过每秒 1000 个 token。对于需要低延迟的应用场景，这个数字意味着交互体验的量级变化。

速度从何而来：并行精炼的工程意义

自回归模型每次只预测一个 token，速度受限于串行解码的固有瓶颈。Mercury 3 换了一条路径：通过扩散过程对整段文本进行多轮并行精炼，理论上可以更充分地利用并行算力。

这种架构对延迟敏感型负载特别友好。官方点名的场景包括浏览器智能体、实时搜索、互动教育和客户支持——这些任务共同的特征是：用户等不起。以浏览器智能体为例，它需要在页面操作与决策之间快速往返，每次生成的延迟都会累积成肉眼可见的卡顿。

有意思的是，扩散文本生成并非没有代价，精炼轮数与输出质量之间的平衡需要工程调优。Inception 声称在基准测试中取得了"强劲结果"，但原文未披露具体的对比模型和分数细节，实际表现仍需独立评测验证。

自回归生成与扩散生成的核心差异在于解码的依赖结构。自回归模型按从左到右的顺序逐 token 生成，第 n 个 token 的分布依赖于前 n-1 个 token，因此天然是串行的：即便 GPU 有大量空闲算力，也无法同时计算多个位置。扩散模型则从一段带噪的初始序列出发，在多个去噪步骤中同时更新所有位置，每一步都利用整段上下文做并行预测，从而把"深度"（token 数）上的串行依赖转化为"轮数"（精炼步数）上的迭代。文本扩散的难点在于离散 token 空间没有连续高斯噪声，需要设计特定的加噪/去噪机制（如掩码、吸收态或嵌入空间扰动），且精炼轮数过少会导致质量不足、过多则抵消并行收益，这正是文中提到的工程调优所在。

百万 token 上下文：为长会话和长文档留出空间

Mercury 3 提供 100 万 token 的上下文窗口。对于实时搜索和多轮客户支持这类应用，长上下文不只是"能塞更多内容"，而是让系统在扩展对话历史中保持连贯性，或在长文档问答中减少信息截断。

结合超过 1000 token/s 的生成速度，这个组合指向的是一类此前受限于延迟而难以落地的应用：需要同时处理大量上下文、又要快速响应的智能体工作流。

百万 token 上下文并不等于百万 token 的有效利用。长上下文模型通常面临"中间遗忘"（lost in the middle）问题：位于上下文中间位置的信息检索准确率低于开头和结尾。此外，注意力计算的成本随序列长度增长，虽然推理框架普遍采用分块预填充、KV 缓存复用等优化，但在百万级长度下显存占用和首 token 延迟仍会显著上升。对智能体工作流而言，长上下文的价值还取决于模型能否在多次工具调用之间稳定保持状态、正确引用早期轮次的信息，这一点往往比单纯的窗口大小更能决定实际可用性。

接入方式：一行模型名，或者一条 CLI 命令

在 AI Gateway 上调用 Mercury 3 的门槛很低。设置环境变量 AI_GATEWAY_API_KEY 后，将模型名指定为 inception/mercury-3 即可。以下是最小可用的 AI SDK 示例：

import { streamText } from 'ai';

const result = streamText({
  model: 'inception/mercury-3',
  prompt: 'Write a brief, friendly reply to a customer whose delivery is late.',
});

for await (const text of result.textStream) {
  process.stdout.write(text);
}

如果想在 Claude Code、Codex、Cursor 等编码智能体中使用，安装最新版 Vercel CLI 并运行 npx vercel ai-gateway setup，随后在智能体中选择 inception/mercury-3 即可。也可以在 model playground 中直接试用。

AI Gateway 的价值：统一 API 与零加价

AI Gateway 的定位是统一模型调用入口，同时提供用量与成本追踪、重试与故障转移配置，以提升高于单一供应商的可用性。它还内置自定义报表、零数据保留（Zero Data Retention）支持、API key 预算和路由规则。

在定价上，AI Gateway 按供应商价格原样反映，不加价，也不对推理收取平台费——包括 BYOK（自带密钥）请求。对于需要多模型切换的团队，这降低了试错成本；对于 Mercury 3 这样的新模型，50% 的发布折扣则进一步压低了早期接入的门槛。

AI Gateway 这类统一入口层解决的是多供应商集成带来的工程碎片化问题：不同厂商的 API 在鉴权方式、请求格式、流式协议、错误码和速率限制上各不相同，团队若直接对接，需要在业务代码中维护多套适配逻辑。网关层通过将各家模型抽象为统一的模型标识符，把鉴权、重试、超时、故障转移等横切关注点收敛到一处。零数据保留（Zero Data Retention）则针对有合规要求的场景，确保请求内容不被网关或供应商留存用于训练或审计之外的用途。BYOK 模式下，团队自带供应商密钥，网关只做路由与观测，这也是"不加价"能够成立的前提——计费仍发生在供应商侧。

扩散文本生成走向主流的一步

Mercury 3 登陆 AI Gateway 的意义，不只是多了一个可选模型。它把"扩散生成文本"这条与主流自回归路线不同的技术路径，放到了一个开发者触手可及的分发渠道上。速度优势是否能在真实业务负载中兑现、基准表现能否经得起第三方复现，将是接下来值得关注的观察点。

对于正在构建低延迟智能体的团队，现在有了一个值得实测的选项。