Using Chinese causes its reasoning to completely collapse. And a solution that may be more flexible

#4
by qwased - opened

Using Chinese instructions to ask it to “draw a web animation of a pelican riding a bicycle,” when it realizes the UI needs to use Chinese, it will continuously introduce garbled Chinese characters, ultimately causing its reasoning to completely collapse.

PixPin_2026-09-27_20-03-14
PixPin_2026-09-27_20-05-49

However, since it is an expert-pruned version, this situation is completely understandable. There is a related project developed for Qwen3.8 Flash Next that allows users to decide to temporarily prune away experts that are not needed, and to hot-recover after incorrect pruning causes the reasoning to collapse. I haven't tested this approach, but perhaps it is a bit more flexible than directly pruning the model's weights.

https://www.bilibili.com/video/BV1RFt66kE3j/
https://huggingface.co/ranxianglei/Qwen3.8-Flash-Next-W4A16-Modular
https://github.com/ranxianglei/sglang-expert-profile/blob/main/README.md

qwased changed discussion title from Using Chinese with this model causes its reasoning to completely collapse to Using Chinese with this model causes its reasoning to completely collapse. And also a solution that may be more flexible than pruning the weights.
qwased changed discussion title from Using Chinese with this model causes its reasoning to completely collapse. And also a solution that may be more flexible than pruning the weights. to Using Chinese causes its reasoning to completely collapse. And a solution that may be more flexible
IST Austria Distributed Algorithms and Systems Lab org

Yes, that is actually expected behavior. Any capability that was not explicitly considered when selecting the experts may be partially or fully degraded, including multilingual capabilities. Please let us know which capabilities you think are particularly important for a coder model to preserve. For example, we added vision after observing that the model was failing a significant number of coding tasks that required visual understanding. Interestingly, after incorporating that capability into the expert-selection process, we did not observe any noticeable degradation in coding performance. This suggests that there may still be room to preserve additional capabilities without sacrificing the model’s core coding abilities.

However, since it is an expert-pruned version, this situation is completely understandable. There is a related project developed for Qwen3.8 Flash Next that allows users to decide to temporarily prune away experts that are not needed, and to hot-recover after incorrect pruning causes the reasoning to collapse. I haven't tested this approach, but perhaps it is a bit more flexible than directly pruning the model's weights.

Thanks for sharing this. Expert pruning is a fairly complex problem and we would really like to use feedback from the community, both failures and successes, to better understand the trade-offs of our approach and improve future models accordingly. For instance, one issue we have already noticed is that long-context performance is somewhat degraded compared with the unpruned IQ3_S model and we are currently investigating ways to improve it. Similar reports about other affected capabilities would be extremely valuable to us.

Given the complexity of real-world work, perhaps a fixed expert-pruning scheme can only be used when the work content and processes are completely fixed; otherwise, sporadic reasoning collapses will always be a sword of Damocles hanging overhead.

IST Austria Distributed Algorithms and Systems Lab org

I understand that concern and that’s exactly why community feedback is so valuable for us.

That said, we do try to make the expert selection generalize beyond the specific calibration set. The selection procedure is designed to avoid overfitting to individual calibration examples and instead preserve behavior across related domains.

For example, the unpruned IQ3_S model is intended for general-purpose use. During pruning, we do not optimize or modify the remaining weights at all and the only thing that changes is which experts are retained. This is quite different from directly optimizing the weights for a particular domain, where there is a much greater risk of specializing to that distribution and losing performance elsewhere.

Of course, the calibration set is still relatively small and cannot cover every possible domain or usage pattern, but the procedure is specifically designed so that the selected experts generalize to tasks and distributions related to those represented in the calibration data, rather than simply memorizing the calibration workload.

Sign up or log in to comment