记一次RooCode 和 vLLM之间的role导致的 400 bad及vLLM(0.15.1)时的合法tool call工具集

搞七捻三
1

搞localllm，想着跟Cline对比下，结果部署了qwen 3 coder后，发现Cline可以继续问答，而RooCode反而持续400，log中恍惚中看到vllm中对role的不支持，

RooCode 发了 tool_choice: “auto”，但 vLLM 没启用自动工具选择，所以直接拒绝。错误里写得很清楚：必须加 --enable-auto-tool-choice 和 --tool-call-parser

于是增加，
–enable-auto-tool-choice
–tool-call-parser qwen3_coder
后面点开vLLM加载qwen 3 coder的脚本，增加这两行参数，Roo问题得到解决，可以继续调用

通过这次调试，也看到了vLLM上当前支持的样式，我本地是用的vLLM 0.15.1

vLLM 在0.15.1支持的合法写法

{
“error”: “KeyError”,
“message”: “invalid tool call parser: qwen (chose from { deepseek_v3,deepseek_v31,deepseek_v32,ernie45,functiongemma,gigachat3,glm45,glm47,granite,granite-20b-fc,hermes,hunyuan_a13b,internlm,jamba,kimi_k2,llama3_json,llama4_json,llama4_pythonic,longcat,minimax,minimax_m2,mistral,olmo3,openai,phi4_mini_json,pythonic,qwen3_coder,qwen3_xml,seed_oss,step3,step3p5,xlam })”,
“invalid_parser”: “qwen”,
“available_parsers”: [
“deepseek_v3”,
“deepseek_v31”,
“deepseek_v32”,
“ernie45”,
“functiongemma”,
“gigachat3”,
“glm45”,
“glm47”,
“granite”,
“granite-20b-fc”,
“hermes”,
“hunyuan_a13b”,
“internlm”,
“jamba”,
“kimi_k2”,
“llama3_json”,
“llama4_json”,
“llama4_pythonic”,
“longcat”,
“minimax”,
“minimax_m2”,
“mistral”,
“olmo3”,
“openai”,
“phi4_mini_json”,
“pythonic”,
“qwen3_coder”,
“qwen3_xml”,
“seed_oss”,
“step3”,
“step3p5”,
“xlam”
]
}

1 个赞
2

是的


  --enable-auto-tool-choice \
  --tool-call-parser hermes \
  --reasoning-parser qwen3 \
3

本地的话其实选择GGUF搭配llama.cpp也很好，vLLM主要还是应用于有并发需求的情景下，本地需要的是吞吐量、Prefill效率、稳定性

4

哈哈，好，这就去下载unsloth的UD_Q6_K，手里刚好也有一批是用llama.cpp起的，只是今天用来验证的恰好是Qwen官方发布的Qwen3_coder_next_FP8

5

感谢大佬，收藏备用