Google has open-sourced the multimodal embedding model EmbeddingGemma 2 on Hugging Face. The model has 740M total parameters, evolves from the Gemma 4 architecture, and is designed specifically for edge devices such as phones and laptops.
It topped the trending list yesterday, and its core advantage is its extremely low runtime requirements, as follows:
- Text only, 270M parameters, bfloat16 VRAM / memory usage about 600MB - 1GB
- Text + image, 440M parameters, bfloat16 VRAM / memory usage about 1GB - 1.5GB
- Text + audio, 570M parameters, bfloat16 VRAM / memory usage about 1.2GB - 2GB
- Full modality, 740M parameters, bfloat16 VRAM / memory usage about 1.8GB - 3GB
In other words, as long as a device has 4G of VRAM/memory space, it can run this model completely, and mainstream flagship phones can run it without any issue.
Next, the technical details.
In the past, cross-modal retrieval or on-device RAG often required maintaining multiple dedicated embedding models, with separate vector spaces. For example, for local photo album search, you need a vision model to write descriptions for images, convert speech to text, and finally use a text model to retrieve the descriptions.
EmbeddingGemma 2 maps text, code, images, audio, and video into the same 768-dimensional vector space, allowing mixed text, image, audio, and video in a single input and sharing an 8K context, making it possible to directly run cross-modal search and offline multimodal knowledge bases on-device.
For example, input a sentence, "the sunset I shot at the beach last year," or drop in a hummed melody, and the model can directly cross modalities to locate the specific video frame or audio clip in local files.
This means on-device RAG and personal assistant hardware no longer need to upload data to the cloud, fully achieving local, private operation.
In its engineering architecture, the model is modularly decoupled. Of the 740M total parameters, the text backbone accounts for 270M, the vision encoder 170M, and the audio encoder 300M.
If only text-only or image-text retrieval is needed, unnecessary encoders can be directly removed at load time, minimizing VRAM usage. At the same time, the model natively supports nested representation learning, and vector dimensions can be truncated to 512, 256, or even 128 dimensions.
When reduced to 256 dimensions, retrieval quality has almost no loss, while vector storage costs can be directly reduced to one third of the original. The direct benefit is that on an ordinary thin-and-light laptop or even in a lightweight local database on a phone, hundreds of thousands of multimodal records can be retrieved smoothly with extremely low latency.
The only flaw, if you can even call it that, is the 8K context limit. Audio eats 25 tokens per second, so long audio and video still have to be chunked before indexing. But at this point, what more could you really ask for?