Google's new on-device embedding model is a big jump for code. For plain text it barely moved.

One number did almost all the work

Google DeepMind released EmbeddingGemma 2 on 6 October 2026, and the launch post calls it "best-in-class" for multimodal embeddings. The model card, which is the document worth reading, shows where that actually comes from.

On the Massive Text Embedding Benchmark for code, the score went from 68.76 to 78.68. That is a 9.92 point jump, which the model card puts at roughly 14% relative improvement over its predecessor. Real, large, and useful if you are indexing a codebase.

On general multilingual text, the same table shows 61.36 against 61.15 for version one. A gain of 0.21 points. Within noise.

So the honest headline is narrower than the marketing one. EmbeddingGemma 2 is a substantial upgrade for code retrieval and a genuine expansion into images, audio and video, which the previous model could not do at all. It is not a meaningful upgrade for plain multilingual text search. If text retrieval is your whole use case, version one was already doing that job.

Google does not hide this. The blog says the model "matches the strong multilingual text performance of EmbeddingGemma" while delivering the code gain, which is accurate. The word "best-in-class" is just doing more work in the headline than in the data.

What the thing actually is

An embedding model turns content into a list of numbers so that similar things land near each other, which is how semantic search and retrieval-augmented generation work under the hood. EmbeddingGemma 2's pitch is that it does this for four kinds of input at once, mapping text, code, images, video and audio into one shared 768-dimensional space, and that it runs on a phone.

The specifications, from the model card: 740M total parameters, built on the Gemma 4 architecture, released under Apache 2.0, with an 8,192 token context window, four times version one's. It understands 100-plus languages. Twenty-four layers, 768 native output dimensions.

The design choice that matters most is modularity. The 740M total splits into a 270M text backbone plus independently loadable vision (170M) and audio (300M) encoders. Text only, and you load 270M. Text and image, 440M. Text and audio, 570M. You pay for the modalities you use, which is the difference between something that fits on a handset and something that does not.

Because one model covers all four, the practical trick it enables is cross-modal: find a video clip from a voice memo, or search hours of audio with a text query, without stitching four separate models together.

The 6x storage saving is a text-only claim

The launch post advertises "up to 6x storage reduction" through Matryoshka Representation Learning, which lets you chop the 768-dimensional output down to 512, 256 or 128 dimensions and keep the leading values. For anyone running a local vector database, that sounds like free money.

The model card prices it properly. "Model users can reduce storage requirements, with minimal quality impact down to 256d. 128d is best suited to text-only workloads."

The table behind that sentence is blunt. At 256 dimensions, a 3x saving, English text drops from 68.46 to 67.78 and the multimodal MMEB overall from 59.01 to 56.24. Acceptable. At 128 dimensions, the full 6x saving, MMEB overall falls to 45.65 and audio retrieval collapses from 69.54 to 56.71. That is not a trim, it is a different quality tier.

Read the two documents together and the guidance is clear: 256d is the real sweet spot for multimodal work, and the 6x figure applies to text, where it holds up far better at 71.41 on code and 65.68 on English. Taking "up to 6x" as a general claim and truncating a multimodal index to 128d will quietly wreck your audio and video retrieval.

What it costs to run on a phone

The on-device numbers are the most concrete thing in the announcement. Quantized on a Google Pixel 11 Pro, Google reports roughly 191MB of active RAM for text-only weights and about 567MB for the full multimodal model.

That 191MB figure is the one to hold onto. It means local semantic search over your own notes, photos and recordings, with nothing leaving the device, is now a thing a normal phone app can ship rather than a research demo. The 8K context window handles up to 5.5 minutes of audio, 29 images or 58 video frames in one pass.

Google also says version one passed 20 million downloads, which is the adoption claim rather than a quality claim, and it is the company's own count.

The benchmark caveat, stated plainly

Every score above was run and published by Google. MTEB, MIEB, MMEB and MAEB are public benchmarks with public leaderboards, which is better than a private internal eval, but a vendor reporting its own results on a public benchmark is still a vendor reporting its own results. No independent replication has been published, and the model shipped yesterday.

"Best-in-class for its size" also carries a qualifier that is easy to skim past. The claim is leading scores "among sub-1B multimodal embedders," a category Google largely defines by competing in it. The stronger and more checkable claim is quality-per-parameter, where a 740M model matching or beating specialist models more than twice its size is a real engineering result.

The weights are on Hugging Face and Kaggle under Apache 2.0, so unlike most launch-day benchmark claims, this one is falsifiable by anyone within a week.

Our take

This is a good release, oversold by one adjective. If you are building on-device search, a local RAG pipeline, or anything that indexes code, EmbeddingGemma 2 is worth switching to, and the licence and footprint make that easy. If you are doing multilingual text retrieval and version one already works, the upgrade buys you almost nothing on your primary metric.

Two practical rules from the documentation rather than the announcement: load only the encoders you need, because text-only is 270M rather than 740M, and truncate to 256 dimensions rather than 128 unless your index is text alone. Both are in the model card. Neither is in the headline.