AREX Feed Article
谷歌发布 EmbeddingGemma 2：740M 参数的开源端侧嵌入模型，统一文本、代码、图像、音频与视频
谷歌于当地时间 10 月 6 日（北京时间 10 月 7 日凌晨）发布开源嵌入模型 EmbeddingGemma 2。称其为谷歌首个原生多模态（natively multimodal）的端侧嵌入开放模型：在文本之外，把代码、图像、音频与视频映射进同一个共享嵌入空间。模型共 740M 参数，以允许商用的 Apache 2.0 许可发布，权重已上架 Hugging Face 与 Kaggle；补充说，开发者可以拿它给应用加多模态搜索，比如用一条语音备忘录找到视频里的某个片段，或与 Gemma 4 搭配，做私有的端侧 RAG（检索增强生成）。
由 Google DeepMind 研究工程师 Sahil Dua 与 Henrique Schechter Vera 署名的同步贴出了量化后的端侧实测账单；第三方 Unsloth 的则称该模型能在 0.5GB RAM 的本地环境运行，GGUF 权重与运行、微调教程已一并上线。
270M 文本底座，加两块可选的视觉与音频编码器
嵌入模型的工作是把内容压成一串向量，检索时按向量之间的距离找相近结果。此前要做跨模态搜索，往往得把不同模态交给各自的模型分别编码，再想办法对齐结果；EmbeddingGemma 2 用一个模型完成映射，官方给出的例子是用语音备忘录定位视频片段、用文本查询搜几小时的录音。
官方博客介绍，这个模型与 Gemini Embedding 模型同源，基于 Gemma 4 架构构建，模块化拆分后各有分工：纯文本任务最低只需 270M 参数的文本模型，视觉（170M）与音频（300M）编码器可选装，装齐才有完整多模态能力。Unsloth 帖中列出的构成与此一致。
这也是 Gemma 系嵌入模型的第二代。初代 EmbeddingGemma 于去年（2025 年）发布，按博客口径累计下载超过 2000 万次，被开发者用来做端侧搜索和隐私优先的检索增强生成。EmbeddingGemma 2 与 Gemma 4 共享文本 tokenizer 和音频编码器，博客称两者能放进同一条流水线，合计内存占用更低，这也是官方把它与 Gemma 4 组合成端侧 RAG 方案的技术前提。
量化后约 191MB：官方给出的 Pixel 11 Pro 内存账单
博客列出的端侧适配细节有三组：
- 经量化，在 Google Pixel 11 Pro 上，纯文本权重的活跃内存约 191MB，完整多模态模型约 567MB，后者略高于 Unsloth 口中的 0.5GB；
- 得益于 Matryoshka Representation Learning（MRL，套娃表示学习），输出向量可以从 768 维截断到 512、256 或 128 维，本地向量库的存储占用最多降至 1/6；
- 上下文窗口 8K token，是初代的 4 倍；单次最多处理 5.5 分钟音频、29 张图片、58 帧视频，或它们的混合输入。
补充了落地参数：8,192 token 的上下文在所有输入之间共享，嵌入维度可选 768、512、256 或 128，Unsloth 建议从 768 维起步；文档还称模型支持 100+ 种语言。文档并特别警告：不要用 FP16 精度运行这个模型，会产生 NaN 或退化的嵌入向量，应改用 BF16 或 FP32。
基准散点图：比较对象最大到 8B 级
本节成绩全部来自谷歌发布材料，属官方自报数字，博客把完整评测指标指向模型卡。按博客数据，EmbeddingGemma 2 在 MTEB（Massive Text Embedding Benchmark）Code 上的得分从初代的 68.76 提到 78.68，涨了 9.92 分，谷歌称这使它适合本地代码库索引、语义代码搜索和编码代理的检索环节。谷歌还称其在 MTEB Code 与 MAEB（Massive Audio Embedding Benchmark）等基准上拿到 1B 以下多模态嵌入模型中的领先成绩，甚至优于部分规模两倍以上的专用（specialist）模型，该说法出自。
博客附了三张散点图，横轴是模型规模，从 125M 拉到 8B，纵轴是平均得分，EmbeddingGemma 2 的标记点都落在左上区域。音频榜上，右侧 8B 级模型的绝对得分仍更高，谷歌主张的是 sub-1B 档位的每参数质量（quality-per-parameter），并非全场第一；图中带星号的模型只支持「图+文」或「音+文」两类输入，不是全模态对比。
配套应用与微调路径已经就位
模型权重之外，谷歌还预告了更多获取渠道：Gemini Enterprise Agent Platform Model Garden 的支持即将上线，Hugging Face 上的 LiteRT Community 也会提供针对端侧优化的版本。应用侧，Google AI Edge Gallery 已内置两个可直接试的功能：Instant Media Search 用文本或图片搜本地媒体库，Video Moments Finder 用文本或音频查询定位视频中的具体时刻；另有 Google AI Edge Foresight 应用演示「本地检索加 Gemma 4 推理」的组合，MediaPipe Decision Task API 面向分类与路由这类实时决策。
部署路径覆盖端侧、浏览器与服务器：端侧走 Google AI Edge MediaPipe 或 LiteRT，浏览器里有 transformers.js 和 WebGPU，服务端点名支持 transformers、sentence-transformers、MLX、vLLM、llama.cpp、SGLang、Ollama 与 LMStudio，向量存储点名 Qdrant。Unsloth 一侧提供了 GGUF 仓库、运行与微调文档和 Colab 笔记本，其 Desktop 应用的 Documents & RAG 功能已可直接选它做本地文档检索；谷歌博客也把微调指引指向了 Unsloth。
掌声之外的待解问题
宣布帖下，回帖祝贺团队，留下一句「开放必胜」（Open for the win）。实操层面的追问出现在同一串回复里：问，中端手机编码 1 万张图片的开销有多大，是一次性成本，还是每次同步都要重跑；想要参考机型数据：峰值内存和持续索引吞吐各是多少，个人媒体库能否在后台更新嵌入而不拖垮续航。
这些问题在发布材料里找不到对应数字：官方博客给出的端侧账单止步于内存占用与上下文上限，没有索引吞吐，也没有耗电与中端机型的实测成绩。