Mercury 3 每秒生成 1068 个 Token：扩散语言模型距离企业应用还有多远？

2026年10月19日，Inception 发布 Mercury 3。官方公布，该模型在 NVIDIA GPU 上的生成速度达到每秒 1068 个 token。与 Mercury 1 相比，Mercury 3 的总参数规模扩大了40倍以上，官方称在保持千 token/s 级别生成速度的同时，模型能力也得到提升。

一天之后，10月20日公开的 CoRAL 预印本又提出了另一种思路：让扩散模型并行探索多种推理方案，再由自回归模型完成方案选择和答案生成。

两项进展接连出现，让扩散语言模型的讨论从“能不能更快生成”，延伸到两个更值得企业关注的问题：模型规模扩大后，速度优势能否保持？并行生成能否与现有模型协作，进入更复杂的业务任务？

Mercury 3 已通过 Inception API、OpenRouter、Baseten 和 Vercel 提供服务。官方披露，早期合作伙伴已经在浏览器 Agent、实时搜索、互动教育和客户支持等场景使用这一模型。这说明扩散语言模型已经出现商业化应用入口，但模型可以调用、客户开始试用和企业大规模稳定部署，仍然是不同阶段。

模型生成速度的提升，究竟能给用户带来多少实际收益？要回答这个问题，需要把模型放回完整的业务执行链路中考察。

本文依据公开论文和官方发布材料展开分析，未进行独立模型测试。厂商公布的速度和研究中的基准成绩，均不能直接视为企业上线后的效果。

自回归语言模型通常按顺序生成文本：后续 token（模型处理文本的基本单位）依赖已经生成的内容。扩散语言模型采用不同的生成过程，可以在多个位置上同时进行预测，再通过多轮更新逐步形成完整结果。

它提供的机会，是减少部分生成工作的串行依赖，并不意味着整个答案只需一次计算就能完成。不同扩散模型的训练目标、采样方式和服务实现也可能不同。

2025年的 Mercury 技术报告介绍了这种由粗到细、并行修改多个 token 的生成方式，同时说明模型仍使用 Transformer 架构。因此，“扩散”描述的是生成与训练机制，不能简单理解成全面替换了既有神经网络结构。更新轮数、每轮处理范围和服务实现，都会影响实际速度。

这种机制对长输出尤其值得关注。例如，一段必须完整返回的代码修改、一份需要整体校验的结构化结果，在生成结束前通常无法进入下一步处理。如果这些任务的大部分等待确实来自解码，减少串行生成就有明确价值。

相反，一个只需要输出类别标签的任务，生成本身很短，网络、排队或输入处理可能才是主要耗时。

同一个客服系统里，生成一段退换货说明和查询一件商品的库存，值得分别计时。前一项可能要等模型写完，后一项则可能要等数据库返回。按具体请求拆开看，比给整个“客服”场景选一个快模型更有用。

Mercury 3 的发布，首先回答了一个扩散语言模型发展过程中一直存在的问题：模型规模扩大后，能否继续保持并行生成的速度优势？

Inception 官方公布，Mercury 3 的总参数规模超过 Mercury 1 的40倍，生成速度达到每秒1068个 token，上下文窗口扩大到100万 token。相比之下，Mercury 2.5 的上下文窗口为26万 token。

这些数字来自厂商发布材料。官方没有公开足以完整复现1068 token/s的全部硬件配置、并发负载和输入输出长度条件。因此，这个数字可以作为启动评估的依据，不能直接作为企业服务的时延承诺。100万 token 的上下文容量，也不能证明模型在长输入下仍能保持相同速度。

从产品状态看，Mercury 3 已通过 Inception API、OpenRouter、Baseten 和 Vercel 提供。官方披露，早期合作伙伴已经将其用于浏览器使用 Agent、互动教育、实时搜索和客户支持等对延迟敏感的场景。

这为企业评估提供了具体方向，但目前公开的应用案例主要来自厂商及合作伙伴，不能替代独立的跨场景性能测试。

同一发布材料还引用了 Octen AI 的测试反馈：模型生成时间中位数为0.9秒，端到端响应时间中位数为2.2秒。这是经厂商发布的客户反馈，尚不足以建立独立、可复现的横向比较，但它说明生成结束和请求完成并不是同一个时间点。两个中位数也不能直接相减，推算每个请求在其他环节的耗时。

与 Mercury 3 直接提升文本生成速度不同，10月20日公开的 CoRAL 预印本研究了扩散模型在复杂推理中的另一种角色：先并行探索多种解题方案，再交给自回归模型评估和执行。

研究团队使用 LLaDA-V 作为规划器（Planner），负责生成多种候选推理路径；使用 Qwen2.5-VL-7B 作为执行器（Executor），负责评估候选方案并生成最终答案。

在 Trip-Planning 任务中，模型需要生成满足航班衔接、日照时长等约束的多城市行程。单独使用 Qwen2.5-VL-7B 时，准确率为0.12，完整 CoRAL 方案达到0.31。

这项研究还有一个值得注意的实现细节：规划器生成的方案可以通过两种方式交给执行器。

一种是文本传递，将候选方案转化为文本，拼接到原始问题中；另一种是潜表示传递，通过训练一个投影层，将规划器内部的潜表示映射到执行器能够接收的嵌入空间。

论文附录 Table 3 对不同架构进行了对照：

RDC（Reward-Guided Denoising for Chain-of-Thought，面向思维链的奖励引导去噪训练）是这套方案的另一项关键设计。它将结果奖励引入扩散模型的训练过程，引导规划器生成更符合任务目标的推理路径。

需要区分的是，0.25不只出现在文本传递实验中。论文 Table 2 的消融实验还显示，完整 CoRAL 准确率为0.31，去掉 RDC 后降至0.25。这说明 RDC 对最终效果有实际贡献，不能将完整方案相较文本传递方案的0.06提升全部归因于潜表示接口。

因此，CoRAL 的价值来自规划器、执行器、信息传递方式和训练目标的组合。它不是简单地把两个现成模型 API 接起来，就能获得同样的效果。

在实现条件上，论文使用 LLaDA-V 作为扩散规划器、Qwen2.5-VL-7B 作为自回归执行器。规划器主体与解掩码策略模块联合训练使用16张 A100 GPU；投影层另行训练，训练时两个模型的权重保持冻结。推理实验的最大生成长度设为128 token。

论文也明确指出，两阶段架构会增加系统复杂度和推理延迟；当前实验使用英语数据集，尚未验证多语言和低资源任务。其视觉输入评测集中于静态图像，尚未扩展到视频理解和流式多模态输入。

Mercury 3 给出的是商业服务的生成速度，CoRAL 的行程规划实验回答的是候选方案能否帮助模型答对。两者不能直接比较吞吐数字，但共同指向了一个值得继续研究的方向：扩散模型除了直接生成答案，还可能承担并行规划等中间任务。

对产品团队来说，还要回到各自的业务里计时：从用户发出请求，到用户拿到可用答案，中间究竟过了多久？

实时系统至少存在三个不同的完成时刻：收到第一个输出、收到第一段有用内容、拿到可以执行或展示的完整结果。

一个系统可能很快输出“好的”，却很晚才给出结论；也可能较晚开始输出，但随后迅速交付完整结果。这两者不应被同一个“响应速度”指标掩盖。

2026年9月29日发布的 Mercury Voice 材料进一步体现了这种区别。Inception 使用 TTFAT（Time to First Answer Token，首个答案 token 时间）衡量模型完成内部推理后，开始输出用户实际听到的答案所需的时间。

在厂商使用的生产语音提示词测试中，Mercury Voice 在低推理强度下的 TTFAT 中位数为320毫秒，95分位为750毫秒。

95分位意味着95%的测试请求，其首个答案 token 时间不超过750毫秒。这仍然是语言模型环节的指标，不能等同于从用户停止说话到扬声器开始播放有效答案的总时间。后者还涉及话轮判断、语音识别、外部调用和语音合成。

企业评估可以按下表定义可用结果。表中的指标是评估建议，并非上述产品的实测结果。

对于需要外部查询的系统，还应分别记录检索、数据库和第三方服务时间。如果必须等待最新库存才能回答，生成加速无法消除这项数据依赖。提前输出未经确认的库存，只是把等待转化为错误风险。

评估代码助手时，如果验收要求是“补丁通过检查”，计时也要包含检查；评估语音客服时，可以从通话录音里标出用户第一次听到有效答复的时刻。

先约定这个终点，模型团队和产品团队才会在比较同一件事。

假设某条完全串行的请求链路原本耗时2秒，其中模型生成占1秒，其余环节占1秒。若生成耗时缩短到原来的四分之一，即0.25秒，而其他环节不变，总耗时就是1.25秒。

模型生成提速4倍，整条链路的加速比只有1.6倍，用户实际少等了0.75秒。

这个例子用于解释串行链路中的时间构成，不是任何产品的评测结果。如果检索、生成和校验可以重叠进行，就要沿实际调用记录，找出决定任务完成时间的那条路径。

业务质量也会改变这个结果。假如更快的模型经常漏掉必填字段，系统就需要重新生成；如果候选方案增多，却没有可靠的筛选方式，执行器可能花更多时间阅读重复或错误的内容。第一次调用快，并不保证最终完成快。

压测时尤其值得看两个问题：为赶时间减少更新轮数后，哪些答案开始出错？并发升高后，等待最久的那部分用户还能省下多少时间？

对生成候选方案的系统，还要检查多出来的方案能否被可靠筛选。反复生成相似的错误答案，只会增加执行器的工作量。

因此，扩散路线能否更快进入企业，取决于几项可观察的变量：目标任务中生成所占的时间比例、较少更新轮数下的质量保持程度，以及高并发时尾部延迟是否稳定。

API 兼容只能降低接口改造工作，无法替代业务迁移测试。结构化输出、停止条件、流式返回、工具调用和超时重试都应在同一业务输入上核查。尤其要避免沿用旧模型的输出长度设置后，直接把结果差异归因于模型架构。

第一步是选取一项对等待敏感、又有明确完成条件的业务。代码补丁、字段抽取或固定范围的语音问答都可以成为候选，前提是已有可使用的对照系统。保留原始请求、长度分布、失败记录和峰值负载，避免只测简短且容易成功的示例。

第二步是给现有链路增加时间记录。至少分开输入准备、排队、模型首个有效输出、完整输出和下游检查。对于流式系统，还要确认内容何时能够安全地交给用户。先识别主要等待环节，再决定是否引入扩散模型；若数据库已经占据大部分时延，优先优化数据路径更直接。

第三步是建立受约束的对照。比较现用模型与候选模型时，固定业务输入和完成标准，记录模型版本、推理设置、区域、并发和输出长度。

质量可以使用任务正确率、字段完整率或补丁检查结果；延迟同时看中位数和95分位，并将超时、重试与失败请求一并报告。不能只统计成功请求，否则较高失败率可能让速度看起来更好。

第四步再判断业务收益。技术负责人需要确认关键路径是否缩短，产品负责人需要观察用户中断、重复追问或任务完成情况是否改善。财务评估则应覆盖重复调用、回退服务和新增运维，而不只比较单次输出价格。

先开展小范围上线，并保留原模型回退路径；只有质量与稳定性达到事先设定的条件，才扩大流量。

从公开进展看，扩散语言模型已经不再局限于实验室研究。Mercury 3 已有商业 API 和早期合作场景，Mercury Voice 也在探索低延迟语音交互；CoRAL 则进一步展示了扩散模型与自回归模型协作的研究方向。

但商业接口开放不等于已经具备普遍适用的生产能力。企业还需要验证模型在自身负载、并发、质量要求和业务流程下的表现。

更可能出现的情况，是企业根据不同任务的特点，让模型承担不同角色：对生成速度敏感的任务，优先评估扩散模型；对复杂推理和答案一致性要求较高的任务，可以探索扩散模型并行生成候选、自回归模型负责验证和执行的组合。

这种分工也有停止条件。当额外调用、候选传输和维护复杂度超过生成节省的时间，单模型方案仍可能更合适。对于答案很短、请求量有限或输入处理占主导的应用，引入第二套模型未必产生足够收益。

因此，判断扩散语言模型距离企业应用还有多远，不能只看生成速度，也不能只看论文基准。更实际的做法，是从一条真实业务链路开始，测量用户拿到可用结果的时间，再比较质量、稳定性和成本。

对开发者，值得比较的是同一批请求里，有多少补丁通过检查，以及等到补丁可应用要多久。对查询订单的用户，值得测的是从问完问题到听见送达日期，中间那段沉默缩短了多少。

扩散语言模型已经提供了新的生成方式和商业化选择。它能否成为企业的有效技术方案，最终要看用户是否真的少等了，业务结果是否依然可靠。

参考文献

1. Inception Team. Diffusion at Scale: Introducing Mercury 3. 2026年10月19日，官方产品发布。 —
2. Wei Cai, Jian Zhao, Yuchen Yuan, Xuelong Li. Beyond the Sequentiality Bottleneck: A Hybrid Diffusion-Autoregressive Framework for Efficient Multimodal Reasoning. arXiv:2610.28584v1，2026年10月20日，预印本。 —
3. Firas Trabelsi 等，Inception. Introducing Mercury Voice. 2026年9月29日，官方产品发布。 —
4. Inception Labs, Samar Khanna 等. Mercury: Ultra-Fast Language Models Based on Diffusion. arXiv:2506.17298v1，2025年6月17日，技术报告。 —