Google 開源 EmbeddingGemma 2：7.4 億引數把全模態檢索塞進手機

EmbeddingGemma 2 是一個專門用來做跨模態向量檢索的輕量開源模型，採用 Apache 2.0 協議開源，全模態版本引數量只有 7.4 億。它不是用來聊天或生成文本的大語言模型，而是負責把文本、程式碼、影像、音訊和影片等各種格式的內容，壓縮並對映到同一個向量空間裡。

這意味著你可以輸入一段文字去檢索一段錄音，或者用一條語音備忘錄去定位特定的影片片段。整個檢索過程完全可以在消費級硬體上離線執行，不需要把資料傳到雲端。

它能做什麼，怎麼做到的

以往做端側語義搜尋或本地檢索增強生成（RAG），開發者常常要為文本、視覺和音訊分別跑不同的專用模型，不僅佔記憶體，不同模態之間的特徵也無法直接比對。EmbeddingGemma 2 基於 Gemma 4 架構打造，核心優勢就是原生打通全模態。

為了兼顧輕量化，模型採用了模組化設計。如果你的應用只需要做純文本搜尋，可以只加載 2.7 億引數的基礎模組；需要支援影像時，再載入 1.7 億引數的視覺編碼器；需要理解音訊，就加上 3 億引數的音訊編碼器。三項全開的總引數量也只有 7.4 億，模型檔案整體只有 1.5GB 左右。

儲存效率上，它引入了俄羅斯套娃表徵學習（MRL）技術。模型預設輸出 768 維的嵌入向量，但開發者可以根據本地硬體條件，將其動態截斷為 512 維、256 維甚至 128 維。這一特性可以讓移動端的本地向量資料庫和記憶體佔用最高縮減到原來的六分之一。

效能表現與執行門檻

效能方面，它在 10 億引數以下的多模態嵌入模型中表現搶眼。在 MTEB Code 程式碼基準測試中，它的得分從上一代的 68.76 提升到 78.68，漲了近 10 個百分點，非常適合用來做原生代碼庫索引、程式碼語義搜尋或程式設計 Agent 的上下文檢索。在音訊基準 MAEB 和影像嵌入測試中，它的質量甚至超過了一些體積是它兩倍以上的專用模型。

模型的上下文視窗擴充套件到了 8K token，比第一代 EmbeddingGemma 擴大了 4 倍。在本地硬體上，這足以支援單次輸入最長 5.5 分鐘的音訊、29 張圖片或 58 幀影片畫面，也可以將圖文音視按任意比例交錯混合輸入。

硬體門檻也被壓得很低。在量化狀態下，在 Google Pixel 11 Pro 手機上執行純文本模型僅需約 191MB 活動記憶體；哪怕開啟文本、視覺、音訊全模態，記憶體佔用也只要約 567MB，完全能常駐在普通移動裝置後臺。

怎麼跑起來

模型的權重目前已經全部上傳至 Hugging Face 和 Kaggle，採用寬鬆的 Apache 2.0 許可證，商用門檻很低。

工具鏈生態也已經準備就緒。本地與服務端部署方面，它直接支援 transformers、sentence-transformers、llama.cpp、Ollama、LMStudio、MLX、vLLM 以及 SGLang，向量儲存可以直接接入 Qdrant。如果想針對私有資料微調，Unsloth 也已經給出了適配指南。

面向移動端和端側工程，開發者可以通過 Google AI Edge MediaPipe 進行開箱即用的檢索整合，或者用 LiteRT 做深度定製；瀏覽器端開發者也可以通過 transformers.js 和 WebGPU 直接呼叫本地算力。

為什麼重要

對於移動端應用開發者、獨立創作者和注重隱私的本地 Agent 構建者來說，EmbeddingGemma 2 是目前少有的、能直接塞進手機的高質量全模態檢索底座。以往要在端側搞定相簿智慧搜尋、離線會議錄音檢索或者個人程式碼庫助手，記憶體開銷和模型整合往往把人勸退，現在不到 600MB 記憶體就能搞定一套完整的全模態檢索管線。

我們認為 Google 把它做成模組化並且跟 Gemma 4 共享分詞器與音訊編碼器的做法非常務實，這讓生成模型與嵌入模型聯合執行時能進一步壓低總記憶體。不過需要指出的是，8K 的上下文視窗處理短影片和日常錄音足夠，但遇到超長音訊或大體量影片時，依然需要開發者在前端先做好切片策略。