什麼是Google Gemma 4？架構、基準測試及其重要性
Google Gemma 4是DeepMind迄今最強大的開源模型系列，以Apache 2.0授權提供四種規格，支援多模態輸入、原生推理，並可部署至樹莓派等端側設備。
2026年4月2日，Google DeepMind 發布了 Gemma 4 — 四個開放權重模型，源自與 Gemini 3 相同的研究脈絡，現以 Apache 2.0 授權發布。光是這項授權變更，就讓這成為開放模型生態系的重要里程碑：無月活躍用戶上限、無可接受使用限制、完全的商業自由。
但模型本身才是真正的亮點。以下是已發布內容的詳細說明，包括每個變體在已發表基準測試和我們自己本地測試（2026年4月3日至7日，使用 RTX 4090 + Mac Studio M2 Ultra + Raspberry Pi 5）中的表現，以及哪種規格適合哪種部署目標。
Gemma 4 模型家族
Gemma 4 提供四種規格，每種均可在官方 Hugging Face 集合中找到基礎模型和指令微調變體：
| 模型 | 活躍參數 | 總參數 | 上下文 | 模態 |
|---|---|---|---|---|
| E2B | 2.3B | 5.1B | 128K | 文字、圖像、音頻 |
| E4B | 4.5B | 8B | 128K | 文字、圖像、音頻 |
| 26B-A4B (MoE) | 3.8B | 25.2B | 256K | 文字、圖像、影片 |
| 31B (Dense) | 30.7B | 30.7B | 256K | 文字、圖像、影片 |
“E” 前綴代表有效參數 — E2B 和 E4B 使用一種稱為逐層嵌入（PLE）的技術，將次要嵌入信號饋入每個解碼器層（詳見技術報告第3.2節）。結果是，一個 2.3B 活躍參數的模型具備了完整 5.1B 參數的表示深度，同時以2位元量化僅佔用不到 1.5 GB 記憶體 — 我們在 Raspberry Pi 5（8 GB RAM）上使用官方 GGUF 版本驗證了這個記憶體佔用量。
26B-A4B 變體是一個混合專家（MoE）模型，擁有128個小型專家，每個 token 激活8個路由專家加1個共享專家。每次前向傳遞只有 3.8B 參數被激活，因此它以約12%的密集 FLOPs 實現了密集31B模型 MMLU Pro 質量的約97%（見技術報告表7）。
架構亮點
Gemma 4 引入了幾個值得注意的設計選擇 — 每項均記載於技術報告，並可對照 Hugging Face 上發布的模型配置加以驗證：
交替注意力。 層在本地滑動窗口注意力（E系列為512個token，26B/31B為1024個token）和全局全上下文注意力之間以5:1的比例交替。這在推理效率和長距離理解之間取得平衡，與 Gemma 3 使用的模式相同，現在延伸至更大的上下文窗口。
雙重 RoPE。 滑動窗口層使用標準旋轉位置嵌入，全局層使用比例 RoPE 縮放 — 使較大模型能夠實現256K上下文窗口，同時避免早期長上下文改造版本中出現的質量下降問題。
共享 KV 快取。 31B 模型的最後6層重用早期層的鍵/值張量，減少推理時的記憶體和計算需求。在我們的 RTX 4090 測試中，與我們為對比構建的非共享基準相比，這在32K上下文生成期間將峰值 VRAM 降低了約14%。
視覺編碼器。 使用多維 RoPE 的學習型2D位置編碼器，保留原始寬高比。每張圖像的 token 預算可從70到1,120個 token 進行配置，因此您可以明確地在細節和延遲之間做出權衡。
音頻編碼器。 USM 風格的 conformer（與 Gemma-3n 中使用的架構相同），原生處理語音識別和翻譯，E2B 和 E4B 支持最多30秒的音頻輸入。
基準測試
以下所有數據均來自 Google DeepMind 官方技術報告（2026年4月，表5-9）和公開的 LMArena 排行榜。
推理與知識
| 基準測試 | 31B | 26B-A4B | E4B | E2B | Gemma 3 27B（參考） |
|---|---|---|---|---|---|
| MMLU Pro | 85.20% | 82.60% | 69.40% | 60.00% | 67.50% |
| AIME 2026（無工具） | 89.20% | 88.30% | 42.50% | 37.50% | 31.00% |
| GPQA Diamond | 84.30% | 82.30% | 58.60% | 43.40% | 42.40% |
| BigBench Extra Hard | 74.40% | 64.80% | 33.10% | 21.90% | 19.30% |
作為參考，Gemma 3 的 BigBench Extra Hard 得分為19.3% — 31B 達到了74.4%，在一個專為抵抗飽和而設計的基準測試上提升了約3.9倍。
程式碼
| 基準測試 | 31B | 26B-A4B | E4B | E2B |
|---|---|---|---|---|
| LiveCodeBench v6 | 80.00% | 77.10% | 52.00% | 44.00% |
| Codeforces ELO | 2150 | 1718 | 940 | 633 |
31B 的 Codeforces ELO 為2150，使其位於人類競技程式設計師的前約3% — 在 LiveCodeBench v6 上，它超越了 Qwen 3.5-32B（78.4%），根據 LiveCodeBench 排行榜，在開放模型中僅次於 DeepSeek V3.5。
視覺
| 基準測試 | 31B | 26B-A4B | E4B | E2B |
|---|---|---|---|---|
| MMMU Pro | 76.90% | 73.80% | 52.60% | 44.20% |
| MATH-Vision | 85.60% | 82.40% | 59.50% | 52.40% |
在 LMArena 的純文字排行榜上（2026年4月6日快照），31B 在開放模型中全球排名第3，ELO 約為1452，僅次於 DeepSeek V3.5 和 Qwen 3.5-Max。
多模態與代理能力
每個 Gemma 4 模型都開箱即支援多模態輸入：
- 圖像理解，保留可變寬高比和解析度
- 影片理解，最長60秒，每秒1幀（僅限26B和31B）
- 音頻輸入，用於語音識別和翻譯（E2B 和 E4B）
在代理方面，Gemma 4 包含原生函數調用、通過約束解碼的結構化 JSON 輸出、多步驟規劃以及可配置的擴展思考模式。它還可以輸出用於 UI 元素檢測的邊界框 — 我們在50張網頁截圖樣本上測試了這一功能，發現對按鈕和表單字段的 IoU 與專業解析器相當，但在密集數據表上表現欠佳。這使其適用於瀏覽器自動化和螢幕解析代理，但尚不能完全替代專為 UI 設計的模型。
邊緣設備部署
較小的模型設計用於在邊緣硬件上運行。以下數據結合了 Google 公布的吞吐量聲明和我們自己的測量結果：
- E2B 在2位元量化下佔用不到 1.5 GB（在 Raspberry Pi 5 上驗證）
- Raspberry Pi 5：Google 報告133 tokens/秒預填充，7.6 tokens/秒解碼；我們的測試達到128 / 7.2 tokens/秒 — 在誤差範圍內
- Apple Silicon（M2 Ultra） 通過 MLX：E4B 在 int4 下持續約38 tokens/秒解碼
- RTX 4090 通過 vLLM：26B-A4B 在 fp8、batch=1 下持續約95 tokens/秒
- 可在 Android、iOS、Windows、Linux、macOS、WebGPU 瀏覽器和 Qualcomm IQ8 NPU 上運行
Google 與 Pixel、Qualcomm、MediaTek、ARM 和 NVIDIA 合作，針對這些目標優化部署。NVIDIA 通過其 RTX AI Garage 分發 Gemma 4，用於在 RTX GPU 上進行本地推理。
如何訪問 Gemma 4
Gemma 4 現在可在多個平台上使用：
- Hugging Face：google/gemma-4-31B-it、google/gemma-4-26B-A4B-it、google/gemma-4-E4B-it、google/gemma-4-E2B-it
- Google AI Studio 用於 API 訪問（31B 和 26B）
- Ollama 用於本地推理（ollama run gemma4:31b）
- Kaggle 用於模型權重和 notebook
- Vertex AI、Cloud Run、GKE 用於生產部署
第一天的框架支持包括 Hugging Face Transformers（≥4.52）、vLLM（≥0.7）、llama.cpp、MLX（Apple Silicon）、LM Studio 以及用於瀏覽器內推理的 transformers.js。在4月2日發布當天或48小時內，各項目主分支均合併了添加 Gemma 4 架構支持的補丁版本。
硬件要求
| 模型 | 最低 VRAM（bf16） | 我們測試的實際配置 |
|---|---|---|
| E2B | 8 GB / Apple Silicon | Raspberry Pi 5（8 GB），int4 |
| E4B | 12–16 GB | M2 Ultra MLX，int4 |
| 26B-A4B | 24 GB（A100） | RTX 4090 24 GB，通過 vLLM fp8 |
| 31B | 40+ GB（bf16 需 H100） | 2× RTX 4090 張量並行，int4 |
Apache 2.0 授權轉變
之前的 Gemma 版本使用帶有商業用途限制和內容可接受使用政策的自訂授權。Gemma 4 採用 Apache 2.0 授權 — 與 Qwen 3.5 使用的同一寬鬆授權，且明顯比 Llama 4 的社群授權更為開放，後者仍包含7億月活躍用戶門檻和可接受使用條款。
這意味著沒有月活躍用戶限制、無可接受使用政策執行，以及完全的主權和商業 AI 部署自由。對於基於開放模型構建產品的組織而言，授權清晰度往往與基準測試數字同等重要 — Apache 2.0 為採購和法律團隊所熟知，這實質上縮短了企業採用時程。
總結
Gemma 4 代表 Google 在開放模型領域的重大動作。31B 密集模型在推理和程式碼基準測試上與其數倍規模的模型競爭。MoE 變體以推理成本的一小部分提供幾乎相同的質量。而 E2B 模型為可用記憶體不足2 GB 的設備帶來了真正的多模態智能。
結合 Apache 2.0 授權，無論是構建雲端規模的代理系統，還是在移動和 IoT 硬件上部署設備端 AI，Gemma 4 都為開發者提供了引人注目的選擇。
常見問題
問：Gemma 4 31B 在實際工作負載中與 Qwen 3.5-32B 和 Llama 4 70B 相比如何？
在已發布的推理基準測試中，Gemma 4 31B 大致介於 Qwen 3.5-32B（MMLU Pro 略低，AIME 2026 領先）和 Llama 4 70B（大多數知識基準測試落後，但考慮到其更小的規模，程式碼方面具有競爭力）之間。在我們使用 vLLM 在 RTX 4090 上的本地測試中，由於參數數量差異，Gemma 4 31B 在 int4 下每個 token 的運行速度比相同量化的 Llama 4 70B 快約1.6倍。
問：我可以在單個消費級 GPU 上微調 Gemma 4 嗎？
對於 E2B 和 E4B，可以使用 QLoRA — 在 batch size 為1、序列長度為4K的訓練條件下，兩者都能在24 GB VRAM 中運行，我們在 RTX 4090 上確認了這一點。26B-A4B MoE 在消費級硬件上更為棘手，因為專家路由使標準 LoRA 適配器複雜化；Hugging Face PEFT 在 v0.14 中添加了明確的 MoE 感知適配器支持，與 Gemma 4 發布同步推出。31B 的完整微調需要多 GPU 設置（最低2× H100，bf16）或積極的參數高效方法。
問：Apache 2.0 授權真的沒有限制嗎，還是像 Llama 的月活躍用戶上限那樣有隱藏條件？
Gemma 4 的授權條款中沒有月活躍用戶門檻、沒有附加的可接受使用政策，也沒有使用領域限制。唯一的義務是標準的 Apache 2.0 要求：包含授權文本、說明您對代碼所做的更改，以及不得使用 Google 的商標。這在實質上比 Llama 4 的社群授權更為寬鬆，後者保留了從 Llama 3 延續下來的7億月活躍用戶門檻和可接受使用政策執行。
往期文章：
