Gemini Embedding 2 enters preview with 8,192-token multimodal vectors and 3,072-dim outputs

Gemini Embedding 2 is a new public-preview embedding model that maps “5 modalities in a single unified embedding space,” according to Google's launch thread. The supported inputs are unusually broad for one endpoint: text, images, video, audio, and documents, with the API docs describing it as gemini-embedding-2-preview and positioning it alongside the older text-only gemini-embedding-001.

The implementation details matter for retrieval system design. Google's feature list says the model supports “up to 8,192 input tokens,” “up to 6 images,” “120s video,” and “audio natively, no transcription step needed,” plus PDFs up to 6 pages per request. That means cross-modal search no longer has to start with separate captioning, ASR, or document-only preprocessing for every asset type. A supporting summary from an engineer recap also highlights the output-size dial: 3,072, 1,536, or 768 dimensions via Matryoshka Representation Learning.

Google's model thread claims state-of-the-art performance across both unimodal and multimodal tasks, and the attached table is the most concrete evidence in the launch set. On text-text retrieval, Gemini Embedding 2 posts 69.9 on multilingual MTEB mean task score versus 68.4 for Google's prior text model, and 84.0 on MTEB Code where the older model shows 76.0. On text-image and image-text retrieval, the

shows large jumps over Google's legacy multimodal model, including 89.6 vs. 74.0 on TextCaps text-image recall@1 and 97.4 vs. 88.1 on TextCaps image-text recall@1.

The table also shows stronger document, video, and speech retrieval coverage than Google's previous offerings. Gemini Embedding 2 reaches 64.9 on ViDoRe v2 text-document nDCG@10, 68.0 on MSR-VTT text-video nDCG@10, 52.5 on YouCook2, and 73.9 on MSEB speech-text mrr@10 in the published comparison. One caveat from that same chart: some competitor figures are marked unavailable or self-reported, and Voyage Multimodal 3.5 slightly edges Gemini on ViDoRe v2 at 65.5 versus 64.9.

The practical pitch from early adopters is pipeline simplification. In one practitioner writeup, the claim is “one API call now handles all your media,” replacing stacks that previously chained “audio to text, images to captions” before embedding. That is the clearest deployment implication here: a text query can retrieve non-text assets directly because the assets live in one shared vector space rather than separate modality-specific indexes.

The first community experiments are already centered on search infrastructure rather than demos. A local prompting-tools test says integrating Gemini Embedding 2 to improve search was “as simple as asking OpenClaw,” while the LlamaParse post shows an “integrated solution” for parsing, embedding, and searching audio files, PDFs, PowerPoints, and videos in one knowledge base. Google's own documentation also ties the model to semantic search, classification, clustering, and RAG, which fits the launch narrative better than pure showcase content.

The storage-performance tradeoff is also more explicit than in many embedding launches. The launch thread and builder explanation both call out Matryoshka Representation Learning, where information is nested so developers can shrink vectors from 3,072 to 1,536 or 768 dimensions. That gives teams a concrete knob for index size, memory footprint, and retrieval quality without swapping to a different model family.