EmbeddingGemma 2’s Storage Savings Depend on What You Search

Google has released a small AI model that lets an application find a photograph from a written description, locate a passage in a recording or search code by meaning. EmbeddingGemma 2, announced October 6, turns those different inputs into lists of numbers that a search system can compare. Developers can run it locally instead of sending every search to a remote server. Google’s announcement

One attractive feature is less obvious than its ability to handle several kinds of media. Developers can shorten those numerical lists, called embeddings, to reduce storage. Google’s results show why that choice deserves its own test: the smallest setting preserves text performance better than it preserves performance across images, video and other media.

That difference matters to anyone building a searchable archive. A shorter index can fit more records on a phone or laptop. Missing a useful picture or recording, however, can make an apparently efficient application less useful. Google has supplied enough detail for developers to begin comparing both outcomes before committing an entire archive to one setting.

What a smaller index buys

EmbeddingGemma 2 normally produces a vector with 768 dimensions, meaning 768 numerical values. It also supports 512, 256 and 128 dimensions through a method called Matryoshka representation learning. Important information is learned at several nested sizes, so developers can retain a shorter portion of the vector. Google’s developer guide

Storage arithmetic makes the attraction clear. One million 768-dimensional vectors, each stored as four-byte floating-point values, occupy 3.072 billion bytes, or 3.072 gigabytes in decimal units. At 256 dimensions, that falls to 1.024 gigabytes. At 128, it becomes 512 megabytes. These are calculations for numerical values alone, excluding search-index structures, filenames, permissions, original media and the model itself.

For an application that stores several passages from each document, the number of vectors can grow much faster than its document count. Conversely, an archive with little material may save too little space to justify extensive tuning. Developers need the number of indexed passages or media segments, their storage format and their expected growth to estimate a useful saving.

The underlying approach predates this release. In their Matryoshka representation learning paper, Aditya Kusupati and colleagues described learning representations at different levels of detail so a system could change representation size to suit its needs. Their research establishes the method; it does not predict how every later model will perform on a particular collection. Matryoshka research paper

Query and stored vectors must match dimensions. Google instructs developers to normalize after truncation and configure stored records and new searches consistently. Developer configuration guide

Google’s results separate text from other media

MMEB v2 tests retrieval across several types of media. Google reports overall scores of 59.01 at 768 dimensions, 56.24 at 256 and 45.65 at 128. The smallest setting uses one-sixth as many values while losing 13.36 points, a relative score decline of about 22.6%. EmbeddingGemma 2 model card

At 256 dimensions, it retains about 95.3% of that benchmark score using one-third as many values. These calculated ratios cannot predict missed results in a particular archive.

Google’s multilingual text score changes less sharply, from 61.36 to 57.89. Its guidance says: “128d is best suited to text-only workloads.” An application searching mixed media should compare larger settings before adopting the smallest one. Google’s benchmark table and guidance

The decision also depends on what a failed search costs. A team can compare whether known relevant records appear among the first five or ten results, then examine which kinds of records disappear as vectors shrink. That proposed test would make storage savings comparable with actual search failures, rather than relying on a single average across unfamiliar tasks.

Research on retrieval supports checking the collection itself. The BEIR benchmark, introduced by Nandan Thakur and colleagues in 2021, evaluated retrieval systems across 18 datasets. Its findings showed substantial differences across tasks and found a traditional keyword method, BM25, remained a strong baseline. BEIR did not test EmbeddingGemma 2, but it explains why a modern model’s general reputation cannot replace a comparison on the documents people actually need. BEIR research paper

The researchers found that re-ranking systems performed strongly, at greater computational cost. Re-ranking takes an initial list of candidates and orders it again, adding another choice between quality and computing cost on a phone or laptop. Historical comparison

Running locally still requires an application budget

Google’s AI Edge guide reports about 191 megabytes of active model-weight memory for the text configuration and about 567 megabytes for the full configuration on a Pixel 11 Pro. Those figures describe specified model configurations on a particular device. An application must also accommodate its index, media decoding and other processes. Google’s AI Edge guide

All encoder configurations share a vector space. Google says a text-only query can search records indexed with the full model, and adding an encoder does not require recomputing existing embeddings. That lets an application load fewer components without shortening its vectors. Encoder configuration guidance

The guide includes local media-search demonstrations using SQLite, a small database, and similarity comparisons. Its examples show a practical route to a product. They do not establish a battery-life or response-time result for every handset. Google also described an ML Kit service and additional hardware acceleration as forthcoming in its October 6 post. An available model and a promised integration have different release dates.

Keeping inference local can remove a required transfer of the original input to a cloud service. It does not decide who can open the index, whether a device backup copies it elsewhere or how an application deletes a former employee’s documents. Those decisions belong in the application’s access and storage design.

A 2023 study by John X. Morris and colleagues demonstrated that text could be reconstructed from embeddings produced by two models they tested. The researchers did not test EmbeddingGemma 2. Their findings provide a specific reason to treat a stored embedding as potentially sensitive, rather than assuming a list of numbers is safe to share. Embedding inversion research

For developers evaluating Google’s release, the next useful evidence will come from the same search requests run against several index sizes: which results remain easy to find, how much storage the complete application needs and how it behaves on the devices its users own. Google’s table already suggests where to concentrate that comparison: the 256- and 128-dimensional settings on searches involving pictures and sound.