Tool calling broken

#2
by kbuettner - opened

Tool calling did not work when started using vllm as follows:

vllm serve XYZAILab/XYZ-Aquila-mini -tp 2 --max-num-seqs 12 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --enable-chunked-prefill --enable-prefix-caching --trust-remote-code --max-cudagraph-capture-size 32

Same questions there, if we use sglang (the website setting), models only return "!!!!!" (we have seen this problem in model converging in slime, but this is not the case):

finish_reason: length
tool_calls: None
content: ''
reasoning: '!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...'

Thanks for the feedback. We take this issue seriously and have updated the README with the recommended serving commands and a tool-use example.

We tested the latest Hugging Face checkpoint through the OpenAI-compatible /v1/chat/completions API and verified that tool calls are returned as structured message.tool_calls output. The environments we checked were:

  • SGLang 0.5.14
  • SGLang 0.5.17.dev302+g7c248dd
  • vLLM 0.26.0

In these environments, we could not reproduce the garbled response or missing tool calls.

Recommended SGLang serving command:

python -m sglang.launch_server \
  --model-path XYZAILab/XYZ-Aquila-mini \
  --served-model-name XYZ-Aquila-mini \
  --host 0.0.0.0 \
  --port 8000 \
  --tp-size 4 \
  --mem-fraction-static 0.8 \
  --context-length 262144 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

Recommended vLLM serving command:

vllm serve XYZAILab/XYZ-Aquila-mini \
  -tp 4 \
  --max-num-seqs 12 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --trust-remote-code \
  --max-cudagraph-capture-size 32

Please try again with the latest README example. Make sure the request is sent to the OpenAI-compatible chat completion endpoint and includes the tools field in the payload.

If the issue still persists, could you share the exact engine version, full serving command, request payload, and complete raw response? That should let us reproduce it and narrow down whether the issue is coming from the serving engine, launch arguments, or request format.

Sign up or log in to comment