【技術解析】Google Gemma 4：四尺寸全員出動，31B 密集模型稱霸開源 Arena

這篇文章在說什麼

2026 年 4 月，Google DeepMind 正式發布 Gemma 4——這是 Gemma 系列有史以來最大規模的一次架構升級，也是 Google 首次在 Gemma 家族中引入 Mixture-of-Experts（MoE）架構。Gemma 4 帶來四種尺寸（E2B、E4B、26B MoE、31B 密集模型），全部支持多模態輸入（圖像、音頻、影片），上下文窗口最高達 256K tokens，並首次在 Android 設備上實現了原生部署。

這篇文章的核心命題是：Gemma 4 的四種規格到底在技術上做了哪些取捨？PLE（Per-Layer Embeddings）和 Shared KV Cache 這些新架構名詞，對開發者實際使用時意味著什麼？以及在 26B MoE 模型中，僅激活 3.8B 參數的情況下是如何打敗眾多 70B+ 密集模型的？

為什麼重要

開源模型的又一里程碑

Gemma 系列從發布至今，累計下載量已超過 4 億次，衍生出超過 10 萬個社群微調變種——Google 將這個生態稱為「Gemmaverse」。Gemma 4 的發布，是 Google 面對 DeepSeek R2、Qwen 3.6 Plus、Meta Llama 系列等激烈競爭下的正面回應：用更強的基準測試、更寬的部署硬體覆蓋、以及完全 Apache 2.0 的商業友好許可，來鞏固開源領先地位。

為什麼 MoE 的首次登場意義重大

過去 Gemma 系列一直以密集模型（Dense Model）為主，MoE 的引入標誌著 Google 終於在 Gemma 家族中承認了「稀疏激活」的效率優勢：模型總參數量可以很大，但在推理時只激活其中一小部分參數。26B MoE 模型在推理時只激活 3.8B 參數，卻能在 Arena AI 開源模型排行榜上排名第 6，僅次於多個 70B+ 規模的密集模型——這意味著企業可以用遠低於過去的 GPU 成本，獲得接近旗艦閉源模型的能力。

對邊緣部署的影響

Gemma 4 的 E2B（2B 有效參數）和 E4B（4B 有效參數）兩個小型模型，支持在手機、Raspberry Pi 和 Jetson Nano 等設備上完全本地運行，且支持音頻輸入。這讓「把 AI 直接做到產品裡」這件事，第一次在不需要網路連接、不需要昂貴雲端 GPU 的前提下，變得真正可行。

技術細節

1. 四種型號：硬體分層的精準設計

Gemma 4 家族包含四種型號，它們並不是單純的「參數縮小版」，而是針對不同硬體等級的差異化設計：

型號	總參數	激活參數	架構	上下文窗口	支持模態	目標硬體
Gemma 4 E2B	~5.1B（含 embeddings）	~2B	Dense + PLE	128K	文本、圖像、音頻、影片	手機
Gemma 4 E4B	~8B（含 embeddings）	~4B	Dense + PLE	128K	文本、圖像、音頻、影片	Raspberry Pi、Jetson Nano
Gemma 4 26B MoE	26B	3.8B	MoE	256K	文本、圖像、影片	消費級 RTX GPU
Gemma 4 31B Dense	31B	31B	Dense Transformer	256K	文本、圖像、影片	單卡 80GB H100

「有效參數」（Effective Parameter）這個標示法並非行銷用語，而是 Google 從 Gemma 3n 沿用過來的設計思路：小型模型在推理時只激活固定數量的參數，但通過 PLE 等輔助機制，彌補因參數量受限而導致的能力損失。

2. 架構核心：PLE 與 Shared KV Cache

Per-Layer Embeddings（PLE）

PLE 是 Gemma 4 小型模型最重要的架構創新。它的核心思想是：每一層都擁有一個屬於自己的小型條件向量，而不是像傳統 Transformer 那樣，所有層都共享同一個輸入嵌入。

在標準 Transformer 中，每個 Token 在輸入層獲得一個嵌入向量後，這個表示會沿著所有解碼層的殘差流（Residual Stream）一路傳遞到底——這意味著最初的嵌入必須「承載」模型在所有深層所需的全部信息，形成了一個極高的信息密度要求。

PLE 引入了一個並行的低維度條件通路。對於每個 Token，PLE 計算一個小型專屬向量，這個向量由兩個信號組合而成：

Token 身份分量（來自嵌入表查詢）
上下文感知分量（來自主嵌入的學習投影）

每個解碼器層在注意力模塊和前饋網路之後，使用對應的 PLE 向量來調制隱藏狀態。這使得每層擁有一個專屬通道，只在 Token 信息變得相關時接收特定信息，而不是被迫將所有東西打包到一個前置嵌入中。

Shared KV Cache

Shared KV Cache 是另一個推理效率優化。其核心思想是：模型的最後 N 層不計算自己的 Key-Value 投影，而是直接重用較早層的 K/V 張量。

在長上下文生成和邊緣設備推理中，KV Cache 的內存佔用是瓶頸之一。Shared KV Cache 通過消除冗餘的 KV 投影，顯著減少了內存佔用和計算量，同時對輸出質量的影響極小。

3. Attention 機制：Alternating Sliding-Window + Global

Gemma 4 在所有模型中採用了交替的局部滑動窗口注意力（Sliding-Window Attention）與全局注意力（Global Attention）：

滑動窗口注意力：每個 Token 只關注局部範圍內的上下文（小型模型 512 tokens，大型模型 1024 tokens），將每 Token 計算量控制在 O(序列長度) 線性範圍內
全局注意力層：穿插在滑動窗口層之間，處理長程依賴，確保 256K 上下文窗口的全局理解能力

這個設計的關鍵在於：既保證了長上下文下的全局視野，又避免了全注意力（Full Attention）在 256K tokens 時的天價計算成本。

此外，Google 還引入了雙 RoPE 配置：

滑動窗口層使用標準 RoPE
全局層使用比例 RoPE（Proportional RoPE）

這使得模型能夠在更長的上下文範圍內維持穩定的位置編碼質量。

4. 多模態能力：原生一體的設計

Gemma 4 的多模態能力不是「事後附加」的，而是從預訓練階段就作為第一等公民」內建在模型中的。

視覺編碼器（所有型號）

採用 SigLIP風格的視覺編碼器，支持：

可變長寬比編碼：不再將圖像強制裁剪為正方形，保留了原始文檔、截圖、海報等的真實長寬比
可配置 Token 預算：圖像可編碼為 70、140、280、560 或 1120 個 Token，讓開發者在速度、內存和質量之間找到平衡
原生 Bounding Box 輸出：模型可以直接輸出 JSON 格式的邊界框坐標，無需任何特定的語法約束提示
OCR 與文檔理解：OmniDocBench 等基準測試中達到領先分數

音頻編碼（僅 E2B 和 E4B）

使用與 Gemma 3n 相同架構的 USM 風格 Conformer 編碼器，支持：

設備端語音識別
多語言語音轉文字
音頻理解（無需雲端來回）

影片理解（所有型號）

Gemma 4 的較小型模型（E2B、E4B）支持帶音頻的影片輸入，大型模型（26B MoE、31B）支持不帶音頻的影片幀序列輸入。儘管這些模型沒有在影片數據上進行明確的後訓練，但它們在影片理解任務上表現出了令人驚訝的能力。

5. Agent 工具調用：原生函數調用

Gemma 4 並非只是一個「回答問題」的模型，而是一個為行動」而訓練的模型：

原生函數調用：結構化工具調用輸出直接內建在基礎模型中，不需要提示工程來繞過限制
結構化 JSON 輸出：請求 JSON 就得到可解析的乾淨 JSON，可靠的結構化輸出是 Agent 管線中跨工具傳遞狀態的基礎
原生系統指令支持：一級 support 系統提示，讓模型在生產環境中可以穩定地被角色扮演和任務約束，不需要依賴「軟指令」的模糊遵循

6. 基準測試：31B 密集模型稱霸開源 Arena

根據 Google 在 2026 年 4 月 1 日 Arena AI 排行榜上的官方數據：

模型	Arena AI 開源排名	LMArena 分數（文本）
Gemma 4 31B Dense	#3	1452
Gemma 4 26B MoE	#6	1441（僅 3.8B 激活參數）

這個數據的關鍵洞察在於：Gemma 4 26B MoE 以僅 3.8B 的激活參數，實現了與 31B 密集模型几乎持平的 Arena 分數（差距僅 11 分），同時在硬體成本上大幅降低。

在 SWE-bench Verified 等代碼基準測試中，Gemma 4 系列也展現了與頂尖閉源模型（Claude Opus 4.6 等）接近的表現，特別是在 Terminal-Bench 2.0 等終端 Agent 編碼任務上。