EmbeddingGemma 2: Unified and Efficient Multimodal Representations

想让一个 embedding 模型同时搜文字、图片、视频和音频，常见做法是先把音频转成文字、给图片配说明，再交给文本模型，既多花算力，又丢掉了语气和画面细节。Google 的 EmbeddingGemma 2 用一个 744M 参数的模型，把这几种输入直接映射到同一个向量空间，各模态编码器还能按需加载。用语音提问去找文本段落最能说明差别：同一个模型先把语音转写成文字再检索，MRR@10 是 57.59，直接读音频能到 69.54。小模型做多模态，不一定要牺牲文本和代码，它的代码检索分数反而比上一代高出近十分，从 68.76 升到 78.68。

做端侧或低成本检索的团队值得读这篇，因为它给出了一份可以照着做的小模型多模态训练配方，而且每个关键选择都有消融：先蒸馏、后对比学习，视觉编码器要一起训，训练结束把最终 checkpoint 和早期 checkpoint 平均。量化到 int4 后，完整多模态模型在 Pixel 11 Pro 上峰值内存 567MB，只做文本时 191MB。需要留意的是，英文文本分数比上一代略低，int4 量化对图片和语音的伤害明显大于文本，视频在加大视觉 token 预算后反而变差。

它到底在解决什么问题？

多模态检索现在大致有三种做法。

EmbeddingGemma 2 想做的是第四种：参数量压到 1B 以下，却仍然能把任意模态和它们的组合编码进同一个空间。

用一个小例子看差别（示意）。手机相册助手要支持一句语音提问“上次弹吉他那段视频”，库里有一段吉他视频、一张吉他照片和一条“吉他调音器”的笔记。

整体流程

这张图看中间那排彩色方块：不同模态的 token 按原来的先后顺序交错排在一个序列里，所以一条输入可以是“一段文字加一张图再加一段语音”。

输入的拼法很直接：文字按词切成 token；图片先过视觉编码器，再在空间上池化到预算以内的视觉 token，前后包上图片起止标记；视频按帧处理，最多 32 帧；音频按 40 毫秒一段切开送进音频编码器。所有片段按原顺序首尾相接，所以“文字加图片加语音”的混合输入也只是一个更长的序列。任务通过前缀告诉模型，例如检索 query 写成 task: search result | query: {text}，文档侧用另一种前缀。

设计一：去掉逐层查表，给非文字输入留位置

为什么需要：Gemma 4 在每一层都会额外注入一份Per-Layer Embeddings（PLE），它由两部分相加，一部分是主 token embedding 的线性投影，另一部分来自一张按词表查的专用表。图片和音频的 soft token 没有词表编号，查不到这张表，表本身还要占内存。

怎么做：EmbeddingGemma 2 只保留投影那一部分，每层的额外输入都从当前 token 的嵌入算出来，不管它来自文字、图片还是音频。

小例子（示意）：一条输入是“吉他”两个字加一张图片的 280 个视觉 token。原来的做法里，这两个字能查到逐层表，280 个视觉 token 只能拿到投影；改完以后，282 个位置拿到的是同一种逐层输入。 Hoot 说▾

Hoot 说同一条图文输入，删表前后每层多拿到的那份输入怎么来收起 ✕

原来文字走“投影 + 查表”、图片只走“投影”，两类位置不一样；删掉查表后，282 个位置都只由自己的嵌入投影得到。

Gemma 4：投影 + 查表

“吉他” 2 个文字位置

投影 + 查表

280 个视觉位置

只有投影，查不到表

合起来

来源不一致，还占内存

还要在内存里存一整张逐层表。

EmbeddingGemma 2：只用投影

“吉他” 2 个文字位置

投影

280 个视觉位置

投影

合起来

282 个位置同一算法

音频 token 同理：只要有嵌入，就能得到逐层输入。

示意：2 个文字位置加 280 个视觉位置；查表只能按词表编号查，视觉 token 没有编号。 出处: 正文“设计一”的 PLE 描述与示意例子

这说明那张专用表对多模态检索没有帮助，去掉它既省内存，视频和视觉文档还略有提升。

设计二：先蒸馏，再用对比学习收尾

为什么需要：小模型直接从对比学习起步，很难学出大模型那样的空间结构；但如果一直蒸馏，学生只能逼近老师的空间，而老师的空间并不是为 768 维、Matryoshka Representation Learning（MRL）截断和这么小的模型准备的。

怎么做：训练分四段，总计约 2.9T token。

对比损失写成 ${\mathcal{L}}_C=-\frac{1}{B}{\sum }_i\log \frac{Z_i^P}{Z_i^P+Z_i^{HN}+Z_i^{IB}+Z_i^{STN}}$，其中 $Z^{STN}$ 是同塔负例：一条 query 和批内其他 query 的相似度，加上它的正例文档和其他正例文档的相似度。加它是为了防止 query 和文档各自挤在两块互不相交的子空间里。

小例子（示意）：一批里有“吉他调音器”和“尤克里里教学”两条 query。批内负例让“吉他调音器”离“尤克里里教学”对应的文档远一些；同塔负例还要求两条 query 本身也拉开，避免所有 query 都聚在空间的一个角上。

这说明蒸馏到一定程度就到顶了。换成整套微调方案（对比损失加 spread-out 正则）后多了 3 分以上；这组对照没有把对比损失和正则分开测。

最后的 checkpoint 合并也值得单独说。常见做法是跑几次不同数据配比或超参的微调再平均，这里只用一次训练：把最终 checkpoint 和同一条训练轨迹上早得多的一个 checkpoint 等权平均。复现时，这个早期 checkpoint 可以在验证集上挑，选在过拟合任务开始掉分之前。作者观察到，微调后期有些任务会过拟合而掉分，早期 checkpoint 还保留着这些任务的能力，平均之后这些任务回升，原本受益于微调的任务还能再涨一点。对资源有限的团队，这比多跑几次微调便宜得多。

quantization-aware training（QAT）也没有放进微调里，而是在合并之后另起一小段：用冻结的浮点模型当老师，初始化并蒸馏出 int4 版本。这样这段训练很短，作者说它主要缩小了英文文本上浮点与量化之间的差距。

设计三：视觉编码器一起训，视觉 token 预算按场景调

为什么需要：从 VLM 继承来的视觉编码器是为生成文字准备的，不一定适合做检索；而每张图用多少个视觉 token，直接决定延迟和效果。

怎么做：视觉编码器在训练中保持可训练。训练时每张图 280 个视觉 token，视频每帧 140 个，推理时可以改成 70 到 1120。

这说明冻结视觉编码器会损失约 4 分，省下的训练成本不值得。

这说明预算加大对 PDF、幻灯片这类视觉文档最有利，从 280 加到 560 涨了 4 分多；视频帧在超过 280 后反而从 48.51 降到 46.52，上线时应当按内容类型分开设置预算。

主要结果：小一个量级，分数却在前沿上

看图时先找星号再看阴影：代码和图片两张图里阴影面积最大，说明在 1B 以下这两个方向它领先最多；音频那张阴影较小，说明它在音频上只是和同量级最好的模型持平。

这说明它的强项集中在代码、图片和视觉文档，代码上超过所有 4B 以下的模型，距离大 28 倍的榜首不到 2 分；文本基本持平上一代，英文略退。

语音检索单独看更清楚，测试是用一种语言说出的问题去找文本段落，覆盖 26 种语言和地区。

这说明省掉 ASR 这一步不只是省算力，还多拿 12 分；截到 256 维（66.76）仍比它自己先转写（57.59）高 9 分以上，只是不如 Gemini Embedding 2 先转写（70.40）；向量存储可以先砍到三分之一。

端侧部署方面，int4 按通道量化后在 Pixel 11 Pro 上峰值内存是纯文本 191MB、图文 447MB、全模态 567MB。

这说明量化对文本几乎无损，对图片和语音的损失在 3 到 6 分之间，部署前要按模态分别评测。

注意论文说明浮点和量化两组的语音、图片分数用的是不同评测脚本，这两项差距只能作为参考。

我认为它的局限

第一，多模态的代价落在了英文文本上。MTEB 英文从上一代的 69.67 降到 68.46，代码虽然大涨，但如果线上主要是英文文本检索，换模型前应该先在自己的数据上确认这 1.2 分的回退影响有多大。

第二，视频是最弱的一环。在视觉 token 预算那组实验里，视频 Hit@1 一直在 46 到 49 之间，预算从 280 加到 560 反而掉了约 2 分，说明多帧信息的整合还没训好，做短视频检索的团队不能直接把视觉文档上的结论搬过去。

第三，音频编码器训练时冻结，直接沿用 Gemma 4 的权重，向量里一些声学信息没有被整理好。一个迹象：在 IEMOCAP 数据上，用向量训练一个线性分类器判断说话人性别，准确率能到 66.40%，说明性别信息还在向量里；但直接按性别给 VoxPopuli 录音聚类时，效果在附表 Table 17 的音频任务里排在最差的一档。也就是说，信息在，但没有排成聚类能直接用的形状。依赖音频聚类或去重的场景要先验证。

一个推荐或搜索团队可以怎么试

1. 先只加载 271M 的文本部分，替换现有文本 embedding，用自己的英文、中文和代码查询各抽一批做离线对比，重点看英文是否回退。
2. 有语音搜索的业务，把语音 query 分两路：一路走现有 ASR 加文本模型，一路直接送音频编码器，比较 MRR@10 和端到端延迟。
3. 有图片或文档库的业务，加载视觉编码器，按内容类型分别试 140、280、560 三档视觉 token 预算，文档类和视频类分开定。
4. 用 MRL 截到 256 维做一组对照，算清索引存储和召回分数各变多少，再决定线上维度。
5. 如果要上端侧，用 int4 按通道量化版本按模态各测一遍，图片和语音的退化要单独过线。
6. 想自己微调的团队，可以照搬它的顺序：先从大模型蒸馏，再用带同塔负例的对比学习收尾，最后把最终和较早的 checkpoint 平均。

一句话结论

这是目前 1B 以下最完整的多模态 embedding 方案，代码、图片和语音检索都在同量级领先，代价是英文文本略退、视频偏弱。