EmbeddingGemma 2: one 740M model for text, image, audio and video, but text barely moved
On 6 October 2026 Google DeepMind released EmbeddingGemma 2. It's an open embedding model that maps text (including code), images, video and audio, alone or interleaved, into a single 768-dimensional space. It has 740M parameters and an Apache 2.0 license, and it's built to run on phones and laptops.
For anyone running RAG or semantic search, two things in this release matter. First, you can now do cross-modal retrieval (a text query against screenshots, PDFs-as-images, meeting audio) with one local model instead of stitching a CLIP-style encoder onto a text embedder. Second, the headline gain for text-only users is code retrieval. General multilingual text is essentially flat versus v1, and that decides whether re-embedding your corpus is worth it.
What actually shipped
From the model card and Google's launch post:
| Aspect | Detail |
|---|---|
| Modular sizes | 270M text backbone (130M transformer plus 140M embedder), 170M vision encoder, 300M audio encoder. Load only what you need: 270M for text, 440M for text+image, 570M for text+audio, 740M for everything |
| Output | 768d native, with Matryoshka truncation to 512, 256 or 128 dimensions |
| Context | 8,192 tokens shared across modalities, 4× the first EmbeddingGemma. An image costs 280 tokens by default (about 29 images max), a video frame 140 tokens at 1 fps (about 58 frames), audio 25 tokens per second (about 327 s) |
| Ecosystem at launch | transformers, sentence-transformers, MLX, vLLM, llama.cpp (GGUF), SGLang, Ollama and LM Studio. On-device runtimes: LiteRT, MediaPipe and transformers.js |
| On-device memory | Google's figures, quantized, Pixel 11 Pro: about 191 MB of active RAM for text-only, about 567 MB for full multimodal |
| Training data cutoff | January 2025 |
It's trained with task prefixes such as task: search result | query: … and title: … | text: …. Leaving them out works but lowers quality.
Numbers that matter
Self-reported, full-precision checkpoint, 768d:
| Benchmark | EmbeddingGemma 2 | EmbeddingGemma 1 |
|---|---|---|
| MTEB multilingual v2 (mean task) | 61.36 | 61.15 |
| MTEB code v1 (NDCG@10) | 78.68 | 68.76 |
| MMEB v2 Image (Hit@1) | 57.28 | n/a |
| MMEB v2 VisDoc (NDCG@5) | 67.84 | n/a |
| MMEB v2 Video (Hit@1) | 50.67 | n/a |
| MSEB retrieval (MRR@10) | 69.54 | n/a |
Matryoshka truncation, from the same card:
| Dim | MTEB multilingual | MTEB code | MMEB overall |
|---|---|---|---|
| 768 | 61.36 | 78.68 | 59.01 |
| 256 | 60.41 | 76.18 | 56.24 |
| 128 | 57.89 | 71.41 | 45.65 |
Illustrative storage example (my arithmetic)
Take 10M chunks stored as float32 vectors with no index overhead:
| Dim | Storage | Change vs 768d | Quality cost |
|---|---|---|---|
| 768 | 10,000,000 × 768 × 4 B = 30.72 GB | baseline | none |
| 256 | 10,000,000 × 256 × 4 B = 10.24 GB | 67% smaller | 0.95 MTEB-multilingual points |
| 128 | 5.12 GB | 83% smaller | text loses 3.5 points, but multimodal retrieval falls 13.4 points (59.01 → 45.65) |
So 256d is the sweet spot for most corpora. 128d is text-only territory, and Google's card says the same.
Artifact sizes from the official ggml-org GGUF repo: the text model is 310 MB at Q8_0 (558 MB BF16), and the mmproj file carrying the vision and audio encoders is another 555 MB at Q8_0 (982 MB BF16).
For a general multilingual text corpus, a +0.21 MTEB gain doesn't justify a full re-index; for code search, +9.92 NDCG@10 (self-reported) probably does.
Technical meaning and trade-offs
Re-embedding is the real cost. A new model means a new vector space, so you can't mix v1 and v2 vectors in one index. For a general multilingual text corpus, a +0.21 MTEB gain doesn't justify a full re-index. For code search, +9.92 NDCG@10 (self-reported) probably does. For multimodal corpora it's a new capability rather than an upgrade.
Two silent-failure modes, both documented by Google. First, never run it in float16. The card says activations exceed fp16 range and the model "returns NaN or silently degraded embeddings rather than raising an error." Use bf16 or fp32. On most CPUs, fp32. Second, re-normalize after truncation. Slicing a unit vector doesn't keep it unit-length, and cosine ranking degrades quietly. Pass truncate_dim with normalize_embeddings=True, or L2-normalize yourself. Queries and documents must use the same dimension.
The shared context budget is a chunking problem. An interleaved product page with three images uses 840 tokens before any text. A 5-minute audio clip uses about 7,500 of the 8,192 tokens. My read: for long media, chunk by time (say 30 to 60 s windows) rather than embedding whole files, or one embedding ends up standing in for too much content.
Prefix discipline. Documents with real titles must be formatted by hand (title: {title} | text: …). prompt_name="Document" hard-codes title: none. That's easy to get wrong in an ingestion pipeline and hard to notice afterwards.
What I'd do
For code search or IDE retrieval, evaluate v2 text-only (270M) against your current embedder on 200 to 500 real query→file pairs. If you're on v1, re-index. For mixed-media knowledge bases (screenshots, slide decks, recorded calls), prototype with text+image (440M) first and add audio only if retrieval on transcripts falls short.
Default to 256d and only go to 128d after measuring on your own data. Store the dimension and model ID with every vector. Lock dtype in config (bf16 on GPU or Apple Silicon, fp32 on CPU) and add a NaN assertion to the embedding job.
For local stacks, the GGUF and MLX builds exist on day one. On a Mac, the Ollama/MLX path I covered in Ollama September 2026 is the obvious place to start. For hosted Matryoshka trade-offs, compare against Cohere Embed 5.
What I couldn't verify
All benchmark numbers are Google's own; I found no independent MTEB/MMEB leaderboard entry in the sources I read. Google says it "outperforms some specialist models more than twice its size" but names none in the post. The Pixel 11 Pro RAM figures are vendor measurements, with no quantization format stated in the post. I didn't check whether llama.cpp, Ollama and LM Studio support the vision and audio inputs, or text only. The GGUF repo ships an mmproj, which suggests multimodal support, but I haven't tested it. No latency or throughput numbers (prefill per token, images/s) were published.
I'll revisit once independent MMEB results or a llama.cpp multimodal-embedding benchmark appear.
Sources
Primary: Google blog: EmbeddingGemma 2; Hugging Face model card: google/embeddinggemma-2; Hugging Face: ggml-org/embeddinggemma-2-GGUF.