谷歌开源EmbeddingGemma 2：740M参数统一五种模态，端侧RAG这次真的能跑了

检索增强生成（RAG）的瓶颈，往往不在生成端，在检索端。2026年10月6日，Google DeepMind 发布并开源 EmbeddingGemma 2，试图把这个问题在端侧解决掉。这是一款 740M 参数的多模态嵌入模型，基于 Gemma 4 架构，采用 Apache 许可证，文本、代码、图像、音频、视频五种模态被映射进同一个 768 维向量空间。

一个模型拆成三块，按需加载

EmbeddingGemma 2 没有做成一体化的庞然大物，而是拆成三个独立组件：270M 参数的文本与代码主干、170M 参数的视觉编码器、300M 参数的音频编码器。开发者可以只加载文本主干做纯文本检索，需要跨模态时再挂载其他模块。

官方数据显示，量化后在 Pixel 11 Pro 上运行，纯文本模式只占约 191MB 内存，全多模态模式约 567MB。手机和入门级开发板都跑得动。

代码检索是明显的强项

MTEB Code 基准上，EmbeddingGemma 2 从上一代的 68.76 分涨到 78.68 分，提升 9.92 分。官方称在 1B 参数以下的多模态嵌入模型中，MTEB Code 和 MAEB 两项均排名第一。

对开发者来说，用自然语言搜函数、搜报错、搜配置片段，740M 的模型就能给出靠谱的向量召回，不必再把代码传到云端 API。

8K 上下文，Matryoshka 省存储

上下文窗口扩展到 8192 token，是上一代的 4 倍。一次输入可以处理约 5.5 分钟音频、29 张图像或 58 帧视频，也支持这些模态的交错组合。

存储端用上 Matryoshka 表示学习：768 维向量可按需截断到 512、256 甚至 128 维，精度损失可控，本地向量库最多省 6 倍存储。百万级文档的索引体积直接降一个数量级。

动手试试：30 行代码跑起来

用 sentence-transformers 加载模型，几行代码就能出向量：

“`python

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(“google/embeddinggemma-2”)

docs = [

“def resize_image(img, w, h): …”,

“季度营收同比增长23%，云业务贡献最大增量”,

“会议录音：周四站会纪要与待办事项”,

]

embs = model.encode(docs, truncate_dim=256) # Matryoshka 截断

“`

配合 sqlite-vec 这类嵌入式向量库，一套完全离线的本地 RAG 系统就成型了。数据不出设备，隐私敏感场景（医疗记录、企业内部文档、个人笔记）终于有了性价比足够的方案。

端侧嵌入的选型变了

EmbeddingGemma 2 之前，端侧嵌入模型基本被两个极端占据：要么是百M级纯文本小模型，跨模态能力为零；要么是数B参数的多模态大模型，端侧根本塞不下。740M 参数加上模块化拆分，正好卡在中间的空档上。

当然它也有偏科：代码检索突飞猛进，文本检索的提升相对温和，超大体量文档库的重排序场景仍需搭配云端模型。但对手机应用、本地笔记工具、离线代码助手这些场景，这块 191MB 的向量引擎已经够用。

模型权重已在 Hugging Face 上开放下载。检索端的本地化，2026年10月这个时间点，算是真正迈过了一道门槛。