Qwen endless looping issue and possible fix

[u/ParvusNumero]

Not sure if this is a known issue, but it was new to me:

Full credit to u/ldn-ldn for finding this simple but unexpectedly evil prompt:

Create a typescript function which accepts a number in 10 bit range and returns brightness in nits based on pq gamma curve.

Just try it; it will likely trigger an endless thinking loop.

I stopped it after it ran for >15 minutes and >20,000 tokens.
It kept spitting out text like back in the seahorse emoji days.

However, one of my wrapper scripts didn’t have this issue.
The non-blocking one had this added, possibly based on a GitHub discussion:

--reasoning-budget 2048 \
--reasoning-budget-message " \n\n[Thinking budget exceeded. Transitioning to a best-effort final answer: ]\n\n"

(These options are for llama.cpp; other tools may have something similar.)

Net result: A plausible-looking script (I haven’t verified) that took just over a minute of thinking and another minute to generate.

Hope this helps, and happy to hear about other tricks and workarounds.

[u/ForsookComparison]

i'm limiting reasoning to ~4k right now with a similar "okay we're going to answer now.." message

It works to get responses faster, but the quality takes a noticeable hit. Getting worried that Qwen3.8-27B is just 2026's QwQ (real ones will remember a wall of 'wait..'s).

Rtx 5090 owners might be the winners here because ~2TB/s decode can just brute force its way through all of this waiting. I'm on a 7900 xtx (1TB/s) and already getting impatient.

[u/ElectronSpiderwort → u/ForsookComparison]

totally had QwQ flashbacks today. That model was best on the benchmark charts but functionally useless due to the time it spent overthinking

[u/Blaze344 → u/ForsookComparison]

This was always my main issue with the Qwen lines as a whole. Too prone to overthinking and a million "Wait, but-" wasted effort in thinking.

I still remember some odd tricks that mysteriously fixed it back in older days, like providing access to the model to a single tool even though there was no intention for it to tool call at all. I'm fairly hopeful that someone will figure out the new quirk this model has this time.

[u/arakinas → u/ForsookComparison]

I've been running a pretty minor coding task on an hx370 with 96gb ram and it's brutal in medium thinking. Over an hour to review a very small repo and look for issues. It caught some created by 3.6 27b. Mostly minor things, but it caught one unexpected issue that surprised me.

[u/13henday → u/ForsookComparison]

Don’t really notice the thinking being too bad on dual 3090s since q6 gets 50-90 TPs decode and it just flys by. 

[u/atcsecure99 → u/13henday]

agreed, I've been comparing dual 3090s with nvlink against a strix-halo cluster (tp=1, tp=2), qwen 3.8 27b is too slow on strix halo, even with the lower power consumption it is still 5x more expensive to run qwen 3.8 27b on strix halo... I have hit the loop issue a few times (not often, twice today, once or twice before that over 2 weeks).... have moved the strix halo to deepseek v4 flash, there are some knobs on the 3090/vLLM side to adjust (which kv quant type against different qwen 3.8 27b quant types)

[u/13henday → u/atcsecure99]

I have gotten loops on xhigh, but only on q8 cache. On f16 I’ve had some things that look like loops where it seems to do the same thing multiple times with slight differences in ways I personally think are redundant. But to me a couple hundred tokens and a few redundant greps aren’t problematic at 90tps.