Chunlin 的论文科普

为什么你的AI Agent越批量越慢？——推测解码在Agent场景的失效与破局

LLM 与智能体

一个反直觉现象：批量跑Agent，怎么越跑越慢？

做工程的朋友都有个基本常识：批量推理=更快。把几十个请求凑成一批一起送进GPU，利用率上去了，平均每个请求的耗时自然下降。放到大模型推理里，这个规律也一直成立——直到你开始批量跑AI Agent。

你可能听过推测解码（Speculative Decoding）能让大模型推理快2-3倍，原理是先用小模型”猜”后面的token，再用大模型一次性验证，猜对了就赚，猜错了也不影响质量。但当你把几十个Agent任务放一起批量跑时，却发现不仅没加速，反而比一个个跑还慢。

这不是你的配置错了。最新研究发现，现有的推测解码方法在大批次Agent场景下确实会出现严重的速度退化，批次超过32时，速度甚至开始低于普通自回归解码 [1]。换句话说，你以为开了加速挂，实际上踩了刹车。

这到底是为什么？Agent的推理和普通对话到底有什么不一样，能把一个公认有效的加速技术反过来变成减速带？

推测解码本来是怎么加速的？为什么到Agent这儿就不灵了？

要搞懂这个问题，我们得先说说推测解码到底是怎么工作的。

你可以把它想象成一场”猜题+验证”的考试：老师（大模型）出题，学生（草稿模型）先一口气猜好几个答案，老师一次性批改。如果全对，这几个答案就算数，省了一道题一道题等的时间；如果中间猜错了，就从错的那道开始重来——反正也没损失，大不了回到原来的速度。

这个模式在普通对话场景跑得挺好，因为人们说话常有固定搭配和常见表达，猜中的概率不低。后来大家发现Agent场景里重复模式更多，比如工具调用的格式、代码的框架、反思的套话，于是又发展出了专门针对重复序列的方法，比如SuffixDecoding用后缀树缓存历史生成的长序列，在Agent任务上能达到5.3倍的加速 [6]；还有基于时间局部性的层级草稿（Hierarchy Drafting, HD），按”最近用过的最可能再用”的原则分层组织候选token [7]。

这些方法在单请求或小批次下都挺有效，但一批量就翻车。AgentSpec的作者做了系统分析，发现核心瓶颈有两个 [1]：

第一个是高拒绝率。普通对话的语义比较连贯，猜中概率高；但Agent的生成是”跳着来”的——上一段还在调用工具的参数，下一段就开始分析结果，再下一段又写代码了。不同语义阶段的内容混在一起，草稿模型很容易”串台”：比如刚写完工具调用的括号，它就顺着猜下一轮工具调用了，但实际上Agent已经转到结果分析了。批次一大，各种不同阶段的请求混在一起，候选token的来源更杂，猜错的概率就更高。EAGLE-3的拒绝率有53.3%，SuffixDecoding是65.9%，NGram更是高达88.7%——相当于猜十次错八九次，验证的成本都超过猜对省下的时间了 [1]。

第二个是动态token预算利用不足。推测解码每次能猜多少个token是有预算的，预算多了浪费，少了不够赚。现有方法一般给每个请求分配差不多的预算，但Agent任务的”好猜程度”天差地别：有的请求正在生成格式化的工具调用，几乎一猜一个准；有的正在做开放式推理，猜一个错一个。预算给得平均，等于让好猜的请求浪费了潜力，难猜的请求又白耗算力。

当然，实际情况比这个比喻更复杂——拒绝率和预算利用还会互相影响，批次越大，这种低效的叠加效应越明显。

AgentSpec：给推测划边界，给预算算权重

找到了病根，药方就好开了。AgentSpec的核心思路就是一句话：既然Agent的生成是有结构的，那我们就顺着结构来推测，而不是瞎猜。

它有两个核心设计，我们分开说。

第一个叫结构隔离的推测起草（Structure-Isolated Drafting）。你可以理解成：背单词只背同一章节的，而不是从整本词典里乱抽。

Agent的工作流天然是分块的——工具调用是一块，代码生成是一块，结果分析是一块，每一块内部的语言模式高度相似，跨块的话就差很远。AgentSpec要求Agent应用在请求里带上语义结构标识（比如agent_id、query_id、语义块起止标签），服务端用缓存的token-字符串映射加轻量下推自动机实时跟踪当前语义块，只从同一个语义块的历史生成里找推测候选，绝不跨块瞎猜 [1]。

这么做效果有多明显？AgentSpec的拒绝率只有26.4%，比EAGLE-3的53.3%低了一半还多，几乎是猜四个中三个 [1]。拒绝率一降下来，验证的浪费就少了，加速自然就上来了。

第二个设计叫冗余感知的预算分配（Redundancy-aware Budget Allocation）。这就像考试出题：给命中率高的考生多出几道题，给命中率低的少出几道，把有限的出题预算用在刀刃上。

AgentSpec会给每个请求算一个”冗余分数”——大致是历史候选中最常见前缀的共识比例乘以历史支持度饱和项，比例越高，说明这块内容越重复、越容易猜对。然后它按批次总预算和各请求的冗余分数比例来分配推测token的长度：越可能被接受的请求，给的推测预算越多；越可能猜错的，就少给甚至不给，省下来的预算匀给别人 [1]。

这两个设计加起来，效果怎么样？在GPT-OSS-20B模型的代码生成任务上，AgentSpec达到了2.02倍的端到端goodput加速，比最好的基线还高104%——注意，是比基线高一倍，不是比原始速度高一倍。因为有些基线在大批次下反而比普通解码还慢 [1]。在Qwen-3-8B的SWE-Bench任务上也有1.31倍加速，比最佳基线高42% [1]。甚至尾延迟也降了，P90降低1.47倍，P99降低1.39倍 [1]。

消融实验还发现，结构隔离起草的贡献比冗余预算分配更大，但两者结合效果最好 [1]——毕竟先保证猜得准，再谈猜得多，这个顺序很合理。

当然，实际情况比这个比喻更复杂：结构隔离不是简单地按标签分桶，它用了轻量下推自动机来实时跟踪语义块的状态，能处理嵌套结构；冗余分数的计算也考虑了历史支持度的饱和效应，不会因为某段历史特别长就无限加权。

从SuffixDecoding到AgentSpec：Agent推理加速走过的路

把AgentSpec放进推测解码的演进脉络里看，你会发现这其实是一条从”通用”到”Agent专用”、从”单请求优化”到”批量优化”的清晰路径。

最早的推测解码是通用的——不管你是什么任务，都用同一个草稿模型来猜。EAGLE系列、MTP（多token预测）都属于这一类，它们在通用对话上效果不错，但到了Agent场景就水土不服，因为Agent的生成模式和日常对话差太远了 [1]。

然后大家注意到Agent场景有大量重复生成，于是出现了专门利用重复模式的方法。SuffixDecoding用后缀树缓存历史长序列，在Agent基准上达到了5.3倍的单请求加速 [6]；层级草稿（HD）按时间局部性分层组织token源，在不同任务上的加速更稳定 [7]。这些方法已经开始向Agent场景倾斜，但本质上还是单请求视角——它们优化的是”一个请求怎么猜得更快”，没考虑”一批请求怎么一起猜得更高效”。

再往后，系统层面的优化开始关注批量处理。SPIN就提出用多个异构的小草稿模型来处理不同难度的请求，还用流水线把推测和验证阶段重叠起来，在通用场景下达到了约2.28倍的加速 [8]。但它的异构模型选择还是通用思路，没有利用Agent特有的结构信息。

AgentSpec的位置就在这里：它第一次把Agent的语义结构信息直接引入批量推测解码，从”利用重复内容”升级到”利用结构信息”，从”单请求优化”升级到”批次内动态调度” [1]。它不需要额外训练小模型，是模型无关的，只要Agent端能提供语义块标识就能用。

这条路还没走完。从通用到专用，从单请求到大批次，下一步很可能是把Agent的任务规划、工具调用、多智能体协作等更上层的信息也融入推理加速——毕竟Agent的”慢”，从来就不只是生成token慢这么简单。

还没解决的问题：结构从哪来？成本怎么算？

AgentSpec虽然效果不错，但它有一个很实在的局限：它需要Agent应用显式提供语义块的边界信息 [1]。

这说起来简单，做起来不一定容易。你用的Agent框架可能根本没有暴露这些结构标签，或者不同框架的标签格式不一样。作者自己也承认，这需要在Agent和服务系统之间加一个轻量接口，实际部署时可能得做些适配工作 [1]。更麻烦的是，如果Agent的生成结构本身就不清晰（比如完全开放式的推理），那结构隔离的效果自然会打折扣。

所以一个核心的开放问题就是：能不能不用显式元数据，自动从生成内容里提取语义块结构？[1] 这个问题如果解决了，AgentSpec的适用范围会大很多。

再往远一点说，Agent的成本优化远不止推理加速这一件事。

比如有研究发现，任务描述写得越简略，Agent的token消耗反而越高——把完整需求砍成一句干巴巴的用户故事，token消耗平均涨了近30%，因为AI得自己花更多轮次去猜细节、试错 [3]。这和我们直觉里”提示词越短越省钱”正好相反。在96%的缓存命中率下，输入token只占总费用的13%，输出token虽然只占总token数的2.7%，却花了一半以上的钱 [3]。所以想给Agent降本，光在推理层做加速还不够，任务规范怎么写、思考强度怎么调，影响可能更大。

再往上走，多智能体协作的成本控制又是另一回事。有研究把多智能体的联盟选择建模成合作博弈，在合成仿真中发现”全广播”（让所有智能体都参与）的效用只达到最优的38.8%——不是智能体越多越聪明，冗余的智能体反而会因为重复工作、错误传播拖后腿 [5]。一个简单的贪心路由策略，每次只加边际价值最高的智能体，就能达到暴力穷举最优解的99.5%，同时只用约1/4的智能体 [5]。

你看，从底层的推理加速，到中层的任务规范，再到上层的多智能体协作，Agent的成本优化是个全栈问题。AgentSpec解决了批量推理这一层的问题，但往上还有很多层值得挖。

如果你只记住一件事

在大批次Agent场景下，通用推测解码会因为高拒绝率和预算浪费反而越批量越慢，而AgentSpec的破局思路是顺着Agent的结构来，而不是跟它对着干——给推测划上语义边界，让预算流向更容易猜中的请求。

参考文献

  1. AgentSpec: Speculative Decoding for Batch Inference of LLM Agents（arXiv、2026、全文精读）
  2. MOSAIC: Adversarial Co-evolution of Specialist Heuristics and Problem Instances for LLM-based Automated Heuristic Design（arXiv、2026、全文精读）
  3. Can your AI agent be cheaper? Investigating the effects of task specifications on token spend in agentic coding tasks（arXiv、2026、全文精读）
  4. MBA: Multimodal Benchmark and Agents for Real-World Business Ideation（arXiv、2026、全文精读）
  5. Dynamic Coalition Formation and Communication Pricing in Skill-Based Agentic AI Systems（arXiv、2026、全文精读）
  6. SuffixDecoding: Extreme Speculative Decoding for Emerging AI Applications（arXiv (Cornell University)、2024、仅摘要）
  7. Lossless Acceleration of Large Language Models with Hierarchical Drafting based on Temporal Locality in Speculative Decoding（2025、仅摘要）
  8. SPIN: Accelerating Large Language Model Inference with Heterogeneous Speculative Models（2025、仅摘要）