EmbeddingGemma 2：不到 600MB 内存，跑通端侧多模态嵌入

Google DeepMind 于 2026 年 10 月 6 日发布 EmbeddingGemma 2：一个以 Apache 2.0 许可发布、紧凑的开源权重嵌入模型，原生地把文本、代码、图像、视频与音频映射进同一个 768 维向量空间。它基于 Gemma 4 架构，可从文本与代码的 2.7 亿参数，扩展到全模态的 7.4 亿参数。对构建本地搜索与媒体检索的开发者而言，它免去了串接「图像描述、语音转写、文本嵌入」等多个模型所带来的延迟与内存开销。本文讲清它能做什么、怎么用，并附上来自官方开发者指南的可运行代码。

一个模型、一个 768 维空间、五种模态

发布了什么，为什么重要

EmbeddingGemma 2 是一个 sub-1B 的嵌入模型，却有一个不寻常的性质：原生多模态。它不是在文本嵌入器前串一个图像描述器和一个语音转写器，而是把文本、代码、图像、视频帧与音频直接映射进同一个 768 维空间，因此性质迥异的内容可以用一次点积进行比较。它基于 Gemma 4 架构、以 Apache 2.0 许可发布，意味着可用于商业产品。第一代 EmbeddingGemma 下载量已超过 2000 万，所以这是对开发者本就依赖的模型的一次升级，而非噱头。

# Install sentence-transformers with the extra modality encoders.
pip install -U "sentence-transformers[image,audio,video]" transformers

串接模型曾是那笔「旧税」

在这类模型出现之前，构建本地多模态搜索意味着一整条流水线：给图像写描述、把音频转写、再把所有文本嵌入，并祈祷跨模态转换中没有丢东西。每一跳都带来延迟、内存，以及一处意义可能泄漏的地方。EmbeddingGemma 2 用「投射进共享空间的模块化编码器」取代了这条链。当它与 Gemma 4 配套时，二者共享同一套文本分词器与音频编码器架构，因此端侧 RAG 流水线能以一个更低的总内存占用同时跑两个模型。实际结果是：跨模态检索从「一个集成项目」变回了「一个单模型问题」。

# Load the full multimodal model (740M params).
from sentence_transformers import SentenceTransformer

MODEL_ID = "google/embeddinggemma-2"
model = SentenceTransformer(MODEL_ID)

# Or load only what you need - disabled encoders never enter memory.
text_only = SentenceTransformer(
    MODEL_ID,
    config_kwargs={"vision_config": None, "audio_config": None},  # 270M
)

端侧本地代码库索引与 Agent 代码检索

模块化设计，存储也便宜

它的体量是一个旋钮，而不是一笔固定开销。你可以只加载所需部分：文本与代码 2.7 亿参数，文本+视觉 4.4 亿，文本+音频 5.7 亿，全模态 7.4 亿——它们都投射进同一个兼容的向量空间。在此之上，Matryoshka Representation Learning 让你把输出向量从 768 维截断到 512、256 或 128 维。在 256 维时，Google 称文本与代码保留了绝大部分完整质量、图像/视频/语音检索约保留 95%，而存储只占三分之一；128 维则省下 6 倍存储。在 bfloat16 精度下，一百万个 768 维向量约占 1.5GB，而截断到 128 维只需 250MB。

# Retrieve with task prompts: encode queries and documents differently.
query = "What causes the northern lights?"
document = "The northern lights are caused by charged particles from the sun."

query_emb = model.encode(query, prompt_name="SearchQuery")
doc_emb = model.encode(document, prompt_name="Document")
print(model.similarity(query_emb, doc_emb))

数据与上下文窗口

Google 报告它在 MTEB Code 上提升 9.92 分（68.76→78.68），这正是它适合本地代码库索引与 Agent 代码检索的原因；在 MTEB 与 MAEB 上也取得 sub-1B 范围内的领先成绩。所有模态共享一个 8,192 token 的上下文窗口——是第一代的 4 倍——在端侧足以处理长达 5.5 分钟的音频、29 张图像、58 帧视频，或它们的交错组合。经量化后在 Pixel 11 Pro 上，Google 给出的数据是：纯文本权重最低约 191MB 活动内存，全模态模型约 567MB。请在你自己的硬件上复核，但这确实是一个货真价实的端侧体量。

# Cross-modal search: one text query against an image and a sound clip.
image_emb = model.encode({"image": "sunset_beach.jpg"})
audio_emb = model.encode({"audio": "ocean_waves.wav"})
query_emb = model.encode("ocean waves at sunset", prompt_name="SearchQuery")
print(model.similarity(query_emb, image_emb))
print(model.similarity(query_emb, audio_emb))

Matryoshka 截断在损失很小的情况下省下 6 倍存储

上手：代码

你可以用 sentence-transformers 库（v6.1.0 或更高）在五种模态上运行 EmbeddingGemma 2。加载完整模型，或在加载时把 vision_config、audio_config 设为 None 以省略编码器——被禁用的编码器根本不会进入内存。检索时，用不同的任务提示词分别编码查询与文档（SearchQuery 与 Document），以正确引导表示。媒体以「按模态为键的字典」传入，交错的文本则用 <|image|>、<|video|> 或 <|audio|> 标记。需要更小的索引时，传入 truncate_dim 并设 normalize_embeddings=True。权重已以 Apache 2.0 许可发布在 Hugging Face 与 Kaggle 上。

# Matryoshka truncation: shorter vectors, smaller indexes, same space.
# 768d -> 512 -> 256 -> 128 (6x storage reduction).
query_emb = model.encode(
    query,
    prompt_name="SearchQuery",
    truncate_dim=256,
    normalize_embeddings=True,
)

它在真实技术栈里的位置

最明显的落点：本地语义搜索、端侧 RAG、媒体库检索，以及编程 Agent 内部的代码检索。由于它可截断到 128 维做一阶段粗排、再用 256 或 512 维做更高召回的排序，你就能廉价地「先粗排、再精排」——这恰好是内存受限型索引的形态。又因为一切都可留在设备上，隐私叙事是免费的：没有任何内容需要离开这台机器才能被嵌入。如果你要构建的检索必须离线可用、必须符合数据驻留要求，或只是想压低延迟，这就是该拿去与你现有流水线做基准对比的那个模型。