EmbeddingGemma 2, explained: one open model for text, code, pictures and sound, tested on a laptop

I downloaded the model (one 1.49 GB file) and ran it with sentence-transformers 6.1 on a MacBook Air with an M4 chip and 24 GB of memory, in float32. The card warns against float16, which it says can quietly return broken vectors.

I wrote 20 short texts on everyday and engineering topics: an overheating laptop, cancelling a subscription, a palindrome function in Python, a SQL query, rate limiting, bread rising, and so on. Then I asked 8 questions worded so that they share almost no words with the right answer, one of them in Spanish. Each question was turned into a vector, compared with all 20, and the closest won.

Google trains the model with short instructions in front of the text, such as "task: search result | query:" for a question. sentence-transformers adds them for you when you pass prompt_name. I ran the search with them and once without, to see whether they mattered.

Seven of the eight questions put the right text first. "Why can't you make good tea at the top of Everest" found the text about water boiling at a lower temperature on a mountain, at 0.750, even though the question never mentions water, boiling or air pressure. The Spanish question about bread rising found the English text about yeast at 0.823. The plain-English request for "the top five customers by number of purchases" found the SQL query at 0.817.

The miss is instructive. "Stop one client from hammering my server with requests" should find the rate limiting text. It came second at 0.698, behind the load balancer text at 0.716. Both are about too much traffic, and the model weighed "server" and "requests" over "one client". A real search would show both in the top three, which is why RAG systems usually fetch several results, and often re-rank them, instead of trusting the first one.

Leaving out the task prefixes changed no ranking on this small set, but the average gap between the right answer and the best wrong one shrank from 0.112 to 0.098. The prefixes cost nothing, so use them.

The new part is that pictures live in the same space as words. I took six product illustrations from this site, a graphics card, a hard disk, a memory stick, a network switch, a rack server and an SSD, and gave each to the model as an image with no caption. Then I typed six plain descriptions and let each one pick the closest picture.

All six picked the right one. The margins were thin: the runner-up was between 0.02 and 0.09 behind, and the SSD was the most common runner-up, which makes sense because several of these parts look like flat boards. Six pictures is a demonstration, not a benchmark, but it shows the claim is real: one model, one space, and a sentence can be compared with an image directly.

I did not test audio or video. Google says they work through the same call; this page only reports what I ran.

Every vector has to be stored, usually in a vector database, and searched. At 768 numbers of 4 bytes each, one vector is 3,072 bytes, and a million of them is about 3 GB before any index. EmbeddingGemma 2 is trained with Matryoshka Representation Learning, named after Russian nesting dolls: the most useful information is packed into the front of the list, so you can keep only the first 512, 256 or 128 numbers, rescale the result to length 1, and still have a usable vector. At 128 numbers that is a sixth of the storage, the "up to 6x" in Google's post.

Google's own table shows the cost: the multilingual text score goes from 61.36 at 768 to 60.41 at 256 and 57.89 at 128, and the multimodal score falls much harder at 128, from 59.01 to 45.65. I ran my 8 questions at every length. The answers held, and 128 even fixed the one miss, but look at the margins: the average gap between right and wrong stayed near 0.11 down to 256 and fell to 0.069 at 128.

The next figure shows why that matters. At 128 numbers every score moved up and the field squeezed together, so the winner on the missed question won by 0.001. That is not the model understanding better; it is a coin landing the right way. Two rules from the model card are easy to get wrong: rescale after cutting, and never compare a 768-number question with a 128-number collection.

Read next: Shorter embeddings: how much can you cut?

A top-1 count hides how close the race was. Here are all 20 scores for the question that missed, at full length and at 128 numbers, on the same scale. At 768 the scores spread from 0.494 to 0.716, and the right text was a close second. At 128 they spread only from 0.685 to 0.805, and the right text won by a hair.

If you use a score cut-off, say "only show results above 0.7", the bunching matters even more: at 128 numbers almost every text clears it. A cut-off tuned at one length is meaningless at another.

I did not draw these vectors as a map of dots. Squashing 768 numbers into two for a picture kept only 18% of the spread in my data, so the distances on such a map would mislead you.

Embedding one sentence took a median of 46.9 ms on the M4's CPU and 40.2 ms on its GPU through MPS (Apple's interface to the Mac's graphics chip). A batch of all 20 texts took 305 ms on the CPU and 326 ms on the GPU, about 15 ms each. For a personal search index of a few thousand notes that is seconds, not minutes.

Memory is the place to be careful with comparisons. Loading only the text part counted 271 million parameters and the full model 744 million, matching the card. The peak memory of my Python process was 2,257 MB for text only and 4,866 MB for the full model, but that is float32, unquantized, and includes PyTorch itself and a temporary copy during loading. Google's 191 MB and 567 MB are for a quantized version on a phone, so they are not the same measurement.