推理服务为什么一接函数调用就开始拖慢吞吐：从 Tool Choice 约束到 Mixed Decode 调度的工程实战

很多团队把函数调用接进推理服务后，最先看到的是模型更能干了。⚠️ 可上线几天后，首 Token 变慢，吞吐下降，普通问答也被拖累。真正的损耗通常不在工具执行，而在模型还没决定要不要调工具前，解码链路已被更重的约束状态机接管。🧠

更隐蔽的是，请求类型已分化，调度器却仍把它们当成同一种流量。🔍 普通问答只要连续生成，函数调用请求却要维持tool schema、参数闭合和回退分支。若共用同一批次和热路径，轻请求就会被重请求拖住。📌

函数调用为什么会把普通解码链路拖重

函数调用模式一旦开启，解码器就不再只追求“下一个 token 概率最大”。🚨 它还要判断是否允许输出工具名、是否必须进入 JSON 参数区、是否需要在非法字段出现时回退重采样。约束越严格，掩码和校验越多，kernel外的控制逻辑也越厚。🧩

很多团队误以为工具调用慢，是因为外部 API 慢。🧪 更常见的情况是：哪怕工具没被调用，只要请求被标记为tool enabled，它就带着更长的前处理和更复杂的解码状态进入批次。结果是工具命中率不高，系统却提前为所有请求支付了约束成本。✅

一组压测把工具价值和调度代价拆开看

这次回放了40路混合流量，其中25%请求允许函数调用，但真实工具命中率只有11%。📊 基线方案是纯文本解码；方案二对所有请求统一开启严格tool choice；方案三只给高置信度请求进入工具批次，并设置回退预算。结果说明，少量工具请求就足以拉低整池效率。⭐

该看的不是“工具能不能用”，而是“有多少请求值得进入重路径”。🛠️ 当调度器先做意图门控，把普通回答和工具回答拆进不同批次，再给工具请求设置失败回落预算，性能和可用性才会一起稳定。📈

defroute_request(intent_score,tool_required,queue_depth):iftool_required:return"tool_batch"ifintent_score<0.72:return"text_batch"ifqueue_depth>32:return"text_fallback"return"tool_batch"

工程上真正该补的是 Mixed Decode 契约

更稳的做法，是把函数调用视为一类独立服务等级，而不是普通文本生成的附加选项。🛡️ 请求进入系统后先做工具意图判定，再把tool enabled、tool required和text only分成三档；只有前两档挂上结构化约束和参数验证。这样既能保住工具能力，也能避免普通问答被无谓拖慢。📦

另一层不能省的是回退与审计。⏱️ 当工具批次排队过深、参数多次闭合失败或下游工具不可用时，系统要明确退回纯文本回答，并把tool miss reason、重采样次数和回退延迟打进监控。笔者认为，竞争点不是谁接了更多工具，而是谁能把重路径稳定隔离在少量高价值流量里。🔁

未来 3 到 6 个月 函数调用会从能力展示转向成本治理

一句话总结：函数调用真正拖慢推理服务的，往往不是调用那一下，而是所有请求都提前背上了工具约束。📍 只要把Tool Choice从全局默认改成按意图启用，再补上Mixed Decode调度和回退预算，系统才能把工具能力变成收益。你们的推理网关，已经把工具请求和普通文本请求分池了吗？