EmbeddingGemma 2 Index Builds: Version, Validate, and Promote
- Version the representation: retain checkpoint, preprocessing, task formatting, dimension and normalization policy with each build.
- Separate failure classes: mismatched dimensions block scoring; changed sampling or prompts can alter relevance while leaving valid vectors.
- Keep measurement boundaries: Google’s full-precision scores and quantized-device memory figures do not describe the same test.
- Release one matched pair: validate the candidate query configuration with its candidate index; retain the previous pair for rollback.
Google’s EmbeddingGemma 2 makes a specific AI capability more practical on constrained hardware: representing text, source code, images, video, audio, and mixed inputs in one comparable vector space for local search, classification, clustering, and retrieval-augmented generation.
The opportunity is real, but so is the implementation risk. EmbeddingGemma 2 exposes several independent choices—active encoders, vector dimension, numerical precision, task prefixes, normalization, media sampling, and chunking. Those choices affect either vector compatibility or retrieval quality. Our earlier deployment guide covers encoder and vector-width selection. This follow-up focuses on the index-build contract: admission checks, traceable configuration changes and a paired release.
Editorial inference: a production index should therefore be treated as a versioned model artifact, not simply a database populated with numbers. Its configuration must be recorded, validated, and evaluated with the corpus it will serve.
What Google released
Google’s Gemma release log records the release of EmbeddingGemma 2 in a 740-million-parameter size on October 6, 2026. Google publishes model weights under the Apache 2.0 license through Hugging Face and Kaggle.
EmbeddingGemma 2 is an embedding model, not a generative language model. It produces vectors that applications can compare for similarity. A RAG system can use those vectors to retrieve evidence, but a separate generative model is required to write an answer. Google presents Gemma 4 as one possible downstream generator, not as part of the embedding checkpoint itself.
The Google-authored model card documents:
- 740M parameters in total
- 270M for the text-and-code component
- An optional 170M vision encoder
- An optional 300M audio encoder
- A native 768-dimensional output
- A shared 8,192-token context window
- Text, code, image, video, audio, and interleaved inputs
- More than 100 supported text languages, with an explicit warning that performance may differ by language
The four documented runtime configurations are:
| Active inputs | Effective parameter count |
|---|---|
| Text and code | 270M |
| Text, code, images, and video frames | 440M |
| Text, code, and audio | 570M |
| All supported modalities | 740M |
Google says these configurations load from the same checkpoint and project into a compatible embedding space. For example, a text query produced by the 270M configuration can be compared with media vectors produced by the full configuration.
Figure 1 separates index creation from request-time scoring, with a shared representation contract at the join.
Why “one vector space” does not remove index risk
A shared embedding space simplifies cross-modal comparison, but it does not make every possible index build interchangeable.
Some settings define hard compatibility boundaries:
- The query and corpus must use the same vector dimension.
- A truncated vector must be L2-normalized again before cosine comparison.
- The deployed model revision and preprocessing pipeline must be able to reproduce the stored representation.
Other settings are quality-sensitive rather than structurally incompatible:
- The selected task instruction
- Query-versus-document formatting
- Code or document chunk boundaries
- Video frame sampling
- Audio segmentation
- Vision token budget
- Quantization and execution backend
Google’s model card says omitting a recommended text prefix still produces an embedding, but reduces precision. By contrast, using different query and corpus dimensions prevents direct scoring, while failing to renormalize truncated vectors can silently damage ranking quality.
A defensible index manifest should record at least:
- Model repository and immutable revision
- Active encoders
- Output dimension
- Inference and stored-vector data types
- Normalization policy
- Query and corpus task formatting
- Text or code chunking policy
- Video sampling rate and vision token budget
- Audio sample rate, window size, and overlap
- Evaluation-set version and acceptance thresholds
That manifest is an engineering recommendation, not a Google product claim. It follows from the model’s documented compatibility and preprocessing requirements.
A minimal application-owned manifest
The example below is a proposed schema, not a Google API payload or a ready-to-run configuration. Replace the revision and corpus placeholders with immutable identifiers. Query and corpus text formats are separately versioned because asymmetric retrieval intentionally formats them differently.
{
"build_id": "candidate-B",
"model": "google/embeddinggemma-2",
"revision": "IMMUTABLE_CHECKPOINT_COMMIT",
"runtime_bundle": "PINNED_RUNTIME_AND_BUNDLE_ID",
"active_encoders": ["text", "vision"],
"inference_dtype": "bfloat16",
"stored_vector_dtype": "float32",
"output_dimension": 256,
"normalize_after_truncation": true,
"query_task": "SearchQuery",
"document_format_version": "titled-document-v1",
"chunk_policy_version": "technical-doc-v1",
"video_sampling_fps": 1,
"audio_input": "16kHz-mono-if-enabled",
"corpus_snapshot": "IMMUTABLE_CORPUS_ID",
"gold_relevance_set": "FROZEN_EVALUATION_ID"
}Separate inference and stored-vector precision: a model may run in BF16 while a database stores float32 coordinates. Also retain source IDs, timestamps or chunk offsets and deletion state so a ranked vector resolves to the correct current object. A manifest makes an experiment reproducible; it does not prove relevance, authorize disclosure or replace deletion handling.
Figure 2 distinguishes vector compatibility, quality-sensitive preprocessing and reproducibility metadata.
Vector dimension is a workload decision
EmbeddingGemma 2 uses Matryoshka Representation Learning, allowing its native 768-dimensional vector to be truncated to 512, 256, or 128 dimensions. Shorter vectors reduce index storage and similarity-search work, but quality loss varies by workload.
The following results are Google-reported model-card evaluations, not Tech Trend Insight measurements or independently reproduced leaderboard results. Google states that all results in the table use the full-precision checkpoint.
Google-reported full-precision dimension sweep
- Output dimension: 768d — MMEB v2 Overall: 59.01 — MTEB Code v1, mean NDCG@10: 78.68 — Interpretation: Full-vector baseline
- Output dimension: 512d — MMEB v2 Overall: 58.38 — MTEB Code v1, mean NDCG@10: 77.24 — Interpretation: Limited loss in Google’s aggregate results
- Output dimension: 256d — MMEB v2 Overall: 56.24 — MTEB Code v1, mean NDCG@10: 76.18 — Interpretation: Plausible storage-constrained candidate
- Output dimension: 128d — MMEB v2 Overall: 45.65 — MTEB Code v1, mean NDCG@10: 71.41 — Interpretation: Substantial multimodal degradation
At 768 dimensions, Google reports 78.68 for EmbeddingGemma 2 versus 68.76 for EmbeddingGemma 1 on MTEB Code v1—a 9.92-point difference under the model card’s conditions. The multilingual MTEB v2 mean changed much less, from 61.15 to 61.36.
That evidence supports a narrower conclusion than “version 2 is better at everything.” The documented gain is much clearer for code and newly supported media than for general multilingual text retrieval.
Figure 3 compares Google’s published dimension-sweep results on two distinct benchmarks.
Precision, prefixes, and normalization are operational requirements
Do not run the checkpoint in FP16
Google’s model card instructs developers to use bfloat16 or float32, not float16. According to the card, the model’s activation range can exceed FP16’s dynamic range, producing NaNs or silently degraded vectors rather than a reliable runtime error. BF16 is the recommended default on hardware with native support; float32 is the fallback, including on most CPUs.
An index-admission process should therefore reject:
- Non-finite vector values
- Unexpected data types
- Zero-length or malformed vectors
- Vectors whose post-truncation norm is outside a defined tolerance
Truncate, then normalize
Matryoshka truncation retains the leading dimensions of the native vector. Slicing a unit-length 768d vector does not leave the shorter vector at unit length, so Google requires L2 renormalization before cosine similarity. The model card warns that skipping this step can yield plausible-looking scores while degrading ranking.
Use task-specific text formatting
EmbeddingGemma 2 was trained with short text instructions for retrieval, question answering, fact checking, code retrieval, classification, clustering, and semantic similarity.
For asymmetric retrieval, queries and corpus items require different formatting. The model card’s code-search pattern, for example, distinguishes a code-retrieval query from a titled or untitled code document. Media inputs do not receive those text prefixes.
This distinction belongs in index metadata. A corpus embedded with one document-formatting convention should not be silently mixed with later batches produced under another.
Figure 4 shows how invalid representations are stopped before publication without mistaking validity for relevance.
The shared context window makes preprocessing part of the model behavior
All modalities draw from one 8,192-token context budget. Under the model card’s default accounting:
Shared-context accounting at default settings
- Input type: Image — Default token cost: 280 tokens per image — Approximate single-modality maximum: 29 images
- Input type: Video — Default token cost: 140 tokens per frame — Approximate single-modality maximum: 58 frames
- Input type: Audio — Default token cost: 25 tokens per second — Approximate single-modality maximum: 327 seconds
- Input type: Text or code — Default token cost: Standard subword tokenization — Approximate single-modality maximum: 8,192 tokens
Those maxima assume no accompanying text or other media. They are not additive.
The model card also documents:
- Configurable vision budgets from 70 to 1,120 soft tokens per image or frame
- Default video sampling at 1 frame per second
- Configurable video frame sampling
- Audio supplied as 16 kHz mono
These controls alter what information reaches the embedding model. A benchmark using one frame per second does not establish retrieval quality for fast motion, brief events, or densely edited video. Similarly, an audio evaluation based on long windows may conceal short acoustic events.
For documents and code, chunking presents the same problem. Function-aware code chunks, layout-aware document regions, and fixed character windows can produce materially different retrieval behavior even when the checkpoint is unchanged.
Figure 5 links frame sampling to possible evidence loss and to the shared context budget using a labeled hypothetical input.
Edge memory claims need their measurement boundary
Google reports that quantized EmbeddingGemma 2 used approximately:
- 191 MB of active RAM for the text-only weights
- 567 MB of active RAM for the full multimodal model
The measurements were made on a Google Pixel 11 Pro and published with the October 6 release.
These are vendor-reported, device-specific figures. They are not a total application-memory guarantee. A deployed product may also hold:
- Stored vectors and metadata
- Approximate-nearest-neighbor structures
- Media-decoding and preprocessing buffers
- Application runtime state
- Retrieved context
- A separate generative model
That distinction is an engineering inference from the stated measurement boundary.
The quality and memory numbers also come from different conditions. Google’s benchmark table uses a full-precision checkpoint, while the Pixel figures use quantization. The cited primary documentation does not establish one universal quality delta for every quantized LiteRT bundle, device, and accelerator.
Deployment paths: available documentation versus announced support
As of October 12, 2026, Google documents or links EmbeddingGemma 2 usage through:
- Hugging Face Transformers and sentence-transformers
- MLX, vLLM, SGLang, llama.cpp, Ollama, and LM Studio
- MediaPipe Tasks and LiteRT
- Pre-quantized LiteRT community bundles
- Google AI Edge Gallery demonstrations
- Google AI Edge Foresight on Mac
The checked launch announcements describe two additional routes as forthcoming; they do not themselves establish general availability:
- Google’s launch page says Gemini Enterprise Agent Platform Model Garden availability is “coming soon.”
- The Google AI Edge announcement says an Android service through ML Kit will arrive “in the coming weeks” and repeatedly labels its API as coming soon.
These are the states stated in the cited announcements, not a live entitlement check. Before choosing either route, confirm a service-specific model listing or API reference and access in the intended project; an open checkpoint alone is not evidence that a hosted or managed service is ready.
Worked migration: keep one searchable contract at a time
Hypothetical application example—not an executed Tech Trend Insight test. A local technical-document search product currently serves build A: one pinned EmbeddingGemma 2 checkpoint, 768d vectors, fixed document chunking and a frozen gold relevance set. The team wants a 256d build B to reduce stored coordinate bytes. The candidate must retain the same source identifiers and access rules; otherwise a higher relevance score could conceal missing or newly exposed documents.
If the full 768d vectors are retained, build B can be derived by keeping the leading 256 coordinates and L2-normalizing again, as Google documents. It is a new index build, not necessarily a new encoding pass. If only a shorter representation was retained, missing coordinates cannot be recovered by padding; rebuild from the original content when a wider representation is required. Changing the checkpoint or input preprocessing likewise needs a separately validated build rather than an assumption that old representations still mean the same thing.
Build B runs beside A without changing the live route. Its query configuration uses the same checkpoint and 256d normalization policy. Evaluate both pairs on the identical corpus and gold relevance set, including code, long documents, multilingual queries and media where supported. Record top-result changes, missing-source failures, actual index bytes and target-device latency; no pass threshold or improvement is implied here.
After B passes the product’s declared gates, switch the application-owned configuration reference so B’s query encoder serves B’s index. An in-flight request should remain pinned to the pair it started with. Keep A’s query configuration, index and manifest together for rollback. A partial switch—256d queries against A’s 768d index—is a compatibility failure, not a gradual rollout. Same-checkpoint encoder additions with documented compatibility need not force a rewrite of existing vectors, but their new modality coverage still needs evaluation.
Figure 6 illustrates a staged same-checkpoint dimension migration and a rollback that restores both sides of the retrieval contract.
Proposed production validation
The following is a proposed evaluation plan, not a Tech Trend Insight test result.
- Build a gold retrieval set. Include representative queries, expected matches, hard negatives, near-duplicates, supported languages, and genuine cross-modal cases.
- Freeze preprocessing. Version chunk boundaries, frame sampling, audio windows, task prefixes, normalization, model revision, and data type.
- Evaluate all four dimensions. Compare 768d, 512d, 256d, and 128d using Recall@k, MRR or NDCG, top-result stability, index size, indexing throughput, and query latency.
- Test the shipped runtime. Measure the actual quantized bundle on each supported device, including cold start, peak application memory, sustained latency, battery use, and thermal throttling.
- Stratify failures. Report text, code, image, video, audio, language, and cross-modal results separately rather than hiding regressions inside one mean.
- Reject invalid index builds. Fail publication on NaNs, missing metadata, mixed dimensions, unexpected precision, absent task formatting, or non-unit vectors after truncation.
- Evaluate generation separately. Only after retrieval passes should a RAG system measure answer faithfulness, citation accuracy, abstention, and generator latency.
The decision rule
EmbeddingGemma 2 is a credible edge-oriented multimodal retrieval model with unusually flexible encoder and vector-size choices. That flexibility is valuable precisely because it is not automatic.
Adopt the smallest encoder configuration and vector dimension that preserve retrieval quality on the target corpus and shipped hardware. Reject any index build whose model revision, precision, dimension, normalization, task formatting, or preprocessing policy cannot be reproduced.
EmbeddingGemma 2 makes local multimodal retrieval possible. The index build determines whether it remains dependable.
Frequently Asked Questions (FAQ)
Why must an EmbeddingGemma 2 vector index be treated as a versioned build artifact?
A manifest ties stored representations to a reproducible query configuration and preprocessing policy. Different query and index widths cannot be scored directly. However, a smaller index can be derived from retained full vectors by truncating and normalizing; a compatible encoder addition does not automatically require recomputing existing vectors. Quality-sensitive changes require evaluation, not an unsupported rule that every edit invalidates the entire corpus.
How does Matryoshka Representation Learning reduce edge memory requirements?
At a fixed stored dtype and item count, retaining 512, 256 or 128 coordinates instead of 768 reduces raw coordinate bytes by about 33.3%, 66.7% or 83.3%, respectively. These are arithmetic reductions, not measured total-index or application-memory savings. Model weights, ANN structures, metadata and media buffers are separate. Re-normalize after slicing and test retrieval loss.
Can we build the vector index on cloud GPUs in FP32 and run queries on-device in Int4?
Do not assume either parity or a fixed degradation. Google’s full-precision scores do not establish a universal quality delta for every quantized bundle. Evaluate the actual query runtime against the intended corpus representation, keeping checkpoint, dimension, normalization and relevance set controlled. Weight quantization is not the same as the dtype of coordinates stored in the database. Record both and measure the resulting rankings.
When should teams keep separate modality indexes instead of a single unified EmbeddingGemma 2 index?
Treat separate pipelines as evaluation candidates when exact transcripts, specialized source representations or distinct access policies are product requirements. The reviewed evidence does not establish universal specialist-model superiority. EmbeddingGemma 2 has 740M parameters in full configuration and a 270M text component—not a 300M unified model. Compare candidate architectures on the same relevant corpus and declared acceptance criteria.
Editorial review: October 12, 2026. Model facts and vendor results were checked against Google’s primary documentation. The manifest, admission controls and release sequence are engineering recommendations; Tech Trend Insight has not performed the proposed retrieval or device tests.
