---
url: /lm/embeddinggemma/introduction.md
description: >-
  EmbeddingGemma 2 是 Google DeepMind 于 2026 年 10 月 6 日发布的开源多模态 Embedding 模型，740M
  参数把文本、代码、图像、视频、音频映射进统一的 768 维向量空间，Apache 2.0 可自由商用，量化后在 Pixel 11 Pro 上仅占
  191MB（纯文本）到 567MB（全模态）内存，MTEB Code 从 68.76 提到 78.68。本文带你搞懂什么是多模态嵌入、Matryoshka
  套娃降维怎么用、以及怎么在本地跑通第一次「以文搜图」。
---

# 认识 EmbeddingGemma 2：谷歌把「用一句话搜视频」塞进手机，740M 参数还 Apache 2.0

你手机相册里躺着九千张照片、两百段视频。你想找去年夏天那次——孩子在海边第一次下水，你举着手机喊了一句「慢点，慢点！」。

相册的搜索框只会认「海边」「沙滩」这类标签。你当时喊的那句话，它一个字也听不懂。

过去想干成这事儿，路子只有一条：把照片视频全传到某个云端服务上，交给人家的服务器去理解。代价你自己清楚——几千段私人影像过一遍别人的机房，还要按月付费。

2026 年 10 月 6 日，Google DeepMind 把这条路给堵上了。**EmbeddingGemma 2**，740M 参数，Apache 2.0 免费商用，能把文本、代码、图片、视频、音频塞进**同一个 768 维向量空间**，而且小到能在手机上跑。

也就是说：**你录一句语音，它能从你的视频里找到那个画面。全程不出你的口袋。**

> 多模态检索这件事，难的不是算法，是「你舍不舍得把数据传出去」。当模型小到能装进手机，这个问题就自动消失了。

## 什么是 EmbeddingGemma 2

先补三十秒的前置知识，不然后面全是黑话。

**Embedding（嵌入）**，说白了就是把一个东西翻译成一串数字（向量）。翻译的规则是：**意思越接近的东西，数字串越像**。你把「如何给手机省电」和「延长续航的小技巧」翻成向量，这两个向量的夹角会非常小；而「今天天气不错」翻出来的向量，会离它俩很远。

有了这个，搜索就不再比字符，而是比意思。这就是 RAG（先检索再让大模型回答）的地基，也是所有「智能相册」「本地知识库」的底牌。

**EmbeddingGemma 2 就是干这个翻译活的模型**，只不过它比大多数同行多了一样本事：**它不只翻译文字，图片、视频、音频它一起翻译，而且翻进同一个空间里**。

同一个空间的意思是——你用一句话去搜，能直接搜出图片和视频；你用一段录音去搜，也能搜出文字。**跨模态检索不需要任何中间转换。**

参数是这么拆的：

| 组成部分 | 参数量 | 干什么用 |
| --- | --- | --- |
| Transformer 骨干 | 130M | 文本理解主体 |
| Embedder（嵌入层） | 140M | 输出 768 维投影前的表示 |
| 视觉编码器 | 170M | 图像、视频抽帧 |
| 音频编码器 | 300M | 语音、环境音 |
| **合计** | **740M** | 全模态拉满 |

前两项加起来 270M，就是**纯文本干活时的最小配置**。视觉和音频编码器是模块化挂件，**不用就不加载**。

架构上是 Gemma 4 的底子：24 层，模型维度 512、隐藏维度 2048，滑动窗口 1024 token，词表 262,144，注意力用 GQA/MQA 混合（局部:全局 = 5:1，每 5 层做一次全局注意力），激活函数是带门控的 GELU FFN，池化用 mean pooling，最后一层 512→768 的投影把维度抬到输出想要的 768 维。

上下文窗口 **8,192 token**，是初代 EmbeddingGemma 的四倍。换成你能感知的单位：**大约 5.5 分钟音频、29 张图片、或者 58 个视频帧**，也可以混着来。

## 它有什么特点

* **四种模态，一个空间**。文本（含代码）、图像、视频、音频，以及它们的任意交错组合，全部映射到同一个 768 维向量。不用为每种模态各养一个模型、各维护一个索引——**一个模型一份索引，全搞定**。这一点听起来朴素，实际能给工程省掉一大半复杂度。

* **Matryoshka 套娃降维（MRL），最高省 6 倍存储**。原生输出 768 维，但你**不用重新训练**，就能在推理时把向量截断到 512 / 256 / 128 维再重新归一化。Google 的说法是本地向量库存储最多能砍到六分之一。官方给了参考数：一百万条向量在 768 维下约 1.5GB，砍到 128 维约 250MB。**但别贪便宜**——模型卡明确写着降到 128 维时，图像、视频、音频的检索质量会掉到满配的**约 75%**，128 维只建议用在纯文本场景。质量可接受的下限是 **256 维**。

* **MTEB Code 从 68.76 冲到 78.68，一次涨了 9.92 分**。这是它相对初代提升最猛的一项。代码跟自然语言不是一回事——变量名叫 `tmp2` 还是 `buffer`，字面毫无关系，语义却可能完全相同。这个涨幅意味着**本地代码搜索、代码库索引、编程 Agent 的检索环节**，从此有了能在自己机器上跑的选项。
  > 做开发工具的都懂：Agent 能不能找对文件，八成取决于它检索那段写得行不行，而不是它用的大模型有多贵。

* **多语言不掉队，覆盖 100+ 语言**。MTEB 多语言（v2）得分 61.36，跟初代的 61.15 基本持平——**加了三个模态，文本能力没退步**，这事本身就挺难的。

* **按需加载，别为用不上的模态买单**。`{"vision_config": None, "audio_config": None}` 传进 `config_kwargs`，模型就只加载文本那 270M。四种组合如下：

  | 开哪些模态 | `config_kwargs` | 实际参数 |
  | --- | --- | --- |
  | 纯文本 | `{"vision_config": None, "audio_config": None}` | 270M |
  | 文本 + 图像 | `{"audio_config": None}` | 440M |
  | 文本 + 音频 | `{"vision_config": None}` | 570M |
  | 全模态 | `{}` | 740M |

* **手机上真能跑**。在 Google Pixel 11 Pro 上量化后，官方口径是**纯文本权重约 191MB 活跃内存，全模态约 567MB**。567MB 是什么概念？差不多是你刷一会儿短视频缓存的量。**「端侧多模态检索」从论文标题变成了一个 App 能塞下的东西。**

* **跟 Gemma 4 共用分词器和音频编码器**。这个细节很容易被略过，但很值钱：你要做「本地检索 + 本地生成」的完整 RAG，跑 EmbeddingGemma 2 + Gemma 4 这套组合，比跑两个互不相干的模型**省内存**，因为底层的东西是共享的。

* **任务前缀这个「小机关」，不加不会报错，但效果会偷偷变差**。训练时文本输入前面带了指令前缀。检索类（非对称）是**查询加查询前缀、语料加文档前缀**；分类聚类相似度（对称）是**两边加同一个前缀**。图片、视频、音频**不加任何前缀**。这套前缀从别的 embedding 模型迁移过来时最容易被忘记——**它不报错，只是分数悄悄低一截**，这种 bug 最难受。

* **Apache 2.0，权重在 Hugging Face 和 Kaggle 上，可商用可修改可分发**。没有「仅限研究」那句要命的话。上一代 EmbeddingGemma 已经被下载了**超过 2000 万次**，社区基础不是从零开始的。

**两个必须提前知道的坑：**

第一，**别用 float16**。模型卡里这行字最容易被跳过：它的激活值范围超出了 float16 的动态范围，用它会得到 NaN 或者**静默退化的向量**——不报错，结果就是不对。请一律用 **bfloat16 或 float32**。这是那种能让你 debug 一整晚然后怀疑人生的坑。

第二，**生态文档里有个数字是错的**。Ollama 的模型页面上写着 256K 上下文，但模型本身每次输入只吃 8,192 token（模型卡口径）。长文档请按几百到两千字切块，别被那个数字骗了。

## 它能用在哪

**1. 「手机里找东西」这件事本身被重做了 —— Google 自己先做了三个 demo**

官方在 **Google AI Edge Gallery** 里放了三个示例应用，直接把能力演示出来了：

* **Instant Media Search（即时媒体搜索）**：用一段文字或者一张图，从媒体库里找语义相近的图片视频；
* **Video Moments Finder（视频时刻定位）**：用文字或音频查询，**定位视频里的某个具体瞬间**——就是开头那个「找到孩子第一次下水的那一段」；
* **Foresight**：本地检索挂上 Gemma 4 的推理能力，做完整的端侧多模态 RAG。

这三个 demo 的意义在于证明了「567MB 能不能干正事」这个疑问——答案是能。

**2. 本地代码搜索，这可能是最快落地的场景**

MTEB Code 78.68 这个分数，配上 Apache 2.0 和 191MB 的纯文本体积，指向一个非常具体的用法：**给你的代码库建一份本地语义索引，让 IDE 插件或者编程 Agent 在本地检索**。

好处很实在：公司代码不用传出去（这条对金融、政企、军工供应商是硬约束），检索零网络延迟（本地比调 API 快一个数量级），而且不要钱。

但说句实在话：**别指望它第一天就能替掉你现在这套**。请把你项目里最刁钻的十个问题拿出来，跟你现在用的检索方案跑一遍对比，再看要不要换。

**3. 隐私优先的本地知识库 / RAG**

这是上一代 2000 万次下载主要流向的地方，也是第二代最有想象力的地方：**你的合同、病历、财务纪要、客户录音，全都留在本地建立索引，配 Gemma 4 做回答**。

跟云端 RAG 相比，它不是「更好」，它是「更能被法务通过」。很多场景不是云端模型不够强，是数据根本不允许出内网——这时候本地小模型不是次优解，是**唯一解**。

**4. 端侧的分流与路由**

通过 **MediaPipe Decision Task API**，可以用多模态上下文做实时分类和路由。比如 App 里用户上传了一张截图加一句抱怨，模型一次前向就判断该转人工还是自动处理——不用先生成一堆 token 再解析。

> 说句实话：这篇写得比平时保守，因为 **EmbeddingGemma 2 在 2026 年 10 月 6 日才发布，到今天满打满算三天**。目前没有查到公开具名的外部企业落地案例和他们自己的效果对比，所有跑分（MTEB、MIEB、MMEB、MSEB、MAEB）和内存数字**全部来自 Google 自报，尚无第三方复现**。所以请把这篇文章当作「知道有这么个东西、它大概能干什么」，而不是选型结论。真正决定它该不该进你生产环境的，是你自己在自己数据上跑出来的那张表。

## 初体验

三种上手难度，挑你自己顺手的。

**路线 A：Ollama，最快**

```bash
ollama pull embeddinggemma-2:270m
```

```python
import ollama

docs = [
    "title: none | text: Galaxy S24，摔过之后屏幕出现绿色竖线，已换屏。",
    "title: none | text: iPad 10，充电口积灰清理，未换件。",
]

query = "task: search result | query: 手机屏幕出现绿线"

doc_vecs = ollama.embed(model="embeddinggemma-2:270m", input=docs).embeddings
query_vec = ollama.embed(model="embeddinggemma-2:270m", input=query).embeddings[0]

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    norm = (sum(x * x for x in a) ** 0.5) * (sum(y * y for y in b) ** 0.5)
    return dot / norm

for doc, vec in zip(docs, doc_vecs):
    print(round(cosine(query_vec, vec), 3), doc)
```

第一个应该明显排第一。注意这里**前缀要自己手写**，Ollama 默认不加。

**路线 B：sentence-transformers，功能最全（要 6.1.0 及以上）**

```bash
python3 -m venv ~/eg2
source ~/eg2/bin/activate
pip install -U "sentence-transformers[image,audio,video]" transformers
```

```python
from sentence_transformers import SentenceTransformer

# 全量 740M；纯文本可加 config_kwargs={"vision_config": None, "audio_config": None}
model = SentenceTransformer("google/embeddinggemma-2")

query = "What causes the northern lights?"
document = "The northern lights are caused by charged particles from the sun."

query_emb = model.encode(query, prompt_name="SearchQuery")
doc_emb = model.encode(document, prompt_name="Document")

print(model.similarity(query_emb, doc_emb))
```

`prompt_name` 会帮你把前缀拼好。常用的几个：`SearchQuery` / `Document`（检索），`QuestionAnswering`、`FactChecking`、`CodeRetrieval`（代码检索），以及 `Classification`、`Clustering`、`SentenceSimilarity`（对称任务用同一套）。想看全列表，打印 `model.prompts` 就行。

`prompt_name="Document"` 默认用 `title: none`；**你的文档真有标题的话，请自己拼成 `title: {标题} | text: {正文}`，加了标题检索准确率会明显变好。**

**四条能省你半天的提醒：**

1. **精度务必设成 bfloat16 或 float32，千万别用 float16**，会得到 NaN 或者静默掉质量。这条我在上面说过一次，这里再说一遍，因为它是这篇最重要的一句话。
2. **截维先看 256**。128 维只适合纯文本；涉及图片视频音频，降到 128 维质量只剩满配的约 75%。先用 768 维跑通，再往下砍到 256 看能不能接受，别一上来就省到骨头。
3. **`config_kwargs` 跳过编码器的写法，不同运行时的行为不完全一致**。换 llama.cpp、MLX、Ollama 之前，请先翻对应运行时的文档别想当然地照搬。
4. **它上架 Gemini Enterprise Agent Platform Model Garden 还是「coming soon」**，目前只有 Hugging Face 和 Kaggle 两个权重来源。另外 SGLang、vLLM、llama.cpp、MLX、LM Studio、transformers.js（浏览器 + WebGPU）都已支持，向量库官方示例用的是 Qdrant。

## 进阶

到这里，你已经知道 EmbeddingGemma 2 是什么、它凭什么叫多模态、怎么把第一条「以文搜图」的链路跑起来了——对新手来说，知道比精通重要得多，剩下的交给好奇心就行。

真想往下挖，建议这个顺序：先用上面那段 demo 把 256 维和 768 维各跑一遍，亲眼看看截断到底掉了多少分；然后把 `prompt_name` 挨个试一遍，体会一下前缀到底影响了什么；接着换成你自己的文档或者自己的代码仓库，跟你现在的检索方案做同集合对比；有余力再去看 Matryoshka 表示学习的原始论文，弄明白「为什么能在推理时剪」。

顺带一提，如果你想横向比较，本站还有[腾讯 WeMM-Embedding](/lm/wemm/introduction)（2B/4B/9B 多模态 Embedding，MMEB-v2 上 9B 拿下 80.6）和 [MTEB 榜单说明](/lm/mteb)，可以对照着看不同路线的取舍。

最后提醒一次：**别第一天就想着让它替换公司跑了三年的检索系统**——那不是入门，那是渡劫。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。