EmbeddingGemma 2 Released: 740M-Parameter Multimodal Embedding Model Under Apache 2.0 Open Weights
According to an official Google DeepMind blog post dated October 6, 2026, EmbeddingGemma 2 is released under the Apache 2.0 license with 740 million parameters, capable of mapping text, code, images, audio, and video into a unified embedding space, with 8K context support and truncatable vector dimensions.
What changed
According to an official blog post published by Google DeepMind on October 6, 2026, Google DeepMind introduced EmbeddingGemma 2, a multimodal embedding model designed for on-device inference. The model is built on the Gemma 4 architecture, has 740 million parameters, and is released under the Apache 2.0 license. The source states it can natively map combinations of text, code, images, audio, and video into a unified embedding space, using technology from the same lineage as Gemini Embedding. Design points reported by the source include: a minimum of roughly 270 million parameters for text-only scenarios, with a visual encoder of about 170 million and an audio encoder of about 300 million as optional modules; via Matryoshka representation learning, output vectors can be truncated from 768 dimensions to 512, 256, or 128 dimensions, which the source says yields up to roughly 6x storage savings; and an 8K token context window, which the source says is 4 times that of EmbeddingGemma 1, capable of handling about 5.5 minutes of audio, 29 images, or 58 video frames. Benchmark figures given by the source include MTEB Code improving from 68.76 to 78.68, i.e., a 9.92-point gain on code tasks, and it claims leading performance among multimodal embedding models under 1 billion parameters. The source also states that after quantization, text-only weights require about 191MB of active memory on a Google Pixel 11 Pro, and the full multimodal model about 567MB. Weights are available on Hugging Face and Kaggle; the source says support for Gemini Enterprise Agent Platform Model Garden is coming soon, and an on-device optimized version is at LiteRT Community on Hugging Face.
What it means for developers
For developers, the core variable in this release is that the capability boundary of embedding models extends from text to audio, video, and code, and the weights are released under Apache 2.0, allowing independent fine-tuning and redistribution, which creates different constraints from closed-source embedding services only callable through a vendor API. It should be noted that Apache 2.0 is openness at the license level, which is a separate matter from whether weights can be downloaded; the license information in this report comes from the source text, and the model card and license files should be checked before actual use. The source says EmbeddingGemma 2 shares the text tokenizer and audio encoder with Gemma 4, meaning that when placing the embedding model and the generative model in the same on-device pipeline, the source expects lower total memory usage, which has a direct impact on the deployment cost of offline RAG and on-device agents. Truncatable vector dimensions are another practical variable: the storage and recall quality of a vector store usually trade off as dimensions decrease, and the choice between 128 and 768 dimensions needs to be measured against one's own data scale rather than directly applying the source's promotional framing. The source also mentions available inference and deployment toolchains covering transformers, sentence-transformers, MLX, vLLM, llama.cpp, SGLang, Ollama, LMStudio, as well as browser-side transformers.js and WebGPU, and mentions Qdrant for vector storage. These tool names are deployment options listed by the source and do not mean this platform has integrated or verified the model; this version currently has no exact match in the KimiSeek live catalog, and the weight download and on-device deployment capabilities mentioned by the source point to publisher channels such as DeepMind and Hugging Face, not to this platform's API supply.
Integration and evaluation
Recommendation one: first decide whether you need multimodal embeddings, then decide whether you need the full model. The source reports that the full multimodal model after quantization uses about 567MB of active memory on a Pixel 11 Pro, text-only about 191MB, and the visual and audio encoders are optional modules. If your retrieval corpus contains only text and code, you can start by loading only the text path; bring in the corresponding encoders only if you genuinely have audio-visual retrieval needs. An actionable evaluation criterion is to measure cold-start latency, peak resident memory, and embeddings per second throughput on the target on-device hardware or the minimally acceptable server specification, confirming whether your latency budget is still met. Recommendation two: run your own recall experiment on MRL truncated dimensions rather than directly adopting the default 768 dimensions. The source gives three tiers of 512, 256, and 128, and a claim of up to 6x storage savings, but whether retrieval quality is acceptable depends on your corpus and query distribution. The evaluation criterion can be set as: on your own labeled or manually judged retrieval set, compare 768 dimensions with 256 and 128 dimensions in terms of Recall@10 and average query latency, adopting lower dimensions only when the quality drop is within your business threshold. Recommendation three: if code retrieval is the primary scenario, treat the source-reported MTEB Code gain as something to reproduce. The evaluation criterion can be set as: on your own codebase, use the same set of queries to measure hit rate and cross-language retrieval performance of EmbeddingGemma 1 and EmbeddingGemma 2 separately, because absolute scores on public benchmarks cannot substitute for relative comparisons on a private codebase. All of the above are recommendations and conditional analysis based on the source information, not established facts reported by the source.
Limits and open questions
First, it must be made clear: EmbeddingGemma 2 currently has no exact match in the KimiSeek live catalog, this platform has not listed the model, and the weight download and on-device deployment capabilities described by the source all point to publisher channels such as DeepMind and Hugging Face, not to this platform's API supply. Second, the benchmark scores in the source (including the MTEB Code improvement from 68.76 to 78.68 and statements about leading performance under 1 billion parameters) come from the publisher's own claims, and the blog does not list complete evaluation conditions, the list of compared models, or the evaluation version, so they cannot be regarded as independently verified results, and actual performance needs to be reproduced by the reader. Third, the memory and storage figures given by the source (about 191MB, about 567MB, up to 6x savings) are based on a specific quantization method and the Google Pixel 11 Pro device, and may not hold on other hardware or quantization configurations. Fourth, the source mentions a joint memory advantage from sharing the tokenizer and audio encoder with Gemma 4, but the actual figures are not given in the source. Fifth, support for Gemini Enterprise Agent Platform Model Garden is labeled in the source as 'coming soon,' which is a planning statement and does not mean it is currently available; this platform also does not provide API access to this model. Prices and availability change over time, and readers should refer to each publisher's current pricing page and model card.
Illustrations from the original report
