Agent 每一步都在等模型：扩散解码快在哪

原文：Inception Labs Blog - 《Diffusion at Scale: Introducing Mercury 3》（https://www.inceptionlabs.ai/blog/introducing-mercury-3）

先算一笔时间账。一个浏览器 agent 跑 30 步，每步调一次模型，单次 2 秒，光等模型就是 60 秒，工具调用和页面加载还没算。用户不会理解这 60 秒花在哪，他只会觉得这东西卡。

所以做 agent 产品和做聊天机器人，关注点不一样：聊天看首字延迟，agent 更该看每一步的模型耗时，因为它是被步数放大的。Inception Labs 上周发的 Mercury 3 就是冲着这个场景讲的——一款扩散式语言模型，官方给的数字是 1068 tokens/秒。

这篇不站队，只把「扩散解码为什么可能更快」和「快在哪一步、不快在哪一步」讲清楚，最后给一段能自己量延迟的代码。

一、agent 的时间都花在哪

端到端耗时的粗略拆法是：步数乘上（模型时间加工具时间），再加重试和人工介入。工具时间由网络和对方系统决定，你改不了；模型时间是唯一能靠选型直接压下去的部分。

这里有个容易被忽略的推论：如果工具步骤占比很高，换更快的模型收益有限。十个步骤里有七个是在等页面加载，那模型快一倍，总时间可能只降 15%。所以优化之前先量比例，不要默认模型是瓶颈。这条是我的工程判断，不是原文结论。

二、自回归解码：一次前向出一个 token

现在绝大多数模型走的是自回归路线：把已有文本喂进去，前向一次，输出下一个 token 的概率分布，采样一个，拼回去，再来一次。输出 300 个 token 就要 300 次前向。

工程上有 KV cache 帮忙，已经算好的前缀不用重算，所以每次前向的成本主要落在新 token 上，实际速度能到每秒几十到几百 token。但结构限制在那儿：前向次数与输出长度是 1 比 1。要提速，只能让每次前向更快，或者一次前向多吐几个候选（投机解码那类做法）。

对 agent 来说，这意味着单步延迟和输出长度近似线性相关。让模型输出一段 500 字的计划，就是 500 次前向。

三、扩散解码：一次前向改一批 token

扩散语言模型的思路完全不同。它先把一段固定长度的 token 全部填成噪声或占位，然后迭代去噪：每一次前向同时修正这一段里的一批位置，迭代若干步后整段收敛成完整文本。

关键在于前向次数和输出长度解耦了。一段 300 个 token 的输出，可能只要十几次到几十次前向就成型，而不是 300 次。这就是吞吐能上到千级 token/秒的结构性原因。

代价也很明确：每次前向都要处理整段，算力花在「重算已经大致正确的部分」上；质量靠迭代步数收敛，步数少了会崩。所以这类模型天然适合长度可预期、对速度敏感的场景，比如工具调用的参数生成、分类、短回复、实时语音。让它写一篇需要长链条推理的散文，未必是它的强项。

上面是扩散语言模型的一般解码方式，具体到 Mercury 3 的实现细节，以官方文档和论文为准。

四、Mercury 3 给的数字，以及读这些数字的口径

官方公布的关键参数：

• 速度 1068 tokens/秒（NVIDIA GPU 上）
• 上下文 100 万 token，上一代 Mercury 2.5 是 26 万
• 价格 输入每百万 token 0.20 美元、输出每百万 0.70 美元；发布期五折，即 0.10 和 0.35；缓存命中的 token 在输入价上再打一折
• 规模 参数量比 Mercury 1 大 40 倍以上，标准基准上的智能水平是 Mercury 1（mini）的 3 倍
• 兼容性 OpenAI API 兼容，可直接替换现有调用；官方平台之外也上了 OpenRouter、Baseten、Vercel

官方还声称它在多项基准上超过 GPT-6 Luna 和 Claude Haiku 5.5，同时快 4 到 8 倍。这类横向对比是厂商自述，没有第三方复现，看的时候当成方向而不是结论。

这里要特别注意口径。1068 tokens/秒 是吞吐，不是首字延迟。一个模型可以吞吐很高但第一个 token 出来得慢，对语音和实时交互来说后者更致命。官方专门有一条产品线 Mercury Voice 强调 TTFAT（time to first answer token），说明他们自己也把这两件事分开看。

按它的价目表算一下成本，一次 20 步的 run，每步输入 3000 token、输出 500 token，就是 6 万输入加 1 万输出：0.06 乘 0.20 得 0.012 美元，0.01 乘 0.70 得 0.007 美元，合计约 0.019 美元一次。发布期五折大约 0.0095 美元。这是按公开价目表推的，不是实测账单。

五、三个一线的现场数字

官方博客里放了几个合作方的说法，都是他们自己在生产环境里的观察，口径各不相同，不能拿来横向比较，但能看出大家到底在关心什么。

浏览器 agent 那边，TinyFish 用它自己的 web agent harness 跑了 50 个真实 Mind2Web 导航任务，Mercury 3 完成 50%，明显高于 GPT-6.1-Sol，而且用的 token 量和 agent 步数跟前沿模型相同，单 token 成本低得多。这条最贴合我们的主题：同样的步数、同样的 token，只是每步更快、更便宜。

实时搜索那边，Octen 的 Sense API 里搜索本身只要约 80 毫秒，瓶颈全在模型生成；换成 Mercury 3 后生成中位数 0.9 秒，端到端中位数 2.2 秒。这个拆解很值得学——先量清哪一段慢，再决定换什么。

教育场景里，RevisionDojo 说提示、批注、释义能在大约 1 秒内返回，质量和之前用的模型相当或更好，而且是直接替换现有栈，没改代码。

六、选型时我会看什么

三条，按优先级排：

一是每步延迟的分位数，不是平均值。agent 的体验由 p95 决定，平均值好看没用。

二是单次 run 的总成本，不是单 token 价格。步数多、上下文长的任务，缓存命中率和上下文长度的影响会盖过单价差异。

三是工具步的占比。前面说过，这个比例决定模型提速能传导多少到端到端。比例低的任务，先把工具调用做批量化、并行化，比换模型划算。

另外，1M 上下文这个升级对 agent 的意义比对聊天大：多步任务里历史轨迹会把上下文迅速撑满，上下文上限直接决定你能把多少步的原始记录留在窗口里。当然，能留不等于该留，全量塞回去还会抬高成本和延迟，这一点在之前几篇里已经反复踩过。

七、量自己的每步延迟

模型是否兼容、参数名是否一致，以官方文档为准；下面是按 OpenAI 兼容接口写的最小计时脚本，用来量自己场景里的单步延迟，不依赖任何厂商 SDK：

# 示意：量单步延迟分布（p50/p95）与有效吞吐，未验证最新版本importtime,statisticsfromopenaiimportOpenAI client=OpenAI(base_url="https://api.inceptionlabs.ai/v1",api_key="YOUR_KEY")PROMPT="给出一条浏览器操作：在当前页面找到价格并返回 JSON，只输出工具调用参数。"defone_step(n=30):lat,tps=[],[]for_inrange(n):t0=time.perf_counter()r=client.chat.completions.create(model="mercury-3",# 模型名与可用区以官方文档为准messages=[{"role":"user","content":PROMPT}],max_tokens=200,temperature=0,)cost=time.perf_counter()-t0 out=r.usage.completion_tokens# 实际输出 token 数lat.append(cost)tps.append(out/cost)# 单次有效吞吐，含网络与排队lat.sort()return{"p50_s":round(statistics.median(lat),3),"p95_s":round(lat[int(len(lat)*0.95)-1],3),"median_tok_per_s":round(statistics.median(tps),1),}print(one_step())

几个地方解释一下。max_tokens=200要贴近你真实场景的输出长度，用默认长输出量出来的延迟没有参考价值。p95用排序后取位，不用均值，是因为 agent 里最慢的那几次会直接决定用户是否放弃。out / cost算的是含网络和排队的有效吞吐，比官方公布的纯推理吞吐低，这才是你能拿去做容量规划的数。temperature=0只是为了让多次调用可比，不保证服务端完全确定。

要把数用起来，再补一步：拿你最近的 20 条 agent 轨迹，统计每步的实际输出长度和步数，乘上量到的 p50 和 p95，得到两条端到端预算线。哪条超了用户耐心，就先优化那一段。

八、小结

扩散解码带来的不是「模型更聪明」，而是「每步更便宜更快」这一件事。对 agent 来说这件事挺关键，因为 agent 的成本和延迟都是被步数乘出来的。

但要记住两个前提：吞吐不等于首字延迟，厂商对比不等于你的场景。真正决定要不要换的，是你在自己任务上量出来的 p95 和单次 run 成本。

文中的模型参数、价格与场景数据均来自上面原文；解码原理部分为通用说明，具体实现与接口以官方文档为准，本文未验证最新版本。