2026 年 4 月 2 日，Google DeepMind 發布了 Gemma 4，並宣布採用 Apache 2.0 授權。這在任何意義上都不是一個例行更新——它是 Google 在開源 LLM 領域投下的最重量級炸彈。在此之前，Gemma 系列雖然開放權重，但授權條款中仍帶有使用限制；此次完全切換為 Apache 2.0，代表 Google 在開源策略上的根本轉變。

Gemma 4 的特殊之處不僅在於模型參數的進步，更在於授權模式、部署範圍與生態系布局的全面升級。從 2B 活躍參數的手機端模型到 31B 的桌面級稠密模型，從 Apache 2.0 的完全商用許可到 AICore 的系統級整合——Google 正試圖複製 Android 在行動裝置市場的成功模式，將 Gemma 打造成開源 AI 領域的「Android」。

本文將從模型架構設計、量化部署效能、行動裝置推論管道、以及開源策略的長期影響四個維度，為 ML 工程師與行動開發者提供完整的技術解析。

為什麼 Google 要在此時將 Gemma 4 完全開源？

這是一個戰略抉擇，而非技術決定。回顧 2024-2025 年的開源 LLM 生態，Meta 的 Llama 3 系列和 Mistral AI 的模型已經吸引了大量開發者社群。根據 GitHub 2025 年底的統計，Llama 3 相關的衍生專案與微調版本數量是 Google Gemma 2 的 3.7 倍。這意味著開發者社群與創新動能正在遠離 Google 的平台。

Google 的選擇非常明確：與其對抗開源趨勢，不如引領它。Gemma 4 的 Apache 2.0 授權加上完整的行動端部署工具鏈，是 Google 試圖在開源 LLM 領域建立全新標準的嘗試。這一步棋如果成功，Google 不僅能重新吸引流失的開發者，還能將其雲端服務與 TPU 硬體生態系與 Gemma 深度綁定。

Gemma 4 模型家族：架構設計與規格解析

四種規格與核心定位

Gemma 4 提供了四種變體，覆蓋從手機端到資料中心的全譜系：

最值得關注的是 26B MoE 版本。它採用 Mixture of Experts 架構，總參數 26B 但每次推論僅啟用 3.8B 的活躍參數——這意味著它的推論速度接近 4B 模型，但表達能力接近 26B 模型。這是專為邊緣裝置設計的權衡方案，也是目前開源 MoE 模型中最具競爭力的選擇之一。

相對前代的性能提升

Gemma 4 的基準測試成績展示了與前代相比的顯著進步。特別值得注意的是小型型號的突破——E2B（2B） 在 GPQA Diamond 上達到 43.4%，與前代旗艦 Gemma 3 27B（42.4%）平分秋色。

這說明 Google 在小型模型的知識蒸餾（Knowledge Distillation）與模型壓縮技術上取得了重大突破。一個 2B 模型擁有接近 27B 模型的推理能力，對行動部署而言是一個巨大的飛躍。

行動裝置部署詳解：AICore、LiteRT-LM 與 MLX

Gemma 4 在行動部署的完整度是其他開源模型無法比擬的。Google 提供了三層部署路徑，涵蓋 Android、iOS 與跨平台場景：

路徑一：Android AICore（系統級部署，推薦）

AICore 是 Android 系統內建的 AI 推論引擎，Google 已將 Gemma 4 模型整合進 Android 14+ 的 AICore 開發人員預覽版。開發者可以透過 ML Kit GenAI Prompt API 直接呼叫：

// Android AICore Gemma 4 呼叫範例
val generativeAi = GenerativeAi.getInstance(context)

val prompt = GenerativeAiPrompt(
    model = GenerativeAiModel.GEMMA_4_E2B,
    systemInstruction = "你是專業的中文技術部落格作者",
    inputText = "解釋什麼是混合式 RAG"
)

scope.launch {
    generativeAi.generate(prompt).collect { response ->
        textView.append(response.text)
    }
}

主要優點：

• 無需下載模型檔案（系統預先載入）
• Google Play Services 統一管理版本更新
• 自動選擇 CPU/NPU/GPU 執行後端

路徑二：LiteRT-LM（跨平台 CLI/Python）

對於跨平台需求（iOS、Linux、桌面），Google 提供了 LiteRT-LM——一個基於 LiteRT（Lightweight Runtime）的命令列工具與 Python SDK。這是目前最靈活的部署方式。

# LiteRT-LM Python SDK 範例
from literrt_lm import LiteRTModel

model = LiteRTModel.from_pretrained(
    "google/gemma-4-e2b",
    quantization="int4",
    backend="cpu"  # 或 metal (macOS) / opencl / vulkan
)

result = model.generate(
    "用繁體中文解釋什麼是 K8s Service Mesh",
    max_tokens=512,
    temperature=0.7
)
print(result)

LiteRT-LM 在 Raspberry Pi 5 上的實測表現尤其值得關注：

• Prefill 速度：133 tokens/s（CPU only）
• Decode 速度：7.6 tokens/s（單線）
• 記憶體使用：約 1.2 GB

這意味著即使是在一台 80 美元的單板電腦上，Gemma 4 E2B 也能提供可用的 AI 能力——對 IoT 與邊緣設備場景意義重大。

路徑三：MLX（Apple Silicon 優化）

對於 Apple 生態系，MLX 社群已提供 Gemma 4 的 Apple Silicon 最佳化版本。在 M4 Max 晶片上的實測數據非常亮眼：

量化技術與實際部署的效能權衡

Gemma 4 能在手機上運行，關鍵在於先進的量化技術。理解量化對效能的影響，是 ML 工程師做出正確部署決策的基礎。

從 FP16 到 INT4：記憶體與效能的交換

一般情況下，Gemma 4 E2B 的 FP16 權重約 4 GB（約為現代手機可用記憶體的一半），這對其他應用而言太大了。Google 的解決方案使用三層量化策略：

1. 權重量化：將權重從 FP16 壓縮為 INT4，模型大小降至約 1 GB
2. KV Cache 量化：推論時產生的 KV Cache 量化為 INT8
3. 激活值量化：根據層級動態決定激活值的量化精度

不同量化方案的比較

Google 的 LiteRT 混合精度方案在記憶體使用與精度損失之間取得了最佳平衡：僅損失 0.3% 的表現，同時將模型壓縮至 1.5 GB。這使得 Gemma 4 E2B 可以在 iPhone 17 Pro 和大部分中高階 Android 手機上流暢運行。

開源策略的長期影響：Gemma 能否成為 AI 界的 Android？

Gemma 4 採用 Apache 2.0 授權是與 Gemma 前代最根本的差異。Apache 2.0 授權明確允許：

• 商業使用，無需付費或回報
• 修改與分發衍生作品
• 專利授權（涵蓋 Google 持有的相關專利）

開源 LLM 授權比較

生態系布局的三個層次

Google 的生態系布局非常具有策略性，分為三個層次：

1. 底層——模型層：Gemma 4 以 Apache 2.0 完全開放，吸引全球開發者使用與貢獻
2. 中層——工具層：AICore、LiteRT-LM、ML Kit GenAI、MediaPipe SDK 等工具鏈降低部署門檻
3. 上層——硬體層：與高通、聯發科、三星深度合作，將 Gemma 4 的推論優化整合進 NPU/APU 設計

這個布局與 Android 當年的成功路徑幾乎一致：開放底層、提供開發者工具、與硬體廠商合作建立標準。到 2027 年，支援高效能本地 AI 推理預估將成為中高階智慧型手機的標配，滲透率預計從 2026 年的 15% 提升至 65% 以上。

已知限制與務實評估

雖然 Gemma 4 的發布令人振奮，但作為負責任的技術分析，必須指出其已知限制：

小型模型的邏輯推理缺陷

多家媒體在實測中發現，Gemma 4 的小型模型（E2B、E4B）在需要嚴格邏輯推理的任務上表現不如預期。一個經典的實測是 “strawberry test”——問模型 “strawberry 有幾個 r”（答案是 3 個），E2B 多次給出錯誤答案。這不是安全問題，而是小型模型在需要計數與符號操作（Symbolic Reasoning）的任務上的固有弱點。

iOS 支援仍在開發者預覽階段

Android 端的 AICore 已經完整支援，但 iOS 端的部署仍需透過 MediaPipe LLM Inference SDK，尚未達到生產成熟度。對於需要在 iOS 上部署 Gemma 4 的團隊，建議先以 MLX 作為過渡方案。

行動端長上下文的實際應用限制

雖然規格上支援 128K 上下文，但實際使用長上下文時，KV Cache 大小可能超過可用記憶體。128K tokens 的 INT8 KV Cache 約需 512 MB。建議在手機端使用時將有效上下文限制在 32K-64K。

FAQ 常見問題

Q1: Gemma 4 的 Apache 2.0 授權是否允許我在商業產品中使用？

是的。Apache 2.0 明確允許商業使用、修改與分發，且包含專利授權條款。你可以將 Gemma 4 整合進商業產品中，無需支付 Google 費用。唯一的義務是保留原始版權聲明。

Q2: Gemma 4 可以在完全不聯網的手機上運行嗎？

可以。透過 AICore 或 LiteRT-LM，模型權重直接儲存在裝置上，推論完全在本地執行，不需要任何網路連線。這是 Google 推動離線 AI 的核心賣點。

Q3: E2B 與 E4B 的實際記憶體需求為何？

以 4-bit 量化為例：E2B 約需 1.5-2 GB RAM，E4B 約需 3-4 GB RAM。再加上 KV Cache 與激活值的開銷，建議裝置至少有 6 GB（E2B）或 8 GB（E4B）的可用記憶體。

Q4: Gemma 4 支援中文嗎？

深度支援。Gemma 4 使用 140+ 語言的訓練語料，中文表現顯著優於 Gemma 3。繁體中文的翻譯、摘要、問答等任務表現出色。在 C-Eval 與 CMMLU 等中文基準測試中，26B MoE 版的分數接近同等參數規模的中文特化模型。

Q5: 26B MoE 與 31B Dense 版本該如何選擇？

如果裝置記憶體足夠（16GB+），31B Dense 在各項基準測試上表現最佳。26B MoE 則在記憶體效率（僅 3.8B 活躍參數）與表達能力間取得最佳平衡，適合在個人電腦或高階手機上運行。對於多數開發者，建議以 26B MoE 為目標版本。

結論：開源 LLM 的分水嶺時刻

Google DeepMind 的 Gemma 4 不只是一次模型發布——它是開源 LLM 生態系的分水嶺。當全球頂尖 AI 研究機構將其最新模型以 Apache 2.0 完全開放，並提供從手機到資料中心的完整部署管線時，這件事的戰略意義遠遠超越了技術參數的競爭。

對於 ML 工程師與行動開發者，我的建議是：

1. 立即試用 E2B 與 26B MoE 版本。Hugging Face 上已經可以直接下載，LiteRT-LM 的安裝只需一行 pip install。
2. 評估你的行動應用中哪些功能可以離線化。即時翻譯、文件摘要、郵件草稿等功能可以完全在本地完成，顯著提升用戶體驗與隱私保護。
3. 關注 Google 生態系的發展。如果 Gemma 4 的開源策略成功，它將成為 Android 生態系中 AI 功能的標準基礎設施。

我們正站在一個新時代的起點——AI 不再是需要「連線請求」的雲端服務，而是每一台裝置內建的基礎能力。Gemma 4 讓這個願景離現實更近了一步。

參考資料

1. Google’s Gemma 4 model goes fully open-source - ZDNet
2. Announcing Gemma 4 in the AICore Developer Preview - Android Developers Blog
3. Bring state-of-the-art agentic skills to the edge with Gemma 4 - Google Developers Blog
4. Gemma 4 26B-A4B Hugging Face Model Card
5. Google 最強小模型發布，手機也能跑 - 36氪
6. Google Gemma 4 實測：手機斷網也能用 - 澎湃新聞
7. Running Gemma 4 Locally on iPhone - 36Kr English
8. Gemma 4 community resources for mobile deployment - Hugging Face Discussions