大模型部署后，Agent调用工具总是超时，是我姿势不对吗？

我也遇到过类似情况，本地 vLLM 跑 7B 做 function calling 确实容易卡。你可以先看看是不是每次调用工具时 prompt 里塞了太多历史记录，上下文一长，7B 的推理速度会断崖式下降。另外 vLLM 的 tool parser 有些版本对 Qwen 的 function call 格式支持一般，解析确实会拖后腿。建议先关掉工具调用，只测纯文本生成，看延迟是不是正常，这样能快速定位是模型推理慢还是解析环节有问题。

7B 模型跑 Agent 本身就有点吃力，尤其是工具调用那种需要模型先理解再输出结构化 JSON 的场景，decode 阶段 token 一多就很容易卡到超时。你可以先看看是不是工具定义的 schema 太复杂了，参数一多模型生成 JSON 就容易翻车。另外确认下是不是每次调用都在重新加载或重复推理，vLLM 那边有没有开 prefix caching。我之前把工具描述精简成一句话、参数只留必填项之后，速度直接好了一截。

工具调用慢多半是解析和网络开销，跟max_tokens关系不大。你试试把工具描述精简点，vLLM那版解析确实拖后腿。

vLLM 部署 Qwen2.5-7B 做 Agent 工具调用超时，大概率不是 Function Calling 解析本身慢，而是几个坑叠在一起了。你先把日志打出来看看时间花在哪：是模型首 token 延迟高，还是工具执行完回填后第二轮生成慢。7B 模型如果没开 prefix caching，Agent 每轮都要重新吞一遍 system prompt 加历史，上下文一长直接爆炸。另外 vLLM 默认可能没启用 tool parser，Qwen2.5 的 function calling 需要配 hermes 或 qwen 对应的 parser，否则模型输出的是带特殊 token 的文本，你后端自己解析可能反复重试。还有 max_tokens 调大反而会让模型在工具调用时生成一堆废话，应该限制工具调用轮次的输出长度。建议先单独测一次纯对话的 TTFT，再测一次带工具定义的 prompt 看差多少。如果工具定义特别长，考虑精简 schema 或者用 RAG 先筛工具。数据库查询本身如果慢，那超时是工具端的事，跟模型没关系，加个日志区分开。

你这情况我去年也踩过，当时用 vLLM 跑 Qwen 的 function calling，一调工具就卡成 PPT，后来发现根子不在解析上。本地推理的超时经常是工具返回的数据太大，比如你查数据库直接 select * 出来几万行，模型光是把这些塞进 context 再生成下一步就爆了。你可以先看看超时是发生在模型生成 tool call 那一步，还是工具执行完把结果喂回模型那一步，这两个的锅完全不一样。另外 vLLM 默认的 guided decoding 对 JSON schema 支持有时候会拖慢速度，尤其你 prompt 里工具定义写得特别细的时候，可以试试把 tools 的 description 精简到只留必要字段。还有个小坑是 max_tokens 调大反而可能让模型在无关 token 上瞎耗，不如把 stop token 和 tool_choice 设明确点。建议先用 curl 直接打 vLLM 的 completions 接口，绕开 Agent 框架单独测一次 tool call 的纯推理耗时，这样能快速分清是框架的锅还是模型本身的锅。

这个问题挺典型的，我一开始也踩过类似的坑。你描述的“一调用工具就慢”其实大概率不是 Function Calling 解析本身的问题，Qwen2.5-7B 的 tool call 解析开销远没到几十秒级别。更可能的是 agent 框架在每一轮都把完整对话历史加上工具描述重新塞进 prompt，导致上下文暴涨，prefill 阶段直接拖垮响应。vLLM 默认配置下如果没开 chunked prefill，长上下文首 token 延迟会非常夸张。你可以先打印一下每次请求的实际 prompt token 数，大概率会吓一跳。另外 tool 定义如果写得特别啰嗦，每轮都重复注入，也是隐形杀手。还有一点容易被忽略，就是本地部署时并发没控制好，agent 内部如果有重试或者多工具并行调用，请求会互相抢显存。建议先把工具描述精简，再确认是不是每轮都在重发全量历史，这两个点排查完基本能定位。