7.4 亿参数把图文音视频塞进同一个向量空间：EmbeddingGemma 2 上线，手机就能跑

做短视频的朋友有个两万条的素材库：几千张产品图、几百段口播录音、一堆没剪的片段。他的问题不是没素材，是找不到。想找"上次那个在厨房拍的、光线偏暖的镜头"，只能靠记忆翻文件夹，翻半小时找不到，最后重新拍一遍。

这不是他一个人的问题。绝大多数团队的素材、文档、历史稿子，都是"存下来了但等于没有"。原因是检索只能靠文件名和标签，而标签是人打的，人打标签的时候想不到未来会怎么找。

十月六号谷歌发布的一个模型，正好冲着这个问题来。

一个 7.4 亿参数的模型能干什么

EmbeddingGemma 2，740M 参数，Apache 2.0 许可，构建在 Gemma 4 架构上。它的核心能力一句话概括：把文字、代码、图片、视频、音频映射进同一个 768 维向量空间。

同一个空间意味着什么？意味着你可以用一段语音备忘录去找一段视频片段，用一句话去找一张图，用一张图去找几段录音。这不是把五个模型拼起来，是一个模型同时理解五种输入。

上一代 EmbeddingGemma 只做文本，累计下载超过 2000 万次。这一代的升级方向很明确：从"文本检索"走到"跨模态检索"。

740M 是怎么分的

这个模型是模块化设计，参数分成三块：

• 文本部分 270M（其中 130M 的 transformer 主干 + 140M 的嵌入层）
• 视觉编码器 170M
• 音频编码器 300M

三块是独立的，可以按需加载。只做文本和代码就加载 270M，加上视觉是 440M，加上音频是 570M，全量是 740M。关键是所有配置共用同一个向量空间，你不会因为今天少加载一个编码器就导致昨天建的索引失效。

在资源占用上，量化后于 Pixel 11 Pro 上实测：纯文本权重约 191MB 运行内存，完整多模态约 567MB。这个数字的意义是——手机能跑。

8K 上下文的实际容量

上下文从上一代的 2K 扩到 8K，翻了四倍。官方给的换算：一张图 280 token、一帧视频 140 token、一秒音频 25 token。

所以单次输入的上限是：29 张图，或 58 个视频帧，或 5.5 分钟音频，或者这些内容的交错组合。

做素材库的话，一条短视频抽 8 到 12 帧足够表征，58 帧的上限意味着你可以一次塞进去四五条短视频做比较。音频 5.5 分钟对会议录音不够，需要先切段，但对口播片段绰绰有余。

向量可以截断，存储省 6 倍

这里有个很实用的特性叫 Matryoshka 表示学习（MRL）。简单说，训练好的 768 维向量可以直接截断成 512、256 或 128 维用，不用重新训练。

官方给的参考：100 万个 768 维向量按 bfloat16 存约占 1.5GB，截到 128 维约 250MB，最多省 6 倍。

质量代价是多少？配套文档里的数据：256 维在图像、视频、语音检索上保留约 95% 的质量；128 维在文本和代码上保留约 90%，但多模态检索掉到约 75%。

这条数据直接决定了你怎么选：纯文本/代码检索可以放心用 128 维；只要涉及跨模态，别低于 256 维。

代码检索涨了近 10 分

单模态里提升最大的是代码。MTEB Code 从上一代的 68.76 提到 78.68，涨了 9.92 分。

这个提升对本地代码库索引、语义代码搜索、编程智能体检索是实打实的。之前很多人做本地代码检索觉得"不如直接搜关键词"，多半是嵌入模型对代码结构理解不够，只能匹配字面。

如果你在搭本地编程助手，值得拿自己的仓库测一遍：把仓库按函数切块建索引，然后用自然语言提问（比如"处理支付回调超时那段在哪"），看召回的第一个结果对不对。

三条能马上落地的用法

本地素材库语义搜索。 把图片、视频帧、录音全部生成嵌入存进本地向量库（比如 sqlite + 向量扩展，或轻量向量数据库）。前端做一个输入框，输入自然语言或拖一张参考图，返回最相似的素材。全部跑在本地，素材不上传。

隐私优先的本地 RAG。 合同、病历、内部文档这类不能出内网的资料，用它在本地建索引，配一个本地生成模型（比如 Gemma 4，两者共用 tokenizer 和音频编码器，合起来内存占用更低）做问答。整条链路不出设备。

会议与访谈录音检索。 把录音按 5 分钟切片生成音频嵌入，之后用文字提问"哪一段提到了交货时间"，直接定位到时间点。这比先转文字再检索少一步，也避免了方言、术语转写错误。

几个要避开的坑

它没有做安全对齐。 模型卡写得很清楚：这是预训练嵌入模型，没有经过后训练对齐、安全微调或输出级审核，安全措施集中在预训练数据过滤上。也就是说，它不会拒答，也不会给你兜底。用在对外产品里，审核逻辑要你自己加。

别为了省存储无脑截到 128 维。 上面说过，多模态场景掉到 75%，这个损失不小。先按 768 或 256 建库，等数据量真的撑不住了再考虑降维重建。

大上下文不等于都记得住。 和所有长上下文模型一样，塞得越满注意力越稀。素材检索的正确做法是把每个素材单独生成嵌入存起来，查询时只送查询本身，而不是每次把整个库塞进上下文。

端侧性能要实测。 191MB / 567MB 是 Pixel 11 Pro 上量化后的数字，换设备、换推理框架都可能不一样。先在你目标机型上跑一遍再承诺给产品。

一周内能做完的最小实验

第一天，装 sentence-transformers，加载 google/embeddinggemma-2，对你的素材跑一遍纯文本嵌入，感受一下速度。

第二天到第三天，加上视觉编码器，把图片库也生成嵌入，做一个命令行检索工具，用文字搜图。

第四天，把向量从 768 截到 256，对比同一组查询的召回结果，看看你的数据上掉多少。

第五天，接一个简单的图形界面或者网页，让不懂命令行的人也能用。

一周之后你会有一个能跑的本地素材检索工具。它不会替代云端的检索服务，但它让你第一次能回答"上次那个镜头在哪"——而且素材一张都没离开你的硬盘。

这才是这类端侧模型真正的价值：不是性能更强，是把"不敢上传"的那部分数据变得可用。