Mercury 3：40倍扩展不减速的扩散LLM

扩散模型在图像生成领域大放异彩，但在语言模型赛道，它一直被视为“非主流”。Product Hunt 上最新发布的 Mercury 3 试图打破这一局面。据官方介绍，这是迄今能力最强的扩散 LLM，在多项基准上超越了 GPT-6 Luna 和 Claude Haiku 5.5，同时运行速度达到 1000+ tokens/s，比对手快 4–8 倍。

扩散 LLM 的差异化路线

主流大语言模型几乎都基于自回归架构：从左到右逐 token 生成。扩散 LLM 则借鉴图像生成思路，先对整段噪声进行迭代去噪，最终“浮现”出完整文本。这种范式天然支持并行解码，理论上能大幅降低推理延迟。Mercury 3 的发布意味着扩散架构在规模扩展上取得了关键突破——标题中“40 倍扩展不减速”正是对过往扩散模型难以做大的回应。

自回归解码与并行解码的本质差异

自回归模型每次前向传播只能确定一个 token，因为第 n 个 token 的生成依赖前 n-1 个 token 作为条件输入，这种序列依赖使推理无法在时间维度上并行，延迟随输出长度线性增长。扩散 LLM 则把整段 token 序列视为一个整体，训练时学习从被噪声污染的状态逐步恢复原始文本的反向过程，推理时从纯噪声出发经过固定步数的去噪迭代得到完整输出。因为每次迭代都在整段序列上同时进行，解码过程天然并行，总延迟取决于去噪步数而非输出长度，这与自回归的逐 token 串行形成根本性区别。

去噪步数带来的精度—延迟权衡

扩散模型的推理质量与去噪步数直接相关：步数越多，文本质量通常越好，但延迟也越高；步数过少则可能出现语义不连贯或重复。因此扩散 LLM 存在一个自回归模型没有的调节旋钮——开发者可以在质量与速度之间显式取舍，这在需要极低延迟的实时场景中是一项结构性优势，但也意味着标称吞吐量必须结合具体步数配置来理解。

性能与速度的取舍

官方宣称 Mercury 3 在能力上超越 GPT-6 Luna 和 Claude Haiku 5.5，同时保持 4–8 倍的速度优势。说一下，目前这些对比数据均来自厂商自述，缺乏第三方独立复现。Product Hunt 页面显示该产品获得 94 票、2 条评论，排名当日第 8，社区关注度不低，但评论样本太少，尚不足以形成共识性评价。

从工程视角看，1000+ tokens/s 的吞吐量对实时应用（如对话式 Agent、代码补全、批量文档处理）极具吸引力。若数据属实，开发者可以在同等硬件成本下支撑更高并发，或把节省的算力用于更复杂的推理链路。

tokens/s 吞吐指标的口径问题

衡量 LLM 推理速度时，tokens/s 至少有两种常见口径：单请求的逐 token 生成速率（影响用户感知的首字延迟与出字速度）和系统级聚合吞吐（影响单位硬件成本可支撑的并发量）。两者的数值可能相差一个数量级，且高度依赖批大小、序列长度、量化精度与硬件配置。扩散 LLM 的并行解码特性使它在低批大小下也可能保持较高利用率，这与自回归模型依赖大批量摊薄权重读取成本的行为模式不同。因此，对比“快 4–8 倍”这类声明前，需要确认双方是否在相同批大小、相同输出长度、相同硬件与相同精度下测量，否则数字之间不具备可比性。

背后团队与定位

Maker 为 Volodymyr Kuleshov，产品归类在 API、人工智能、开发工具三个标签下。这表明 Mercury 3 并非面向终端用户的聊天应用，而是以 API 形式提供模型能力，目标客户是希望替换现有推理后端的开发团队。对于成本敏感或延迟敏感的场景，这是一个值得关注的替代选项。

理性看待“颠覆”叙事

扩散 LLM 要真正挑战自回归模型，还需要在长上下文一致性、指令遵循、工具调用等维度拿出可复现的评测结果。Mercury 3 的 40 倍扩展与速度优势是亮眼的工程信号，但基准超越的声明仍需社区验证。对开发者而言，现阶段更务实的做法是将其纳入小规模对照测试，而非直接替换生产管线。

（本文基于 Product Hunt 公开信息整理，性能数据以官方发布为准。）

长上下文一致性为何是扩散 LLM 的难点

自回归模型在生成每个 token 时都能关注到全部已生成内容，长程依赖由注意力机制在因果掩码下逐位维持。扩散 LLM 则在多轮去噪中同时改写整段序列，早期迭代中远端 token 之间的一致性约束较弱，容易出现指代漂移、事实前后矛盾或格式结构崩坏，尤其是在数千 token 以上的长输出中。指令遵循与工具调用同样依赖严格的序列结构约束（如 JSON 语法、函数签名），而扩散解码的全局并行更新并不天然保证这些约束被逐位满足，通常需要额外的约束解码或后处理校正。这正是评估扩散 LLM 时不能只看短问答基准的原因。