-
Notifications
You must be signed in to change notification settings - Fork 13.4k
tool-call
: Qwen3 Coder chat format support
#15162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Related to #15012 ? |
case COMMON_CHAT_FORMAT_FUNCTIONARY_V3_1_LLAMA_3_1: return "Functionary v3.1 Llama 3.1"; | ||
case COMMON_CHAT_FORMAT_HERMES_2_PRO: return "Hermes 2 Pro"; | ||
case COMMON_CHAT_FORMAT_COMMAND_R7B: return "Command R7B"; | ||
case COMMON_CHAT_FORMAT_QWEN3: return "Qwen3"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I though it is Qwen3 Coder specific format, not all Qwen3 models?
Also check #15019. This seems to be the more proper solution since it basically implements https://huggingface.co/Qwen/Qwen3-Coder-30B-A3B-Instruct/blob/main/qwen3coder_tool_parser.py. It's abandoned for now though. |
FYI, I made some changes to #15019 to make it work properly. No more tool calls in the output and works flawlessly in qwen-code and sst/opencode (a basic hello world program in C test). I've borrowed some things from this PR. 🙂 |
WIP! Will fix #15012 & #15046 when done.
Depends on Minja fixes: #15161
Qwen3 Coder has a weird syntax for tool calls: a Qwen2-esque
<tool_call>\n<function=${fn_name}>...</function></tool_call>
, except the parameters aren't a JSON object. Instead they're a succession of XML-ish parameters:<parameter=${name}>\n${typeof value === 'string' : value : JSON.stringify(value)}\n</parameter>\n
This special treatment of strings technically means it's impossible for the model to output a call argument string that contains the substring
</parameter>
(probably avoided having to train the model to do proper JSON string escapes?). This is quite unfortunate tbh. I don't think we should follow it to the letter. In this PR I'm just constraining the format to be:<parameter=${name}>\n${JSON.stringify(value)}\n</parameter>\n
(that is, string arguments will have quotes and their content will need to be escaped)