OoO-Spec: Out-of-Order Semantic Speculation for Fast Tool Calling
Zhiheng Zhang, Mujie Xu, Feiyu Sun, Zhixin Zhang
cs.CL
2026-08-02
OoO-Spec 在目标模型旁挂一个冻结的 0.6B 边车,一次性并行预测函数选择和全部参数槽,再渲染成文本塞回目标当草稿;7 个目标 × 3 基准共 21 格全部最快,平均比自回归快 3.89 倍。
让大模型 agent 调一次工具,要生成一段结构化的函数调用:选哪个函数、每个参数填什么值。主流模型还是逐 token 自回归地写这段 JSON,但这里有个浪费。函数的选择和大部分参数值,从用户请求和工具 schema 里基本就能推出来,根本不必一个字一个字地生成。
已有的 ToolSpec 抓住了 schema 这一半:它复用 schema 里写死的 token,再检索历史调用里出现过的片段来加速。它的上限是只能复用「已经存在的东西」。用户发来「下午 3 点和 John 开会,记一下」这样的请求,3 点、John、开会这些请求专属的值既不在 schema 里、也没在历史调用里出现过,ToolSpec 帮不上,目标模型还是得逐字写。
核心观察是:工具调用虽然在文本上按顺序提交,它的语义却不必按顺序算。函数选择和各个参数槽相互独立,可以并行填。
OoO-Spec(Out-of-Order,乱序)在目标模型旁边挂一个 6 亿参数的小模型当 sidecar:Qwen3-0.6B 加一个 LoRA 适配器,只用 Qwen2.5-32B 当老师产生的调用轨迹训一次,然后冻结。请求一到,sidecar 在一次并行的 vLLM 批生成里同时预测函数编号和全部 schema 定义的参数槽(每槽不超过 32 个 token),把这些值拼成一个结构化对象,再渲染成纯 JSON、Markdown、XML(Qwen3 用)等多种文本视图,作为一条「语义提示」。
与此同时,目标模型照常跑它自己的 ToolSpec 解码循环。它在每个候选构造的边界上做一次非阻塞的就绪检查:提示如果算好了,就用目标模型自己的分词器重新分词,塞进候选池当草稿。这里有个关键设计,sidecar 只生成文本、不碰目标的内部状态,所以两者没有共享的模型维度、token id 或隐藏态。这正是它能一个 sidecar 通吃 Qwen2.5、Qwen3、Llama 而不用按目标重训的原因,也是它和 EAGLE 这类要读目标内部态的草稿器的根本区别。目标模型始终是唯一的验证者和提交者,按贪心逐字核对,接受最长匹配前缀、拒掉不匹配的部分,一条错的提示也污染不了输出。
7 个目标模型 × 3 个基准,21 个格子里 OoO-Spec 全部最快。整体相对纯自回归解码加速 2.46× 到 5.34×,不加权平均 3.89×,而 ToolSpec 是 2.95×。
| 目标 | OoO-Spec 整体加速 | ToolSpec 整体加速 |
| Qwen3-4B | 4.46× | 3.51× |
| Qwen3-8B | 4.73× | 3.61× |
| Qwen3-14B | 4.55× | 3.23× |
| Qwen3-32B | 4.75× | 3.46× |
固定同一个 sidecar、把目标从 4B 一路放到 32B,相对 ToolSpec 的提升分别是 27.1%、31.0%、40.9%、37.3%,平均 34.1%。目标越大,相对增益反而越大,因为目标每步验证越贵,sidecar 替掉一次验证就越划算。对比已发布的可学习草稿模型(EAGLE-3、PARD-2、DFlash),在所有可比较的格子里 OoO-Spec 也都领先。
延迟上,目标路径单请求 309.5 毫秒,sidecar 85.0 毫秒,但两者并发,端到端只多了 2.4 毫秒。65.2% 的提示在第一次候选构造前就绪,98.6% 在目标解码结束前就绪,最终 94.6% 被用上。每条请求的语义载荷平均才 85 字节。
agent 每走一步几乎都要发一次结构化工具调用,工具调用就是 agent 推理的成本瓶颈。接近 4 倍的加速,约等于同样的 GPU 时间能多跑近 4 倍的 agent 步数。
对工程落地更关键的是「一个 sidecar 通吃所有目标」。EAGLE 这类可学习草稿器要么得针对每个目标单独训练,要么要读目标的内部隐藏态,部署门槛高。OoO-Spec 的 sidecar 只交换文本、6 亿参数、训一次冻结,新增一个目标模型不用重训草稿器。它付出的代价是把「何时生成提示」和「何时使用提示」解耦:sidecar 慢一点也没关系,只要在目标的某次候选构造前算完就能用上。
最大的工程约束是它需要单独一块 GPU。消融实验里把 sidecar 和目标塞在同一块卡上(colocated),整体加速掉到 3.32× 到 3.54×,已经只比 ToolSpec 高 0.11× 左右,而且 Qwen3-32B 根本塞不进单张 80GB 卡。标题里接近 4 倍的加速,默认你有一块空闲 GPU 给 sidecar。
评测范围也偏窄。所有数字都来自贪心解码、batch size 为 1 的设置。真实在线服务几乎都用动态 batching 和采样,而投机解码方法在 batching 下表现往往不一样,这一点论文没测。sidecar 的训练数据只有 API-Bank 和 ToolAlpaca 两个集、用 Qwen2.5-32B 当老师,换到 schema 差异很大的工具生态能不能保持这个命中率,没有直接证据。论文自己把异构硬件、多目标混部、边缘部署都列为未来工作。最后要强调,这是工具调用专属的加速,不是通用解码加速。