Google DeepMind has released EmbeddingGemma 2, a 740-million-parameter open model that transforms text, images, audio, and video into the numeric vectors that search and retrieval systems run on. It is licensed under Apache 2.0, built on the Gemma 4 architecture, and small enough to run on a phone.
The announcement came from Sahil Dua and Henrique Schechter Vera, research engineers in the team, on October 6. Her opening number is the one that explains the release: the first EmbeddingGemma crossed 20 million downloads. That’s a lot of developers who wanted embeddings they could run themselves, and the sequel is pretty much aimed at them.
Three encoders you can mix and match
The interesting design choice here is modularity. EmbeddingGemma 2 is not a 740M blob You are loading completely.
The text encoder is 270 m parameters and works on its own. Vision adds 170m. Added audio 300m. You attach only the bits your product needs, which means a text search function doesn’t pay the memory cost of an audio encoder it never calls.
Google has quantified the active RAM on a Pixel 11 Pro measured with the model: about 191MB running text only, about 567MB with all modality loaded. Both figures are good in what a mid-range phone can spare for a background function.
There is a second track if you are already running Gemma 4 locally. EmbeddingGemma 2 shares Gemma 4’s text tokenizer and its audio encoder, so the two models use the same components in memory instead of loading a copy of each. If your app does generation and recovery on the same device, this overlap is real money.
Where the scores have moved, and where they haven’t
Code retrieval is the headline improvement. On MTEB code, the model goes from 68.76 to 78.68, a gain of almost ten points over its predecessor. That’s a big leap for a generation, and it’s important for anything that does semantic search over a repository.
Retrieving multilingual text is the opposite story. Google’s own post says that performance there matches EmbeddingGemma rather than beating it. If multilingual text is your entire use case, this upgrade gives you modality support and a longer context window, not better results on the thing you’re already doing.
Audio is a new territory, benchmarked on MAEB, the Massive Audio Embedding Benchmark. There is no number of the previous generation to compare against, because the previous generation could not process audio at all.
Keep the three results separate when planning a migration. “New model, better scores” is not uniformly true here, and Google does not claim that it is.
Eight thousand tokens, and what you can fit in them
Context runs on 8K tokensfour times what the first EmbeddingGemma handled. The handy translation Google offers is more useful than the token count:
| input | How much fits in one embedding |
|---|---|
| Audio | Up to about 5.5 minutes |
| Pictures | Until the 29th |
| Video | Up to 58 frames |
| Mixed | Any interleaved combination of the above |
The last line is the one that deserves attention. You can embed a document that contains text, a diagram, and a voice memo as a single vector, rather than inserting each piece separately and merging the results at query time. For anything resembling a meeting recording, a lecture, or a slide deck with narration, that changes what retrieval is able to see.
The trick of shortening
default output is 768 Dimensions. With Matryoshka Representation Learning you can cut that to 512, 256 or 128 and continue to use the same model, no retraining or separate checkpoint required.
Google quantifies the benefit as up to a 6x reduction in storage. Smaller vectors also mean faster similarity searches, since you’re comparing shorter arrays across your entire index.
One point of caution. Google does not publish quality-versus-dimension figures. It says that truncation is supported and saves space. It doesn’t say how much retrieval accuracy you give up at 256 or at 128. Several write-ups circulating about this launch claim that 256 dimensions maintain search quality and that 128 is suitable for plaintext indexing. Neither claim appears in the Google post, and no source is cited for it anywhere. Benchmark shortening on your own corpus before committing to an index for it.
Run it
The weights are on Hugging Face, Kaggle, and the LiteRT community. Availability through the Gemini Enterprise Agent Platform’s Model Garden is listed soon.
Supported runtimes are unusually broad for a launch-day release: Transformers, Saz-Transformers, MLX, vLLM, llama.cpp and SGLang, plus Ollama and LM Studio for anyone running local models through a desktop app rather than a Python script. Qdrant supports vectors natively, Unsloth handles fine-tuning, and transformers.js runs it in a browser tab via WebGPU.
On mobile, the deployment goes through MediaPipe or LiteRT.
If you’ve run local models through Ollama or LM Studio, this is a drop-in way to add retrieval to that stack without introducing an API dependency.
What Google built to prove the point
Three demos shipped next to the model, and they are more informative than the benchmark tables about what it is.
Direct media searchin AI Edge Gallery, search a phone’s photo and audio library by description rather than file name or date.
Video Moments Finder locate a specific moment in a video from a text query, something that would normally require uploading the file somewhere.
AI Edge Foresight predicts what a user is likely to do next from on-device signals, built on a new MediaPipe Decision Task API. Google AI Edge Foresight is currently available for macOS, completely free to download, and users can download it directly from the official website.
All three run locally. That’s the real argument of this release: the requests you least want to send to a server, your photo library, your voice memos, your private video – are exactly what a 191MB model can handle on your own hardware.
Is it worth switching
If you do a code search, yes, and the ten point profit makes that an easy call.
If you need image, audio or video recovery and have previously assembled separate models per modality, yes. A single common embedding space across four input types is the kind of simplification that removes entire categories of bugs.
If you do multilingual text retrieval and nothing else, the case is weaker. Same quality, bigger model, longer context. Whether the context window alone justifies the migration depends on how long your documents are.
And if you’re building something where sending user content to a cloud API is a problem, legally or commercially, this is the most capable thing in that form right now, under a license that allows you to send it.