Live data from Hacker News

Google releases Gemma 4 open models

deepmind.google

311–320 of 507 posts

Re: Google releases Gemma 4 open models

#311

Thinking / reasoning + multimodal + tool calling. We made some quants at https://huggingface.co/collections/unsloth/gemma-4 for folks to run them - they work really well! Guide for those interested: https://unsloth.ai/docs/models/gemma-4 Also note to use temperature = 1.0, top_p = 0.95, top_k = 64 and the EOS is " ". " thought\n" is also used for the thinking trace!

I haven't tried a local model in a while. I can only fit E4B in VRAM (8GB), but it's good enough that I can see it replacing Claude.ai for some things.

Re: Google releases Gemma 4 open models

#312

Prompt: > what is the Unix timestamp for this: 2026-04-01T16:00:00Z Qwen 3.5-27b-dwq > Thought for 8 minutes 34 seconds. 7074 tokens. > The Unix timestamp for 2026-04-01T16:00:00Z is: > 1775059200 (my comment: Wednesday, 1 April 2026 at 16:00:00) Gemma-4-26b-a4b > Thought for 33.81 seconds. 694 tokens. > The Unix timestamp for 2026-04-01T16:00:00Z is: > 1775060800 (my comment: Wednesday, 1 April 2026 at 16:26:40) Gem…

To clarify, the parent here didn't actually give the model a way to run the commands. The model just wrote the script/command and then, being unable to run anything, just mentally calculated what the result would probably be (and got it wrong). Yes the answer was wrong, but so was the setup (the model should have had access to a command runner tool).

Yes, you are right that for a model that wants to use tools, the environment was wrong. I didn't do that on purpose. I was simply interested in seeing what the answer to my question would be. The fact Gemma 4 wanted to use tools was a bit of a surprise to me - the Qwen model also can use tools, but it opted not to.

I think it is interesting to see, that when forced to derive the value on its own, Gemma gets it wrong while Qwen gets it right (although in a very costly way).

I also think that not using tools is better than hallucinating using them.

Re: Google releases Gemma 4 open models

#314

Earlier quoted context omitted.

I'm curious what the thinking trace looked like. Interesting that it can get that close to the answer yet still be off.

Here's Gemma's. Qwen's is a bit too long to post here. Input format: ISO 8601 string (2026-04-01T16:00:00Z). Target format: Unix timestamp (seconds since Jan 1, 1970). Year: 2026 Month: 04 (April) Day: 01 Time: 16:00:00 Timezone: Z (UTC/Zulu) Option A: Manual calculation (too error-prone). Option B: Use a programming language (Python/JavaScript). Option C: Knowledge of specific dates. Let's use Python logic internall…

I find it interesting that it decided to write a script despite not having access to tools, and is apparently aware of this lack of access since it then proceeds to do the computation manually.

It's impressive it got as close as it did with estimates (and that it can actually do basic math now). Yet then it goes "let's do a precise check using tools" and just blatantly makes the whole thing up. Comedic but also worrisome.

I find the entire sequence pretty weird. It's such a bizarre mix of competence with blatant incompetence that borders on deceit.

Re: Google releases Gemma 4 open models

#315
post #187

Earlier quoted context omitted.

For me, receipt scanning and tagging documents and parts of speech in my personal notes. It's a lot of manual labour and I'd like to automate it if possible.

Have you tried paperless-ngx, a true and tested open source solution that's been filling this niche successfully for decades now?

They, too, offer integrations for LLMs these days, presumably for better OCR and classification.

Re: Google releases Gemma 4 open models

#316

Prompt: > what is the Unix timestamp for this: 2026-04-01T16:00:00Z Qwen 3.5-27b-dwq > Thought for 8 minutes 34 seconds. 7074 tokens. > The Unix timestamp for 2026-04-01T16:00:00Z is: > 1775059200 (my comment: Wednesday, 1 April 2026 at 16:00:00) Gemma-4-26b-a4b > Thought for 33.81 seconds. 694 tokens. > The Unix timestamp for 2026-04-01T16:00:00Z is: > 1775060800 (my comment: Wednesday, 1 April 2026 at 16:26:40) Gem…

I ran gemma4:26b without any tooling access and it gave me the correct answer in a few minutes only (definitely less than 8 minutes, but I didn't timed it).

Specs : RX 9070 XT (24GB VRAM) + 16 GB RAM

gist : https://gist.github.com/vgalin/a9c852605f39ab503f167c9708a46...

(I gave it another go and it found the correct result in about a minute, see the comment on the gist)

Re: Google releases Gemma 4 open models

#317
post #106
post #83

Earlier quoted context omitted.

Do you think it's just part of their training set now?

If it's part of their training set why do the 2B and 4B models produce such terrible SVGs?

Larger models better understand and reproduce what's in their training set.

For example, I used to get verbatim quotes and answers from copyrighted works when I used GPT-3.5. That's what clued me in to the copyright problem. Whereas, the smallest models often produced nonsense about the same topics. Because small models often produce nonsense.

You might need to do a new test each time to avoid your old ones being scraped into the training sets. Maybe a new one for each model produced after your last one. Totally unrelated to the last one, too.

Re: Google releases Gemma 4 open models

#319

Earlier quoted context omitted.

That rule of thumb was invented years ago, and I don’t think it is relevant anymore, despite how frequently it is quoted on Reddit. It is certainly not the "current" rule of thumb. For the sake of argument, even if we take that old rule of thumb at face value, you can see how the MoE still wins: - (DGX Spark) 273GB/s of memory bandwidth with 3B active parameters at Q4 = 273 / 1.5 = 182 tokens per second as the theore…

Kimi 2.5 is relatively sparse at 1T/32B; GLM 5 does 744B/40B so only slightly denser. Maybe you could try reducing active expert count on those to artificially increase sparsity, but I'm sure that would impact quality.

Reducing the expert count after training causes catastrophic loss of knowledge and skills. Cerebras does this with their REAP models (although it is applied to the total set of experts, not just routing to fewer experts each time), and it can be okay for very specific use cases if you measure which experts are needed for your use case and carefully choose to delete the least used ones, but it doesn't really provide any general insight into how a higher sparsity model would behave if trained that way from scratch.

Re: Google releases Gemma 4 open models

#320

Thinking / reasoning + multimodal + tool calling. We made some quants at https://huggingface.co/collections/unsloth/gemma-4 for folks to run them - they work really well! Guide for those interested: https://unsloth.ai/docs/models/gemma-4 Also note to use temperature = 1.0, top_p = 0.95, top_k = 64 and the EOS is " ". " thought\n" is also used for the thinking trace!

I'm trying to disable "thinking", but it doesn't seem to work (in llama.cpp). The usual `--reasoning-budget 0` doesn't seem to change it, nor `--chat-template-kwargs '{"enable_thinking":false}'` (both with `--jinja`). Am I missing something?

EDIT: Ok, looks like there's yet another new flag for that in llama.cpp, and this one seems to work in this case: `--reasoning off`.

FWIW, I'm doing some initial tries of unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, and for writing some Nix, I'm VERY impressed - seems significantly better than qwen3.5-35b-a3b for me for now. Example commandline on a Macbook Air M4 32gb RAM:

  llama-cli -hf unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL  -t 1.0 --top-p 0.95 --top-k 64 -fa on --no-mmproj --reasoning-budget 0 -c 32768 --jinja --reasoning off
(at release b8638, compiled with Nix)
Post reply on HN