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 1mini的 3 倍兼容性 OpenAI API 兼容可直接替换现有调用官方平台之外也上了 OpenRouter、Baseten、Vercel官方还声称它在多项基准上超过 GPT-6 Luna 和 Claude Haiku 5.5同时快 4 到 8 倍。这类横向对比是厂商自述没有第三方复现看的时候当成方向而不是结论。这里要特别注意口径。1068 tokens/秒 是吞吐不是首字延迟。一个模型可以吞吐很高但第一个 token 出来得慢对语音和实时交互来说后者更致命。官方专门有一条产品线 Mercury Voice 强调 TTFATtime 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 clientOpenAI(base_urlhttps://api.inceptionlabs.ai/v1,api_keyYOUR_KEY)PROMPT给出一条浏览器操作在当前页面找到价格并返回 JSON只输出工具调用参数。defone_step(n30):lat,tps[],[]for_inrange(n):t0time.perf_counter()rclient.chat.completions.create(modelmercury-3,# 模型名与可用区以官方文档为准messages[{role:user,content:PROMPT}],max_tokens200,temperature0,)costtime.perf_counter()-t0 outr.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_tokens200要贴近你真实场景的输出长度用默认长输出量出来的延迟没有参考价值。p95用排序后取位不用均值是因为 agent 里最慢的那几次会直接决定用户是否放弃。out / cost算的是含网络和排队的有效吞吐比官方公布的纯推理吞吐低这才是你能拿去做容量规划的数。temperature0只是为了让多次调用可比不保证服务端完全确定。要把数用起来再补一步拿你最近的 20 条 agent 轨迹统计每步的实际输出长度和步数乘上量到的 p50 和 p95得到两条端到端预算线。哪条超了用户耐心就先优化那一段。八、小结扩散解码带来的不是「模型更聪明」而是「每步更便宜更快」这一件事。对 agent 来说这件事挺关键因为 agent 的成本和延迟都是被步数乘出来的。但要记住两个前提吞吐不等于首字延迟厂商对比不等于你的场景。真正决定要不要换的是你在自己任务上量出来的 p95 和单次 run 成本。文中的模型参数、价格与场景数据均来自上面原文解码原理部分为通用说明具体实现与接口以官方文档为准本文未验证最新版本。 
长河君 · 2026/10/23 4:59:54 · 阅读 1.2k Agent 每一步都在等模型：扩散解码快在哪
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 1mini的 3 倍兼容性 OpenAI API 兼容可直接替换现有调用官方平台之外也上了 OpenRouter、Baseten、Vercel官方还声称它在多项基准上超过 GPT-6 Luna 和 Claude Haiku 5.5同时快 4 到 8 倍。这类横向对比是厂商自述没有第三方复现看的时候当成方向而不是结论。这里要特别注意口径。1068 tokens/秒 是吞吐不是首字延迟。一个模型可以吞吐很高但第一个 token 出来得慢对语音和实时交互来说后者更致命。官方专门有一条产品线 Mercury Voice 强调 TTFATtime 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 clientOpenAI(base_urlhttps://api.inceptionlabs.ai/v1,api_keyYOUR_KEY)PROMPT给出一条浏览器操作在当前页面找到价格并返回 JSON只输出工具调用参数。defone_step(n30):lat,tps[],[]for_inrange(n):t0time.perf_counter()rclient.chat.completions.create(modelmercury-3,# 模型名与可用区以官方文档为准messages[{role:user,content:PROMPT}],max_tokens200,temperature0,)costtime.perf_counter()-t0 outr.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_tokens200要贴近你真实场景的输出长度用默认长输出量出来的延迟没有参考价值。p95用排序后取位不用均值是因为 agent 里最慢的那几次会直接决定用户是否放弃。out / cost算的是含网络和排队的有效吞吐比官方公布的纯推理吞吐低这才是你能拿去做容量规划的数。temperature0只是为了让多次调用可比不保证服务端完全确定。要把数用起来再补一步拿你最近的 20 条 agent 轨迹统计每步的实际输出长度和步数乘上量到的 p50 和 p95得到两条端到端预算线。哪条超了用户耐心就先优化那一段。八、小结扩散解码带来的不是「模型更聪明」而是「每步更便宜更快」这一件事。对 agent 来说这件事挺关键因为 agent 的成本和延迟都是被步数乘出来的。但要记住两个前提吞吐不等于首字延迟厂商对比不等于你的场景。真正决定要不要换的是你在自己任务上量出来的 p95 和单次 run 成本。文中的模型参数、价格与场景数据均来自上面原文解码原理部分为通用说明具体实现与接口以官方文档为准本文未验证最新版本。