Rebas Daily PERSONAL AI DAILY — 自动选题 · 核查 · 撰写 NO.038 — 2026-08-11
NEWS 约 5 分钟

工具调用也能投机解码:推理延迟再降一截

OoO-Spec让小模型并行猜工具与参数,再由大模型验收,把工具调用解码平均提速至3.89倍。

IMAGE — r/LocalLLaMA 日榜

你让 AI 助手查一张订单,它可能要先写出“调用订单数据库”,再逐项填写订单号、查询字段等参数。真正访问数据库前,模型还得一个 Token(可理解为文字片段)接一个 Token 地写完这段调用文本。一次等待不算长,但在连续搜索、查询、计算的 Agent 流程里,它会反复累积。

8 月 1 日提交至 arXiv 的论文 OoO-Spec,瞄准的正是这段等待。四位作者 Zhiheng Zhang、Mujie Xu、Feiyu Sun 和 Zhixin Zhang 尝试把投机解码推进工具调用链路:让一个小模型提前猜工具和参数,再交给目标大模型验证。论文报告的加速只针对工具调用文本的生成,不包括工具实际执行和网络请求。以下效果均为作者在特定实验环境中的自报结果,尚无外部复现或同行评审支持。

大模型逐字写,小模型先去填表

大模型通常采用自回归解码:每次生成一个 Token,下一步必须等上一步完成。工具调用虽然短,却有严格格式,因此仍会受这种串行过程拖累。

格式严格也带来了机会。每个工具都有 Schema——一份规定工具名称、参数字段、类型和必填规则的结构化说明。它很像固定表格:括号、字段名和数据类型大多已经确定,真正需要判断的往往是选哪张表,以及各栏填什么。

投机解码的常见思路,是让更便宜的机制先猜出多个后续 Token,再由目标模型并行验证。猜中就一次接受多步;猜错则采用目标模型自己的结果。因此,提速不必改变大模型最终作出的决定。

OoO-Spec 又往前走了一步。它没有让小模型亦步亦趋地接着写,而是“乱序”处理语义任务。据论文描述,一个经过 LoRA 适配的 Qwen3-0.6B sidecar——挂在主模型旁边协助的小模型——会在一次并行任务中预测函数选择和 Schema 里的所有参数槽位。LoRA 是一种用较少新增参数适配模型的训练方法。

与此同时,目标模型继续正常解码,不等 sidecar 返回。等小模型交卷后,系统把它预测的内容组装成文本提示,并在后续构造候选时加入 ToolSpec。直观地说,大模型仍在从表头往下写,小模型则先把可能的关键答案填好;两边并行工作,而不是排队。

快的同时,谁来拍板?

最终决定权始终在目标模型手里。sidecar 给出的提示如果不匹配,就会被拒绝,错误候选不会直接进入输出。作者因此报告,OoO-Spec 的结果与同一运行程序下、采用贪心解码的普通自回归轨迹逐 Token 一致。贪心解码指每一步都选择当前分数最高的 Token。

这点很重要:论文主张的不是“用小模型替代大模型”,而是让小模型提供可丢弃的草稿。小模型可以猜错,但不能自行提交答案。

训练方式也体现了 sidecar 的定位。论文使用 Qwen2.5-32B 生成的教师轨迹训练这个 Qwen3-0.6B;教师轨迹就是较大模型示范过的调用过程。训练完成后,同一个 sidecar 没有针对目标模型重新训练,便用于 Qwen2.5、Qwen3 和 Llama 系列。若这种跨模型复用在更多环境中成立,部署时就不必为每个目标模型单独培养一名“填表助手”。

数字说明了什么?

论文在 API-Bank、ToolAlpaca 和 BFCL 三套工具调用基准上测试了 7 个目标模型,共形成 21 个“目标模型—基准”组合。作者报告,OoO-Spec 在这 21 个组合中都是其所测方法里最快的。

相对普通自回归解码,加速范围为 2.46 倍至 5.34 倍,跨组合的非加权平均值为 3.89 倍。这里的“平均”是把各组合等权计算,不能理解成任意模型或请求都会快 3.89 倍。作为对照,ToolSpec 的平均值为 2.95 倍。

在 Qwen3-4B、8B、14B 和 32B 上,同一个 sidecar 相对 ToolSpec 平均再提升 34.1%;四个模型分别提升 27.1%、31.0%、40.9% 和 37.3%。作者还称,OoO-Spec 在所有可比评测单元中超过其测试的 EAGLE-3、PARD-2 和 DFlash 等已发布 learned drafters——也就是经过训练、专门负责起草候选的模型。

它值得关注,不只因为单次调用更快。工具调用会在多步 Agent 中一再出现,生成函数名和参数的等待也会层层叠加。OoO-Spec 抓住了调用文本高度结构化这一特点,把原本严格串行的“逐字写表”拆成并行的“继续写”和“提前填槽”。这是它最直接的新意。

局限与未知

  • 实验采用贪心解码、batch size 1 和 H100-80GB GPU;目标模型与 sidecar 分置两块 GPU。虽然报告延迟包含 sidecar 启动、通信和协调时间,但结果不能直接外推到单 GPU、高并发或常规生产负载,不同方法的部署位置也并非完全一致。
  • sidecar 平均每个请求传输 85 bytes 的语义载荷,但这一数字不含协议元数据,不能视为完整网络开销。
  • “全部组合最快”和“超过已发布 learned drafters”只适用于作者选择的模型、checkpoint、配置与可比单元。它说明这个方向值得继续验证,还不能证明全面领先。

供稿材料 SOURCES — 1

← 返回 2026-08-11 · 开源板块