Mercury 2.5扩散语言模型：770 tokens/秒的推理速度突破

一则值得关注的性能数据

Hacker News 上出现了一条关于 Mercury 2.5 大语言模型的简短讨论，核心信息只有一句话：这款模型的推理吞吐达到了 770 tokens per second（每秒 770 个 token）。虽然帖子本身讨论热度不高（4 分、2 条评论），但这个数字本身放在当前 LLM 生态里，足以引起从业者的注意。

对比一下就能理解为什么。主流的自回归大模型（如 GPT 系列、Claude 系列）在标准部署条件下，单请求的生成速度通常在几十到一两百 tokens/秒的区间。770 tokens/秒意味着接近甚至数倍于常规体验的响应速度——对于交互式应用、实时代码补全、长文本生成等场景，这种速度差异是能被用户直接感知的。

Mercury 背后的技术路线

Mercury 系列的定位是「扩散式语言模型」（diffusion LLM）。与传统自回归模型逐个 token 顺序生成不同，扩散语言模型采用并行去噪的思路，可以在一次前向过程中同时优化多个位置的输出，再通过多轮迭代逐步收敛到最终文本。

这种架构差异正是速度优势的来源。自回归模型的生成速度天然受限于「一次一个 token」的串行特性，即便硬件再快，也要一步步吐字；而扩散式方案通过并行化打破了这个瓶颈，理论上能在同等硬件下获得显著更高的吞吐。770 tokens/秒的数据，本质上是这条技术路线的一次工程化验证。

需要说明的是，Hacker News 原帖并未提供关于模型规模、评测环境、硬件配置或质量基准的细节。这里对技术路线的解读基于扩散语言模型的公开常识，具体到 Mercury 2.5 的实现方式，仍需以官方资料为准。

扩散模型（Diffusion Model）最初在图像生成领域大放异彩，其核心思想是：先向数据中逐步加入噪声（前向过程），再训练模型学会逐步去除噪声以还原原始数据（反向过程）。将这一框架迁移到文本生成时，研究者面临的挑战在于文本是离散的——不像像素值可以连续插值。扩散语言模型的主要技术分支之一是「掩码扩散」（Masked Diffusion），将「加噪」重新定义为随机遮盖（mask）部分 token，再训练模型并行预测所有被遮盖的位置，从而实现非自回归的并行解码。这与 BERT 的掩码语言模型有形式上的相似，但在生成阶段通过多轮迭代逐步「去掩码」，使输出质量随迭代步数收敛。Inception Labs（Mercury 的开发商）正是沿着这一方向推进工程化落地。

速度之外，还要看什么

单看吞吐数字容易产生误导。评估一款 LLM 是否真正可用，至少还要看三个维度：

输出质量

速度快而质量差没有意义。扩散语言模型作为相对较新的路线，在生成连贯性、指令遵循、复杂推理等能力上是否能追平成熟的自回归模型，是决定其实用价值的关键。原帖没有给出任何质量对比数据，这是目前最大的信息缺口。

评估语言模型输出质量通常依赖一套标准化基准测试，涵盖多个维度：MMLU 测量多领域知识理解，HumanEval / MBPP 测量代码生成能力，MT-Bench 和 AlpacaEval 评估指令遵循与对话质量，GSM8K 和 MATH 考察数学推理能力。扩散语言模型在这些基准上的历史表现普遍落后于同规模的成熟自回归模型，早期工作（如 MDLM、PLAID）主要在困惑度（Perplexity）指标上取得进展，但在开放式生成和复杂推理任务上仍有明显差距。Mercury 2.5 若要证明自身实用价值，需要在上述主流基准上提供可对比的数据，而非仅凭速度指标说话。

测试条件

770 tokens/秒是在什么硬件、多大 batch、多长上下文下测得的？是单请求延迟还是聚合吞吐？这些条件不同，数字的含义天差地别。缺乏这些背景，单个数值只能作为参考而非结论。

成本与可用性

高吞吐如果建立在昂贵硬件或不可扩展的部署方式上，商业价值就要打折扣。真正有意义的指标是「单位成本下的有效吞吐」。

扩散语言模型的行业意义

抛开这条具体新闻，扩散式 LLM 代表的是一种对「速度天花板」的探索方向。随着模型应用从「一次性问答」转向「Agent 多轮调用」「实时协作编程」等高频交互场景，推理速度正在成为和智能水平同等重要的产品维度。

如果扩散语言模型能在保持质量的前提下持续拉开速度差距，它可能会在延迟敏感型应用中占据一席之地——比如实时翻译、语音助手的文本生成、IDE 内联补全等。Mercury 2.5 的这次数据披露，可以看作这一趋势的又一个信号。

小结

这条 Hacker News 帖子信息量有限，但传递的信号明确：扩散语言模型正在把推理速度推向新的量级。770 tokens/秒是个亮眼的数字，不过在看到独立的质量评测、完整的测试条件和成本数据之前，理性的做法是保持关注而非盲目乐观。对于关注 LLM 部署效率的开发者来说，这至少是一个值得持续跟踪的技术方向。