Speculative Tool Calls — L2 #

§1 TL;DR #

用小模型提前投机预测 agent 的下一次 tool call 并异步执行，使工具执行与主模型推理重叠。提出 client-side（无需改引擎）和 engine-side（修改 vLLM 保持 KV-cache 驻留）两种方案，client-side 节省 6-21% 端到端时延，理论上界 < 2×；engine-side 额外节省 2-3%。

§2 Q1 · Q2 · Q3 #

Q1 痛点 #

LM agent 每次 tool call 都会打断推理：生成停止 → 序列从 batch 中驱逐 → 客户端运行工具 → 带工具输出重新调度 → 重新 prefill 不断增长的 prompt。这条严格的顺序依赖链引入三类开销：

1. 工具等待时延：生成与工具执行完全串行，agent 在等待工具返回期间推理引擎空闲。
2. 驱逐/重调度开销：序列被移出 active batch 后 KV-cache 可能被淘汰，重新进入时需重新 prefill（即使有 prefix caching 也要付出调度和 cache 管理成本）。
3. 多租户竞争：多个 agent 共享推理引擎时，cache 淘汰更频繁，overhead 被放大。

现有的缓解措施——并行 tool call（模型一次返回多个独立调用）和 prefix caching——只能部分缓解，无法消除顺序依赖本身。

Q2 方法 #

核心思路：将 speculative decoding 的"用小模型投机、大模型验证"范式从 token 级别推广到 tool call 级别。由于 tool call 的时延远大于几个 token 的 decode 时间（毫秒 vs 秒），传统 speculative decoding 只能 overlap 几个 token 的生成——收益微乎其微。本文的关键洞察是：tool 应该尽早投机、尽多投机，而非像 token-level speculation 那样只领先几步。

两个互补方案：

Client-side speculation（Algorithm 2）：在发送 prompt 给主模型 $M$ 的同时，异步发送给 $\lambda$ 个更小更快的投机模型 $S$。$S$ 先返回时提取 tool call 并异步执行工具，结果缓存在 client 端的 tool cache 中。当 $M$ 返回需要同一个 tool call 时，直接从 cache 取结果，跳过等待。优势：完全不需要修改推理引擎或 API，纯 client 侧实现。

Engine-side speculation（Algorithm 5）：在推理引擎内部维护 tool cache。客户端将投机工具执行结果通过 POST /cache-tool-output/{response_id} API 提交给引擎。引擎实现三重优化：

• O1：投机执行工具，掩盖工具时延（与 client-side 同理）
• O2：检测到 tool call 开始时，从 cache 中取 draft tokens 做 speculative sampling 验证，跳过逐 token decode tool call 参数
• O3：检测到 tool call 结束且 cache 命中时，直接将 tool output 注入 KV-cache 继续 decode，避免序列驱逐和重调度

核心技术壁垒：engine-side 的 tool proposer 需要在 token 流中实时检测 tool-call 边界，并在两种 cache lookup 策略之间动态切换——tool-start 时用部分键（tool name）做 early exit speculation，tool-end 时用完整键（name + canonicalized args）做 exact match 注入。这要求深度改造推理引擎的 speculative decoding 基础设施（论文基于 vLLM 的自定义 fork 实现），是复现的主要技术障碍。

Q3 结果 #

• Client-side：在 32 并发 gpt-oss-120b agent、xLAM-2-8B 投机模型的配置下，节省 6-21% 端到端时延（取决于工具时延与主模型生成时间的比值），吞吐量提升最高 +196.4 tok/s。
• Engine-side：在工具时延 < 主模型推理时间的场景下，相比 client-side 额外节省 2-3%（因为省去了驱逐/重调度开销）。
• 商业 API 验证：gpt-5 + gpt-5-nano 的 client-side speculation 中，1 次投机即可获得 ~9.5% 时间节省，额外成本仅 ~$0.025/100 turns（主模型成本的 ~4%）。
• 理论上界：client-side 投机的最大加速比严格 < 2×（Lemma 1 证明），因为只能掩盖生成和工具执行两个阶段中的一个。

§3 架构 / 方法图 #

Client-side 投机流程 #



Paper Figure 2：Client-side speculative tool calling 的时序对比。上方为 baseline（Prefill→Decode→Tool 严格串行），下方为投机方案（投机模型与主模型并行运行，工具执行与主模型生成重叠）。

Client-side 方案的核心是时间重叠：投机模型 $S$ 比主模型 $M$ 更快返回 tool call 预测，工具在 $M$ 还在 decode 的过程中已经异步执行完成。当 $M$ 最终也需要同一个 tool call 时，结果已在 cache 中等待，跳过了工具等待时间。

Engine-side 投机流程 #



Paper Figure 4：Engine-side speculative tool calling 的架构。相比 client-side 增加了三重优化：(1) 保持序列驻留避免驱逐，(2) 通过 speculative sampling 缩短 tool call 参数的 decode，(3) 直接注入 tool output 继续生成。

Engine-side 方案的关键区别在于序列始终驻留在 batch 中——tool call 不再触发驱逐。投机的 tool output 通过 HTTP API 提交到引擎内部的 tool cache，引擎的 tool proposer 在检测到 tool-call boundary 时自动查询 cache 进行验证和注入。

Agent 循环状态机 #

stateDiagram-v2 [*] --> SubmitPrompt SubmitPrompt --> ParallelInference: send to M and S×λ ParallelInference --> SpecModelReturns: S returns tool call SpecModelReturns --> AsyncToolExec: launch tool async AsyncToolExec --> CacheResult: store in tool cache ParallelInference --> MainModelReturns: M finishes decode MainModelReturns --> CacheHit: tool call matches cache MainModelReturns --> CacheMiss: no match CacheHit --> AppendResult: reuse cached output CacheMiss --> RunTool: execute tool (baseline path) RunTool --> AppendResult AppendResult --> CheckDone CheckDone --> SubmitPrompt: more tool calls needed CheckDone --> [*]: task complete CacheResult --> MainModelReturns

Tool cache 约束 #

投机仅适用于无状态、低成本的工具（web search、file read、ls 等）。有副作用的工具（代码执行、文件写入、API 调用改变外部状态）无法安全投机，除非引入 undo/rollback 机制——本文不处理这一场景。

§4 作者证明 #

符号表 #

Symbol	含义	来源
$M$	主模型（大模型）	§3
$S$	投机模型（小模型）	§3
$\lambda$	每轮投机采样数	§3.1
$G$	主模型平均生成时间	§3.1.1
$g$	投机模型平均生成时间	§3.1.1
$T$	平均工具执行时间	§3.1.1
$\alpha$	投机模型 acceptance rate	§3.1.1
$\phi$	prefill 速率 (s/tok)	§3.2.1
$\delta$	decode 速率 (s/tok)	§3.2.1
$X_i$	第 $i$ 轮 prefill token 数	§3.2.1
$R_i$	第 $i$ 轮 reasoning token 数	§3.2.1
$t_i$	第 $i$ 轮 tool call token 数	§3.2.1
$T_i$	第 $i$ 轮工具执行时间	§3.2.1
$o$	API 和驱逐 overhead	§3.2.1
$K$	agent 连续 turn 数	§3.2.1

方程物理意义 #

Client-side 性能模型：$N$ 次请求的标准时间 $T_{\text{standard}} = N(G + T)$，投机时间 $T_{\text{spec}} = \alpha N \max\{G, g + T\} + (1 - \alpha)N(G + T)$。物理含义：投机成功（概率 $\alpha$）时，工具执行与主模型生成重叠，总时间取两者较大值；投机失败时退化为 baseline。

Lemma 1（加速比上界）：$S_{\text{spec}}(\alpha) = \frac{G+T}{\alpha \max\{G, g+T\} + (1-\alpha)(G+T)}$。加速比关于 $\alpha$ 严格递增，最大值 $S_{\max} = \frac{G+T}{\max\{G, g+T\}} \leq 2 - \frac{2g}{G+g+T} < 2$。物理含义：client-side 只能掩盖生成和工具执行中的一个阶段，因此永远无法达到 2× 加速。当 $g \to 0^+$ 时趋近 2×。

Engine-side 性能模型：$T^*_{\text{spec}} = (1-\alpha)2Ko + \phi(X_1 + \sum(t_i + t_{o,i})) + \delta(\alpha K + \sum R_i + (1-\alpha)\sum t_i) + (1-\alpha)\sum T_i$。物理含义：当 $\alpha = 1$ 时，消除所有驱逐 overhead（$2Ko$）、所有工具等待时间（$\sum T_i$）、以及大部分 tool call decode 时间（$\sum t_i - K$ 个 token），仅剩 prefill、reasoning decode 和每轮 1 个 verification token。

6 项检查 #

#	检查项	结果
1	Lemma 1 证明逻辑完整性	✓ 令 $M := \max\{G, g+T\}$，$\Delta := M - (G+T) \leq 0$，分母关于 $\alpha$ 严格递减，加速比严格递增。用 $\max\{a,b\} \geq (a+b)/2$ 建立上界。证明完整。
2	Equation (3) 边界条件	✓ $\alpha = 0 \Rightarrow S = 1$（无加速），$\alpha = 1, g \to 0 \Rightarrow S \to 2$（理论极限），符合物理直觉。
3	Equation (6) 边界条件	✓ $\alpha = 0 \Rightarrow T^*_{\text{spec}} = T_{\text{cached}}$，$\alpha = 1$ 消除所有可投机的开销。
4	投机正确性（无输出变更）	✓ Client-side：cache miss 时退化为 baseline，不影响输出。Engine-side：使用 speculative sampling 验证 draft tokens，拒绝时回退到正常 decode。数学等价性继承自 speculative decoding 的正确性证明。
5	约束条件合理性	✓ 仅投机无状态工具、$g < G$（投机模型比主模型快）、$\alpha > 0$（非零命中率）——三个约束都是实际部署中容易满足的。
6	Speedup model vs 实验一致性	✓ 模型预测最佳 client-side 加速在 $T \approx G$ 时取得——Figure 6 中 tool latency 2.0-2.5s 时间节省最大（~21%），与 gpt-oss-120b 生成时间量级一致。

Agent-specific 检查 #

• Success-rate model：Figure 5 展示 (model size, speculation count, cache hit rate) 的扫描矩阵。沿 model size 轴单调（8B > 3B > 1B），沿 speculation count 轴单调（更多 sample 提高 hit rate），沿 cache hit rate 轴吞吐量单调递增——与理论预测一致。
• Latency budget per turn：$G$ (主模型生成) + $T$ (工具执行) + overhead ($2o$)。论文声明"interactive latency"的条件是 $T < \delta R_i$（工具在 reasoning 期间完成），在 reasoning model 生成数秒 reasoning trace 的场景下合理。
• Failure mode classification：两类失败——(1) cache miss（投机模型预测错误的工具/参数），退化为 baseline 无额外开销；(2) stateful tool（无法安全投机），需人工标注工具为 stateless/stateful。论文方法主要解决 (1) 的效率问题。

§5 实验与数据 #

主要结果：吞吐量提升 #



Paper Figure 1：32 个 gpt-oss-120b agent 使用 vLLM 推理时，投机方案 vs vanilla 的吞吐量对比。在工具时延 ~1.5s 时获得 +196.4 tok/s 的提升。

图中可见投机方案在所有工具时延下都优于 baseline。吞吐量差距随工具时延增大先增后减——符合理论预测的"$T \approx G$ 时最优"。

投机准确率与吞吐量关系 #



Paper Figure 5：不同投机模型的 cache hit rate 与吞吐量关系。xLAM-2-8B 在 1× speculation 时达到 ~80% 命中率；1B 模型通过 9× sampling 将命中率从 ~35% 提升到 ~55%。

关键观察：吞吐量与 $\alpha$ 近似线性正相关（与 Equation 3 一致）。更多投机 sample 对小模型帮助显著——xLAM-2-1B 的 9× 比 1× 命中率提升约 60%——但对 8B 模型提升有限，因为其 1× 准确率已经很高。

理论加速比分布 #



Paper Figure 3：Client-side 加速比的理论分布热力图，横轴 $g/G$，纵轴 acceptance rate $\alpha$，五个 panel 对应不同 $T/G$ 比值。

五个 panel 直观展示 Lemma 1 的含义：(1) 加速比随 $\alpha$ 增大、$g/G$ 减小而增大；(2) $T \approx G$ 时（中间 panel）获得最大加速空间；(3) 即使 $\alpha = 1, g/G \to 0$，加速比也被限制在 2× 以下。这是 client-side 方案的根本局限。

Client-side 时间节省 #



Paper Figure 6：32 个异步 gpt-oss-120b agent 在 1× speculation 下，不同工具时延的 percent time saved。xLAM-2-8B 在 2.0-2.5s 工具时延时节省最多（~21%），短工具（~0.5s）也能节省 ~6%。

该图验证了核心分析预测：最佳收益在 $T \approx G$ 附近（gpt-oss-120b 的 decode 时间约 2-3s）。工具时延过长时，工具执行主导总时间，投机节省的占比下降。

商业 API 成本效益 #



Paper Figure 7：使用 gpt-5-nano 为 gpt-5 投机的成本-收益分析。1 次投机节省 ~9.5% 时间，额外成本仅 ~$0.025/100 turns（主模型成本 $0.606/100 turns 的 ~4%）。

这是生产部署可行性的关键证据：投机模型的推理成本比主模型低一个数量级以上，成本效益比非常高。9× 投机虽然进一步提升时间节省至 ~13.5%，但成本增至 ~$0.23/100 turns（~38%），边际收益递减。

Engine-side vs Client-side 对比 #



Paper Figure 8：1 个异步 agent、xLAM-2-8B 投机时，engine-side 与 client-side 的时间节省对比。工具时延 < 1s 时 engine-side 额外节省 2-3%；工具时延 > 1s 时两者趋同。

Engine-side 的额外收益来自 O2（省 decode tool call tokens）和 O3（省驱逐/重调度开销）。这两项收益的绝对值固定，在短工具场景下占比更大。当工具时延远超主模型生成时间时，工具等待主导总时间，engine-side 的 O2/O3 优势被稀释。注意该实验受限于 vLLM speculative decoding 在 batch > 1 时的高 overhead，仅展示单 agent 结果。

§6 论证链 #

Step	论点	支撑	评注
1	Tool call 引入严格顺序依赖，是 agent 推理的性能瓶颈	§1 问题分析 + §2.1 工具调用机制	行业共识，无争议
2	传统 speculative decoding 不适合 tool-level speculation：draft 仅领先 3-10 tokens，无法掩盖秒级工具时延	§2.2 speculative decoding 背景 + §3 关键差异分析	正确区分了 token-level vs tool-level 的时间尺度差异
3	Client-side speculation 可在不修改引擎的前提下，通过异步投机模型 + tool cache 实现工具执行与生成的时间重叠	Algorithm 2 (§3.1) + Equations 1-3 (§3.1.1)	方法简洁，工程可行性高
4	Client-side 加速比有严格理论上界 < 2×，因为只能掩盖生成和工具执行中的一个阶段	Lemma 1 证明 (§3.1.1) + Figure 3 热力图	证明完整，bound tight
5	Engine-side speculation 通过保持序列驻留 + speculative validation + tool output 注入，额外消除驱逐开销和部分 decode 开销	Algorithm 5 (§3.2) + Equations 4-6 (§3.2.1)	三重优化 O1/O2/O3 各有独立贡献
6	实验验证：client-side 节省 6-21%、engine-side 额外 2-3%、商业 API 仅 4% 成本增加	Figures 1, 5-8 (§6)	与分析模型预测一致；engine-side 受限于 vLLM 实现成熟度

§7 实现 cross-reference #

实现状态 #

论文基于 vLLM 的自定义 fork实现 engine-side 算法，client-side 使用 OpenAI async Python client + asyncio。截至论文发表（2025-12），代码未公开发布。

[实现未公开]

关键实现细节 #

1. Tool cache keying 使用 canonicalized arguments：cache 键不使用原始文本，而是将 tool name + 参数进行规范化（canonicalize），以处理参数顺序不同但语义相同的情况。这是 cache hit rate 不被 trivial 格式差异降低的关键——容易被忽略但直接影响 $\alpha$。
1. Tool proposer 的双阶段 cache lookup：engine-side 的 tool proposer 在 token 流中检测到 tool-call-start token 时，仅用部分键（tool name）查询 cache 以获取 draft tokens 做 early exit speculation；在检测到 tool-call-end token 时，用完整键（name + canonicalized args）做 exact match 以安全注入 tool output。这种分阶段策略平衡了投机的激进性（尽早开始）和正确性（完整匹配才注入结果）。

LLM backbone 要求 #

• 主模型：gpt-oss-120b（120B reasoning model），reasoning trace 持续数秒，为工具投机提供时间窗口。方法对主模型无特殊要求，仅需支持标准 tool calling format。
• 投机模型：xLAM 系列（1B/3B/8B，基于 Llama 的 tool-calling fine-tuning）。8B 模型在 BFCL 上达到 ~80% tool call 预测准确率。也验证了 gpt-5-nano 作为投机模型。
• backbone 敏感性：论文未做跨 backbone 家族的消融（未测试 Qwen/Claude），但方法在架构上对 backbone 无特殊假设。关键依赖是投机模型的 tool call 预测准确率 $\alpha$。