← Alla nyheter
ARTIKEL
9 oktober 2026 Uppdaterad den 23 oktober 2026 7 min läsning

EmbeddingGemma 2: Googles öppna 740M-modell söker i dina foton, inspelningar och dokument på enheten, offline

Den 6 oktober 2026 släppte Google DeepMind EmbeddingGemma 2, en öppen inbäddningsmodell under Apache 2.0-licensen som mappar text (inklusive kod), bilder, video och ljud till ett enda 768-dimensionellt rum. Den har 740 miljoner parametrar, uppdelade i en textmodell på 270M plus valfria visions- och ljudenkodare på 170M respektive 300M.

EmbeddingGemma 2: Google's open 740M model searches your photos, recordings and documents on-device, offline

On 6 October 2026 Google DeepMind released EmbeddingGemma 2, an open embedding model under the Apache 2.0 licence that maps text (code included), images, video and audio into a single 768-dimensional space. It has 740 million parameters, split into a 270M text model plus optional 170M vision and 300M audio encoders, so a text-only app loads only the 270M part. Google says that, quantized on a Pixel 11 Pro, it needs about 191 MB of active RAM for text-only weights and about 567 MB for the full multimodal model. The context window is 8,192 tokens.

An embedding model is the "search" half of retrieval-augmented generation. One that understands voice memos, scans and video clips on the device makes a private search over your own files possible without sending them to anyone's cloud. That is the practical story here; the benchmark story is Google's, and we treat it that way.

Below: the verified spec sheet, what on-device multimodal RAG looks like with Google's own demo apps, a minimal code sketch, Google's claims set against what you should test, and a checklist for teams that handle client files. We read Google's blog post, the Google Developers Blog post and the Hugging Face model card on 8 October 2026.

Diagram: a 270M text model plus optional 170M vision and 300M audio encoders, 740M in total, feeding one shared 768-dimensional space with Matryoshka truncation to 512, 256 or 128; an on-device retrieval loop in five steps; Google's quantized memory figures for a Pixel 11 Pro.
Load only the encoders you need, keep vectors on the device, and keep the answering model local too if the whole pipeline must stay offline. Memory figures are Google's.

Licence and access. Apache 2.0, according to Google's blog, the model card and the Hugging Face licence tag. The Hugging Face repository is not gated. Weights are on Hugging Face and Kaggle; Google says availability in its Model Garden is "coming soon".

Size, modular. 740M in total: a 270M text model (a 130M transformer plus a 140M embedder, per the card), a 170M vision encoder and a 300M audio encoder. The card lists the effective sizes when you switch encoders off: 270M for text only, 440M for text and images, 570M for text and audio.

One space for everything. Text, code, images, video and audio land in the same 768-dimensional space, so a spoken query can find a photo and a typed query can find a moment in a clip.

Smaller vectors on demand. Matryoshka Representation Learning lets you cut vectors to 512, 256 or 128 dimensions. Google's blog and the card say this gives up to 6x less storage; the Developers Blog says up to 8x for storage and index footprints. The card adds two rules worth keeping: re-normalize vectors after truncating, and never score a query against a corpus of a different dimension.

Context. 8,192 tokens, which Google says covers up to 5.5 minutes of audio, 29 images or 58 video frames, or interleaved combinations.

Memory, Google's figures. About 191 MB of active RAM for text-only weights and about 567 MB for the full model, quantized, on a Pixel 11 Pro.

Languages and lineage. The card says 100+ languages. The model is built on Gemma 4 and shares its text tokenizer and audio encoder; Google says that lowers combined memory when both run in one pipeline.

RAG in one line. Embed your files once, embed the question, fetch the closest matches, and hand them to a generative model that writes the answer. What changes with EmbeddingGemma 2 is that the embedding step can cover voice memos, scanned pages, photos and video clips, and can run on the device.

Google's own demos. On the Developers Blog, Google describes Instant Media Search in the Google AI Edge Gallery app for Android and iOS: the query and the media are embedded on the phone, the media vectors sit in a local SQLite database, results are ranked by cosine similarity, and there is no internet connection required. Video Moments Finder locates moments in local video recordings without transcribing the audio or generating intermediate text captions. Google AI Edge Foresight for Mac, which Google calls "an experimental app", pairs EmbeddingGemma 2 with Gemma 4 as a meeting companion that searches transcripts and personal files locally.

Building blocks for developers. Google says MediaPipe Tasks is adding EmbeddingGemma 2 support: a Universal Embedder task that handles image resizing, normalization and tokenization and returns 768-dimensional or truncated vectors, and a Semantic Retriever task that indexes embeddings on the device and runs approximate nearest-neighbour search. LiteRT sits underneath for teams that want finer control, and Google says quantization-aware training compresses the weights to INT4 and INT8. Its own latency example is a vision embedding in as little as 37.3 ms on a MacBook M5 Pro GPU; that is one device, measured by Google.

Where it could help. These are possibilities, not tested results: a field technician searching site photos by describing the fault; a consultant finding the moment in a recorded call where a client agreed a deadline; a small office searching scanned contracts without uploading them anywhere.

The honest limit. "Offline" means the embedding and the search run locally. The generative model that writes the answer must also run locally for the whole pipeline to stay on the device. The sketch below is text-only and uses the model ID, prompt names and options documented on the Hugging Face card; for images, audio and video, copy the input format from the card rather than guessing it.

# pip install -U sentence-transformers transformers
from sentence_transformers import SentenceTransformer

# Text-only: skip the vision and audio encoders ("Selective Encoder Loading" on the model card)
model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)

docs = [
    "Invoice 2026-114: boiler service, paid 3 October",
    "Site visit notes: pressure valve replaced on floor 2",
]
query = "when was the pressure valve replaced?"

# Prompt names, truncate_dim and normalize_embeddings as documented on the model card
doc_vecs = model.encode(docs, prompt_name="Document", truncate_dim=256, normalize_embeddings=True)
query_vec = model.encode(query, prompt_name="SearchQuery", truncate_dim=256, normalize_embeddings=True)
print(model.similarity(query_vec, doc_vecs))  # higher = closer match

Google's claims, attributed. Google calls EmbeddingGemma 2 "best-in-class for its size," with "leading scores among sub-1B multimodal embedders" on MTEB Code and MAEB, "matching or outperforming many larger models." It reports MTEB Code rising from 68.76 to 78.68 compared with the first EmbeddingGemma, and the model card describes a ~14% improvement on code tasks. The card also says quality is close to lossless down to 256 dimensions, while 128 dimensions degrades multimodal quality substantially and should be validated against your own workload. We did not re-run any benchmark, and public leaderboards measure public datasets, not your scans and recordings.

A test plan you can run.

  1. Build a small golden set from your own files: about 50 queries with known right answers, spread across text, images and audio.
  2. Compare 768, 256 and 128 dimensions on that set before you shrink the index.
  3. Measure memory and latency on the oldest device you must support, not on Google's reference phone.
  4. Try the multilingual queries your users actually type. The card says 100+ languages; your customers' phrasing is your test, not Google's.
  5. Re-check after quantization, because Google's memory figures are for a quantized build.

A checklist for MSPs and teams handling client files.

  1. Decide what "private" means for the client. Embeddings computed on the device, vectors stored on the device, and the answering model on the device. If any one of the three runs in a cloud, say which.
  2. Treat vectors as data. Embeddings of client files are derived data. Back them up, encrypt them and delete them under the same rules as the files.
  3. The licence check is simple here. Apache 2.0, per Google and the card. Keep the licence file with any app you ship.
  4. Do not wait for ML Kit if you need this now. Google says ML Kit support on Android arrives "in the coming weeks"; MediaPipe Tasks and LiteRT paths are described today.
  5. Load only the encoders you need. Text-only at 270M for documents; add vision or audio when the use case demands it.
  6. Pilot on real devices before a fleet rollout. Google's memory figures are for a Pixel 11 Pro.

Where it stands on 8 October 2026. Google DeepMind released EmbeddingGemma 2 on 6 October under Apache 2.0: 740M parameters split into 270M text, 170M vision and 300M audio; one 768-dimensional space for text, code, images, video and audio; Matryoshka truncation to 512, 256 or 128; an 8,192-token context; and, by Google's figures, about 191 MB text-only or 567 MB for the full model, quantized, on a Pixel 11 Pro. The demo apps are in Google AI Edge Gallery and in the experimental Foresight for Mac, and ML Kit support is due in the coming weeks. Every benchmark and comparison here is Google's claim. On-device multimodal RAG over your own files is the practical win, provided the answering model is local too.