谷歌开源 EmbeddingGemma 2：740M 参数把四种模态编进同一向量空间

Google DeepMind 在 10 月 6 日发布 EmbeddingGemma 2，一个以 Apache 2.0 许可开源的嵌入模型。它把文本（含代码）、图像、音频、视频四种输入映射到同一个 768 维向量空间。模型总参数 740M，定位是跑在手机和笔记本上的端侧模型。权重已经放在 Hugging Face 与 Kaggle 上，可以直接下载。

上一代 EmbeddingGemma 只做文本，这一代是原生多模态。你可以用一句文字去几小时的录音里找片段，也可以用一段语音备忘去定位某个视频镜头。官方称其多语言文本能力与前代基本持平，代码检索基准提升约 9.9 分。原文链接见 Google 官方发布页。

EmbeddingGemma 2 不是一个整体不可拆的模型。它由一个 270M 参数的文本骨干（130M Transformer 加 140M 嵌入层）和两个可选编码器组成：视觉编码器 170M、音频编码器 300M。开发者可以只加载需要的模态，做纯文本检索时就只挂文本骨干。这样能把内存和加载时间压到最低。

输出向量默认 768 维。模型用了 Matryoshka 表示学习（MRL），可以把向量直接截断到 512、256 或 128 维再归一化。官方给出的最高压缩比是 6 倍。本地向量库的存储和内存占用可以按需缩小，这对端侧应用很关键。

上下文窗口是 8192 token，比上一代扩大 4 倍。官方称这一长度足以一次处理约 5.5 分钟音频、29 张图片或 58 帧视频。对会议录音和视频素材库这类长内容，一次就能编码，不必再切段拼接。

官方给的内存数字是在 Google Pixel 11 Pro 上、量化之后测的。纯文本权重约 191MB 活跃内存，完整多模态模型约 567MB。这意味着它可以在不联网的手机或笔记本上完成嵌入计算。原始数据不用离开设备，也就省去了把内容传到云端的合规风险。

使用路径比较直接。用 pip 安装 sentence-transformers 后，加载 google/embeddinggemma-2 这个模型名即可。文本检索时通过 prompt_name 这类指令前缀区分查询和文档。Google 同时提供 LiteRT、MediaPipe、transformers.js 与 WebGPU 的接入方式，覆盖移动端和浏览器。

需要留意向量截断的代价。降到 256 维质量仍有小幅下滑，到 128 维时下降更明显。官方建议 128 维只用于纯文本场景。做多模态检索时，最好保留 512 维以上。

EmbeddingGemma 1 去年发布，只做文本。官方称它已被下载超过 2000 万次，主要用在端侧搜索和隐私优先的 RAG。EmbeddingGemma 2 沿用 Gemma 4 的架构，和 Gemini 的嵌入模型同源。但它走的是开源、端侧路线，而不是云端 API。

基准上，它在多语言文本检索 MTEB v2 拿到 61.36，前代是 61.15，基本持平。代码检索 MTEB code v1 从 68.76 升到 78.68。多模态侧是新增能力：图像 MIEB lite 64.64、视频 MMEB v2 50.67、音频 MSEB 检索 69.54。官方称它在 1B 参数以下的多模态嵌入模型里领先，并在部分任务上超过参数量两倍以上的专用模型。

和闭源的 Gemini Embedding API 相比，差别主要在部署形态与合规。EmbeddingGemma 2 适合对数据外发敏感、要求离线可用的场景。代价是要自己承担运维与量化调优。如果团队没有端侧工程能力，云端 API 仍然更省事。

最直接的受益方是三类。一是做端侧或隐私优先 RAG 的团队，尤其是医疗、法律、企业内部知识库这类不方便把原文传到云端的场景。二是做本地代码索引、语义代码搜索的开发者，代码检索是这一代提升最明显的一块。三是做跨模态搜索的产品，比如用文字在相册、会议录音、视频素材库里检索。

如果你的应用只做纯文本，且已在用云端嵌入 API 且效果达标，这次升级的边际收益有限。可以先不动，等自己的评测集给出结论。反过来，如果你的痛点恰恰是音频和视频没法搜，EmbeddingGemma 2 是目前少有的、能在一台设备上把四种模态放进同一空间的开源选择。它值得进入你的候选清单。

对已经在用 Gemma 4 做端侧生成的团队，还有一个额外好处。两者共享文本分词器和音频编码器，可以放进同一条流水线。合并后的总内存占用更低，部署也更简单。

不要只看官方榜单就决定换不换。更靠谱的做法是从真实数据里抽 200 到 500 条查询与对应正确答案。分别用旧模型和 EmbeddingGemma 2 计算向量，比较 recall@k 或 nDCG。再把 768、512、256 维都跑一遍，看降到哪一档质量仍可接受。

第二步是压内存。在目标机型上量一遍量化后的峰值内存与单条延迟，确认 567MB 这个量级是否落在预算内。第三步再检查许可证与合规，Apache 2.0 允许商用。但端侧处理涉及的用户数据能否本地留存，仍要按你所在地区的规定确认。

如果只是想先知道能不能用，最快的方式是在 Colab 或本地用 sentence-transformers 跑通官方 Quick Start。再用自己的十几条样本对比排序结果。半小时内就能有体感，不必先做完整评测。

这次发布延续了一个清晰方向：把检索从云端挪到设备上，并从单一文本扩展到多模态。对云端嵌入 API 厂商来说，端侧模型精度每提升一点，能留在本地处理的场景就多一点。定价与差异化会越来越依赖超大模型和托管能力。中小团队的自建成本则继续下降。

下一步值得关注三点。第一是 Gemini Enterprise Agent Platform Model Garden 何时上架该模型。第二是社区会不会很快给出 GGUF、MLX、ONNX 等本地运行时支持，这决定它能否真正进入普通开发者工作流。第三是是否出现围绕图文音视混合检索的开源评测集，用来复核官方口径。

编辑判断是：对做检索和 Agent 记忆层的团队，这是一个值得本周就上手试跑的开源模型。对只做纯文本、已稳定运行云 API 的团队，先观察再决定即可。不必因为一次榜单更新就重构管线。

本文由 AI 潮汐编辑部基于官方公告与公开资料整理，补充了行业影响、适用场景和行动建议，帮助你在阅读原文前先理解这条信息为什么重要。

原始来源：https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2/

如发现事实、价格或链接有误，可通过 联系我们 提交更正。