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 帧算,连两秒的片子都装不满。
网硕互联帮助中心




评论前必须登录!
注册