Google DeepMind released EmbeddingGemma 2 on October 6, 2026. It is an Apache 2.0 multimodal embedding model with 740 million parameters, built on the Gemma 4 architecture. The model maps text, code, images, video, and audio into one shared embedding space. Weights are on Hugging Face as google/embeddinggemma-2 and on Kaggle, with Model Garden availability noted as coming soon.
EmbeddingGemma 1 was text-focused and passed 20 million downloads. Version 2 keeps that on-device design goal and adds native multimodality. That matters for local retrieval-augmented generation (RAG) and multimodal search: one model can index a codebase, screenshots, meeting audio, and short video clips without sending raw media to a remote API.
What changed versus EmbeddingGemma 1
The Google blog post by Sahil Dua and Henrique Schechter Vera lists several concrete upgrades:
- Modalities. Text and code remain first-class. Images, video, and audio join the same vector space.
- Context. The context window is 8,192 tokens, four times EmbeddingGemma 1. That covers up to about 5.5 minutes of audio, 29 images, 58 video frames, or interleaved mixes of those inputs.
- Code retrieval. On MTEB Code, the score moves from 68.76 to 78.68, a 9.92-point gain. The model card also describes roughly a 14% improvement on code relative to the predecessor.
- Multilingual text. MTEB multilingual v2 Mean(Task) is 61.36 versus 61.15 for EmbeddingGemma 1 at full 768-dimensional precision. Text quality is essentially held while code and new modalities expand.
- Footprint options. Text-only work can stay at 270M parameters. Vision (170M) and audio (300M) encoders load only when needed.
- Storage. Matryoshka Representation Learning (MRL) lets you truncate the native 768-dimensional output to 512, 256, or 128 dimensions for up to 6x storage reduction.
The model sits in the same technology family as Gemini Embedding models, while staying open under Apache 2.0 for commercial use.
Architecture and modular sizes
The model card breaks the 740M total into modular parts:
- Text backbone: 270M (130M transformer plus 140M embedder)
- Vision encoder: 170M
- Audio encoder: 300M
Core architecture details from the card:
- 24 layers
- Model dimension 512, hidden dimension 2048
- Vocabulary size 262,144
- Attention: GQA/MQA
- Pooling: mean pooling
- Projection: 512 to 768
- Native output dimension: 768
- MRL truncation dimensions: 128, 256, 512
- Context window: 8,192 tokens
- Languages: 100+
The developer guide documents four practical load configs that share one vector space:
- 270M: text only
- 440M: text plus vision
- 570M: text plus audio
- 740M: full multimodal
Because all configs project into the same space, a text-only query from the 270M setup can match documents embedded with the full model. You can start with a text index and later enable vision or audio without re-embedding existing text vectors.

Benchmarks
All numbers below are from the model card at 768 dimensions and full precision unless noted. Google reports EmbeddingGemma 2 as leading among sub-1B multimodal embedders on MTEB Code and MAEB, and as matching or outperforming many larger models on text, vision, and audio tasks.
Overall results at 768d:
- MTEB multilingual v2 Mean(Task): 61.36 (EmbeddingGemma 1: 61.15)
- MTEB code v1 NDCG@10: 78.68 (EmbeddingGemma 1: 68.76)
- MIEB lite Mean(TaskType): 64.64
- MMEB v2 Image Hit@1: 57.28
- MMEB v2 VisDoc NDCG@5: 67.84
- MMEB v2 Video Hit@1: 50.67
- MSEB Retrieval MRR@10: 69.54
- MAEB Mean(Task): 49.39
The code jump is the clearest text-side change. Local codebase indexing, semantic code search, and coding-agent retrieval are the use cases the Google blog calls out.

MRL truncation and storage tradeoffs
MRL lets you keep only the leading dimensions of each embedding, then L2-normalize again. Queries and documents must use the same dimension. Skipping re-normalization after truncation silently hurts ranking quality.
Truncation quality from the model card (key rows):
| Dim | Compression | MTEB multi | MTEB eng | MTEB code | MIEB | MMEB overall | MSEB | MAEB |
|---|---|---|---|---|---|---|---|---|
| 768d (full) | 1:1 | 61.36 | 68.46 | 78.68 | 64.64 | 59.01 | 69.54 | 49.39 |
| 512d | 1:1.5 | 61.17 | 68.41 | 77.24 | 64.32 | 58.38 | 69.18 | 49.21 |
| 256d | 1:3 | 60.41 | 67.78 | 76.18 | 63.13 | 56.24 | 66.76 | 48.91 |
| 128d | 1:6 | 57.89 | 65.68 | 71.41 | 59.06 | 45.65 | 56.71 | 46.92 |
Guidance from the developer guide:
- 768d or 512d: Prefer when multimodal or visual-document recall matters more than storage.
- 256d: About a 3x storage cut. Keeps most full quality on text and code, and about 95% on image, video, and speech retrieval.
- 128d: About a 6x storage cut. Around 90% text/code quality and around 75% multimodal quality. Validate before using 128d for multimodal queries.
Storage example from the guide: one million vectors in bfloat16 take roughly 1.5 GB at 768d versus about 250 MB at 128d.
In sentence-transformers, pass truncate_dim with normalize_embeddings=True on encode(), or set truncate_dim at load time so every call shares one dimension.
How to run it
Install and load
The developer guide requires sentence-transformers v6.1.0 or later:
pip install -U sentence-transformers[image,audio,video] transformersFull model:
from sentence_transformers import SentenceTransformer
MODEL_ID = "google/embeddinggemma-2"
model = SentenceTransformer(MODEL_ID)Selective encoders via config_kwargs:
# Text only (270M)
text_only = SentenceTransformer(
MODEL_ID,
config_kwargs={"vision_config": None, "audio_config": None},
)
# Text + vision (440M)
text_vision = SentenceTransformer(
MODEL_ID,
config_kwargs={"audio_config": None},
)
# Text + audio (570M)
text_audio = SentenceTransformer(
MODEL_ID,
config_kwargs={"vision_config": None},
)Task prefixes
Text inputs use short instruction prefixes. Skipping them still works but reduces precision. Prefixes apply to text only; pass images, video, and audio without a prefix.
Asymmetric tasks use different query and document prefixes. Symmetric tasks use the same prefix on all compared inputs. Examples from the model card:
- SearchQuery:
task: search result | query: {query}with documents astitle: {title} | text: {content} - CodeRetrieval:
task: code retrieval | query: {query}withtitle: {title or filename} | text: {code}
Other prompt names listed on the card include QuestionAnswering, FactChecking, Classification, Clustering, and SentenceSimilarity. In sentence-transformers you can pass prompt_name (for example "SearchQuery" or "Document"). prompt_name="Document" applies title: none; titled documents should be formatted manually.
Interleaved multimodal inputs
Mark media positions in text with <|image|>, <|video|>, and <|audio|>. Encoded together, they produce one vector that can be compared to a text-only query in the same space.
Token budget
All modalities share 8,192 tokens. Default costs from the model card:
- Text: 1 token per subword
- Image: 280 tokens per image by default (about 29 images max alone)
- Video: 140 tokens per frame by default (about 58 frames max alone)
- Audio: 25 tokens per second (about 327 seconds max alone)
Defaults: video at 1 FPS; audio as 16 kHz mono. Vision soft-token budgets can range from 70 to 1120 tokens per image or frame when you trade latency for finer visual detail.
Precision warning
Run inference in bfloat16 or float32. Do not use float16. The activation range exceeds float16; the failure mode is NaN or silent degradation rather than a hard error.
Ecosystem
Beyond sentence-transformers, the Google blog lists MediaPipe, LiteRT, transformers.js, WebGPU, transformers, MLX, vLLM, llama.cpp, SGLang, Ollama, LMStudio, and Qdrant. Fine-tune guidance is available via Unsloth. LiteRT Community builds on Hugging Face target on-device deployment.
On-device use and pairing with Gemma 4
Quantized on a Pixel 11 Pro, Google reports about 191 MB active RAM for text-only weights and about 567 MB for the full multimodal model. That is the on-device framing: local indexing for privacy, lower latency, and offline search.
EmbeddingGemma 2 pairs with Gemma 4 for on-device RAG. The two share a text tokenizer and audio encoder, which lowers combined memory when both run in one pipeline. EmbeddingGemma 2 embeds multimodal context; Gemma 4 does generation and reasoning over retrieved chunks. For cloud-side Gemini context, see our note on Gemini 4 Argon pricing and limits; EmbeddingGemma 2 is the open, local embedding counterpart in the broader Google stack.
Google points to demos of these local patterns: Instant Media Search and Video Moments Finder in the Google AI Edge Gallery, and local file retrieval plus Gemma 4 reasoning in the Google AI Edge Foresight app.
If you are building skills around Gemma and related tooling, Google also appears among the verified free AI courses for 2026.
Limits and responsibilities
From the model card:
- Pretraining data cutoff: January 2025.
- EmbeddingGemma 2 is not post-trained for safety the way generative models often are. Safeguards during development focused on pretraining data filtering.
- Developers own application-level safeguards such as retrieval filtering and fairness testing.
- Deployments must follow the Gemma Prohibited Use Policy.
- Performance is not equal across all 100+ languages.
- Omitting task prefixes can reduce text embedding quality.
- Biases in training data can affect representations; continuous evaluation is recommended for production use.
Treat EmbeddingGemma 2 as a retrieval and representation tool, not as a moderated chat model. App policy, filtering, and evaluation remain your responsibility.
