要点摘录

Inception Labs 的 Mercury 2 声称约每秒 1,000 个 token，在关键基准测试上优于 Google 的 DiffusionGemma。两者均使用并行扩散式生成，而非逐字逐 token 的序列解码，能让大段文本在多次迭代中被精炼。 Mercury 2 在 AIME 2026 得分 90%，而 DiffusionGemma 得分 69.1%，且 Mercury 2 在其他学术测试中也有竞争性结果。Mercury 2 以付费 API 提供且权重为封闭；DiffusionGemma 则以免费开放权重在 Hugging Face 上提供。实际案例显示，在使用 Mercury 2 的生产子代理中可大幅降低延迟与成本。

情感分析

• 文章整体情感为偏正面：强调 Mercury 2 的明显技术进展与亮眼基准成绩，同时指出实际注意事项，例如权重封闭与仍有适用最佳情境。语气对扩散生成的潜力表示热情，但对于序列模型仍占优势的领域则持谨慎态度。
• 技术乐观可见：开发者与供应商对高吞吐量、较低延迟与大量任务的成本节省感到兴奋。但文章同时强调，在某些情境下，绝对前沿的推理能力仍可能由其他模型家族领先。
• 对产业影响的呈现偏建设性：扩散式 LLM 将架构设计导向许多快速子代理，但生态系统（本地运行时、代理编排）仍需赶上。

文章正文

Inception Labs 推出 Mercury 2，并将其定位为其中一款最快的推理型语言模型，报告的生成速度约为每秒 1,000 个 token。公司将这些速率与其他广为人知的模型比较：例如 Anthropic 的 Claude Haiku 4.5 Reasoning 与 OpenAI 的 GPT-5 Mini 的每秒 token 速率明显较低。大约在同一时间，Google 发布了 DiffusionGemma，这是另一款声称可比吞吐量的扩散式模型。这两类模型都放弃了逐 token 的序列方式，转而采用并行精炼：它们从一个带有噪声的 token 区块开始，经过数次迭代减少不确定性，直到整个区块稳定为连贯的输出。

这种并行扩散方法类似于图像生成中使用的技术，连续的去噪步骤将随机噪声转变为最终图像。应用于文本时，该方法能在许多任务上实现更高的吞吐量与更低的延迟。两者在性能与权衡上有所分歧。在 AIME 2026 基准测试（一个以正确解题百分比计分的具有挑战性的数学题套件）上，Inception 报告 Mercury 2 达到 90% 正确率。Google 在相同数据集上评估 DiffusionGemma 并记录到 69.1% 的结果。相比之下，Google 的非扩散标准 Gemma 4 在该测试中得分 88.3%，这显示扩散变体可能因设计选择而在某些解题精确度上有所牺牲。

Mercury 2 与 DiffusionGemma 在其他科学基准上也相近。在 GPQA（博士级别的科学评估）上，Mercury 2 得到 77%，DiffusionGemma 得到 73.2%，显示在某些任务上差距缩小。Google 的开发者指南亦建议，当追求最高质量时，非扩散的 Gemma 4 仍然较为可取。实际上的含义是：在吞吐量与低延迟至关重要的情境下，扩散模型表现优异，而在最艰难的推理任务上，一些序列大型模型可能仍占优势。

实际整合案例说明了操作上的好处。一个与代码代理公司的案例研究指出，用 Mercury 2 替换序列模型后，一个上下文压缩子代理的延迟约减少 82%，成本约降低 90%，同时维持输出质量。这些节省来自于能够执行大量短且快速的工具调用，而不会累积序列管道中的延迟惩罚。再加上通用 GPU 的支持，更高的吞吐量在大规模下能显著降低基础设施成本。

Inception 的技术血统可追溯到基于分数的扩散方法研究；创始人的学术工作促成了现代图像与现在文本扩散模型背后的去噪技术。公司获得来自知名投资者与机器学习硬件及研究社区的战略性资金。Mercury 2 以商业 API 并封闭权重提供，而 DiffusionGemma 则以免费、开放权重的检查点在 Hugging Face 上发布，为研究人员与产品团队创造不同的可及性轮廓。

在架构上，扩散模型鼓励为复杂系统采用不同的编排模式。生产堆栈不再由单一庞大模型处理所有任务，而是成为一组专门化的子代理——有些为推理调优，有些为摘要、路由或快速检查。 启用扩散的子代理使频繁的工具调用变得足够便宜，可以广泛使用，这改变了设计者如何划分功能并优化对延迟敏感的体验，例如实时编码、语音交互与实时自动完成。

限制仍然存在。扩散式 LLM 目前最适合速度敏感且高流量的工作流部分，而非推理能力的绝对前沿。可及性各异：封闭权重的 API 限制本地实验，而开放权重的发布则允许更广泛的社区开发。此外，周边生态系统——本地运行时、代理框架与工具——仍在发展中，以便在各种环境中无缝利用并行生成。

即时使用场景包括能跟上快速编辑的响应式编程辅助、依赖大量快速调用的多代理系统，以及需要最小延迟的语音界面。在大规模部署时，提升的吞吐量可转化为标准硬件上的显著能耗与成本减少，使扩散式 LLM 成为对延迟关键的应用的有吸引力选择。

关键见解表