7.4亿参数只占191MB:谷歌把多模态嵌入塞进手机

7.4 亿参数的模型，在手机上跑纯文本只占 191MB 内存。谷歌 10 月 6 日发布的 EmbeddingGemma 2 把这件事做成了，省下来的内存来自一次拆分：三块编码器，用哪块挂哪块。

191MB 是三块零件按需拼出来的

先明确它的身份，这是个嵌入模型，不回答问题，只把文本、图片、音频、视频各转成一串数字，让机器拿去比对相似程度。

它的 7.4 亿参数由三块拼成：2.7 亿的文本核心，1.7 亿的视觉编码器，3 亿的音频编码器。只做文本检索的应用可以不加载后两块，量化后的纯文本权重跑在 Pixel 11 Pro 上约 191MB；三块全挂，约 567MB。

191MB 对应的是纯文本，567MB 才是三块全挂的完整多模态。

这里有个容易误读的地方。初代 EmbeddingGemma 是 3.08 亿参数的纯文本模型，这次多出来的四亿多参数几乎全在视觉和音频上，做代码索引或文档检索的人升级过来，内存账单大概不会变。

768 维砍到 256 维，质量掉多少

每输出一条向量，本地向量库就多存一条。一张照片、一段录音、一页文档各占 768 个浮点数，几千条之后手机就吃不消了。

谷歌用的办法叫 Matryoshka 表示学习，名字来自套娃，一条 768 维向量按粗细分层，直接截到 512、256 或 128 维仍然能用，存储和内存占用最多降到六分之一。

砍到哪里开始疼，官方开发者指南给了答案：256 维时，图像、视频、语音检索保留约 95% 的完整质量​。所以多数手机应用根本不用留满 768 维，128 维是留给"宁可漏一点、也不能卡"的场景。

8K 上下文换算成视频，只有 58 帧

上下文窗口从初代的 2K 提到 8K，看着是四倍。换算成真实素材，一次能吃下 5.5 分钟音频、29 张图片，或者 58 帧视频。58 帧是什么概念，按两秒 30 帧算，连两秒的片子都装不满。

所以别指望它把一部两小时的电影直接索引掉。它的处理单位是片段，你要先把视频切好、音频分好，它再把每一片变成向量。切块这一步谁来做，直接决定检索准不准，这也是端侧 RAG 里最不体面的部分：模型很强，切分策略粗糙，结果就废。

最实在的提升在代码，还有和 Gemma 4 共用零件

这次基准里涨得最多的是代码，MTEB Code 从 68.76 涨到 78.68，多出 9.92 分；多语言文本的分数几乎没动。

这解释了谷歌为什么把它往编程代理上引：本地代码库索引和语义搜索都要求嵌入模型小而准，同时不许把公司的代码传出去。

另一处细节是它和 Gemma 4 架构同源，共享文本分词器和音频编码器。同一台设备上跑"检索加生成"的端侧 RAG，两份模型的内存开销比装两个互不相干的模型更低，谷歌自己的 AI Edge Foresight 会议应用就是这么跑的。

要不要迁移，判断标准很短：数据敏感到不能离开设备，或者断网也要能用，才值得为它改一遍管线。只在云端做 RAG 的，没必要动。

权重放在 Hugging Face 和 Kaggle 上，Apache 2.0 许可，ollama、llama.cpp 这类工具也已经能用，试错成本很低。真要动手前先想一个问题：你手机里最想搜、又最不愿意上传的那批东西，是照片、录音，还是一整个代码仓库？留言告诉我你选哪个，我挑几个典型的写下一篇落地拆解。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～