Feature Article · For engineers

One shared space for text, code, images, video and audio.

EmbeddingGemma 2 puts text, code, images, video and audio in one 768-number space. What that changes in search, and five steps to check it yourself.

· 6 min read · sources read up to 25 Oct 2026

Seen on Instagram: the post this article goes with.

One model, five kinds of content

Google's developer guide for EmbeddingGemma 2, its open model for turning content into numbers, says the model "maps text, code, images, video, and audio into a unified 768-dimensional space" [1]. In plain words: each file goes in, a list of 768 numbers comes out, and the list for a photo sits on the same map as the list for a paragraph or a recording.

Two terms, once. An embedding is a list of numbers a model makes from content. A space is one map where similar things land close together. The guide says embeddings from different media "occupy the same dimensional space and can be compared on their semantic similarity" [1], and the model card says an embedding "can be compared directly against any other EmbeddingGemma 2 embedding" [2].

One precision. The model card counts four kinds of input: text, images, video and audio, and code goes in through the text side rather than a separate path [2]. We say five media because the guide and the launch post both name code alongside the rest [1][3]. If you are counting parts of the model, there are four.

At full size, every embedding is 768 numbers long whatever the media. The model card also lists shorter optional sizes [2]. We stay at full size in everything below.

What changes in a retrieval pipeline

This part is conditional. If your search stack keeps a separate store and a separate model for each kind of content, here is what Google's pages let you reconsider. The guide describes one space and direct comparison. It does not tell anyone to merge their stores, and we are not telling you to either [1].

The questionWhat the docs give you
Models to runOne download. You load only the parts you need, from a text-and-code setup up to one with image, audio and video [1]
Embedding sizesOne: 768 numbers for every media at full size [2]
Searching across mediaEmbeddings from different media can be compared directly, so one similarity search can span them [1][2]
StorageRoughly 1.5 GB per million full-size embeddings [1]
Adding media laterEmbeddings you have already computed do not need recomputing [1]
Ranking fairly across mediaThe docs don't say [1][2][3][4]

The last row is the open one, and it is why this article ends with a check you run yourself.

The storage line is arithmetic you can verify: 768 numbers at two bytes each, times a million embeddings, is about 1.5 GB [1]. That is embedding storage only. The four pages we read put no price on anything else, not compute, not querying, not testing, not hosting [1][2][3][4]. A claim that one space is cheaper to run is a guess until you measure it on your own stack.

The guide describes starting with a text-only setup and adding image or audio parts later by reloading the model with the extra part, and says the embeddings you already computed do not need recomputing [1]. That holds inside EmbeddingGemma 2. The guide says nothing about embeddings from other models, so whether moving from one of them would mean recomputing a whole collection is not something we can source [1].

The guide also says a query embedded with the small text-only setup can be matched directly against documents embedded with the full model [1]. If that holds on your data, the query side can stay light while the document side handles the media.

Five steps to check it on your own files

We have not run these steps. They follow the guide and the model card, and the last section says so plainly. What they show is the one thing a reader of the docs cannot see: where your own files land [1][2].

First, load the model once

The guide's route is sentence-transformers, a free Python library for making embeddings, version 6.1 or later [1]. Its install line is:

pip install -U sentence-transformers[image,audio,video] transformers

Then load google/embeddinggemma-2. The guide labels each piece of text as a query or a document when it encodes it [1]. Copy the loading and encoding calls from the guide's own examples; we have not run them, so we do not reprint them. The model card says the model is designed to run on consumer hardware such as laptops [2], and the Gemma docs describe running it locally and offline [4].

Second, embed ten of your own files

Pick ten files you are allowed to run through a model on your own machine: a few documents, a few code files, some screenshots, and one or two short clips of video and audio. One input holds a single 8,192-token window, which at default settings is about 29 images, 58 video frames or 5.5 minutes of audio, with one media type per input [2][3]. We found no source for how long video and audio take, or how much memory they need, on a laptop [2][4]. Start short.

Third, embed a plain-text question

Write the question you would really ask. Our example, not a result: "where do we set the retry limit?" Embed it as a query [1].

Fourth, rank every file against the question

Sort the ten files by how close each one's embedding is to the question's. All of them live in one space, so a single sort covers the documents, the code, the screenshots and the clips [1][2].

Fifth, check the ranking by eye

For each question, is the file you wanted near the top? Try three or four questions. Watch for one media type that always floats to the top, or never shows up.

The docs do not say whether the closeness numbers mean the same thing for an image as for a clip. None of the four Google pages we read covers it [1][2][3][4]. So the order is your evidence, and the numbers alone are not. Google's own advice for its smallest embedding size is to validate on your target data before deploying it for multimodal queries [1]. The habit is the same at full size.

What a good result would and would not tell you

A good ranking on ten files tells you the one space works for those ten files. It does not tell you the model is better than another one, and it does not price your pipeline. For that you need your real data and your real traffic.

We left some things out on purpose. The pages we read also cover a licence, optional shorter embedding sizes, number formats and comparisons with the previous version. Each deserves its own post.

What we checked, and what we did not

We read four Google pages on 25 October 2026: the developer guide, the model card on Hugging Face, the launch post and the Gemma docs [1][2][3][4]. The guide and the launch post are dated 6 October 2026 [1][3]. We did not download the model, run any of the steps or test any media type. Nothing here is reproduced; it is all from the docs, and the storage figure is also checked by arithmetic [1]. We looked at no other vendor's model, so this article makes no comparison with any. zenlite is independent of Google.

Sources

Each source was opened and read on the date shown. Numbers in square brackets in the text point here.

  1. EmbeddingGemma 2: The Developer Guide (Google Developers Blog)developers.googleblog.com · read 25 Oct 2026
  2. google/embeddinggemma-2 model card (Hugging Face, Google DeepMind)huggingface.co · read 25 Oct 2026
  3. EmbeddingGemma 2 launch post (blog.google)blog.google · read 25 Oct 2026
  4. Gemma docs: EmbeddingGemma (ai.google.dev, marked deprecated in favour of gemma.ai)ai.google.dev · read 25 Oct 2026