你让同事写一段回复，常见做法是从第一个字一路写到句号，后面的内容必须等前面定下来。今天的主流大语言模型也大多如此：一次生成一个 token——可以是字、词或词的一部分。这种“自回归”机制很稳，却限制了单条回答的并行速度。Inception 在 2026 年 8 月 31 日发布的 Mercury 2.5 Preview，想换一条路：同时生成多个 token，再经过多轮修正。它不再严格逐字往后写，但也不是一口气交出完整答案。
这款模型最值得看的，不只是一个速度数字，而是扩散式语言模型（diffusion LLM，简称 dLLM）开始正面挑战主流生成范式。不过，目前公开信息全部来自 OpenRouter 的同一模型页，核心能力又源于 Inception 的产品描述，尚不能算独立交叉验证。
像改草稿，而不是接龙
自回归模型更像接龙：每一步都依赖前面已经写好的内容。扩散式语言模型则通常从一段不完整或带噪的 token 状态出发，同时处理多个位置，再反复修订，直到形成最终文本。它试图绕开的，正是“前一个 token 没写完，后一个就不能开始”的串行瓶颈。
这也解释了标题中的“不再逐字生成”：它描述的是生成机制，不等于模型没有中间步骤。Mercury 2.5 仍要迭代，只是一次可以修改多个位置。并行带来的收益尤其可能出现在延迟会层层累积的流程中。Inception 点名了搜索 Agent、语音流水线和代码子 Agent——Agent 指能自主拆解任务并调用工具的软件系统。
据 OpenRouter 转述，Inception 宣称 Mercury 2.5 在“标准 GPU”上可达到每秒 1,107 tokens，并称它是“最快的推理 LLM”。但同一页面的实际监测数据显示，其 P50 吞吐量为每秒 275 tokens，P50 总延迟为 1.33 秒。P50 就是中位数：一半请求快于它，一半慢于它。两个速度数字的测试条件没有公开，硬件型号、并发量、输入和输出长度、推理等级也都未知，因此不能直接比较，更不能把 1,107 tokens/sec 当作普遍实测表现。
快之外，它还想进入生产流程
Mercury 2.5 支持调节推理强度，也就是控制回答前投入多少计算或修订步骤。强度提高，复杂任务表现可能改善，但通常也会增加延迟和成本。它还支持并行工具调用，以及符合指定 schema 的 JSON 输出。schema 可以理解为程序预先规定的数据格式；严格按格式输出，软件才能稳定读取结果，而不是临时猜测自然语言的意思。
模型提供 260,000 tokens 的上下文窗口，单次最多输出 65,536 tokens。OpenRouter 页面还称，它比 Mercury 2 的“智能水平”提高 10 分以上，质量可比 GPT-5.6 Luna (Low)、Gemini 3.5 Flash-Lite 和 Claude Haiku 4.5 等成本优化型前沿模型。不过，页面没有给出基准名称、测试集和评分方法，这些目前只能视为厂商主张。
为什么现在值得关注
扩散模型在图像领域可以逐步去除像素噪声，但文字由离散 token 组成，不能直接照搬。Mercury 背后的团队为这条路线积累多年。据 Amplify Partners 介绍，Stefano Ermon、Aditya Grover 与 Volodymyr Kuleshov 的合作可追溯至 Stanford；他们后来因训练规模所需算力超出学校资源而创办 Inception。团队此前先用 Mercury Coder 切入对速度敏感的代码生成，如今 Mercury 2.5 又把同一路线推进到推理和通用任务。
真正的看点因此不是“每秒多写多少字”，而是并行修订能否同时守住三件事：速度、回答质量，以及可靠的工具调用。如果可以，语言模型的生成方式就不必永远只有逐词接龙这一种答案。
局限与未知
- “最快”“智能提高 10+ points”和同类模型质量相当，均缺少公开测试细节与第三方复核。
- 1,107 tokens/sec 的厂商口径与 OpenRouter 监测到的 275 tok/s 差距明显，现有材料不足以解释原因。
- OpenRouter 显示该模型目前仅由一个提供商托管，请求会直接转发，不能据页面的通用容灾说明推断它已有多提供商保障。
价格同样要看期限：截至 2026 年 9 月 8 日 07:00 UTC，Inception 提供八折后再减至原价两成的限时价格，即每百万输入 tokens 0.04 美元、输出 0.15 美元、缓存读取 0.004 美元；页面所列常规价格分别为 0.20、0.75 和 0.02 美元。它很便宜，但至少在更多公开测试出现前，Mercury 2.5 更适合被看作一次值得追踪的产品化挑战，而不是已经坐实的新范式胜利。