EmbeddingGemma 2 for multimodal search: what to check first

Google released EmbeddingGemma 2 on 6 October 2026, an open embedding model that puts text, code, images, video and audio into one 768-dimensional vector space.¹ It has 740 million parameters, ships under Apache 2.0 and is small enough that Google demonstrates it on a phone. The most useful design choice is that its encoders are modular. You can run the 270M text-only part today, add the image or audio encoder later, and the new vectors land in the same space as the old ones.

Every benchmark number published so far comes from Google. We searched on 13 October and found no independent evaluation, so the scores below are vendor-reported. The model card is unusually detailed about the trade-offs, though. Three of them decide whether the model suits a given search product. Quality falls faster for images and audio than for text when you shorten the vectors, every modality shares one context window, and two settings degrade embeddings without raising an error.

This post goes through what Google released, what the card’s numbers say and don’t say, and how we would test the model before moving a search index onto it.

What Google released on 6 October

Sources: Google’s launch post, developer guide and model card.¹²³ Google lists support in Transformers, Sentence Transformers, vLLM, SGLang, MLX, llama.cpp, Ollama, LM Studio and transformers.js, and Qdrant for storage.

Four configurations from one checkpoint

The developer guide describes four ways to load the same weights.²

Google says all four share one vector space, so a query embedded with the 270M configuration can match documents embedded with the full model, and adding an encoder later doesn’t require recomputing existing embeddings.²

That changes how you can roll out multimodal search. With most stacks, adding image search means a second model, a second index and a fusion step, or a full re-embed with a multimodal model. Here a team can ship text search on the small configuration, keep the text vectors, and later embed only the new images with the vision encoder enabled. Text queries then find images, and image queries find text, in one index. We haven’t tested how well text-to-image matching works in practice, and the card has no number for it in isolation. That belongs in your own evaluation.

Google’s numbers, and what they compare against

The model card reports these results at 768 dimensions and full precision.³

Read it for what it compares. The only model named on the card is EmbeddingGemma 1. Multilingual text is flat, at 61.36 against 61.15. Code is the real gain, about 10 points or 14% relative, which Google’s guide also quotes.² The launch post says the model leads sub-1B multimodal embedders on MTEB Code and MAEB and outperforms “some specialist models” more than twice its size, without naming those models in the text.¹

So the card tells you EmbeddingGemma 2 is at least as good as its predecessor on text and much better on code. How it ranks against the hosted embedding API or the CLIP-style model you already run is still an open question. For image search in particular, a domain-tuned model can beat a general one by a wide margin. When we compared FashionSigLIP, CLIP and DINOv2 for visual product search, the fashion-tuned model put the right product in the top five 63% of the time, against 38% for general CLIP. A general multimodal embedder has to be tested against that kind of baseline on your own data.

Shorter vectors cost multimodal quality first

EmbeddingGemma 2 uses Matryoshka representation learning, so you can keep the first 512, 256 or 128 dimensions of each vector. The model card gives scores at each size.³

The losses are uneven. Going from 768 to 128 dimensions costs English text about 4% of its score (68.46 to 65.68). It costs the MMEB multimodal score about 23% (59.01 to 45.65) and speech retrieval about 18% (69.54 to 56.71). At 256 dimensions the multimodal drop is under 5%. The card says 128 dimensions “degrades multimodal quality substantially” and suits text-only workloads.

Storage is the reason to shorten at all. Google’s guide puts a million 768-dimension vectors in bfloat16 at about 1.5 GB and the same million at 128 dimensions at about 250 MB.² Its own advice is 768 or 512 for multimodal and visual-document retrieval, 256 for storage-constrained indexes, and 128 for large text-only indexes or a first-stage shortlist. A common pattern that fits these numbers is to shortlist with 128-dimension vectors and rerank the shortlist with the full 768.

One 8,192-token budget for every modality

The 8K window is shared. The model card gives the default token cost of each input type.³

The vision budget per image can be set anywhere from 70 to 1,120 tokens, which trades detail for count. At the low end about 114 images or frames fit. Interleaved inputs share the same budget, so a product page with text, four photos and a short clip uses it up quickly.

For video, this decides your chunking. One embedding covers roughly a minute at the default frame rate, so a ten-minute lecture becomes at least ten vectors, and a search hit points to a segment. One of Google’s demo apps, Video Moments Finder, is built around finding moments in video.¹ Audio works the same way at about five and a half minutes per vector.

Settings that degrade embeddings without an error

Three details from the model card and guide would cost recall quietly if you missed them.³²

Don’t run it in float16. The card says the model’s activations exceed float16’s range and can return NaN or “silently degraded” embeddings without raising an error. Use bfloat16 where the hardware supports it, or float32. Check which precision your inference server actually loads, because half precision is a common setting for speed.

Use the task prompts. Text inputs take a prompt name. Retrieval uses SearchQuery for queries and Document for documents, and the card lists others for question answering, fact checking, code retrieval, classification, clustering and similarity. It warns that leaving out the prefix may reduce quality. The Document prompt fills in title: none, so if your documents have titles, format them yourself as title: {title} | text: {content}. Prefixes apply only to text. Images, video and audio go in without one.

Match the audio format. The guide expects 16 kHz mono audio. Resample before embedding rather than trusting each loader to do it.

With Sentence Transformers 6.1 or later, a text-only setup with the right prompts and a shorter vector looks like this:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},  # 270M text-only
    truncate_dim=256,
)
docs = model.encode(["title: Refund policy | text: Refunds are issued within 14 days..."], prompt_name="Document")
query = model.encode("how long do refunds take", prompt_name="SearchQuery")
print(model.similarity(query, docs))

Note that the document is formatted with its title by hand, and the query and document use different prompts.

Running it on a device

Google’s launch post reports about 191 MB of active RAM for quantised text-only weights and about 567 MB for the full multimodal model, measured on a Pixel 11 Pro.¹ Google also publishes LiteRT builds of the 740M and 270M text-only variants and supports MediaPipe and transformers.js with WebGPU.¹ We haven’t measured latency or memory ourselves, and Google gives no latency figures in the post.

On-device embedding matters for products that index private content, such as photos, notes and recordings, where uploading everything to a server is a privacy or cost problem. The card also notes that this is a pre-trained embedding model that “does not undergo post-training alignment, safety tuning, or output-level moderation”, and leaves retrieval filtering and fairness testing to the developer.³

How we would test it before switching

The model card is enough to decide that EmbeddingGemma 2 is worth testing. The decision to switch needs your own queries. Our routine for an embedding change:

1. Collect 100 to 300 real queries with the documents a person judged correct. For multimodal search, include text-to-image, image-to-text and image-to-image queries in proportion to real traffic.
2. Embed the corpus with the current model and with EmbeddingGemma 2 at the dimension you’d actually deploy, not only at 768.
3. Compare Recall@10 and nDCG@10, and read the queries where the two models disagree. The disagreements show you what each model is good at.
4. Check the precision setting and the prompts on the inference server you’ll use in production, since both change the vectors.
5. If you plan to start text-only and add vision later, test that path directly. Embed the text corpus with the 270M configuration, the images with the vision configuration, and measure cross-modal queries against that mixed index.

Frequently asked questions