EmbeddingGemma 2 发布：7.4 亿参数的开放轻量多模态嵌入模型，端侧统一文本、代码、图像、音频与视频

2026年10月6日，Google DeepMind 发布 EmbeddingGemma 2，一款开放、轻量、原生多模态的嵌入模型。它把文本、代码、图像、音频和视频映射到同一个共享嵌入空间。模型基于 Gemma 4 架构，采用商业友好的 Apache 2.0 许可证，总参数量为 7.4 亿，定位是在端侧设备上直接运行。 一、发布了什么

去年发布的初代 EmbeddingGemma 只处理文本，目标是让应用在消费级硬件上完成高质量的文本嵌入。官方称其下载量已超过 2000 万次，开发者主要用它构建端侧智能搜索和注重隐私的检索增强生成（RAG）流水线。EmbeddingGemma 2 在此基础上把输入范围扩展到代码、图像、视频与音频，并且由单一模型原生处理，而不是拼接多个专用模型。官方举的例子是：用一段语音备忘录去找某个视频片段，或者用一句文字查询去搜索数小时的录音。该模型与 Gemini Embedding 系列出自同一技术路线。

二、模块化架构

EmbeddingGemma 2 采用模块化设计。纯文本场景最少只需 2.7 亿参数；需要视觉能力时，可加载 1.7 亿参数的视觉编码器；需要音频能力时，可加载 3 亿参数的音频编码器。三者相加即为 7.4 亿参数的完整多模态模型。这种设计让开发者按需加载：只做文本检索的应用不必为用不到的视觉和音频权重付出内存。 三、套娃表示学习与存储成本

模型使用套娃表示学习（Matryoshka Representation Learning，MRL）。输出向量默认为 768 维，开发者可以在运行时把它截断为 512、256 或 128 维。官方称，这最多可带来 6 倍的存储缩减，既降低本地向量数据库的体积，也降低内存占用。对于要在手机或笔记本上保存大量向量的应用，这是直接的成本杠杆。需要注意的是，截断维度意味着精度与体积之间的取舍，具体损失应由开发者在自己的数据上评估。 四、端侧资源占用与上下文长度

在 Google Pixel 11 Pro 上，经过量化后，纯文本权重的活跃内存最低约 191MB，完整多模态模型约 567MB。上下文窗口为 8K token，是初代 EmbeddingGemma 的 4 倍。官方给出的单次输入上限相当于 5.5 分钟音频、29 张图像或 58 帧视频，也可以是它们的交错组合，全部在本地硬件上处理。 五、基准表现

官方称，EmbeddingGemma 2 在同等规模的 1B 以下多模态嵌入模型中取得领先，涉及的基准包括 MTEB Code（大规模文本嵌入基准的代码部分）和 MAEB（大规模音频嵌入基准），并在文本、视觉、音频任务上持平或超过许多更大的模型。多语言文本能力与初代持平。代码检索进步最明显：MTEB Code 得分从 68.76 升至 78.68，提升 9.92 分。官方还称，它在图像、视频、文档和音频任务上，甚至优于一些体量超过自身两倍的专用模型。完整指标见官方模型卡。以上均为厂商自报数据，独立复现尚待社区验证。

六、对开发者与企业的意义

第一，隐私。本地生成嵌入，数据不必离开设备，适合医疗、法务、个人笔记等敏感场景。第二，延迟与成本。本地推理不依赖网络往返，也没有按调用计费的嵌入接口开销。第三，工作流简化。过去做跨模态检索，往往要为文本、图像、音频分别部署模型并对齐向量空间；现在一个模型即可。第四，代码场景。MTEB Code 的提升，使本地代码库索引、语义代码搜索和编程智能体的检索环节更有实用价值。第五，许可证。Apache 2.0 允许商业使用，企业集成的法律门槛较低。 七、展望与挑战

端侧多模态嵌入会让「个人数据的本地语义索引」成为常见能力：相册、录音、视频和代码在设备上统一可搜。但挑战同样明确。首先，8K 上下文对长视频和长录音仍然有限，需要分段与聚合策略。其次，不同量化方案对检索质量的影响，需要在真实数据上测量。再次，向量数据库、检索框架和移动端运行时需要跟进对多模态嵌入的支持。最后，基准分数不等于业务效果，团队应在自己的语料上做评估。总体上，EmbeddingGemma 2 把「小模型、多模态、可商用」三件事放在了一起，值得 AI 工具开发者重点关注。

九、落地建议

第一步，先确定要覆盖的模态。若只需文本与代码检索，只加载 2.7 亿参数的文本部分即可，内存占用最低。第二步，用真实语料建立评估集，对比 768、512、256、128 维下的召回率与延迟，选出够用的最小维度。第三步，在目标设备上实测量化后的内存与耗时，不要只看官方给出的 Pixel 11 Pro 数据。第四步，为长音频和长视频设计分段策略，因为 8K 上下文一次只能容纳约 5.5 分钟音频。完成这四步后，再决定是否把云端嵌入接口替换为本地模型。 八、与初代相比的变化小结

把两代模型放在一起看，变化集中在四点。输入范围：从只有文本，扩展到文本、代码、图像、音频和视频。上下文长度：从初代的 2K 提升到 8K，是后者的 4 倍。代码检索：MTEB Code 得分由 68.76 升至 78.68。部署形态：由单一文本模型，变为可按需组合视觉与音频编码器的模块化模型。对已经在使用初代模型的团队而言，升级的主要工作是重新为数据建立向量索引，因为新旧模型的嵌入空间不能混用。对于新项目，可以直接从统一的多模态索引起步，少维护几套检索栈，也少写几层对齐向量空间的胶水代码。落地时建议先在小规模真实数据上，比较不同截断维度与量化方案下的召回率，再决定上线配置。