You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clarification request: Qwen enable_thinking setting used for reported ALFWorld results #90
I have a question about the Qwen backend configuration used for the reported results, especially the ALFWorld numbers for Qwen3.6-35B-A3B or Qwen3.5–4B.
In the current released code, skillopt/model/qwen_backend.py appears to only send:
when config.enable_thinking is true. When enable_thinking=false, the request does not explicitly send chat_template_kwargs={"enable_thinking": False}. In that case, the actual thinking behavior may depend on the vLLM server / model chat-template default.
Could you clarify:
For the ALFWorld results reported in the paper for Qwen3.6-35B-A3B, was Qwen thinking mode enabled or disabled?
If it was disabled, did your serving endpoint explicitly force enable_thinking=false, or was it controlled only by the SkillOpt client-side config?
Would you recommend always sending chat_template_kwargs={"enable_thinking": false} when enable_thinking=false to avoid ambiguity across vLLM deployments?
I am asking because local runs can differ substantially depending on whether Qwen reasoning/thinking is enabled by default on the serving side. Explicitly clarifying this would help make the reported Qwen results easier to reproduce.
After checking, our experiments on open-source models are all conducted with enable_thinking=false, that is, Qwen thinking mode is disabled in our reported experimental results.
The serving endpoint is launched with default settings, and we send enable_thinking=false from client side.
SkillOpt doesn't fundamentally prefer reasoning or not. I think it is a choice depending on the situation, a trade-off between performance and optimization budget (slower and more costly when more tokens are generated and evaluated). I think this should be a user-controllable parameter in the framework, and we will adjust our code and give clearer explanation on this afterwards.
Thanks for your question! Also, we plan to conduct relevant experiments with Qwen thinking mode enabled to provide more reference for users — stay tuned!
Hi Yanan (@yanan1116) , here are the corresponding results with Qwen thinking mode enabled:
Benchmark
4B No Skill
4B SkillOpt
35B No Skill
35B SkillOpt
AlfWorld
0.4179
0.7537
0.5970
0.8209
DocVQA
0.8930
0.9011
0.9251
0.9332
OfficeQA
0.2384
0.3488
0.4477
0.4651
SearchQA
0.7100
0.7486
0.7621
0.8157
SpreadsheetBench
0.2071
0.2429
0.4143
0.4214
Overall, the reasoning-enabled version generally performs better than the corresponding reasoning-disabled version. SkillOpt still works when we turn reasoning mode on. We do not tune training hyperparameters in these experiments. For better performance, we have multiple key training configs for user to explore. We may find a more suitable set of training hyperparameters for Qwen with reasoning mode enabled like we do when training neural networks.
Regarding your specific question about ALFWorld, enabling thinking mode does not consistently outperform the non-thinking setting. One possible reason is that the ALFWorld task prompt explicitly requires the model to generate a think tag in its output, which may partially conflict with or interfere with the model’s native reasoning behavior.
Activity
yanan1116 commentedon Jul 2, 2026
raytrun could you take a look at this concern. thanks.
Huangzisu commentedon Jul 6, 2026
Hi Yanan (@yanan1116), sorry for the delay. Here is some clarification:
enable_thinking=false, that is, Qwen thinking mode is disabled in our reported experimental results.enable_thinking=falsefrom client side.Thanks for your question! Also, we plan to conduct relevant experiments with Qwen thinking mode enabled to provide more reference for users — stay tuned!
Huangzisu commentedon Jul 21, 2026
Hi Yanan (@yanan1116) , here are the corresponding results with Qwen thinking mode enabled:
Overall, the reasoning-enabled version generally performs better than the corresponding reasoning-disabled version. SkillOpt still works when we turn reasoning mode on. We do not tune training hyperparameters in these experiments. For better performance, we have multiple key training configs for user to explore. We may find a more suitable set of training hyperparameters for Qwen with reasoning mode enabled like we do when training neural networks.
Regarding your specific question about ALFWorld, enabling thinking mode does not consistently outperform the non-thinking setting. One possible reason is that the ALFWorld task prompt explicitly requires the model to generate a think tag in its output, which may partially conflict with or interfere with the model’s native reasoning behavior.
Add explicit qwen_chat thinking_mode wire policy (#240)