Meta Data

• 发表时间：2026-04-15（arXiv 首次提交）；2026-04-16（公布）
• 作者：Heming Xia, Yongqi Li, Cunxiao Du, Mingbo Song, Wenjie Li
• 论文链接：https://arxiv.org/pdf/2604.13519.pdf
• arXiv 页面：https://arxiv.org/abs/2604.13519
• 项目链接：https://github.com/hemingkx/ToolSpec

ToolSpec：通过 Schema 感知与检索增强推测解码加速工具调用

摘要

工具调用（tool calling）通过使大语言模型（Large Language Models, LLMs）能够与外部应用交互，极大地扩展了 LLM 的实用价值。随着 LLM 能力不断提升，有效的工具使用 越来越需要多步、多轮交互来解决复杂任务。然而，由此带来的工具交互次数增长会产生显著的推理延迟，成为实时 LLM 服务的一项关键挑战。通过实证分析，我们发现工具调用轨迹高度结构化，遵循受约束的 schema，并且常常表现出重复出现的调用模式。基于这些观察，我们提出 ToolSpec，一种面向加速工具调用的 schema 感知、检索增强推测解码（speculative decoding, SD）方法。ToolSpec 利用预定义的工具 schema 生成准确的草稿，并使用有限状态机（finite-state machine, FSM）在确定性 schema token 填充与针对可变字段的推测生成之间交替进行。此外，ToolSpec 检索相似的历史工具调用并将其复用为草稿，以进一步提升效率。ToolSpec 提供了一种即插即用、无需训练的解决方案，可无缝集成到现有 LLM 工作流中。在多个工具调用基准上的实验结果表明，ToolSpec 最高可实现 4.2\times 加速，显著优于现有无需训练的推测解码方法。我们在 https://github.com/hemingkx/ToolSpec 发布了代码。

引言

大语言模型（LLMs）的最新进展显著拓宽了它们的能力边界，包括开放域对话、数学推理和程序合成等。与此同时，工具调用已成为一项关键能力，使 LLM 能够与搜索引擎、计算器和代码解释器等外部工具交互。通过引入外部工具，LLM 能够缓解独立模型的一些根本局限，包括知识过时和算术错误等。随着 LLM 能力持续改进，工具使用 越来越多地采用多步、多轮、反馈驱动的交互循环来解决复杂任务。

图 1：ToolSpec 示意图。ToolSpec 通过两项创新加速工具调用生成：1）schema 感知草稿生成（schema-aware drafting），其中预定义工具 schema 作为忠实草稿，并支持对受约束变量（例如工具名称）进行并行验证；2）检索增强推测（retrieval-augmented speculation），检索并复用相似的历史工具调用作为高质量草稿。

然而，工具调用频率的不断增长会显著增加推理延迟，给实时 LLM 服务带来重大挑战。近期工作提出了多种加速工具调用的策略。一类研究将工具调用轨迹建模为刻画工具间依赖关系的有向无环图（DAGs），并并行执行彼此独立的工具以降低整体延迟。另一类工作通过在文本生成过程中重叠执行工具调用来提升并行性，即在模型仍在解码时启动工具调用，从而进一步加速端到端工具调用。

尽管这些在加速工具执行方面的工作取得了进展，本文将关注点转向提升工具调用生成的效率。我们的初步分析表明，生成延迟可能成为主导瓶颈：在广泛使用的基准 ToolBench 上，使用 Qwen2.5-14B-Instruct 生成工具调用约占端到端推理延迟的 80\%，并且大约是执行工具所耗时间的 4\times。此外，对于固定工具集和环境，工具执行时间通常相对稳定；而工具调用生成延迟会随模型规模以及生成工具调用序列长度而增长，使其成为许多工具使用场景中的主要延迟来源。

在本工作中，我们提出关于工具调用的两个关键观察：1）工具调用输出高度结构化。 这些输出通常以 JSON 表示，并遵循严格受约束的 schema。因此，在生成的 tokens 中，只有一小部分对应可变字段，其余均由 schema 决定；2）LLM 在不同请求之间表现出重复出现的工具调用模式， 表明存在可复用的结构与语义规律。受这些洞察启发，我们提出 ToolSpec，一种面向加速工具调用的 schema 感知、检索增强推测解码（SD）方法。ToolSpec 利用任务特定的工具 schema 构造高质量草稿序列，并采用有限状态机在确定性 schema token 填充与针对可变字段的推测生成之间交替。此外，ToolSpec 检索相似的历史工具调用并将其复用为草稿候选，从而进一步提升效率。在 API-Bank、ToolAlpaca、BFCLv2 和 ToolBench 等广泛使用的工具调用基准上的实验表明，ToolSpec 最高可实现 4.2\times 加速，并优于现有 SD 方法。

我们将贡献总结如下：

• 我们提出 ToolSpec，一种面向加速工具调用生成的 schema 感知、检索增强 SD 方法。它提供了一种无需训练的解决方案，可无缝集成到现有 LLM 工作流中。
• 在多种模型和任务上的大量实验表明，ToolSpec 稳定实现 3.5\times \sim 4.2\times 加速，相对此前最优 SD 方法最高提升 71\%。
• 进一步分析验证了我们所提出组件的有效性，并揭示了格式遵循度对 ToolSpec 加速效果的影响，表明随着 LLM 能力持续提升，ToolSpec 的效率潜力将进一步释放。

相关工作

高效工具调用

随着大语言模型（LLMs） 越来越依赖多步、多轮工具调用工作流，LLM 服务中的推理延迟显著增长。为应对这一问题，近期研究利用有向无环图（DAGs）建模工具间依赖关系，使彼此独立的 API 调用能够并行执行，从而降低延迟。另一类工作在生成过程中主动执行工具调用，以最小化系统空闲时间。与先前聚焦工具执行的方法不同，本文将注意力转向加速工具调用生成，以进一步提升工具使用型 LLM 的推理效率。

推测解码

近年来，推测解码（SD）已成为加速 LLM 推理的广泛采用范式。在每个解码步，SD 首先生成一段草稿 token 序列，随后由目标 LLM 并行验证。SD 的最新进展，例如 Eagle 系列，在目标 LLM 之上引入轻量草稿模型，取得了有前景的加速效果。尽管这些方法需要额外训练或参数，另一条研究路线聚焦于无需训练的 SD 方法。值得注意的是，Token Recycling 将先前步骤的 top-k 候选 token 存入邻接矩阵，并使用广度优先搜索构造草稿树。类似地，SAM-Decoding 利用后缀自动机，从输入上下文和静态文本语料中高效检索高质量草稿。

预备研究

本节对工具调用生成进行实证分析，涵盖：（i）生成与工具执行之间的延迟分解；（ii）工具调用模式分析。

图 2：Qwen2.5-Instruct 模型系列在 ToolBench 上的延迟分解。工具执行延迟基本保持恒定，而工具调用生成延迟随模型规模增长，最高可达端到端延迟的 96\%。

延迟分解

我们首先分析工具调用中的延迟瓶颈。实验使用 Qwen2.5-Instruct 系列在 ToolBench 上进行。如图 2 所示，工具执行延迟在不同模型规模下几乎保持恒定，而工具调用生成延迟显著增加，对于 Qwen2.5-72B-Instruct 最高占端到端延迟的 96\%。这些结果表明，工具调用生成是工具调用流水线中的主导瓶颈，尤其在多工具、多轮场景中，这凸显了加速生成的重要性。

工具调用模式分析

图 3 展示了来自 API-Bank 的一个工具调用轨迹示例。如图所示，这些轨迹是遵循受约束 schema 的高度结构化 JSON 对象，由以下部分组成：

• schema tokens，例如 name 、 parameters 以及标点符号，它们构成工具调用 schema 所需的固定骨架；
• 工具名与参数名，分别以红色和蓝色高亮，用于指定目标工具及其参数；
• 参数值，以绿色显示，用于根据查询特定内容实例化参数。

这些结构化模式使工具调用生成区别于一般自然语言生成，表明它可以被形式化为受约束解码（constrained decoding）问题。在实践中，有效工具调用必须遵循严格 JSON schema，这意味着输出 tokens 的很大一部分，即 schema tokens，实际上是预先确定的。一旦选定目标工具，其参数名就来自有限、由 schema 定义的集合（例如 user_id 、 time 和 health_data ）。因此，模型只需要生成一小部分 tokens，即参数值，并以用户查询和对话上下文为条件。

图 3：来自 API-Bank 的工具调用轨迹示例，不同字段以颜色高亮显示。

接下来，我们进一步分析 LLM 中实际的工具调用行为，包括 schema 遵循度与重复工具调用模式。

表 1：不同模型的格式遵循度。

Schema 遵循度

如表 1 所示，当前工具使用型 LLM 对工具调用格式表现出很强的遵循性，即其输出可以被可靠解析为有效 JSON。LLaMA-Instruct 和 Qwen2.5-Instruct 两个模型家族在遵循所需工具调用 schema 方面都超过 99\% 的准确率。这一观察进一步支持了我们早先的主张：工具调用生成可以在预定义 schema 下被形式化为受约束解码。鉴于此，为一般文本生成设计的加速方法对于工具调用可能并非最优。相反，显式利用工具调用生成的受约束结构可以带来额外效率收益。

表 2：工具调用基准的数据集统计。

重复工具调用

除 schema 遵循度外，我们还观察到 LLM 频繁调用相同工具以满足重复出现的用户意图和偏好模式。这种行为在广泛使用的工具调用基准中一致出现。如表 2 所示，在 API-Bank 中，对相同工具的重复调用非常频繁，每个工具的平均调用次数超过 10.95。这一观察促使我们利用历史工具调用轨迹。系统不必丢弃先前调用，而是在先前调用仍然有效时复用它们，从而进一步提升工具调用效率。

ToolSpec

本节介绍 ToolSpec，一种用于加速工具调用生成的即插即用 SD 方法。该方法利用工具调用的高度结构化特性以及重复出现的历史模式，以可忽略的开销构造高质量草稿。如图 5 所示，ToolSpec 集成两种互补的草稿策略：schema 感知草稿生成与检索增强推测，下文将详细介绍。

任务形式化

给定用户查询以及包含系统提示和工具文档的输入上下文，ToolSpec 从文档中提取工具规范，并将其转换为结构化 schema。该 schema 定义：（i）schema token 集合 \Sigma_{\text{schema}}；（ii）可调用工具集合 \mathcal{C}_{\text{tools}}（例如 ForgotPassword）；（iii）与每个工具关联的参数字段（例如 Status、Username）。

设 \mathcal{M} 表示目标模型，\boldsymbol{x} 表示输入上下文，\boldsymbol{y} = (y_1, y_2, \ldots, y_L) 表示待生成的工具调用序列。在解码步 t，遵循标准 SD 范式，ToolSpec 首先提出草稿 token 序列 \tilde{\boldsymbol{y}}_{t:t+\gamma-1} = (\tilde{y}_{t}, \tilde{y}_{t+1}, \ldots, \tilde{y}_{t+\gamma-1})，作为后续解码步的预测。目标模型 \mathcal{M} 随后并行验证这些草稿候选，并接受与其概率分布一致的最长前缀。当草稿生成过程的延迟显著低于验证时，最大化 \tilde{\boldsymbol{y}} 的接受长度可以直接提升有效解码并行度，并降低端到端延迟。

图 4：ToolSpec 中状态转移示意图。一旦由 <tool_call> 触发工具调用，FSM 进入工具名状态 q_t，随后在参数名状态 q_p 与参数值状态 q_v 之间交替，直到工具调用完成。

Schema 感知草稿生成

如第 3.2 节所讨论，先进 LLM 的工具调用遵循预定义 schema 格式。这种结构规律性使输出的大部分可以进行确定性草稿生成。为利用这一性质，ToolSpec 根据解析得到的工具 schema 构造有限状态机（FSM）。形式上，FSM 定义为

\mathcal{F} = (\mathcal{Q}, \Sigma_{\text{schema}}, \delta, q_0),

其中 \mathcal{Q} 是状态集合，\Sigma_{\text{schema}} 是 schema token 字母表，\delta: \mathcal{Q} \times \Sigma_{\text{schema}} \rightarrow \mathcal{Q} 是转移函数，q_0 \in \mathcal{Q} 是初始状态。

状态空间 \mathcal{Q} 将工具调用生成过程分解为结构组件：

• q_t：工具名状态，模型从预定义工具集 \mathcal{C}_{\text{tools}} 中选择一个工具。
• q_p：参数名状态，模型为所选工具选择一个参数字段。
• q_v：参数值状态，模型生成所选参数的值。
• q_o：“其他”状态，对应工具调用之外的一般自然语言生成。

图 5：使用 ToolSpec 进行工具调用生成的示意图。为加速结构化工具调用，ToolSpec 集成两种互补草稿策略：（a）schema 感知草稿生成，其中有限状态机在预定义工具 schema 内引导高精度草稿生成；（b）检索增强推测，复用历史生成模式作为高质量草稿，以加速重复出现的工具调用。

如图 4 所示，一旦生成特殊 token <tool_call>，FSM 转移到工具名状态 q_t。在该状态下，通过受约束解码执行草稿生成以构造候选草稿序列。我们将提出的草稿序列 \tilde{\boldsymbol{y}} 形式化为必要结构元素的拼接（记为 \oplus）：

\tilde{\boldsymbol{y}} = \tilde{\boldsymbol{y}}_{\text{prefix}} \oplus \tilde{\boldsymbol{y}}_{\text{tool\_name}} \oplus \tilde{\boldsymbol{y}}_{\text{suffix}}

其中 \tilde{\boldsymbol{y}}_{\text{prefix}} 和 \tilde{\boldsymbol{y}}_{\text{suffix}} 表示与 q_t 关联的 schema 前缀和后缀，\tilde{\boldsymbol{y}}_{\text{tool\_name}} \in \mathcal{C}_{\text{tools}} 表示候选工具名。所有潜在草稿随后由目标模型 \mathcal{M} 并行验证。

验证成功后，FSM 转移到参数名状态 q_p，其中 \mathcal{M} 并行验证与所选工具关联的候选参数名。随后 FSM 转移到参数值状态 q_v。由于参数值通常不受约束，ToolSpec 在此阶段不再施加 schema 约束，而是依赖通用 SD 算法来预测这些可变字段。

之后，FSM 根据 schema 特定分隔符在状态之间转移。例如，分隔符 ", 会终止参数值状态 q_v 并返回 q_p 以处理下一个参数；而分隔符 "}}" 则标记工具调用完成。因此，ToolSpec 能够在结构状态（例如 q_t 和 q_p）的确定性 schema token 填充与开放状态（例如 q_v 和 q_o）的推测生成之间无缝交替。

检索增强推测

虽然 schema 定义了工具调用的结构骨架，并支持对工具名等受约束字段进行局部草稿生成，但可变字段（尤其是参数值）高度依赖输入上下文，无法仅凭 schema 推断。受工具调用中重复模式启发，ToolSpec 引入检索增强草稿策略，在序列层面加速工具调用生成。

表 3：ToolSpec 与先前即插即用方法的推理效率比较。我们报告平均接受 token 数（#MAT）、平均解码速度（tokens/s）以及相对标准自回归解码的墙钟加速比。最优结果加粗，次优结果加下划线。Eagle 系列为需要训练的 SD 方法，仅作参考。

我们维护一个数据存储 \mathcal{H}=\{(\boldsymbol{h}_j, \boldsymbol{y}_j)\}_{j=1}^{|\mathcal{H}|}，其中保存先前成功的工具调用；\boldsymbol{h}_j \in \mathbb{R}^d 表示输入问题 \boldsymbol{x}_j 在其最后一个 token 处的隐藏表示，d 是隐藏维度，\boldsymbol{y}_j 是对应的工具调用输出。给定查询 \boldsymbol{x}_i，我们检索 top-k 个最相似的历史工具调用：

\mathcal{I}_k = \operatorname{Top-K}_{j \in \{1 \ldots |\mathcal{H}|\}} \text{sim}(\boldsymbol{h}_i, \boldsymbol{h}_j)

其中 \text{sim}(\cdot) 表示余弦相似度，\mathcal{I}_k 是检索到的条目索引。给定部分已生成输出 \boldsymbol{y}_{\lt t}，我们通过匹配后缀将其与每个检索到的工具调用 \boldsymbol{y}^{\prime} 对齐：

\boldsymbol{y}_{t-L:t-1}=\boldsymbol{y}^{\prime}_{m-L:m-1}

其中 L 表示后缀长度，m 表示 \boldsymbol{y}^{\prime} 中对应匹配位置。当找到后缀匹配时，ToolSpec 提取后续 n 个 tokens \boldsymbol{y}^{\prime}_{m:m+n-1}，并将这些延续作为草稿。如图 5 所示，若当前后缀与包含 … parameters 的历史调用匹配，则后续 tokens（例如 :{ status : Forgot Password …）会被提出作为草稿候选。直观地说，一旦工具名和键值对已对齐，工具调用剩余结构往往遵循重复模式，因此 \boldsymbol{y}^{\prime}_{m:m+n-1} 是后续值片段的高质量草稿。

实验

实验设置

模型与数据集

我们主要使用 Qwen2.5-Instruct 系列、ToolLLaMA 系列、LLaMA-3.1-8B-Instruct 和 LLaMA-3.2-3B-Instruct 评估方法。评估覆盖四个广泛使用的工具使用基准：API-Bank、ToolAlpaca、BFCLv2 和 ToolBench。这些数据集的更多细节见附录 B.1。

实现细节

检索参数 k 设为 10。对于后缀匹配，我们遵循 PLD，考虑后缀长度 L \in \{5,6,7\}。延续提取使用预定义长度 n \in \{32, 16, 8, 8\}。我们在 ToolSpec 中采用 Token Recycling（TR）作为通用推测策略。遵循先前工作，我们采用推测采样（speculative sampling）作为接受策略，batch size 为 1。更多实现细节见附录 B.2。

基线方法

我们主要将 ToolSpec 与三种现有即插即用方法比较：PLD、TR 和 SAM-Decoding（SAMD）。对于 SAMD，我们从输入上下文构造静态 SAM，并采用 TR 作为其解码策略。为便于比较，我们还在主要结果中加入需要训练的高级方法 Eagle-2 和 Eagle-3。

图 6：ToolSpec 与先前即插即用方法在 ToolBench 上的加速比比较。

评估指标

我们使用三个广泛采用的指标评估 ToolSpec：平均接受 token 数（#MAT）、吞吐量（tokens/s）以及相对标准自回归解码的墙钟加速比。从理论角度看，ToolSpec 保持目标 LLM 的输出分布，因此无需对生成质量进行大量评估。不过，我们仍在附录 B.3 中报告 API-Bank 和 ToolAlpaca 上的性能以供参考。

主要结果

表 3 比较了 ToolSpec 与先前即插即用方法在广泛使用的工具使用任务上的推理效率。结果揭示以下关键发现：（1）ToolSpec 稳定优于现有方法，在多种模型和任务上相对标准自回归解码实现 3.5\times \sim 4.2\times 加速。与此前最优方法相比，其相对加速提升最高达 71\%（从 2.45\times 到 4.19\times）。（2）ToolSpec 的效率收益主要来自较高的接受 token 数（记为 #MAT），在不同设置下范围为 4.02 到 5.80。与 Eagle-3 等基于模型的 SD 方法不同，ToolSpec 不需要额外草稿模块，且仅引入很小的草稿开销（约 6\%，如图 11 所示）。这一低开销使更高的 #MAT 能更有效地转化为端到端加速。

关于 Eagle 表现的讨论

我们观察到，如表 3 所示，Eagle 系列达到的 #MAT 低于 TR 等先前即插即用方法。我们假设这一差距源于 Eagle 模型未在工具调用格式上训练，使此类输入对这些模型而言属于分布外（out-of-distribution）。相比之下，如第 3.2 节所讨论，工具调用轨迹表现出结构规律性和重复调用模式。这些性质有利于 TR 等利用历史轨迹构造草稿序列的 SD 方法。基于这一洞察，ToolSpec 利用工具调用任务的 schema 约束特性，实现更准确的草稿生成，并获得更高整体效率。

ToolLLaMA 上的结果

除通用 LLM 外，我们还在 ToolLLaMA 的两个变体上进一步评估 ToolSpec，该模型专门针对工具使用任务训练。图 6 展示了 ToolSpec 与先前即插即用 SD 方法在 ToolBench 上的推理效率比较。结果表明，ToolSpec 相对标准自回归解码实现约 3.7\times 加速，证明了其在专用工具使用型 LLM 上的有效性。

分析

图 7：在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 时，前两个解码步的接受 token 长度分布。绿色三角表示均值，黑色菱形表示离群点。

本节对 ToolSpec 进行全面分析。具体而言，我们评估其有效性（§6.1），考察对工具调用格式的遵循度影响（§6.2），并分析不同模块的时间分配（§6.3）。

ToolSpec 的有效性

图 8：重复工具调用的平均接受 token 数（#MAT）与加速比。结果在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 获得。

统计分析

我们首先进行统计分析以评估所提出模块的有效性，包括：1）Schema 感知草稿生成。 图 7 报告了前两个解码步的接受 token 长度，分别对应 ToolSpec 中的工具名状态 q_t 和第一个参数名状态 q_p。如图所示，schema 感知草稿生成使 ToolSpec 在这两个步骤中平均生成 19.3 个 tokens。相比之下，TR 等先前方法平均生成 8.5 个 tokens，而 Eagle-3 平均仅 2 个 tokens，等同于标准自回归解码。这些结果展示了 schema 感知草稿生成在工具调用生成中的明显优势。2）检索增强推测。 图 8 展示了重复工具调用的 #MAT。结果表明，ToolSpec 稳定优于先前方法，每个解码步平均接受 9.3 个 tokens，并实现约 5.5\times 加速。这一改进凸显了所提出检索策略在处理重复工具调用时的有效性。

图 9：在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 时的接受 token 长度分布。为便于可视化，超过 17 的值被截断。

接受长度分布

图 9 展示了 ToolSpec 与先前方法的接受 token 长度分布。现有方法通常产生少于 8 个 tokens 的接受长度，而 ToolSpec 将分布推向更长接受长度，其中 22\% 的解码步超过 8 个 tokens。此外，ToolSpec 表现出明显的长尾分布：近 4\% 的解码步达到 17 到 33 之间的接受 token 长度。这种长尾行为来自检索增强推测，它复用历史工具调用轨迹以产生更长、更准确的草稿。这些 持续更高的接受 token 长度贡献了 ToolSpec 的整体加速效果。

表 4：ToolSpec 模块的消融实验。“SAD”和“RAS”分别表示 schema 感知草稿生成和检索增强推测。结果在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 获得。

消融实验

表 4 展示了 ToolSpec 及其提出组件的消融实验。结果表明，schema 感知草稿生成和检索增强推测对 ToolSpec 的效率都至关重要。当移除这些组件后，ToolSpec 类似于 PLD，依赖输入上下文内的后缀匹配，得到的加速略高于 TR。

图 10：不同模型在工具调用生成中的格式遵循度。结果在 API-Bank 上获得。

格式遵循度的影响

除第 3.2 节分析外，我们进一步评估工具使用型 LLM 在工具调用生成过程中对所需 schema 的严格遵循程度。我们使用两个标准定义严格格式遵循度：1）输出必须能够被正确解析为有效 JSON；2）任何多余的自然语言、Markdown 围栏、类 XML 标签或畸形 JSON 结构都视为违规。结果显示，格式遵循度与 ToolSpec 实现的加速之间存在强正相关，Pearson 相关系数约为 0.90。值得注意的是，LLaMA-3.1-8B-Instruct 达到最高遵循分数 0.997，对应在 API-Bank 上 4.45\times 加速。

图 11：LLM 响应查询时各操作的时间分配。结果在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 获得。

时间分配

图 11 展示了 ToolSpec 主要延迟密集型组件的时间分配。如图所示，目标模型的解码阶段主导整体延迟，占总运行时间的 91.0\%。相比之下，ToolSpec 引入的额外操作，包括 top-k 检索和草稿树构造，仅带来适度开销，只占总延迟的 5.7\%。尽管开销很小，ToolSpec 仍在工具调用生成中实现约 4\times 加速，证明了其在降低端到端延迟方面的有效性。

结论

本文提出 ToolSpec，一种面向加速工具调用生成的 schema 感知、检索增强推测解码方法。它不需要额外训练或辅助模型，可无缝集成到现有 LLM 工作流中。在多种 LLM 和工具使用基准上的大量实验表明，ToolSpec 在保持输出分布的同时实现 3.5\times \sim 4.2\times 加速。进一步分析凸显了所提出组件的有效性，以及格式遵循度对 ToolSpec 效率的影响。我们希望本工作推动 LLM 中高效工具使用的发展，并为可扩展的工具调用生成提供实践洞察。

局限性

由于计算资源限制，我们的实验未包含更大规模语言模型，例如 Qwen2.5-72B-Instruct 和 LLaMA-3.1-70B-Instruct。不过，我们预期 ToolSpec 能够很好地泛化到这些模型，并在工具调用生成效率上取得进一步提升。我们在附录 B.6 中给出了 Qwen2.5-32B-Instruct 的实验结果。此外，我们的方法假设对预定义工具 schema 有较强遵循性，并存在重复调用模式；这与频繁使用工具的真实应用场景一致。如第 3 节和第 6.2 节所讨论，我们预期随着 LLM 能力持续提升，ToolSpec 的有效性将进一步增强。

伦理声明

我们实验中使用的数据集均已公开发布，并通过英文人机交互进行标注。在该过程中，用户隐私受到保护，数据集中不包含个人信息。我们使用的科学制品均可在宽松许可下用于研究。本文对这些制品的使用与其预期用途一致。因此，我们认为本研究工作符合 ACL 的伦理标准。

附录 A：ToolSpec 细节

本节提供 ToolSpec 的细节，包括并行验证的实现以及详细算法。

并行验证

遵循先前工作，ToolSpec 采用基于树的注意力机制并行验证多个候选草稿序列。具体而言，候选草稿被压缩为单一扁平序列并输入目标模型 \mathcal{M}。模型随后使用树结构注意力掩码，通过单次前向传播同时验证所有草稿序列，如图 1 所示。

为支持不同草稿策略，ToolSpec 采用两类草稿树架构：（1）静态树。 对于开放状态（例如 q_v 和 q_o），ToolSpec 采用通用 SD 策略（例如 TR）进行文本生成，其中使用预定义静态树架构进行草稿生成；（2）动态树。 对于结构状态（例如 q_t 和 q_p）以及检索增强推测，ToolSpec 构造适应各草稿序列长度的动态树掩码，从而减少不必要的验证计算。

算法

我们在算法 1 中给出 ToolSpec 的伪代码。具体而言，在每个解码步，ToolSpec 检查当前后缀是否与历史调用中的任何序列匹配。若找到匹配，则提取其延续作为高质量草稿；否则，ToolSpec 使用有限状态机（FSM）引导 schema 感知草稿生成，从而加速工具调用生成。

算法 1：使用 ToolSpec 进行工具调用

输入：目标模型 \mathcal{M}；输入查询 \boldsymbol{x}；工具文档 \mathcal{D}；历史数据存储 \mathcal{H}=\{(\boldsymbol{h}_j,\boldsymbol{y}_j)\}_{j=1}^{|\mathcal{H}|}；参数 k。

输出：生成的工具调用序列 \boldsymbol{y}。

1. 将文档 \mathcal{D} 解析为 schema \mathcal{S}
2. 由 \mathcal{S} 构造 FSM \mathcal{F}=(\mathcal{Q}, \Sigma_{\text{schema}}, \delta, q_0)
3. \boldsymbol{y} \leftarrow \emptyset，q \leftarrow q_0
4. 计算查询表示 \boldsymbol{h}_x
5. 检索历史调用 \mathcal{I}_k \leftarrow \operatorname{Top-K}_{j} \text{sim}(\boldsymbol{h}_x,\boldsymbol{h}_j)
6. 当 NotFinished(q,\boldsymbol{y}) 时循环：
   • // 检索增强推测
   • \mathcal{B}_{\text{retrieval}} \leftarrow \text{SuffixMatch}(\boldsymbol{y}, \{\boldsymbol{y}_{j}\}_{j \in \mathcal{I}_k})
   • 若 \mathcal{B}_{\text{retrieval}} \neq \emptyset：
     • \mathcal{B} \leftarrow \mathcal{B}_{\text{retrieval}}
   • 否则：
     • // Schema 感知草稿生成
     • \mathcal{B} \leftarrow \text{SchemaAwareDraft}(q,\mathcal{S},\boldsymbol{y})
   • // 使用树注意力打包序列
   • (\boldsymbol{z},\mathbf{A}) \leftarrow \text{PackDraftsAsTree}(\mathcal{B})
   • \hat{\mathcal{B}} \leftarrow \text{Verification}(\mathcal{M}, \boldsymbol{x}, \boldsymbol{y}, \boldsymbol{z}, \mathbf{A})
   • (\tilde{\boldsymbol{y}}^{\star},\ell) \leftarrow \text{SelectLongestAcceptedPrefix}(\hat{\mathcal{B}})
   • \boldsymbol{y} \leftarrow \boldsymbol{y} \oplus \tilde{\boldsymbol{y}}^{\star}_{1:\ell}
   • // 更新 FSM 状态
   • q \leftarrow \delta(q, \tilde{\boldsymbol{y}}^{\star}_{1:\ell})
7. 返回 \boldsymbol{y}

附录 B：实验细节

本节给出实验细节，包括数据集描述、实现细节、扩展结果以及补充主要发现的额外分析。

数据集

我们的评估涵盖四个广泛使用的工具使用基准，评估数据细节如下：

• API-Bank：一个三级评估框架，包含 73 个多样化 API。它通过自然多轮对话，在不同难度级别上评估 LLM 选择与调用工具的能力。
• ToolAlpaca：用于评估 LLM 通用工具使用能力的基准。评估数据集包含两个子集：（i）包含 10 个合成工具的模拟子集；（ii）包含来自不同领域 11 个 API 的真实世界子集。
• BFCLv2：覆盖广泛场景的综合基准，包括单步推理、多步工具使用、实时执行等。我们在单函数和多函数设置下评估 ToolSpec。
• ToolBench：一个大规模高质量基准，通过 ChatGPT 自动构建，覆盖 16,464 个真实世界 API 的多工具、多轮交互。我们在其单工具子集上评估 ToolSpec。

实现细节

检索参数 k 设为 10，即每个检索步保留 top-10 候选。对于后缀匹配，我们遵循 PLD，考虑后缀长度 L \in \{5,6,7\}，并采用最长优先策略（从 7 到 5）。一旦找到匹配，我们按顺序提取匹配后缀后的延续，使用预定义长度 n \in \{32, 16, 8, 8\} 构造草稿候选。我们在 ToolSpec 中采用 Token Recycling（TR）作为通用推测生成策略。所有实验使用 PyTorch 2.5.1，在 2 块 NVIDIA A100-PCIE GPU（40GB）和 40 个 CPU 核心、CUDA 12.4 环境下进行。我们的方法和所有基线的推理均使用 Hugging Face transformers 包完成。遵循先前工作，我们采用推测采样作为接受策略，batch size 为 1。

性能比较

表 5：ToolSpec 与标准自回归解码在不同模型、两个广泛使用的工具使用基准上的性能比较。

表 5 展示了 ToolSpec 与标准自回归解码在 API-Bank 和 ToolAlpaca 上不同模型的准确率比较。结果表明，ToolSpec 保持自回归解码的原始性能，在多种模型和数据集上实现 持续可比的准确率。Qwen2.5-14B 在 ToolAlpaca 上观察到的轻微差异可归因于 fp16 精度。

ToolSpec 中的超参数

表 6 和表 7 展示了 ToolSpec 在不同超参数设置下的加速，包括延续长度和检索参数 k。评估在 API-Bank 训练集采样的 100 个实例上进行。表 6 表明，较短的延续长度（例如 \{16, 8, 4, 4\}）会导致次优的 #MAT 和加速。尽管更长的延续长度（例如 \{64, 32, 16, 8\}）会略微提升 #MAT，但也会引入额外计算开销并降低整体加速。因此，我们在实验中采用 \{32, 16, 8, 8\} 的延续长度。我们进一步将该设置与统一延续长度 \{16, 16, 16, 16\} 比较，结果表明为排名更高的候选分配更长延续带来更大收益。类似地，表 7 表明将检索参数 k 设为 10 在我们的实验中取得最佳加速。

表 6：ToolSpec 在不同延续长度下的加速。结果在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 获得。

表 7：ToolSpec 在不同检索参数 k 下的加速。结果在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 获得。

内存开销

ToolSpec 引入的额外内存开销较小。主要持久成本来自输出内存（output memory），它存储每个输入问题的隐藏状态，以及每个记忆样本对应的输出 tokens。在 API-Bank 上，597 个条目仅需 4.9 MB 内存，约合每个条目 0.0082 MB。为支持更大数据集，ToolSpec 可以维护固定大小的记忆库，例如 1,000 个记忆样本，从而在保留检索增强推测收益的同时限制输出内存。我们将此类内存管理策略的设计留作未来工作。

表 8：使用 Qwen2.5-32B-Instruct 在 API-Bank 上，ToolSpec 与先前即插即用方法的加速比较。最优结果加粗，次优结果加下划线。

图 12：ToolSpec 相对先前最优方法的相对加速提升。结果在 API-Bank 上使用 Qwen 系列获得。

Qwen2.5-Instruct-32B 上的结果

表 8 比较了在 API-Bank 上使用 Qwen2.5-32B-Instruct 时，ToolSpec 与先前即插即用方法的加速。结果表明，ToolSpec 优于这些基线，并相对标准自回归解码最高实现 3\times 加速。图 12 显示，ToolSpec 相对最强复现基线的相对加速增益随模型规模增大而增大。这些结果表明，ToolSpec 能良好扩展到大模型规模，并相对现有即插即用方法提供 越来越明显的效率收益。

图 13：在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 时，相似用户查询下 ToolSpec 的案例研究。

图 14：在 LLaMA-3.1-8B-Instruct 上，不同工具参数值场景下 ToolSpec 的案例研究。

案例研究

图 13 展示了在 API-Bank 上使用 LLaMA-3.1-8B-Instruct 时，当前用户查询与历史观察查询相似的一个 ToolSpec 案例。如图所示，ToolSpec 首先应用 schema token 填充生成所需工具名和 schema 约束 tokens，随后检索高度相似的历史工具调用，并将其延续复用为草稿 tokens，在后续解码步中最高接受 33 个 tokens。该案例展示了 schema token 填充与检索增强推测的有效性。

类似地，图 14 展示了一个用户查询相似但工具参数值不同的案例。ToolSpec 将先前输出的延续复用为草稿 tokens，在第三个解码步接受 16 个 tokens，随后修正用户特定的出行信息，并通过通用推测生成完成工具调用。该案例凸显了 ToolSpec 在重复工具调用场景中的优势：大部分 tokens 可由历史调用草稿生成，而目标 LLM 专注于关键参数值。