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 帧算，连两秒的片子都装不满。