当整个行业仍在追逐更大参数规模的语言模型时，推理速度正成为制约生产级 AI 应用体验的关键瓶颈。Inception Labs 推出的 Mercury 2 标志着一种根本性的范式转换 —— 它不是通过优化现有架构来提升速度，而是用扩散模型（Diffusion Model）替代自回归（Autoregressive）解码，从生成机制层面实现了数量级的性能跨越。本文将从架构原理、推理速度曲线、token 生成范式差异三个维度，深入解析这一技术方向的核心优势与工程落地要点。
自回归解码的固有困境
当前主流的大型语言模型几乎无一例外采用自回归解码机制。给定前文序列，模型每次只预测下一个最可能的 token，然后将预测结果追加到输入中，再预测下一个。这种 “逐字逐词” 的生成方式在逻辑上保证了输出的一致性，却也带来了无法回避的性能瓶颈：生成 N 个 token 必然需要 N 次前向推理步骤，且每一步都必须等待前一步完成才能开始。GPU 并行计算能力在自回归解码中无法得到充分利用，因为每一步的输入都是上一步的输出，形成了严格的依赖链。
这一瓶颈在生产环境中会被急剧放大。当构建 AI Agent 时，一个复杂任务往往需要模型进行数十甚至上百次推理调用 —— 检索、规划、执行、反思，每个环节都在累积延迟。自回归模型的延迟不是线性叠加，而是乘数级放大：每个 token 的生成时间直接乘以输出长度，再乘以调用次数。Inception 在博客中精准描述了这一问题：生产级 AI 不是一次问答，而是循环执行的 Agent 流程，延迟会在每一次迭代中复合。
扩散模型如何改变生成逻辑
扩散模型在图像生成领域已经证明了自己的价值 —— 从 Stable Diffusion 到 MidJourney，再到 OpenAI 的 Sora，扩散架构展现了对高维数据的强大建模能力。将这一机制迁移到语言生成，核心思想是将 “逐词预测” 转变为 “整体迭代精修”。
具体而言，扩散语言模型不再逐个预测 token，而是从随机噪声出发，通过多步迭代逐步 “去噪”，将隐含的语义向量还原为连贯的 token 序列。每次迭代中，模型并非只预测一个位置的概率分布，而是同时对多个位置进行预测和修正。这种并行生成机制使得 GPU 的并行计算能力得到充分发挥 —— 不再是串行的 N 步执行，而是一个小步数（通常在 8 到 16 步之间）的并行迭代过程。
Mercury 2 将这一原理推向极致。它采用并行精修（Parallel Refinement）策略：每一次扩散步骤，模型同时生成多个 token，然后通过少量步骤收敛到最终输出。Inception 团队在官方博客中将其比喻为 “更像一位编辑同时修订整篇草稿，而不是打字机逐字敲击”。这不仅大幅提升了原始吞吐量（官方数据为每秒 1,009 个 token，基于 NVIDIA Blackwell GPU），更重要的是改变了速度曲线的形态 —— 不再受输出长度的线性约束，而是呈现出一个相对平缓的收敛曲线。
推理速度优势的量化分析
对比自回归模型，Mercury 2 的速度优势可以从三个维度量化。第一是首 token 时间（Time to First Token，TTFT），即用户发起请求到获得首个字符的等待时长。自回归模型必须完成整个前缀的处理才能开始输出，而扩散模型从第一个扩散步骤开始就能并行生成多个 token，显著缩短了感知延迟。第二是 token 生成速率，Mercury 2 官方标称达到每秒 1,009 个 token，Inception 声称这比传统自回归模型快超过五倍。第三是单位成本，得益于并行处理的高效硬件利用，Mercury 2 的定价为输入每百万 token 0.25 美元、输出每百万 token 0.75 美元，显著低于同档次推理模型。
这一速度优势在特定场景下尤为关键。代码补全场景中，开发者对延迟的敏感度极高 —— 任何超过 200 毫秒的停顿都会打断编程心流。Mercury 2 的毫秒级响应使补全建议能够 “融入开发者自身的思维节奏”。实时语音交互场景的延迟预算更为严苛：从用户说话到系统回应，整个环节必须在数百毫秒内完成才能保证对话的自然感，Mercury 2 的推理速度使得在语音交互中加入复杂推理成为可能。Agentic 工作流中，每一次工具调用、每一次检索都在累积延迟，减少单次调用的耗时可以直接转化为增加推理步数或提升最终输出质量的预算空间。
推理质量与可控性的工程考量
速度优势并不意味着质量妥协。Mercury 2 被定位为 “推理模型”，意味着它需要处理复杂的多步推理任务，这与单纯追求快速生成的场景有本质区别。Inception 强调 Mercury 2 支持可调推理（Tunable Reasoning）、128K 上下文长度、原生工具调用以及 Schema 对齐的 JSON 输出。这些能力使其能够胜任需要结构化思考的任务，而不仅仅是快速生成短回复。
值得注意的是，扩散模型的可控性是其天然优势之一。由于生成过程是通过迭代精修完成的，可以在每一步引入显式的约束条件 —— 例如强制输出符合特定 JSON Schema，或确保不偏离指定的业务规则。这种细粒度的控制能力在自回归模型中需要复杂的采样策略或后处理逻辑才能实现，而在扩散框架下可以作为生成过程的一部分原生支持。
生产部署的关键参数与监控点
将 Mercury 2 投入生产环境需要关注几个工程化要点。首先是推理步数与质量的平衡 —— 虽然更多扩散步骤通常带来更高质量的输出，但会增加延迟。实际部署时需要根据业务场景在 4 到 16 步之间寻找最优配置。其次是批处理策略，扩散模型的并行特性使得批处理的效率收益不同于自回归模型，增大批处理大小往往能显著提升吞吐量。第三是流式输出的处理方式，Mercury 2 支持流式 token 输出，但需要客户端做好并行接收的准备，而非传统的逐字接收范式。
监控层面应重点关注 P95 延迟（高并发下的响应时间分布）、每秒处理的请求数、以及 GPU 利用率曲线。Inception 在官方文档中指出，他们优化的是 “用户实际感受到的响应性”—— 包括高并发下的 P95 延迟和系统繁忙时的一致性表现，这些是比单纯吞吐量更贴近用户体验的指标。
面向未来的推理架构
Mercury 2 的出现揭示了一个重要趋势：当模型能力足够强大后，推理速度将成为差异化竞争的核心维度。扩散模型带来的不仅是更快的 token 生成，更是一种全新的架构思维方式 —— 从顺序依赖走向并行精修，从单点预测走向整体优化。这一方向的天花板远未可见：随着扩散步数的进一步优化、硬件特性的深度适配，推理速度还有持续提升的空间。
对于正在构建生产级 AI 系统的团队而言，理解并评估扩散语言模型已经不再是可选项，而是应对下一代交互范式 —— 无论是实时语音、AI Agent 还是多模态推理 —— 的必要技术储备。
资料来源：Inception Labs 官方博客（inceptionlabs.ai/blog/introducing-mercury-2）及产品页面。