EmbeddingGemma 2: 740M Parameters, 8K Context, and an Apache 2.0 License

Bottom line: Google released EmbeddingGemma 2 on October 6, 2026: a 740-million-parameter embedding model under the Apache 2.0 license with an 8K context window. The 191MB figure Google cites refers to a quantized build running on a Pixel 11 Pro.

The parameter count and the memory count are not the same measurement. Google’s October 6 launch post says EmbeddingGemma 2 has 740 million parameters, is built on the Gemma 4 architecture, and is released under Apache 2.0. The same post says that with quantization, on a Google Pixel 11 Pro, the model needs as little as about 191MB of active RAM for text-only weights and about 567MB for the full multimodal model. 740 million parameters is a weight count. 191MB is a RAM figure on one phone, after quantization, for one slice of the model. Paste the wrong one into a capacity plan and you will either overbuy a server or underbuy a phone.

We already wrote a small-model sticker that was not the average saving. Haiku 5.5 lists at $0.10 in and $0.50 out on short prompts, and the 75% figure is a different cut. We already wrote a local Gemma run that still needed a GPU and a stack. Antigravity’s SDK path for Gemma 4 is that stack. We already wrote an open-weight score that was a rank, not a shipping date. Mistral Large 4 at 38, with weights landing later. EmbeddingGemma 2 is a fourth shape: an embedding model, not a chat model, with a parameter total that splits if you leave the encoders out.

EmbeddingGemma 2’s 740 million is the three slices added up

The launch post’s modular line is the one to pin up. Text-only workloads can run on as little as 270 million parameters. An optional vision encoder adds 170 million. An optional audio encoder adds 300 million. 270 plus 170 plus 300 is 740. Google did not print that addition. The arithmetic lands on the headline parameter count, which is a reason to trust that the three slices are parts of the 740 million rather than a second model. It is not a reason to treat “as little as 270 million” as a rounded slogan. “As little as” is Google’s hedge. A text-only build might not be exactly 270 million in the checkpoint you download. The post says as little as 270 million for text-only workloads.

Open Data Science on October 7 restates the same split: 740 million parameters, Gemma 4, Apache 2.0, text-only at approximately 270 million, vision encoder 170 million, audio encoder 300 million. ODSC says “approximately” on the text slice. Google’s blog says “as little as.” Those are close, and they are not identical. Those stay with Google until a second outlet prints them.

The developers’ post the same week repeats the 740 million count and the Pixel 11 Pro memory pair, about 191MB active RAM for text-only weights and about 567MB for the full multimodal model. A related-post label on that page dates “EmbeddingGemma 2: The Developer Guide” to October 6, 2026. Two Google properties and one trade writeup. The trade writeup confirms the parameter split. It does not confirm the phone memory.

The context window is 8K, and the media budgets are Google’s ceilings

Google says the context window is 8K tokens, four times EmbeddingGemma 1. It also says that window can take up to 5.5 minutes of audio, 29 images, 58 video frames, or interleaved combinations of those, on local hardware. “Up to” is doing a lot of work. 5.5 minutes of audio and 29 images are not a budget you can spend at the same time without the interleaved clause, and the interleaved clause does not publish a mixing table. The launch post’s ceilings are the ceilings.

Four times the previous context is a comparison with EmbeddingGemma 1, not with Gemini, and not with the Gemma 4 generative model the developers’ post says you can pair this with. A 4x context on an embedding model is a longer document, a longer clip, or more frames in one vector request. It is not a longer chat. This model produces vectors. The launch post is explicit that the point is search, retrieval, and routing on device, including the example of finding a video clip from a voice memo or searching hours of audio with a text query. “Hours of audio” in that example and “5.5 minutes” in the context bullet are not the same capacity. Hours would be many requests, or a pipeline that slices audio before the embedding call. One call, on the bullet Google printed, tops out at 5.5 minutes.

The developers’ post adds a reason the pairing with Gemma 4 is cheaper than a naive sum: EmbeddingGemma 2 shares Gemma 4’s text tokenizer and audio encoder, so running both in one pipeline has a lower combined memory footprint. Lower than what, by how many megabytes, is not in the paragraph. “Lower” is the claim. A plan that subtracts 191MB from a Gemma 4 footprint and calls the result the joint cost has invented the subtraction. The Antigravity piece on this site was about a different runtime.

The code score moved 9.92 points; the sources do not list the other scores

Google says EmbeddingGemma 2 matches the multilingual text performance of the previous EmbeddingGemma, and that code performance on MTEB Code moved from 68.76 to 78.68, a 9.92-point gain. The difference is 9.92. Google’s “9.92-point improvement” matches the subtraction. That is a check, not a new benchmark. The post also says the model sets a quality-per-parameter mark for sub-1B models across image, video, documents, and audio, and that it outperforms some specialist models more than twice its size. It does not name those models. “Some” is not a leaderboard row.

ODSC did not, in the text we pulled, repeat the 68.76 or the 78.68. So the code delta is a Google figure with an arithmetic check, not a figure a second newsroom recomputed. The launch post points at the EmbeddingGemma 2 model card for full metrics. Image and audio benchmarks are named, MTEB-style, in the post’s section labels. A blank cell is more honest than a remembered one.

Sub-1B is true of 740 million by inspection. Twice 740 million is 1.48 billion. “More than twice its size” means Google is comparing against models above that line, unnamed. A specialist model at 1.5 billion parameters is not, on this evidence, a model EmbeddingGemma 2 beat. It is the threshold Google’s phrase implies and does not document. Leave the phrase as theirs.

768 dimensions down to 128 is the storage claim, and 6x is the short vector

Matryoshka Representation Learning, in the launch post, lets you truncate output vectors from 768 dimensions to 512, 256, or 128. Google says that provides up to a 6x storage reduction for local vector databases and memory. 768 divided by 128 is 6. The top of “up to 6x” is the shortest vector, not a measured database benchmark with an index, a recall target, and a disk trace. Cutting dimensions saves the vector store. It can also throw away retrieval quality. Google does not, in the paragraphs we have, print the recall drop at 128 dimensions. Using 128 because 6x is the largest number in the sentence is how a local index gets small and useless. The post says you can truncate. It does not say you should.

191MB and 567MB are the other pair people will screenshot. Both are approximate, both are on a Pixel 11 Pro, and the launch post attaches them to quantization. The developers’ post says “active RAM” and “weights” in the same neighborhood: about 191MB for text-only weights, about 567MB for the full multimodal model. If your phone is not a Pixel 11 Pro, these are not your numbers. If you skip quantization, the launch post does not give you a substitute figure. “As little as” applies. A laptop CPU build can land somewhere else.

Apache 2.0 is the license line, on the launch post and again at ODSC. Commercially permissive is Google’s description of that license in the launch post. Weights you can download are not weights you have evaluated. The model card is still the missing page for the scores under the chart labels.

What this is not

EmbeddingGemma 2 is not a drop-in replacement for a chat model, and the launch post does not pretend it is. It embeds. Pairing it with Gemma 4 for on-device retrieval is Google’s suggested shape, with a shared tokenizer and a shared audio encoder, and with an unspecified memory savings. It is not Haiku’s price list. There is no per-token rate in any of these three sources, because the pitch is local inference rather than an API meter. If a later page adds a hosted endpoint, that page is a different product. This one is a 740 million parameter checkpoint, a 270 million parameter text slice, an 8K context, and a phone memory figure that only holds under the conditions Google named.

The developers’ post mentions LiteRT, a Hugging Face model card, and a browser demo. The news, dated October 6 on Google’s blog and October 7 at ODSC, is the checkpoint and the split. The evaluation you still owe yourself is the model card, plus a vector store that you actually measured at 768 and at 128 before you take the 6x.

What this means for you

If you are evaluating it for on-device search, benchmark retrieval quality on your own data at each embedding dimension you plan to use. Smaller vectors save storage, but the trade-off in recall should be measured, not assumed.