vLLM 工具调用不准，病灶在解析这一层

同一份开放权重模型，换一家推理服务商跑，agent 的成功率就掉了——很多人第一反应是模型不行，其实引擎的锅不少。

一、发生了什么

Ubicloud 的两位工程师 10 月 20 日发文复盘了这问题。他们用 vLLM 服务 Kimi K2.6 时，发现工具调用符合预期格式的比例只有 92%——平均每 25 次调用就有 2 次格式是坏的。对多轮 agent 来说，坏调用会产生报错信息污染上下文，模型接着在垃圾上下文上继续推理，质量滑坡，还得多花重试的钱。

根子在生成机制本身。模型是按概率挑下一个 token 的，它不是编译器，也没有类型检查。哪怕提示词写得再清楚，它也可能生成训练时见过的工具名或字段名，而不是当前环境里真实存在的那个——比如环境里叫检索的函数，它偏偏用了训练数据里另一个写法。

修复靠的是受限解码：推理引擎在每一步采样时，只放行符合工具 schema 的 token，不合法的路径直接被屏蔽。模型仍然自己决定「做什么」，但「怎么写」被运行时锁死。实现层面借的是一个开源结构化生成库的「结构化标签」机制：先按工具的格式定义出合法路径——开始调用、工具名、序号、参数、结束——再在生成时逐步做遮罩，比如到了序号阶段就只允许整数 token 通过。由于遮罩可以预先计算、在显卡上高效施加，官方称这套运行时保障几乎不付出性能代价。这个特性先进入 vLLM 的代码，之后以服务端开关的形式发布，开启后 Ubicloud 测得格式符合率从 92% 升到 100%，覆盖 Kimi 和 DeepSeek 的新模型。

二、跟你有什么关系

自建推理服务的人：模型分数和你的线上表现之间隔着一个引擎配置层，跑 agent 业务前先把这一层校准，比换模型便宜得多。

用第三方 API 的：服务商没开格式约束的话，你多付的是隐形重试成本，可以用小流量对照测试再决定留在哪家。

模型评测者：跑分前先确认推理配置和官方一致，否则测出来的差距可能是引擎造成的，与模型无关。

三、怎么排查

1. 先跑格式符合率测试。Moonshot 发布的厂商验证基准专门测这个，2000 条请求，分「何时触发调用」和「格式是否合规」两个维度。
2. 查引擎版本和开关。格式约束相关的能力在 vLLM 新版里以服务端标志提供，确认自己有没有开。
3. 注意默认值。因为要兼容大量模型，vLLM 后来把默认行为改回了不开启——部分模型开启会出问题，需要用严格级别标志手动打开。
4. 改完重跑基准，验证达标再上生产。

四、三个别信的说法

模型官方榜单分高，服务质量就一定高。 榜单分是模型能力，格式符合率还取决于引擎解析层，两者要分开测。

开格式约束没有代价。 对个别模型，强行屏蔽合法路径之外的 token 反而把生成带偏，还出现过约束解码与其他加速特性冲突的缺陷，这也是它没被设为全局默认的原因。

解析层的小错无所谓。 一次坏格式就是一轮报错加一次重试，多轮 agent 里会滚雪球，92% 和 100% 的差距在长任务里被放大得很明显。

五、一句话结论

agent 掉链子时，先别急着骂模型，看看推理引擎有没有把格式这一关守住。

信息来源

• Ubicloud 博客：Fixing Tool-Call Accuracy in vLLM（2026-10-20）

功能与价格以官方公告为准。本文写于 2026 年 10 月 27 日。