Google 开源 EmbeddingGemma 2：7.4 亿参数把全模态检索塞进手机

EmbeddingGemma 2 是一个专门用来做跨模态向量检索的轻量开源模型，采用 Apache 2.0 协议开源，全模态版本参数量只有 7.4 亿。它不是用来聊天或生成文本的大语言模型，而是负责把文本、代码、图像、音频和视频等各种格式的内容，压缩并映射到同一个向量空间里。

这意味着你可以输入一段文字去检索一段录音，或者用一条语音备忘录去定位特定的视频片段。整个检索过程完全可以在消费级硬件上离线运行，不需要把数据传到云端。

它能做什么，怎么做到的

以往做端侧语义搜索或本地检索增强生成（RAG），开发者常常要为文本、视觉和音频分别跑不同的专用模型，不仅占内存，不同模态之间的特征也无法直接比对。EmbeddingGemma 2 基于 Gemma 4 架构打造，核心优势就是原生打通全模态。

为了兼顾轻量化，模型采用了模块化设计。如果你的应用只需要做纯文本搜索，可以只加载 2.7 亿参数的基础模块；需要支持图像时，再加载 1.7 亿参数的视觉编码器；需要理解音频，就加上 3 亿参数的音频编码器。三项全开的总参数量也只有 7.4 亿，模型文件整体只有 1.5GB 左右。

存储效率上，它引入了俄罗斯套娃表征学习（MRL）技术。模型默认输出 768 维的嵌入向量，但开发者可以根据本地硬件条件，将其动态截断为 512 维、256 维甚至 128 维。这一特性可以让移动端的本地向量数据库和内存占用最高缩减到原来的六分之一。

性能表现与运行门槛

性能方面，它在 10 亿参数以下的多模态嵌入模型中表现抢眼。在 MTEB Code 代码基准测试中，它的得分从上一代的 68.76 提升到 78.68，涨了近 10 个百分点，非常适合用来做本地代码库索引、代码语义搜索或编程 Agent 的上下文检索。在音频基准 MAEB 和图像嵌入测试中，它的质量甚至超过了一些体积是它两倍以上的专用模型。

模型的上下文窗口扩展到了 8K token，比第一代 EmbeddingGemma 扩大了 4 倍。在本地硬件上，这足以支持单次输入最长 5.5 分钟的音频、29 张图片或 58 帧视频画面，也可以将图文音视按任意比例交错混合输入。

硬件门槛也被压得很低。在量化状态下，在 Google Pixel 11 Pro 手机上运行纯文本模型仅需约 191MB 活动内存；哪怕开启文本、视觉、音频全模态，内存占用也只要约 567MB，完全能常驻在普通移动设备后台。

怎么跑起来

模型的权重目前已经全部上传至 Hugging Face 和 Kaggle，采用宽松的 Apache 2.0 许可证，商用门槛很低。

工具链生态也已经准备就绪。本地与服务端部署方面，它直接支持 transformers、sentence-transformers、llama.cpp、Ollama、LMStudio、MLX、vLLM 以及 SGLang，向量存储可以直接接入 Qdrant。如果想针对私有数据微调，Unsloth 也已经给出了适配指南。

面向移动端和端侧工程，开发者可以通过 Google AI Edge MediaPipe 进行开箱即用的检索集成，或者用 LiteRT 做深度定制；浏览器端开发者也可以通过 transformers.js 和 WebGPU 直接调用本地算力。

为什么重要

对于移动端应用开发者、独立创作者和注重隐私的本地 Agent 构建者来说，EmbeddingGemma 2 是目前少有的、能直接塞进手机的高质量全模态检索底座。以往要在端侧搞定相册智能搜索、离线会议录音检索或者个人代码库助手，内存开销和模型集成往往把人劝退，现在不到 600MB 内存就能搞定一套完整的全模态检索管线。

我们认为 Google 把它做成模块化并且跟 Gemma 4 共享分词器与音频编码器的做法非常务实，这让生成模型与嵌入模型联合运行时能进一步压低总内存。不过需要指出的是，8K 的上下文窗口处理短视频和日常录音足够，但遇到超长音频或大体量视频时，依然需要开发者在前端先做好切片策略。