Gemma 是 Google DeepMind 發布的開放模型家族。在官方產品頁上，這條產品線的標題是「Gemma / 我們能力最強的開放模型」，並被放在名為 Open models（開放模型）的導覽欄目下，與 Gemini、Veo、Imagen 這些只能透過 API 呼叫的閉源產品線刻意分開。這個位置本身就是關於這個條目最重要的事實：你拿到的不是一個帳號和用量計費表，而是可以自己下載、自己託管、自己執行的模型權重。
有必要把名字說清楚，因為絕大多數混淆都從這裡開始。Google DeepMind 是一個研究機構；Gemini 是它的旗艦閉源模型家族，透過 Google 自家產品和 API 提供服務；而 Gemma 是那個開放的兄弟產品——按官網 Gemma 4 頁面的說法，它是「源自 Gemini 3 研究與技術、以最大化每單位參數智慧水準為目標的最智慧開放模型」。這三個名字經常被導覽站和新聞聚合器混為一談，但它們指的是完全不同的東西：一個組織、一個託管模型、一個可下載模型。本頁說的是第三種。
Gemma 的設計意圖直接來自這種開放性。Google 明確的目標是可移植性而非跑分榜第一：「我們最先進的開放模型幫助開發者建立可以在使用者需要的任何地方執行的 AI 應用——從雲端伺服器到筆記型電腦，甚至手機。」這個家族的其他一切特徵——異常寬的參數檔位跨度、混合專家變體、小模型裡的逐層嵌入技巧——都是這句話的下游產物。Gemma 被設計成同一個模型家族既能部署在 Jetson Nano 上，也能部署在一整機架的加速卡上，中間不需要更換供應商或重寫應用。
開放性還有第二個實際後果。因為權重是分發的而不是託管服務的，這裡沒有註冊流程、沒有席次數、也沒有 Google 按 token 開給你的帳單。取而代之的是一份授權條款、一張硬體帳單，以及一份完全由你承擔的維運負擔。評估 Gemma 的工作，大半就是搞清楚這三樣各自落在哪裡。
Google 同時把 Gemma 定位為負責任部署的工具，而不只是一個原始研究產物。Open models 欄目下的一句話定位是「負責任地大規模建構 AI 應用」，家族中也確實附帶了專門的安全分類器變體。但這個定位能否成立，很大程度取決於你在模型外圍搭建了什麼——官方文件對這一點說得非常直白，本文的「限制」一節會再回到這裡。
採用 Gemma 最難的部分不是安裝，而是在階梯上挑對那一級。各檔位之間並不可互換，而決定性因素通常是你手上已有的硬體，而不是某張跑分表。
邊緣檔（E2B、E4B）。 Google 明確把這一檔定位給受限裝置：「支援即時邊緣處理的音訊與視覺能力。它們可以在手機、Raspberry Pi 和 Jetson Nano 這類邊緣裝置上完全離線執行，延遲接近於零。」離線執行是其核心屬性。如果你的硬性要求是推論必須在無網路環境下運作——車內、診所、車間、鄉村教室——這一檔就是你需要考慮 Gemma 的根本原因。代價是更短的上下文視窗，以及在困難推理與長文件檢索上明顯更弱的表現。
工作站檔（12B、26B A4B、31B）。 這一檔瞄準的是消費級顯示卡而非資料中心加速卡。Google 的定位是它們提供「面向 IDE、編碼助手與智慧體工作流的進階推理能力。這些模型針對消費級 GPU 最佳化——讓學生、研究者和開發者能把工作站變成本地優先的 AI 伺服器。」26B A4B 是其中值得注意的中間選項：總參數 25.2B，但推論時啟用約 3.8B，因此速度上更接近小模型，同時保留更多容量。31B 稠密模型以 30.7B 參數配 256K 視窗，是這個家族的上限。
上一代仍然重要。 Gemma 3 並沒有消失。它仍以 270M、1B、4B、12B 與 27B 五個檔位提供，具備 128K token 視窗，而 Google 自己的描述——「Gemma 3 的 128K token 上下文視窗讓你的應用能夠處理和理解海量資訊，實現更複雜的 AI 功能」——描述的依然是一個可用的模型。尤其是 270M 這一檔，Gemma 4 中並沒有對應型號，因此在極度受限的部署場景下，上一代有時是唯一選項。關鍵在於兩代之間的授權條款並不相同，這是下一節的內容。
一條實用的選型經驗法則：從你的部署目標出發，而不是從跑分榜出發。如果必須在手持裝置上離線執行，你就在邊緣檔，並且應該盡早用你真實的任務驗證品質。如果你有一張現代消費級 GPU，想要本地的編碼或智慧體助手，從 12B 起步，只有當品質確實不夠時再往上走。如果需要語音輸入，就把範圍限制在 E2B、E4B 或 12B。如果你追求最高品質且硬體足夠，31B 稠密模型是這個家族的天花板。
這一節值得讀兩遍，因為關於 Gemma 流傳最廣的那句話——「Gemma 是 Apache 2.0 授權的」——只對當前這一代成立。
Gemma 4 確實轉向了真正標準的開源授權條款。Google 開源官方部落格說得很直白：「Gemma 4 模型是 Gemmaverse 中首批以 OSI 認證的 Apache 2.0 授權條款發布的模型。」官方模型卡以機器可讀的形式確認了這一點，front matter 欄位直接寫著 license: apache-2.0。因此對 Gemma 4 而言，你面對的是一份 OSI 認證的寬鬆授權條款，具備開發者所預期的再分發與商用屬性。
早期版本則是另一回事。Hugging Face 上 Google 官方組織的儲存庫中繼資料清楚地顯示了這一分界：Gemma 4 系列儲存庫帶 apache-2.0 標籤，而 gemma-2、gemma-3n、gemma-7b 等儲存庫仍然標註 Google 自訂的 gemma 授權條款。第三方的版本譜系梳理記錄了同一次轉變，指出 Google 是在發布 Gemma 4 時採用「自由開源的 Apache 2.0 授權條款」，而更早的幾代是以 source-available 的 Gemma 使用條款分發的。
實際後果非常具體。如果你的合規流程把「Gemma」作為一個 Apache 2.0 相依項核准通過，而你的工程師隨後拉取了 Gemma 3 或 Gemma 2 的檢查點——這完全合理，因為那些型號仍在維護、有時甚至更合適——那麼真正約束你部署的授權條款，並不是你流程核准的那一份。每一次都去查你實際下載的那個具體儲存庫的授權欄位，不要依賴家族層面的籠統說法，包括本文這一句。
在採用規模方面，Google 報告稱「自首次發布以來，社群已下載 Gemma 模型超過 4 億次，並建構了超過 10 萬個衍生模型，社群稱之為 Gemmaverse」。這些是廠商自報數字，未經獨立稽核；它們可以作為「生態沒有荒廢」的訊號，但不應被解讀為品質指標。
分發管道是刻意鋪開在開發者已經在用的工具鏈上的，而不是收攏到某個 Google 自有平台。官方頁面列出的平台與整合涵蓋 Kaggle、Hugging Face、Keras、Ollama、PyTorch、Gemma.cpp、JAX、Google AI Edge、Google Cloud、Android、LM Studio 與 Unsloth。
具體到權重，Gemma 4 頁面把下載管道與訓練部署管道分開列出，權重下載指向 Hugging Face、Ollama、Kaggle、LM Studio 與 Docker。實際上這意味著最快的路徑完全取決於你已有的技術堆疊，而不取決於任何 Gemma 專有工具：
支援體系是社群與文件形態的，而不是合約形態的。官方頁面指向「用於建構 Gemma 應用的官方文件、快速上手與指南」，並把提問引導至開發者論壇。下載一個開放模型不會附帶 SLA、工單佇列或客戶經理——這個取捨在原理上顯而易見，但在生產環境中偶爾仍會讓人意外。
Google 公布了 Gemma 4 與上一代的對照基準表，在重推理任務上的世代躍升幅度很大。在不使用工具的 AIME 2026 數學測試上，31B 模型報告為 89.2%，而 Gemma 3 27B 為 20.8%。Gemma 4 頁面公布的其他數字還涵蓋競技場評分、競賽程式設計與研究生水準問答。
對該表中的每一個數字都適用兩條警告。第一，這些是廠商自報結果，由對結果有利益關係的一方產出；它們是合理的初始假設，而不是獨立結論。第二，總覽均值會掩蓋在部署中最要命的、隨型號變化的效能懸崖。長上下文檢索是最清楚的例子：在 MRCR v2 八針 128K 檢索指標上，模型卡給出最大型號 66.4%，而每個更小的檔位都依次顯著下滑。一個宣稱支援長視窗的模型，未必能可靠地使用那個視窗，而這個指標上從階梯頂端到底端的差距，遠大於通用知識基準上的差距。
獨立分析提出了一個相關的結構性質疑：對 Gemma 4 技術報告的分析指出，它「把效能提升歸功於資料構成，然後用兩句話描述了自己的訓練資料」。由於語料構成沒有詳細揭露，外部方無法獨立評估基準汙染或核實領域涵蓋範圍。這並不讓已公布的數字失效，但它意味著唯一能為你的使用情境完全定論的基準，是你自己在自有保留資料上跑出來的那一個。
Gemma 適合那些看重部署控制權勝過看重便利性的開發者、研究者與技術團隊。如果你能自如地準備硬體、選定服務堆疊並承擔維運面，這個家族給了你來自同一家供應商、工具鏈一致、檔位跨度異常寬的一條模型階梯。
它適合那些有託管 API 無法滿足的硬性約束的組織——離線執行、資料駐留、程式碼保密，或者在規模化後使按 token 計價難以為繼的單位經濟性。在這些情況下，維運負擔不是缺點，而是你為一個別無他法的需求所付的代價。
它適合打算改造模型的人。微調、量化、蒸餾，或者把模型嵌入裝置映像檔，都需要權重。如果你的計畫涉及上述任何一個動詞，開放模型就不是若干選項之一，而是唯一符合條件的類別。
它不適合只想打開瀏覽器分頁就拿到結果的非技術使用者。這裡沒有面向消費者的產品。除了 AI Studio 試用之外，使用 Gemma 意味著工程工作。任何需求是「和 AI 助手聊天」的人，都更適合託管產品，很可能就是 Gemini，而本條目對他們只是一次不必要的繞路。
它同樣不太適合需要合約級支援保障的團隊。文件和開發者論壇就是全部支援模式。如果你的採購流程要求供應商提供 SLA 和升級路徑，下載一個開放模型並不提供這些，無論其背後的廠商有多大。
Google 自己的文件對模型邊界說得異常直接，而這些自述限制比大多數第三方批評更有用，因為它們是可歸屬的。
它不是知識庫。 模型卡聲明模型「基於從訓練資料集中學到的資訊生成回答，但它們不是知識庫。它們可能生成不正確或過時的事實性陳述。」把事實性輸出當作需要核實的對象，而不是檢索結果。
訓練資料有截止日期。 記錄在案的預訓練截止日期是 2025 年 1 月，涵蓋網頁文件、程式碼、數學、圖像與音訊。該日期之後的一切都在模型知識之外，因此時效敏感的應用無論選哪個檔位都需要外接檢索。
開放式任務比明確定義的任務更難。 按模型卡的說法，模型「在能夠用清晰提示與指令框定的任務上表現良好。開放式或高度複雜的任務可能構成挑戰。」提示詞結構在這裡確實起作用。
能力在階梯上並不均勻。 這一點值得強調，因為它是實踐中最常見的失望來源。音訊輸入只存在於 E2B、E4B 與 12B。長上下文檢索在較小模型上急劇衰減。在 31B 上驗證過的能力，絕不應假定能遷移到 E2B。
專業建議不在適用範圍內。 Google 自己的頁尾提示很明確：「不要依賴大型語言模型取得醫療、法律、財務或其他專業建議。任何涉及這些主題的內容僅供參考，不能取代合格專業人士的建議。」MedGemma 的存在並不改變這一點；一個領域微調模型仍然不是臨床醫師。
訓練資料透明度有限。 如上所述，獨立分析批評訓練資料描述過於簡略。你無法完整稽核進入模型的是什麼。
你繼承了維運負擔。 沒有託管端點意味著可用性、擴縮容、安全修補、GPU 容量規劃與成本都歸你。對小團隊而言，這一點在做決定的當下經常被低估。
開放模型的隱私格局與託管服務在結構上不同，而這種不同是雙向的。
好的一面是，自託管意味著推論資料完全不必離開你的基礎設施。不需要就廠商側的提示詞日誌留存去談判，因為根本不存在廠商側的推論。對於保密工作負載，這是整個類別最有力的論據。
在訓練側，Google 報告了對預訓練語料的過濾工作：「為使 Gemma 預訓練模型安全可靠，我們使用自動化技術從訓練集中過濾掉特定個人資訊和其他敏感資料」，並在多個階段實施了 CSAM 過濾。這是廠商關於流程的陳述，不是獨立稽核，應當據此解讀。
對任何部署 Gemma 的人來說，最關鍵的一點是 Google 明確把下游安全責任分配給了你。模型卡把隱私侵犯列為已識別風險，並聲明「鼓勵開發者採用隱私保護技術遵守隱私法規」。在內容安全上同樣直接：「鼓勵開發者保持謹慎，並根據其特定產品政策與應用使用情境實施適當的內容安全防護措施。」
這種責任分配不是形式主義。在託管 API 中，無論你想不想要，供應商的審核層都橫在你的使用者和原始模型之間。當你下載權重時，那一層不會跟著一起下載。護欄、濫用監控、日誌策略、年齡限制與法規遵循都變成了你要自己搭建的東西。ShieldGemma 2 的存在能幫上其中一部分，但把它接進去是你的工作。
在基礎設施層面，Google 聲明「Gemma 4 模型與我們的閉源模型經過同樣嚴格的基礎設施安全流程」，把這個家族定位為面向企業與主權機構的可信基座。該聲明涉及的是模型如何被生產與發布，而不是你隨後如何營運它們。
Gemma 誠實的比較集合是其他開放權重家族，而不是託管助手，因為「是否自託管」這個決定在前，「託管哪個模型」在後。
與 Gemini 比較，這其實是一個關於部署模式而非品質的問題。Gemini 由 Google 託管、管理並持續更新；Gemma 由你下載、自行營運並鎖定版本。如果沒有強制自託管的約束，託管路徑省事得多。如果確實存在這樣的約束，那麼 Gemini 無論出多少錢都無法滿足它。
與其他開放權重家族比較——通常拿來比較的是 Llama、Qwen 與 Mistral 系列——Gemma 的差異化在於其檔位跨度異常寬（尤其在小尺寸一端）、當前代採用 Apache 2.0 授權條款，以及官方領域變體的豐富程度。不過競爭者迭代很快，任何關於「誰在品質上領先」的斷言保存期限都很短。在做決定的那一刻用你自己的任務做評測，而不要相信籠統排名，包括本段的描述。
與完全不在本地跑任何東西比較，帳很好算：託管 API 在首個結果的取得速度上勝出，在資料控制、離線能力與規模化後的邊際成本上落敗。當這三個因素中至少有一個是硬性要求而非偏好時，Gemma 的維運成本才是值得付的。
在家族內部，最被低估的替代方案是上一代。Gemma 3 提供了 Gemma 4 所沒有的 270M 檔位，在極度受限的部署場景下這可能是決定性的——前提是你把上文討論過的授權差異也一併算進去。
權重可以免費下載，執行時 Google 也不按 token 收費，因為算力由你提供。Gemma 4 以 OSI 認證的 Apache 2.0 授權條款發布。真正的成本是硬體、電費或雲端執行個體時數，以及自己營運模型的工程投入。這裡的「免費」指的是「沒有授權費」，而不是「沒有成本」。
對 Gemma 4 而言，Apache 2.0 授權條款在其標準條件下允許商業使用、修改與再分發。對更早的版本則需要單獨核實：Gemma 2、Gemma 3n 及其他舊儲存庫仍標註 Google 自訂的 gemma 授權條款而非 Apache 2.0，那些自訂條款包含 Apache 2.0 所沒有的使用限制。請務必查看你實際下載的那個儲存庫的授權欄位。
Gemini 是 Google 的閉源模型家族，以託管服務的形式存取。Gemma 是開放家族，權重由你下載並自行執行，建構自相關研究——Gemma 4 頁面稱其源自 Gemini 3 的研究與技術。同源，但分發模式相反。而 Google DeepMind 是發布兩者的那個研究機構。
完全取決於你選擇的檔位。E2B 與 E4B 是為手機和小型開發板設計的，包括 Raspberry Pi 與 Jetson Nano，並且可以完全離線執行。12B、26B A4B 與 31B 面向消費級 GPU。26B A4B 是混合專家設計，推論時在 25.2B 總參數中啟用約 3.8B，因此執行速度快於其總規模所暗示的水準——通常是這個家族中每單位顯示記憶體容量性價比最好的選擇。
工作站檔最高 256K token，邊緣檔配備更小的 128K 視窗。需要注意的是，支援一個視窗和可靠地使用它是兩回事：在模型卡的長上下文檢索指標上，最大型號達到 66.4%，而較小檔位急劇下滑。在圍繞長上下文做設計之前，先在你實際的上下文長度上測試檢索表現。
圖像與影片理解在整條 Gemma 4 產品線上都可用，也支援交錯多模態輸入。音訊是例外：官方模型卡把自動語音辨識與語音轉翻譯文字限定在 E2B、E4B 與 12B。如果語音輸入是硬性需求，兩個最大的型號就不在選項之內。
Google 聲明支援 140 種語言，並把目標框定為理解文化語境而非執行字面翻譯。與任何寬泛的多語聲明一樣，品質在這個範圍內差異相當大，因此請在你具體的目標語言上驗證表現，而不要假定各語種表現一致。
如果你自託管，推論資料完全不必離開你的基礎設施，這是開放權重方案最強的隱私屬性。但 Google 明確把下游責任分配給你，鼓勵開發者採用隱私保護技術遵守隱私法規。資料保護法規遵循、日誌策略與內容防護措施，都需要由你自己設計並實施。
可以——微調是 Google 為該家族列出的五項能力之一，官方分發頁面也給出了包括 Unsloth、Keras、JAX 與 GKE 在內的訓練工具鏈入口。微調得到的模型仍在你的控制之下，這正是團隊選擇開放權重而非託管 API 的主要理由之一。
Gemma 4 在推理類基準上更強，且採用更寬鬆的 Apache 2.0 授權條款，因此是預設選擇。Gemma 3 在兩種情況下仍然相關：當你需要 270M 這個 Gemma 4 沒有對應型號的檔位時，以及當現有工具鏈已經鎖定在它上面時。如果你確實選擇 Gemma 3，請記住它的授權條款與 Gemma 4 不同，必須單獨審閱。
