Google DeepMind releases EmbeddingGemma 2, and its card and config disagree on the sliding window

Google DeepMind released EmbeddingGemma 2 on October 6, 2026, an open embedding model that maps text, code, images, video and audio into one 768-dimensional vector space. The model card gives it 740M parameters in total, and Hugging Face counts 744,371,512 in its weight file. Google’s announcement says it is released under the Apache 2.0 licence and can be cut down to a 270M text-only core. Its weights are a single 1.49 GB file. We have not run it. Every quality, memory and speed claim below is Google’s, taken from its announcement, the model card, the repository’s config file and the Hugging Face data we saved on October 15.

Takeaway points

• Google DeepMind released EmbeddingGemma 2 on October 6 with 740M parameters, and its weights come to 1,488,915,288 bytes in one file.
• The model card says shorter vectors cost quality, with the MMEB multimodal score falling from 59.01 at 768 dimensions to 45.65 at 128.
• We have not run the model, and Google’s card and config file disagree on its sliding window, at 1024 and 512 tokens.

What is EmbeddingGemma 2 and how big is it?

EmbeddingGemma 2 is a model that turns an input into a list of 768 numbers, so that a search system can compare a text query with a photo, a video clip or a voice recording by how close their numbers sit. It does not write text. The card calls it “a pre-trained embedding model” and says it has no post-training alignment, safety tuning or output moderation.

The card splits the 740M parameters into four parts, and says the vision and audio parts can be left out when they are not needed.

The card gives the effective size of each combination: 270M for text only, 440M for text and images, 570M for text and audio, and 740M with everything loaded. The text model has 24 layers, a model dimension of 512 and a vocabulary of 262,144 tokens, and it projects from 512 to 768 dimensions at the end.

Hugging Face records the repository google/embeddinggemma-2 as created on September 14, 2026, three weeks before the announcement. Its history shows one squashed commit, dated October 6. The repository is not gated, and its metadata gives the licence as apache-2.0. The weights are in bfloat16, and the card warns against float16: in that format, it says, the model “returns NaN or silently degraded embeddings rather than raising an error.”

Google’s announcement says the first EmbeddingGemma has had more than 20 million downloads. On code it gives the new model a 9.92-point gain on the MTEB code benchmark, from 68.76 to 78.68, and the card calls the same gain about 14%. By our arithmetic both describe one result. On the multilingual text benchmark the card shows 61.36 against 61.15 for the first model, a near tie. We have not reproduced any score.

How much does truncating EmbeddingGemma 2 vectors cost in quality?

Little down to 256 dimensions, and a lot at 128 for images, video and audio, by the card’s own table. The model is trained with Matryoshka Representation Learning, which lets a 768-number vector be cut to its first 512, 256 or 128 numbers. Google’s announcement presents this as “up to 6x storage reduction”. The card adds the condition: 128 dimensions “degrades multimodal quality substantially” and should be checked against the user’s own data first.

The card says 128 dimensions is “best suited to text-only workloads”. It also sets two rules for anyone storing shorter vectors: they must be normalized again after cutting, and a query and the stored documents must use the same length. Skipping the first step, the card says, produces plausible-looking scores rather than an error.

What limits does the EmbeddingGemma 2 context window put on video and audio?

All inputs share one window of 8,192 tokens, and the card prices each kind of media against it. An image costs 280 tokens by default, which fits about 29 images. A video frame costs 140 tokens, about 58 frames, and video is sampled at one frame a second by default. Audio costs 25 tokens a second, which fits about 327 seconds, and must be mono at 16 kHz.

At one frame a second, 58 frames is under a minute of video. Google’s announcement puts the audio limit at “up to 5.5 minutes”, and the card’s 327 seconds is 5.45 minutes by our arithmetic. The card says a lower vision budget can raise the limit to about 114 images or frames, at a cost in quality. Mixing kinds of media in one input draws on the same budget, so less of each fits. The announcement says the window is four times that of the first EmbeddingGemma.

Do Google’s documents and Ollama’s listing agree on EmbeddingGemma 2?

Not in three places. The first is inside Google’s own files. The card’s architecture table gives a sliding window of 1024 tokens, while the repository’s config file sets sliding_window to 512. Both agree on the pattern of five sliding-window layers to one full-attention layer, and the config lists four full-attention layers among 24. We do not know which window figure is meant to stand.

The second is the context length. Ollama’s library page lists every embeddinggemma-2 tag with a “256K context window”. The model card gives 8,192 tokens. The config file holds a max_position_embeddings of 262,144 for the text model, which may be where the larger figure comes from, though Ollama does not say. The way Ollama sets context by default is covered in Ollama’s default context length for Gemma 4 31B on a 48 GB Mac.

The third is input types. Ollama lists its 740m tag as taking “Text, Image” and its 570m tag, the text and audio build in Google’s table, as text only. Ollama’s page does not list audio or video input for any tag.

The timing is also out of step. Ollama’s release v0.40.0, dated September 25 on GitHub, says “MLX now has support for an embedding model: embeddinggemma-2”, eleven days before Google’s announcement. That release is the one covered in Ollama making MLX its default on Apple silicon. Google’s announcement lists Ollama, MLX, llama.cpp, vLLM, SGLang and LM Studio among the tools that serve the model.

On the licence the documents agree, though the card’s link is odd. All four sources give Apache 2.0: the model card, the Hugging Face metadata, the announcement and Google’s documentation page. The card’s licence line reads “Apache 2.0”, but the link behind those words points to an address on Google’s developer site named for the Gemma 4 licence. We opened that page: its title is “Apache License 2.0” and its text is the standard Apache License, version 2.0. So the licence named and the text linked match, though the address names Gemma 4.

The card adds a condition outside the licence: “Deployments must adhere to the Gemma Prohibited Use Policy.” It does not say how that policy relates to the Apache terms.

Google’s documentation page has a smaller inconsistency. It describes the first EmbeddingGemma as a 308M model, and a few lines earlier says the text model shrank “from 300M parameters down to 270M parameters”.

Will EmbeddingGemma 2 fit on a 48 GB Mac?

Yes, by file size. The weight file is 1,488,915,288 bytes, about 1.49 GB, and every file in the repository together comes to 1.53 GB, against the 48 GB of memory on our test machine, an Apple M4 Pro. The model is small enough to sit beside a chat model, the use Google describes when it pairs EmbeddingGemma 2 with Gemma 4 and says the two share a text tokenizer and audio encoder. Our measurement of two models at once on a 48 GB Mac was made with other models, not this one.

Google gives one memory figure of its own, for a phone. The announcement says that with quantization on a Pixel 11 Pro the model “requires as little as ~191MB active RAM for text-only weights and ~567MB for the full multimodal model.” It gives no figure for a laptop. The LiteRT Community repositories, which the announcement points to for on-device builds, were created on September 29.

What has Google not published, and have we tested EmbeddingGemma 2?

We have not tested EmbeddingGemma 2, so this piece has no speed, memory or quality figure of our own. We read the announcement, the model card, the config file, Google’s documentation page, Ollama’s release notes and library page, and the Hugging Face data, and compared the file size with our machine’s memory.

Several things are missing from Google’s material. The announcement says the model “outperforms some specialist models more than twice its size”, but the card’s benchmark table compares it only with the first EmbeddingGemma, and names no other model. Neither document gives a speed figure for a laptop or desktop. The card states a training data cutoff of January 2025 and content in over 140 languages, but gives no token count or data mix. Google has not explained the 1024 and 512 sliding window figures, and Ollama has not explained its 256K context listing or why its tags do not list audio input. If you run the model through Apple’s MLX runtime, what MLX is in LM Studio covers that runtime on the same kind of Mac.