Google: Gemini Embedding 2 (batch)

Google: Gemini Embedding 2 (batch) is an embedding model from Google. It is listed on api14 under the embeddings category, and its provider release date is 2026-05-20. Google describes it as Gemini Embedding 2, the company's first multimodal embedding model. Rather than generating chat replies, it produces vector representations that you store and compare, which makes it a building block for search and retrieval systems rather than an assistant you talk to.

The model accepts text, image, file, audio and video inputs, and its only output modality is embeddings. Google's description states that text and images are currently supported for mapping into a unified vector space for semantic search and retrieval-augmented generation (RAG), so the broader input list reflects the model's multimodal design while the documented mapping covers text and images. The context window is 8192 tokens, and the maximum output is 7372. Because the output is a vector rather than prose, there is no text generation to configure or read back.

Those capabilities point to a few practical patterns. Semantic search over a mixed corpus is the most direct one: embed documents and queries into the same space and rank by similarity, so a text query can surface relevant images or vice versa. RAG pipelines use the same property, embedding chunks at index time and the user question at query time so a generator can be handed the closest passages. Because files, audio and video are listed as accepted inputs, teams working with richer media may be able to embed that content directly instead of writing a separate transcription or captioning step first, though Google's current description only commits to text and images.

Calling it through api14 works like any other model on the gateway, using the OpenAI-compatible API with the model id "google/gemini-embedding-2:batch". The batch suffix indicates this variant is intended for batch embedding work. The supported parameters list is empty, so there are no extra request options to set beyond the standard request fields the endpoint expects. You send your input, receive embeddings back, and handle storage and similarity comparison on your side.

The main constraint to weigh is the 8192 token context window. Long documents need to be split into chunks before embedding, which is normal for retrieval work but adds a chunking step to your pipeline. If your task is generating text rather than representing it as vectors, an embeddings model is the wrong tool and a chat or completion model will fit better. If your inputs are mostly audio or video and you need guaranteed support rather than a listed modality, verify that behaviour before committing, since Google's description currently names text and images.