Google has released Gemma 4 this time (Part 1)

Wed, 08 Apr 2026 23:48:20 +0800

On the day of the initial release, what I originally wanted to do was simple: find an upgraded version corresponding to Gemma 3 and download it to run. However, after looking around, I was a bit stunned. The familiar naming convention of 4B / 12B / 27B is gone; instead, we have E4B, 26B A4B, and 31B. How should I put it? This time, what Google truly changed wasn’t just the model sizes, but even “how you should understand this batch of models.”

I’ve broken down these articles into three parts. This current article only clarifies the release information, model names, and protocols; the next one will cover Google Released Gemma 4 (Part II): Running Locally on a 3060 12GB, 26B A4B is More Realistic; and the last one will conclude with Google Released Gemma 4 (Part III): Why VRAM Insufficiency Causes a Cliff, and Why Mac Can Be a Fallback But Isn’t Fast.

Let’s first clarify what was actually released this time

Last year, Gemma 3 was released on March 12, 2025, and this Gemma 4 was released on April 2, 2026. It is indeed about a year apart. However, we cannot approach this by asking, “Who is the next generation after 27B.” The four main sizes provided by the official source are no longer simply categorized by total parameters. | E2B | Dense | 2.3B effective, 5.1B including embeddings, 128K context | On-device, ultra-lightweight local |

Clarify what was actually released this time

Model	Structure	Key Numbers	Typical Scenarios
`E4B`	Dense	4.5B effective, 8B including embeddings, 128K context	The original 4B small model main line

Clarify what was actually released this time

Model	Structure	Key Numbers	Typical Scenarios
`26B A4B`	MoE	25.2B total, approx. 3.8B active, 256K context	Consumer GPUs, local deployment, balancing quality and speed

Clarify what was actually released this time

Model Size	Structure	Key Numbers	Typical Scenarios
`31B`	Dense	30.7B dense, 256K context	Aiming for the upper limit, leaderboards, and more stable quality

Let’s clarify what was actually released this time

If you only look at the surface, you might feel that the naming is more confusing. But it’s not random; Google is deliberately splitting the three tracks:

Small model for on-device use, given to E2B / E4B
Local player track, given to 26B A4B
Quality and upper limit track, given to 31B This is also why many people’s first impression might be, “The previously familiar upgrade path has been broken.” It’s not that they didn’t release an upgraded version; it’s that Google doesn’t want to sell products based on just one dimension: total parameters.

‘E’ and ‘A’ are not decorative letters this time

In this batch of names, the most confusing ones are E4B and A4B. The ‘E’ in E2B and E4B stands for effective parameters, according to the official documentation. Because these two models use Per-Layer Embeddings, the total parameter count and the actual effective parameter count are not measured by the same metric. Simply put, Google is reminding you that this is not like the old “a simple 4B dense model.” The ‘A’ in 26B A4B stands for active parameters. The total size is 25.2B, but only about 3.8B are actually activated per token. This is key to the MoE approach: the total model size is large, but the part that actually participates in computation at runtime is much smaller. So, even though both names seem to have a ‘4B’, their meanings are completely different:

E4B is for the small model line.
26B A4B is a large MoE with “activation scale of around 4B” during local inference. This naming convention was indeed awkward at first, but it is closer to the actual deployment experience than before.

If you previously used Gemma 3, how to find the corresponding relationship this time

I think the easiest place to misjudge with this generation is to treat it as a linear upgrade from Gemma 3. If you look at it based on usage habits, you can roughly understand it like this:

Those who used to focus on 4B for light tasks should now first look at E4B
Those who used to focus on 27B to see the model’s upper limit should now look at 31B
If you previously wanted to find a balance point on consumer-grade GPUs that is “powerful enough but not completely unrunnable,” now focus on 26B A4B If you don’t clarify this layer first, local deployment will easily go wrong later. You might complain, “Why isn’t there the familiar upgraded version?” while mistakenly choosing a model that isn’t actually suitable for you.

The most valuable update this time isn’t the parameters

What really made me feel like this release was a “finally figured it out” moment wasn’t the leaderboard, but the license. The old Gemma terms weren’t unusable, but they always felt a bit awkward. Especially if you care about these things:

Redistribution
Distillation or secondary packaging
Integrating the model into your own product pipeline
Commercial deployment You always have to go back and look at how those notices, downstream restrictions, and accompanying agreements in the terms should be handled. By changing directly to Apache 2.0 this time, Gemma 4 made things much cleaner. The core message is very clear:
Commercially usable
Modifiable
Redistributable The main obligations are limited to retaining familiar open-source elements like the license, notices, and modification documentation. Simply put, Google didn’t just open-source a model this time; they smoothed out the entire process of “whether or not people feel safe using it.”

Initial Community Feedback, Basically Two Lines

If you only look at the first week’s buzz, there are roughly two main sentiments.

The first line is that 31B is genuinely capable. The official benchmarks are already very impressive. In the Arena AI text leaderboard, 31B was ranked among the top open-source models upon release, and it also showed a significant improvement over Gemma 3 27B on LiveCodeBench v6. Many people’s first reaction is that achieving this level of performance with this size is quite beyond expectations.

The second line is that 26B A4B seems like a lifeline for local users. It might not be the flashiest flagship model at first glance, but it is very practical. Especially if you aren’t running things in a data center, but rather on consumer-grade GPUs, workstations, or even older machines, the local experience tends to fall onto this line.

Of course, there’s a very realistic prerequisite for the initial wave of feedback: the ecosystem is still catching up with the versions. Templates, quantization methods, inference frameworks, and front-end tools—many haven’t fully kept pace yet. Therefore, when looking at comments right now, it’s best to view them in two layers:

The core model: There has indeed been a big improvement here.
Local experience: This will continue to be influenced by the maturity of the toolchain.

My Conclusion on the First Article

If you just want to know what Google actually released this time, one sentence is enough. Gemma 4 is no longer following the old idea of “a line of dense models from small to large,” but rather separating three paths: device-side deployment, local deployment, and quality ceiling. The names like E4B, 26B A4B, and 31B sound strange, but behind them is a very practical division of labor for deployment. But if you ask me what the biggest change is this time, I still stick to that judgment: It’s not about parameters, nor is it about leaderboards; it’s that Google finally put Gemma 4 into an open-source protocol that everyone feels more comfortable actually using. This step is more important than the numbers on the surface. In the next article, I won’t continue talking about the conference narrative; I’ll go straight back to local machines. Still with that unupgraded RTX 3060 12GB, why was it that my initial focus wasn’t on 31B, but on 26B A4B.

References

Writing Notes

Original Prompt

$blog-writer Google has released the Gemma4 model after a year. As usual, I'm trying to deploy it locally on that old desktop with an unupgraded NVIDIA 3060 12GB graphics card. This time I caught the initial release, but I couldn't find an upgraded version of the previously used Gemma3. However, there is a similar version called GemmaE4b. Please first search and introduce all the models released this time, what the abbreviation letters mean in them, and then search for online reviews about Gemma4. The key point is that Google updated the model's protocol this time, so the restrictions for users are fewer. The biggest surprise: my usual test question—write a piece of C++ code to output a five-pointed star in the console. Last year's smaller parameter open-source models couldn't handle this problem, but Google managed it this time. In the first version, it gave an answer that completely exceeded my expectations; it knew about my trap. Outputting a five-pointed star to the console is very tricky, so it directly hardcoded a string for the five-pointed star, and the console outputted it directly. This is the original text: Because drawing a five-pointed star with precise geometric structure using mathematical logic in a pure text console (Console) is very complex (involving coordinate system transformation and pixel filling), the most classic and visually best method is to use ASCII Art. After I forced it to perform calculations, it also managed it through mathematical calculation and successfully drew the five-pointed star. Previously, I often used Gemma4 for local translation tasks; many multilingual versions of historical articles on current blogs are like this. The model used for local testing: gemma-4-26b-a4b. The 31b version is indeed too slow. But looking at the reviews, the 31b performs very well, and its ranking scores are excellent. Also, while browsing forums, I realized that if the VRAM is insufficient and the model parameters increase, the token generation speed will drop drastically. Can you explain why? Macs don't have this problem because they use unified memory; please explain the technical reason. Furthermore, if speed is required, then an NVIDIA card with large VRAM is still necessary. The Mac solution can serve as a fallback, but it cannot match the speed. This content is quite extensive; please evaluate whether it should be split into a series of articles.

Writing Outline Summary

The first article will only focus on clarifying “what was actually released this time” and “why the protocol is important,” avoiding topics that compete with local experience discussions.
We will separate the model roadmap breakdown and then explain the meaning of the letters, making the logical flow more direct than the previous version.
For the protocol section, we retained the judgment: “What was truly released this time is not the parameters, but the usage restrictions.”
Community feedback will only be used for synthesis/conclusion, without preemptively including too many local experience details.

Apache on Uncle Xiang's Notebook

Google has released Gemma 4 this time (Part 1)

Let’s first clarify what was actually released this time

Clarify what was actually released this time

Clarify what was actually released this time

Clarify what was actually released this time

Let’s clarify what was actually released this time

‘E’ and ‘A’ are not decorative letters this time

If you previously used Gemma 3, how to find the corresponding relationship this time

The most valuable update this time isn’t the parameters

Initial Community Feedback, Basically Two Lines

My Conclusion on the First Article

References

Writing Notes

Original Prompt

Writing Outline Summary