Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by PaulKeeble on Friday October 23, 2026 @02:16PM
(#50213222)
I have tried the Thinking cap and the Swift model for QWEN-3.8 27B and my experience was its not as smart and capable, the results on the same task were less impressive. For the amount of tokens saved it might very well be worth it but I wanted to run the xhigh precisely because I wanted the peak result. I haven't tested this but I suspect it ends up much the same trade off, in theory it does well in the benchmarks but in practice on your own tasks its not as capable.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by dofm on Friday October 23, 2026 @02:30PM
(#50213408)
Yeah. I didn't find these any good either.
However, Gemma 4 26B is a reasonably good general chat inquiry model (it's also not too bad at commonplace code questions, if not as good for agentic code).
So this could be a good, fast model for that, in some situations; I may test it.
I still broadly just prefer working with Muse Glimmer, to be honest; we get along OK. I am trying out the Nemotron Bolt 74B/A9B MoE and I really do think it could be quite good, but it's still slow on Metal.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by dofm on Friday October 23, 2026 @02:58PM
(#50213771)
It is hard to explain why it is better. Benchmarks etc., context length, it should be worse than Qwen 3.8 27B and I am sure for long context work it is.
But on my old M1 Max, with "Reasoning strength: low" in the system prompt, it's just kind of nice to use. It's not really slow (despite being a dense model it is faster to actual solutions than the Qwen 3.6 35B MoE), it writes well, etc.
So I use it as a developer-friend and researcher at the moment. Though it is actually the only model I've deployed code from! In general I am still writing my own (because I'm stuck in a bespoke framework on my main project) but it wrote me a plugin I needed for another app without any difficulty.
It's the first local LLM I've considered building hardware for.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by simonw on Friday October 23, 2026 @02:55PM
(#50213733)
Qwen 3.8 27B defaults to "xhigh" (its maximum level) for thinking, which makes it diabolically slow. Setting it to "medium" or "low" speeds it up a lot.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by dofm on Friday October 23, 2026 @05:01PM
(#50215270)
I have found it to be OK on sort of general purpose overview code stuff. At the moment it's too slow in llama.cpp on Mac for me to bother testing further.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by verdverm on Friday October 23, 2026 @07:57PM
(#50216984)
This is my experience with Fireworks Ember-1 (reduced thinking Kimi K3)
It hallucinated and claimed task completion almost every session. Zero trust for this concept of fine tuning out excessive thinking, seems to do more harm than good. Eventually, as token vendors continue to commoditize, we will not care.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by BottleCapAI on Saturday October 24, 2026 @05:46AM
(#50219630)
There is a trade-off, but on Gemma we reduced thinking tokens by 39% on average for just a 0.15 percentage-point drop in average accuracy across 12 benchmarks. We'd encourage you to give this release a try.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by syntaxing on Friday October 23, 2026 @03:15PM
(#50213988)
I tried using thinkingcap Qwen 27B for about two weeks. It definitely does dumber things than vanilla 27B but isn’t too far off. Swift 1.5 is noticeably dumber that I stopped using it after one day. Oddly, I switched back to regular 27B because the thinkingcap one is noticeably more censored. Anything explicit gets instantly shot down by thinkingcap while vanilla 27B will chug along.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by arjie on Friday October 23, 2026 @04:01PM
(#50214535)
It feels clear to me that smaller models are moving parameter-level thinking into inference time. i.e. they use more tokens to perform computation because they don't perform it in the model itself. There's some conservation of difficulty for tasks and you either do the computation in the model or you do it in the looped iterations of the model.
This is why the massive tok/s you see on many small MoE never manifest as worthwhile outcomes. Sonnet 5.5 can be faster on tasks than DeepSeek 4 Flash Vision simply because it gets there faster.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by serf on Friday October 23, 2026 @04:09PM
(#50214616)
"ThinkingCap PRO: want even better efficiency? The PRO version of this model uses up to 87.6% fewer thinking tokens, 62% on average. Faster answers and lower inference costs at scale. Contact us at [email protected]."
lol what's old is new again, software selling performance options like it's the beginning of the multi-core days again.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by mehdi_zare on Friday October 23, 2026 @05:28PM
(#50215624)
In the case of PR reviews, cost is mostly thinking tokens. For me, what matters is a shorter reasoning at the same accuracy rather than a slightly higher score.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by zedlasso on Friday October 23, 2026 @05:36PM
(#50215708)
Byteshape's Quant for Qwen has been surprisingly fast at good at output for my humanities stuff. It's small model punching way above its weight and it being so early in all this nutiness is quite amazing to see.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by yieldcrv on Friday October 23, 2026 @07:09PM
(#50216629)
other improvements in the inference engine and harness net 1.5x+ improvements in tokens/sec, so if you're doing that on your own hardware you don't really need less tokens run, you just need any output done quickly
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by jacquesm on Friday October 23, 2026 @09:13PM
(#50217481)
No, it won't. Using open weight models is using them 'as is'. If you start modifying them and then gatekeep the results you are no better than parties that distribute modified open source binaries without the source.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by intoXbox on Saturday October 24, 2026 @03:50AM
(#50219096)
Better than is not part of the issue. If open weights models are released with a copy-left license as GPL, companies won’t include them in their products and favour commercially permissive models
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by kadoban on Friday October 23, 2026 @09:17PM
(#50217504)
Hm? I see a model download link to hf.
These people building on or tweaking open models is _great_, it should be encouraged. There's a lot of room to spend some effort improving models in various ways that the original creators didn't have time for.
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by intoXbox on Saturday October 24, 2026 @03:52AM
(#50219106)
Yeah agreed, I hope the b2b marketplace will automatically make these products redundant if they are mainly targeted at engineers. Unless they offer value somehow else.
I don’t think a license change would have a net positive effect, they will just add their tiny wrapper around another permissive model
Re:Gemma-4-26B-A4B with 39-69% less thinking at same accuracy
by peter_d_sherman on Saturday October 24, 2026 @10:58PM
(#50227853)
In the training phase, penalizing models not just for wrong answers, but
also for excessive length in the (CoT) thinking trace
seems to be the recipe, or at least part of the training recipe, for training a model to "think" less (and thus output less CoT tokens and thus operate faster) at approximately the same accuracy as the same model, previously trained without penalizing excessive length wrong answers in the thinking trace...
However, Gemma 4 26B is a reasonably good general chat inquiry model (it's also not too bad at commonplace code questions, if not as good for agentic code).
So this could be a good, fast model for that, in some situations; I may test it.
I still broadly just prefer working with Muse Glimmer, to be honest; we get along OK. I am trying out the Nemotron Bolt 74B/A9B MoE and I really do think it could be quite good, but it's still slow on Metal.
Welcome to our very exclusive club of now two people! Ever since it came out I’ve been trying to find a better model, but just can’t.
But on my old M1 Max, with "Reasoning strength: low" in the system prompt, it's just kind of nice to use. It's not really slow (despite being a dense model it is faster to actual solutions than the Qwen 3.6 35B MoE), it writes well, etc.
So I use it as a developer-friend and researcher at the moment. Though it is actually the only model I've deployed code from! In general I am still writing my own (because I'm stuck in a bespoke framework on my main project) but it wrote me a plugin I needed for another app without any difficulty.
It's the first local LLM I've considered building hardware for.
I had to hack the template of Qwen 3.8-27B to get it to go into low reasoning mode. Not sure if that is fixed.
Have you tried Nemotron 74B-9B? (Slow on Mac with llama.cpp due to a missing tensor type)
It hallucinated and claimed task completion almost every session. Zero trust for this concept of fine tuning out excessive thinking, seems to do more harm than good. Eventually, as token vendors continue to commoditize, we will not care.
I’ve built something custom that’s pretty darn fast but not ready for prime time yet. Might share it eventually.
Perhaps I'll give bottlecap AI's fine tune a go.
This is why the massive tok/s you see on many small MoE never manifest as worthwhile outcomes. Sonnet 5.5 can be faster on tasks than DeepSeek 4 Flash Vision simply because it gets there faster.
Muse Glimmer (dense 30B), in practice, can get to better answers more quickly than Qwen 3.6 35B-A3B.
It just appears to be slower word by word.
lol what's old is new again, software selling performance options like it's the beginning of the multi-core days again.
And hilarious cause what a time to be alive.
I hope that the producers of the actual open models will modify their licenses to ensure that this practice becomes a thing of the past.
These people building on or tweaking open models is _great_, it should be encouraged. There's a lot of room to spend some effort improving models in various ways that the original creators didn't have time for.
https://huggingface.co/bottlecapai
I don't see Gemma there.
That claims to have been there for 12 hours when i view it
I don’t think a license change would have a net positive effect, they will just add their tiny wrapper around another permissive model
If this is your concern, complain about the licence, not about people acting within rights granted by the licence.
Copyleft is the only good sort of licence. (oh boy am I gonna get downvoted for that)
also for excessive length in the (CoT) thinking trace
seems to be the recipe, or at least part of the training recipe, for training a model to "think" less (and thus output less CoT tokens and thus operate faster) at approximately the same accuracy as the same model, previously trained without penalizing excessive length wrong answers in the thinking trace...
Anyway, well done BottleCap AI!