很多团队把函数调用接进推理服务后最先看到的是模型更能干了。⚠️ 可上线几天后首 Token 变慢吞吐下降普通问答也被拖累。真正的损耗通常不在工具执行而在模型还没决定要不要调工具前解码链路已被更重的约束状态机接管。更隐蔽的是请求类型已分化调度器却仍把它们当成同一种流量。 普通问答只要连续生成函数调用请求却要维持tool schema、参数闭合和回退分支。若共用同一批次和热路径轻请求就会被重请求拖住。图 1函数调用的代价常在模型决定之前就已经发生函数调用为什么会把普通解码链路拖重函数调用模式一旦开启解码器就不再只追求“下一个 token 概率最大”。 它还要判断是否允许输出工具名、是否必须进入 JSON 参数区、是否需要在非法字段出现时回退重采样。约束越严格掩码和校验越多kernel外的控制逻辑也越厚。很多团队误以为工具调用慢是因为外部 API 慢。 更常见的情况是哪怕工具没被调用只要请求被标记为tool enabled它就带着更长的前处理和更复杂的解码状态进入批次。结果是工具命中率不高系统却提前为所有请求支付了约束成本。✅图 2真正变重的是解码状态机而不只是工具执行时间一组压测把工具价值和调度代价拆开看这次回放了40路混合流量其中25%请求允许函数调用但真实工具命中率只有11%。 基线方案是纯文本解码方案二对所有请求统一开启严格tool choice方案三只给高置信度请求进入工具批次并设置回退预算。结果说明少量工具请求就足以拉低整池效率。⭐方案首 Token 延迟吞吐工具命中率无效参数率纯文本解码388 ms91 token/s0%0%全量严格 Tool Choice471 ms74 token/s11%4.8%分层门控 Mixed Decode409 ms86 token/s10.6%1.2%该看的不是“工具能不能用”而是“有多少请求值得进入重路径”。️ 当调度器先做意图门控把普通回答和工具回答拆进不同批次再给工具请求设置失败回落预算性能和可用性才会一起稳定。defroute_request(intent_score,tool_required,queue_depth):iftool_required:returntool_batchifintent_score0.72:returntext_batchifqueue_depth32:returntext_fallbackreturntool_batch图 3先分流再约束比全量重解码更稳工程上真正该补的是 Mixed Decode 契约更稳的做法是把函数调用视为一类独立服务等级而不是普通文本生成的附加选项。️ 请求进入系统后先做工具意图判定再把tool enabled、tool required和text only分成三档只有前两档挂上结构化约束和参数验证。这样既能保住工具能力也能避免普通问答被无谓拖慢。另一层不能省的是回退与审计。⏱️ 当工具批次排队过深、参数多次闭合失败或下游工具不可用时系统要明确退回纯文本回答并把tool miss reason、重采样次数和回退延迟打进监控。笔者认为竞争点不是谁接了更多工具而是谁能把重路径稳定隔离在少量高价值流量里。图 4函数调用要想跑稳核心不是多接工具而是把重路径隔离出来未来 3 到 6 个月 函数调用会从能力展示转向成本治理一句话总结函数调用真正拖慢推理服务的往往不是调用那一下而是所有请求都提前背上了工具约束。 只要把Tool Choice从全局默认改成按意图启用再补上Mixed Decode调度和回退预算系统才能把工具能力变成收益。你们的推理网关已经把工具请求和普通文本请求分池了吗