Gemma-4-26B-A4B with 39-69% less thinking at same accuracy | Hacker News Reader

Gemma-4-26B-A4B with 39-69% less thinking at same accuracy

bottlecapai.com

127 pointsarmcat34 comments

"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 enterprise@bottlecapai.com."

lol what's old is new again, software selling performance options like it's the beginning of the multi-core days again.

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.

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.

> I still broadly just prefer working with Muse Glimmer

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.

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.

But Qwen 3.8 27b is unbearable slow, you get 10minutes of "let me think" over any trivial stuff.

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.

It does. It's quite good with the low setting. I prefer Muse Glimmer for, I dunno, hard to explain comfort reasons.

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)

that nemotron model is such a dog, like all the other nemotrons

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.

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.

For most folks in this thread running old M1 Max like me, look into MTPLX models (and the namesake inference engine).

I’ve built something custom that’s pretty darn fast but not ready for prime time yet. Might share it eventually.

Please share it. Fellow M1 (Ultra) user here

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.

I really don't like these companies taking open weight models and then gatekeeping the results of their minor contributions.

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.

That will just make people less likely to use open models for any commercial work.

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.

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

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.

That's the Google link, here is Bottlecapai on HF:

https://huggingface.co/bottlecapai

I don't see Gemma there.

https://huggingface.co/bottlecapai/ThinkingCap-gemma-4-26B-A...

That claims to have been there for 12 hours when i view it

Get used to it. In the AI era, gatekeeping is how you build value.

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

Our ThinkingCap weights are publicly available on Hugging Face: BF16 and GGUF. Free to download and run locally. https://huggingface.co/bottlecapai/ThinkingCap-gemma-4-26B-A... https://huggingface.co/bottlecapai/ThinkingCap-gemma-4-26B-A...

The work is released under the Apache 2.0 licence which is permissive.

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)

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.

Indeed — the output token speed is showy but not that useful as a metric.

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.

Indeed, which is why I always compared wallclock time at equal power consumption. I think that's the fairest way to compare models.

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.

Base qwen 3.8 27B was so bad at over thinking that I couldn't work with it day to day. Swift solves that.

Perhaps I'll give bottlecap AI's fine tune a go.

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...

Anyway, well done BottleCap AI!

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.

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.

And hilarious cause what a time to be alive.

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

Reply on news.ycombinator.com