Gemma 4 把 256K 上下文帶進開放模型
Google DeepMind 的 Gemma 4 加入文字、圖片、音訊輸入，最高 256K context，還提供五種開放權重規格，適合本機與伺服器部署。
Google 的 Gemma 4 是一組開放權重模型，主打多模態輸入、最高 256K context，還分成五種尺寸給不同部署場景。
說真的，這次不是只換個版本號。它把文字、圖片、音訊一起塞進同一條產品線。最大 context 也拉到 256,000 tokens，對長文件和多輪代理流程很有感。
更實際的是，Google DeepMind 把它拆成五種尺寸。小的給裝置端，大的給工作站和伺服器。這種切法很務實，不會逼大家拿同一顆模型硬打全部場景。
| 模型 | 參數 | Context | 模態 | 定位 |
|---|---|---|---|---|
| E2B | 2.3B effective，5.1B with embeddings | 128K | 文字、圖片、音訊 | 裝置端效率優先 |
| E4B | 4.5B effective，8B with embeddings | 128K | 文字、圖片、音訊 | 小型但支援音訊 |
| 12B Unified | 11.95B | 256K | 文字、圖片、音訊 | 單一解碼器架構 |
| 26B A4B MoE | 25.2B total，3.8B active | 256K | 文字、圖片 | Mixture-of-experts |
| 31B | 30.7B | 256K | 文字、圖片 | 家族中最大 dense 模型 |
Gemma 4 的重點是長上下文和多模態
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Gemma 4 不是單一模型。它是一個家族。這件事很重要。因為不同產品的需求差很多。手機助理、桌面 coding 工具、文件分析服務，根本不會用同一種部署策略。
小模型像 E2B 和 E4B，重點是速度和記憶體。大一點的 12B、26B A4B、31B，則比較適合 GPU、工作站，或伺服器推論。這種分層，對開發者來說比單點規格更有用。
context 也是這次的核心。小模型是 128K，其他幾個版本直接上到 256K。這代表你可以塞長報告、整包 codebase，或很多輪對話，不用一直切碎輸入。老實說，這才是很多團隊真正會碰到的痛點。
- E2B 和 E4B 都支援文字、圖片、音訊。
- 12B Unified 是單一架構，三種模態都吃。
- 26B A4B 和 31B 走 256K context。
- 五個尺寸都是 open-weight。
架構選擇不是裝飾，是成本差
Google 的文件提到，Gemma 4 混用了 dense 和 mixture-of-experts。它還加上 hybrid attention，會在 local sliding-window attention 和 global attention 之間切換。這種設計不是拿來寫簡報的，是拿來決定推論速度和成本的。
26B A4B 很能說明問題。它總參數是 25.2B，但推論時只有 3.8B active parameters。意思很直接。它在 runtime 看起來更像小模型，但保留了大模型級別的容量。這對雲端成本很敏感的團隊很有吸引力。
小模型還用了 per-layer embeddings。Google 說這有助於裝置端效率。講白了，就是盡量省記憶體，又不要把功能砍爛。這種取捨比單純追大參數實際多了。
“The future of AI is open,” said Demis Hassabis, co-founder and CEO of Google DeepMind, in a 2024 blog post announcing Gemma.
這句話放在這裡很合理。Gemma 4 延續了 open-weight 路線，但功能已經不是早期那種簡單文字模型。現在它能讀圖，也能聽音訊。Google 顯然想讓開發者能檢查、調整、再部署。
數字比較很清楚，26B A4B 是焦點
這次的 benchmark 很多。看起來有點雜，但其實層次很明顯。31B 通常拿最高分，26B A4B 則常常用更少 active parameters 追得很近。對要算推論成本的團隊，這比單看最高分更重要。
幾個比較值得看的指標如下。這些數字直接反映 reasoning、coding，還有長上下文表現。你如果要做產品選型，這些比行銷詞有用太多。
- MMLU Pro：31B 是 85.2%，26B A4B 是 82.6%，12B Unified 是 77.2%。
- LiveCodeBench v6：31B 是 80.0%，26B A4B 是 77.1%，12B Unified 是 72.0%。
- Codeforces Elo：31B 是 2150，26B A4B 是 1718，12B Unified 是 1659。
- MRCR v2 at 128K：31B 是 66.4%，26B A4B 是 44.1%，12B Unified 是 43.4%。
Codeforces 2150 這個數字很有份量。它代表這家族在 coding 題上不是來湊熱鬧。26B A4B 能把 1659 拉到 1718，也說明 MoE 不是只省算力，實際表現也有差。
不過長上下文檢索就沒那麼平均。從高階模型往下掉，分數差距會變明顯。這很正常，但如果你的場景是整份文件、逐字稿、或 repo 級輸入，就要特別看這一項。
開發者真正會拿它做什麼
Gemma 4 的目標不是只有聊天。Google 強調它可以做文字生成、程式設計、推理、function calling，還有多模態理解。它也支援 system role，這對結構化提示詞很有幫助。
這件事很務實。很多模型都會喊 agent，但底層能力沒跟上。Gemma 4 至少把長 context、function calling、system prompt 這三件事放在一起。對要做助手、審稿、文件分析的人來說，這樣才像樣。
如果你在比其他 open-weight 選項，重點就是部署位置。小模型比較適合本機和邊緣裝置。大模型比較適合伺服器端。對已經在用 Hugging Face、Ollama、LM Studio 的團隊，open-weight 會讓測試門檻低很多。
Google 也把它接到自己的生態裡，像 Google Developers Blog、Google AI、Vertex AI。這表示從本機測試到雲端部署，路徑算是接得上。
這不是噱頭，是產品線整理
我覺得 Gemma 4 最有意思的地方，不是某一個單點數字，而是它把產品線整理得很完整。多模態、長上下文、不同規格、開放權重，這幾件事同時到位，才是真的能拿來做產品。
如果你在做文件助理、coding copilot、或多模態 agent，現在該問的不是 open model 能不能做，而是哪一顆 Gemma 4 合你的 latency、記憶體和 context budget。這才是工程問題，不是新聞標題。
我的判斷很簡單。26B A4B 會先吸引最多開發者，因為它在效果和成本之間抓得不錯。12B Unified 也可能很有市場，因為它同時吃文字、圖片、音訊，架構又相對單純。接下來要看第三方工具跟不跟得上，讓大家真的能快速試到這些模型。
如果你是台灣團隊，現在最值得做的事不是先喊採用，而是先挑一個真實工作流。拿 100 份文件、10 小時逐字稿，或一個中型 repo 去跑。數字會比簡報誠實很多。