Google开源EmbeddingGemma 2：7.4亿参数多模态向量模型

Google 于周二发布了 EmbeddingGemma 2，将文本、代码、图片、视频和音频检索整合在一个 7.4 亿参数的开源模型中，在该公司于 Pixel 11 Pro 上的量化测试中仅占用约 567MB 的活跃内存。

该模型基于 Gemma 4 构建，将五种输入类型映射到同一个 768 维向量空间中。图片不再需要先添加描述文字，音频也不需要先转录，两者都可以直接与文本一起进行搜索。

Google 以 Apache 2.0 协议发布了模型权重，通过 LiteRT 和 MediaPipe Tasks 实现设备端部署现已可用。Android ML Kit 集成（支持 NPU 加速的设备）将在未来几周内推出。

模块化编码器，一个向量空间

完整模型最多达 7.4 亿参数，但开发者只需加载其数据所需的编码器。文本和代码运行在 2.7 亿参数的基座上，Google 在同一手机上测量约需 191MB 活跃内存。

加上图像和视频的视觉编码器，模型达到 4.4 亿参数；替换为音频编码器则达到 5.7 亿参数，同时加载两者则达到完整的 7.4 亿参数。每种配置都投影到同一个嵌入空间中，因此一个团队从纯文本索引开始后，可以在之后添加图像或音频搜索，而无需重新嵌入已经存储的任何内容。

Google 还将上下文窗口扩大四倍，从 2048 增加到 8192 个 token，该公司称这足以覆盖单次输入中最多 5.5 分钟的音频、29 张图片或 58 个视频帧。视频默认按每秒一帧采样，因此这 58 帧相当于不到一分钟的 footage。

在 Google 的 Video Moments Finder 演示中，视频帧和音频片段在本地建立索引，然后通过纯文本进行搜索以定位到特定时刻，整个过程不生成任何字幕或转录文本。Instant Media Search 将相同的方法应用于手机上的照片和视频，将嵌入向量存储在 SQLite 中，并在用户输入时实时更新结果。

Matryoshka 缩小索引

在手机上，索引本身可能与模型竞争空间——因为 100 万个 768 维 bfloat16 向量约占 1.5GB。Google 使用 Matryoshka Representation Learning 训练了 EmbeddingGemma 2，允许开发者在无需重新训练的情况下将这些嵌入向量截断到 512、256 或 128 维。

在 256 维时，100 万向量的索引降至约 500MB。Google 表示，较短的嵌入向量在文本和代码上保持了大部分完整尺寸的质量，在图像、视频和语音检索上保持约 95%。

在 128 维时，权衡更为明显：Google 将文本和代码置于约 90%，但多模态检索降至约 75%，该公司建议在实际数据上测试该设置后再用于多模态查询。在嵌入向量发布中，为效率而牺牲少量检索质量已成为今年秋季的常见策略，正如 Cohere 更快的查询模型在其自身测试中几乎不影响检索质量一样。

设备端代码搜索

代码与文本运行在同一个 2.7 亿参数的基座上，Google 报告 EmbeddingGemma 2 的 MTEB Code 得分为 78.68，高于原始 EmbeddingGemma 的 68.76。

为了展示它在 agent 工作流中的表现，Google 使用纯文本设置对 Hugging Face Transformers 仓库进行嵌入，并将该索引与在 Pi 上运行的 Gemma 4 26B A4B 配对。这正是某个 MCP 服务器变通方案背后的同一 agent 框架——该方案在使用前消耗了 18000 个 token。在 Google 的设置中，EmbeddngGemma 2 负责仓库中的检索工作，而更大的模型则驱动 agent。

同一个嵌入模型还可以通过 MediaPipe Decision 处理分类任务，它将输入的嵌入向量与候选描述进行比较，而不是生成回复。在一个设备端国际象棋演示中，Google 用它在不到 100 毫秒内评估每回合 500 个选项。如果你见过 agent 在一个根本不需要生成答案的决策上烧掉 token，这提供了一种更便宜的方式来做出判断。

更轻量的本地 RAG 管道

EmbeddingGemma 2 借用了 Gemma 4 的文本分词器和音频编码器架构，这意味着两个模型在设备上一起运行时占用更少的内存。目前 Google 已在自己的旗舰手机上展示了多模态检索工作。我们只能等待，看看更大的索引、不同的硬件以及非 Google 演示的应用会表现如何。