Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google releases Gemma 4 open models

deepmind.google

Post reply on HN
Print view View original

241–250 of 507 posts

Re: Google releases Gemma 4 open models

#241

Post by neonstatic »

augusto-moura wrote: post #238
neonstatic wrote: post #228

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…

The date command is not wrong, it works on GNU date, if you are in MacOS try running gdate instead (if it is installed): gdate -u -d @1775060800 To install gdate and GNU coreutils: brew install coreutils The date command still prints the incorrect value: Wed Apr 1 16:26:40 UTC 2026

Good catch, I just ran it verbatim in iTerm2 on macOs:

date -u -d @1775060800

date: illegal option -- d

btw. how do you format commands in a HN comment correctly?

Re: Google releases Gemma 4 open models

#242

Post by zozbot234 »

neonstatic wrote: post #228

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…

If you want the model to have function calls available you need to run it in an agentic harness that can do the proper sandboxing etc. to keep things safe and provide the spec and syntax in your system prompt. This is true of any model: AI inference on its own can only involve guessing, not exact compute.

Re: Google releases Gemma 4 open models

#243

Post by augusto-moura »

neonstatic wrote: post #241
augusto-moura wrote: post #238

Earlier quoted context omitted.

The date command is not wrong, it works on GNU date, if you are in MacOS try running gdate instead (if it is installed): gdate -u -d @1775060800 To install gdate and GNU coreutils: brew install coreutils The date command still prints the incorrect value: Wed Apr 1 16:26:40 UTC 2026

Good catch, I just ran it verbatim in iTerm2 on macOs: date -u -d @1775060800 date: illegal option -- d btw. how do you format commands in a HN comment correctly?

Start the line indented with two or more spaces [1]

[1]: https://news.ycombinator.com/formatdoc

Re: Google releases Gemma 4 open models

#244

Post by GistNoesis »

kpw94 wrote: post #226
GistNoesis wrote: post #140

Earlier quoted context omitted.

I just tried with llama.cpp RTX4090 (24GB) GGUF unsloth quant UD_Q4_K_XL You can probably run them all. G4 31B runs at ~5tok/s , G4 26B A4B runs at ~150 tok/s. You can run Q3.5-35B-A3B at ~100 tok/s. I tried G4 26B A4B as a drop-in replacement of Q3.5-35B-A3B for some custom agents and G4 doesn't respect the prompt rules at all. (I added in the system prompt as described (but have not spend time checking if the reaso…

> I'll need to investigate further but it doesn't seem promising. That's what I meant by "waiting a few days for updates" in my other comment. Qwen 3.5 release, I remember a lot of complaints about: "tool calling isn't working properly" etc. That was fixed shortly after: there was some template parsing work in llama.cpp. and unsloth pulled out some models and brought back better one for improving something else I can…

The model does call tools successfully giving sensible parameters but it seems to not picking the right ones in the right order.

I'll try in a few days. It's great to be able to test it already a few hours after the release. It's the bleeding edge as I had to pull the last from main. And with all the supply chain issues happening everywhere, bleeding edge is always more risky from a security point of view.

There is always also the possibility to fine-tune the model later to make sure it can complete the custom task correctly. But the code for doing some Lora for gemma4 is probably not yet available. The 50% extra speed seems really tempting.

Re: Google releases Gemma 4 open models

#245

Post by neonstatic »

zozbot234 wrote: post #242
neonstatic wrote: post #228

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…

If you want the model to have function calls available you need to run it in an agentic harness that can do the proper sandboxing etc. to keep things safe and provide the spec and syntax in your system prompt. This is true of any model: AI inference on its own can only involve guessing, not exact compute.

Thanks, I am very new to this and just run models in LMStudio. I think it would be very useful to have a system prompt telling the model to run python scripts to calculate things LLMs are particularly bad at and run those scripts. Can you recommend a harness that you like to use? I suppose safety of these solutions is its own can of worms, but I am willing to try it.

Re: Google releases Gemma 4 open models

#246

Post by fc417fc802 »

neonstatic wrote: post #228

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…

Given the working script I don't follow how a broken verification step is supposed to lead to it being off by 1600 seconds?

Re: Google releases Gemma 4 open models

#247

Post by vunderba »

misiti3780 wrote: post #225
vunderba wrote: post #32

Earlier quoted context omitted.

Strongly agree. Gemma3:27b and Qwen3-vl:30b-a3b are among my favorite local LLMs and handle the vast majority of translation, classification, and categorization work that I throw at them.

what HW are you running them on ? are you using OLLAMA ?

I'm using the default llama-server that is part of Gerganov's LLM inference system running on a headless machine with an nVidia 16GB GPU, but Ollama's a bit easier to ease into since they have a preset model library.

https://github.com/ggml-org/llama.cpp

Re: Google releases Gemma 4 open models

#249

Post by wolttam »

simonw wrote: post #106
wordpad wrote: 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?

Because it is in their training set but it's unrealistic to expect a 2B or 4B model to be able to perfectly reproduce everything it's seen before.

The training no doubt contributed to their ability to (very) loosely approximate an SVG of pelican on a bicycle, though.

Frankly I'm impressed

Re: Google releases Gemma 4 open models

#250

Post by zozbot234 »

swalsh wrote: post #199

I gave the same prompt (a small rust project that's not easy, but not overly sophisticated) to both Gemma-4 26b and Qwen 3.5 27b via OpenCode. Qwen 3.5 ran for a bit over an hour before I killed it, Gemma 4 ran for about 20 minutes before it gave up. Lots of failed tool calls. I asked codex to write a summary about both code bases. "Dev 1" Qwen 3.5 "Dev 2" Gemma 4 Dev 1 is the stronger engineer overall. They showed b…

The models are not technically comparable: the Qwen is dense, the Gemma is MoE. The ~33B models are the other way around!
Post reply on HN