你有没有想过这样一件事：你想找手机里的一段录音，但只记得里面有人提过”下周三”三个字，却不知道是哪个文件。按文件名翻，永远找不到。
十月六日，谷歌 DeepMind 发布了一个模型，专门干这类活。它叫 EmbeddingGemma 2。
一句话说清它是什么
EmbeddingGemma 2 是一个嵌入模型。嵌入模型不生成文字、不回答问题，它只干一件事：把一段内容变成一串数字，让计算机可以通过比较数字来判断两段内容像不像。
听起来抽象，但它是所有搜索和知识库问答的底座。你在笔记本里搜”上季度报价单”，能搜出来不是因为文件名里有这几个字，而是因为系统把每份文件都变成了数字，然后算哪一串离你的问题最近。
这一代最大的变化是：它不再只认文字。 文字、代码、图片、音频、视频全都被放进同一个空间。所以你可以用一句文字描述，去找一段音频或者一帧画面——中间不需要再挂一个转换模型。
为什么”同一个空间”是重点
如果每种内容各用一套模型去编码，那跨类型搜索就得做两次转换：先把你的文字变成 A 空间的坐标，再想办法猜 B 空间里对应哪一点。这个”猜”就是误差的主要来源。
EmbeddingGemma 2 的做法是把五种输入统统塞进同一个坐标里。语音备忘录和视频片段、代码和图片，彼此之间可以直接算距离。官方给的例子很贴切：用一句描述去找一段视频，或者用一段录音去找一组照片。
模型采用模块化设计，这一点很实惠：
- 只做文字任务：约两亿七千万参数
- 需要看图片：再加一亿七千万参数的视觉编码器
- 需要听声音：再加三亿参数的音频编码器
- 全部加起来：七亿四千万参数
也就是说，如果你只做文本检索，根本不用背上多模态那部分开销。
能在手机上跑的账是怎么算出来的
参数少只是第一步，真正决定能不能落地的是内存。谷歌给的数字是：在量化之后、在 Pixel 11 Pro 上，纯文本权重占用约一百九十一兆字节内存，完整的全模态版本约五百六十七兆字节。
上下文窗口从上一代的两千个词元提到了八千个，翻了四倍。换算成内容，大约是五分半钟的音频、二十九张图片，或者五十八帧视频，也可以把这些混着塞进去。
还有一个细节值得单独说：向量长度可以截断。借助一种叫 Matryoshka 的表示学习方法，输出向量能从七百六十八维一路缩到五百一十二、二百五十六或者一百二十八维，本地向量库的存储最多能省六倍。对笔记本和手机这种存储紧张的场景，这一条的价值不比参数少。
另外，因为它建立在 Gemma 4 的架构上，和 Gemma 4 共用同一套分词器和音频编码器，两个模型放在一条流水线里跑，总内存占用比分开跑更低。
跑分涨在哪，也有两块没涨
先明确一件事：以下数字都来自谷歌自己的评测，没有第三方复现。这个前提必须记住。
- 代码检索涨得最猛：在 MTEB Code 上从六十八点七六提到七十八点六八，涨了九点九二分，接近百分之十四。做本地代码库索引、语义化代码搜索的人，这是最直接的收益。
- 多语言文本基本持平：从六十一点一五到六十一点三六，几乎没动。官方的说法是这一代的重点放在新增模态上，而不是重做已经好用的部分。理解这个取舍，比看涨了多少更重要。
- 图片检索并不是霸主：在多模态检索基准 MMEB v2 的图片检索项上，它拿到五十七点二八分，而一些参数规模更大的开放模型可以到七十七点九分，更大的版本甚至能到八十点六分。谷歌的主张有明确前提——它比的是十亿参数以下这一档，在这个档位里它说自己领先。
再补一句官方自己承认的限制：这个模型没有做安全微调，而且它支持的超过一百种语言里，表现并不均衡。
和云端方案比，它省的不只是钱
把同样的活交给云上的嵌入接口，账单大致是这样：谷歌自家的 Gemini Embedding 2 大约每一百万文本词元零点二美元；Voyage 的多模态版本按像素算，约每十亿像素零点六美元再加词元费；Cohere 的 Embed 系列约每一百万图片词元零点四七美元。这些都跑在别人服务器上。
开放权重里最接近的对手是 Jina 的 Embeddings v5 Omni，同样支持文图视频音，但它用的是禁止商用的许可。EmbeddingGemma 2 用的是 Apache 2.0，可以商用——对打算把东西做出来卖的人，这一条是实打实的差别。
省下的另一部分是隐性成本：本地生成向量意味着数据不出设备、延迟更低、断网也能用。对处理病历、法律文件、私人录音的场景，这既是省钱，也是少签一份数据处理协议。
上手三步
- 先把文件拿回来。 权重放在 Hugging Face 和 Kaggle 上，另外谷歌云上的模型目录也在跟进。接口层面已经有 transformers、sentence-transformers、MLX、vLLM、llama.cpp、Ollama 这些常见工具支持，你现有的本地推理环境基本不用换。
- 用官方的体验入口试一次手感。 谷歌在自家 AI Edge Gallery 里放了”即时媒体搜索”，可以直接用文字或图片在本地媒体库里找最接近的结果，还有一个 Mac 端的应用把本地会议音频和文件接进笔记。先感受一下”一句话找到一帧画面”是什么体验，比看介绍快。
- 用自己的音频和视频验一遍。 这一步别省。目前的唯一质量证据来自出品方，而且官方明确说模型没做安全微调、各语言表现不均。拿你真实的素材跑一次，再决定要不要进生产。
如果你更关心”这类模型装在哪台机器上”，站内写过的 DGX Spark 和 本地大模型部署实战 可以连着看；如果你更关心底座模型本身，Qwen3.8-27B 的本地跑法是另一条线上的选择。
优缺点
优点：
- 一个模型覆盖五种输入，跨类型检索不用再拼第三方转换服务
- 模块化裁剪，纯文本场景的内存开销小得多
- 向量可截断，最多省六倍存储
- Apache 2.0 可商用，这是同档开放模型里最稀缺的一条
- 离线可用，数据不出设备
缺点：
- 跑分全部来自厂商自测，没有独立复现
- 图片检索这一项明确打不过参数更大的开放模型
- 没做安全微调，也没有内容审核能力
- 支持的语言多，但各语言表现不均衡
- 只负责”找”，不负责”答”——要组成问答还得再配一个生成模型
适合谁，谁先别急
现在就该试： 在做本地知识库和 RAG 的人；需要跨图片、音频、视频做检索的产品；对数据出境敏感、又不想放弃多模态搜索的团队；正在给桌面端或移动端应用找离线检索方案的个人开发者。
先别急着上： 已经用云端嵌入接口跑顺、且不介意数据外发的团队——迁移的收益可能抵不上改造成本；需要图片检索精度做到一流水准的项目——这一档不是它的强项；以及需要把模型直接放进合规产品的场景——没做安全微调这件事，得你自己在应用层补。
四个替代方案
- 云端省事路线：继续用 Gemini Embedding 2 或 Cohere Embed。省运维，代价是每请求付费和数据处理协议。
- 要图片精度：选参数更大的开放多模态嵌入模型，接受它跑不动手机的代价。
- 已经绑在某个知识库上：比如用 Dify 那套流程，评估先别换底座，等官方支持再说。
- 只做文字：继续用上一代 EmbeddingGemma 或同档文本模型就够了，多模态这部分对你没用。
老达点评
第一，这个模型真正的价值不在”又发布了一个模型”，而在它把多模态检索从云服务变成了一个可以下载的文件。过去想做一个能搜图、搜音频的小工具，第一步就得先去申请一个 API 密钥；现在第一步是下载几十兆权重。门槛降下来的地方，才是普通人有机会的地方。
第二，模块化设计比参数总量更值得学。 它给的不是一个七亿参数的大包，而是一份”按需装配”的清单：只做文字就只背两亿七千万。很多产品其实用不到多模态，但为了少数场景被迫背全套成本。这种”能拆开”的设计思路，值得所有做工具的人借鉴。
第三，跑分那两块没涨反而是好信号。 多语言文本基本持平，图片检索明确输给更大的模型——官方把这两条明明白白写出来了。愿意说清自己哪块不行的团队，比只报最高分的团队可信。
第四，对做内容的人，这里有一条被忽略的用法：给自己的素材库做本地索引。 几个 G 的录音、视频、截图存久了就是一堆废料，本地建一次索引，之后用一句话就能翻出来。这件事过去要租云、要付费，现在一台笔记本就能干。
上手第一步
今天最省事的一步：去 Ollama 或 llama.cpp 里把这个模型拉下来，挑二十个你自己的文件——几张图、一段录音、几份文档，本地生成一次向量，然后用一句话去搜。感受一下”跨类型搜索”到底好不好用，再决定要不要往生产里放。
