EmbeddingGemma 2 發布：7.4 億參數的開放輕量多模態嵌入模型，端側統一文字、程式碼、圖像、音訊與影片

2026年10月6日，Google DeepMind 發布 EmbeddingGemma 2，一款開放、輕量、原生多模態的嵌入模型。它把文字、程式碼、圖像、音訊和影片對應到同一個共享嵌入空間。模型基於 Gemma 4 架構，採用對商業友善的 Apache 2.0 授權，總參數量為 7.4 億，定位是直接在端側裝置上執行。 一、發布了什麼

去年發布的初代 EmbeddingGemma 只處理文字，目標是讓應用程式在消費級硬體上完成高品質的文字嵌入。官方稱其下載量已超過 2000 萬次，開發者主要用它建構端側智慧搜尋和重視隱私的檢索增強生成（RAG）流程。EmbeddingGemma 2 在此基礎上把輸入範圍擴展到程式碼、圖像、影片與音訊，並且由單一模型原生處理，而不是拼接多個專用模型。官方舉的例子是：用一段語音備忘錄去找某個影片片段，或者用一句文字查詢去搜尋數小時的錄音。該模型與 Gemini Embedding 系列出自同一技術路線。

二、模組化架構

EmbeddingGemma 2 採用模組化設計。純文字場景最少只需 2.7 億參數；需要視覺能力時，可載入 1.7 億參數的視覺編碼器；需要音訊能力時，可載入 3 億參數的音訊編碼器。三者相加即為 7.4 億參數的完整多模態模型。這種設計讓開發者按需載入：只做文字檢索的應用不必為用不到的視覺和音訊權重付出記憶體。 三、套娃表示學習與儲存成本

模型使用套娃表示學習（Matryoshka Representation Learning，MRL）。輸出向量預設為 768 維，開發者可以在執行時把它截斷為 512、256 或 128 維。官方稱，這最多可帶來 6 倍的儲存縮減，既降低本地向量資料庫的體積，也降低記憶體占用。對於要在手機或筆電上保存大量向量的應用，這是直接的成本槓桿。需要注意的是，截斷維度意味著精度與體積之間的取捨，具體損失應由開發者在自己的資料上評估。 四、端側資源占用與上下文長度

在 Google Pixel 11 Pro 上，經過量化後，純文字權重的活躍記憶體最低約 191MB，完整多模態模型約 567MB。上下文視窗為 8K token，是初代 EmbeddingGemma 的 4 倍。官方給出的單次輸入上限相當於 5.5 分鐘音訊、29 張圖像或 58 幀影片，也可以是它們的交錯組合，全部在本地硬體上處理。 五、基準表現

官方稱，EmbeddingGemma 2 在同等規模的 1B 以下多模態嵌入模型中取得領先，涉及的基準包括 MTEB Code（大規模文字嵌入基準的程式碼部分）和 MAEB（大規模音訊嵌入基準），並在文字、視覺、音訊任務上持平或超過許多更大的模型。多語言文字能力與初代持平。程式碼檢索進步最明顯：MTEB Code 得分從 68.76 升至 78.68，提升 9.92 分。官方還稱，它在圖像、影片、文件和音訊任務上，甚至優於一些體量超過自身兩倍的專用模型。完整指標見官方模型卡。以上均為廠商自報數據，獨立復現尚待社群驗證。

六、對開發者與企業的意義

第一，隱私。本地產生嵌入，資料不必離開裝置，適合醫療、法務、個人筆記等敏感場景。第二，延遲與成本。本地推論不依賴網路往返，也沒有按呼叫計費的嵌入介面開銷。第三，工作流程簡化。過去做跨模態檢索，往往要為文字、圖像、音訊分別部署模型並對齊向量空間；現在一個模型即可。第四，程式碼場景。MTEB Code 的提升，使本地程式碼庫索引、語意程式碼搜尋和程式設計智慧體的檢索環節更有實用價值。第五，授權。Apache 2.0 允許商業使用，企業整合的法律門檻較低。 七、展望與挑戰

端側多模態嵌入會讓「個人資料的本地語意索引」成為常見能力：相簿、錄音、影片和程式碼在裝置上統一可搜。但挑戰同樣明確。首先，8K 上下文對長影片和長錄音仍然有限，需要分段與聚合策略。其次，不同量化方案對檢索品質的影響，需要在真實資料上測量。再次，向量資料庫、檢索框架和行動端執行環境需要跟進對多模態嵌入的支援。最後，基準分數不等於業務成效，團隊應在自己的語料上做評估。總體上，EmbeddingGemma 2 把「小模型、多模態、可商用」三件事放在了一起，值得 AI 工具開發者重點關注。

九、落地建議

第一步，先確定要涵蓋的模態。若只需文字與程式碼檢索，只載入 2.7 億參數的文字部分即可，記憶體占用最低。第二步，用真實語料建立評估集，比較 768、512、256、128 維下的召回率與延遲，選出夠用的最小維度。第三步，在目標裝置上實測量化後的記憶體與耗時，不要只看官方給出的 Pixel 11 Pro 數據。第四步，為長音訊和長影片設計分段策略，因為 8K 上下文一次只能容納約 5.5 分鐘音訊。完成這四步後，再決定是否把雲端嵌入介面替換為本地模型。 八、與初代相比的變化小結

把兩代模型放在一起看，變化集中在四點。輸入範圍：從只有文字，擴展到文字、程式碼、圖像、音訊和影片。上下文長度：從初代的 2K 提升到 8K，是後者的 4 倍。程式碼檢索：MTEB Code 得分由 68.76 升至 78.68。部署形態：由單一文字模型，變為可按需組合視覺與音訊編碼器的模組化模型。對已經在使用初代模型的團隊而言，升級的主要工作是重新為資料建立向量索引，因為新舊模型的嵌入空間不能混用。對於新專案，可以直接從統一的多模態索引起步，少維護幾套檢索堆疊，也少寫幾層對齊向量空間的膠水程式碼。落地時建議先在小規模真實資料上，比較不同截斷維度與量化方案下的召回率，再決定上線配置。