谷歌Gemma 4深夜突降，31B爆殺20倍巨頭，手機跑全血「龍蝦」

谷歌深夜掏家底！Gemma 4全系開源，僅用31B越級斬殺20倍體量巨頭。數學能力暴漲68%，硬生生把前代打成計量單位，開源界迎來終極大洗牌！

谷歌這次，把家底都掏了。

凌晨，谷歌DeepMind正式發佈Gemma 4，一口氣放出四款開源模型。

從能塞進手機的2B，到可以單卡跑滿的31B，四個尺寸全覆蓋，全部基於Gemini 3同源打造。

時隔一年，Gemma 4終於來了，實力迎來史詩級躍遷。

最炸的一個數字，31B Dense在Arena AI文本榜單上拿下開源第三，Elo評分1452。

排在它前面的，一個600多億參數，一個超過1000億。Gemma 4用31B的體量，硬生生擠進了這個量級的牌桌。

26B MoE更離譜：260億參數，推理時只激活38億，Elo打到1441，排開源第六。

看一眼成績單，Gemma 4幾乎沒有弱點，簡直就是對上一代的「血脈壓制」——

數學（AIME 2026）：89.2% vs 21.2%，暴力拉昇68個百分點；

編程（LiveCodeBench）：80% vs 29.1%，實力堪稱代際斷層；

智能體（t2-bench）：Gemma 4狂攬86.4%，Gemma 3僅有6.6%，差距大到「沒眼看」。

另外，在多語言推理、知識問答的基準測試中，Gemma 4均實現了40%性能飆升。

令全網背脊發涼的是，一個31B Gemma 4，越級斬殺體量是其20倍的模型。

一臺Mac mimi即可跑Gemma 4，還有人手機已經用上了。

Hugging Face CEO Clément Delangue的評價只有一句話，「這是一個巨大的里程碑。」

四款模型，從口袋到工作站全覆蓋

先看Gemma 4「全家桶」具體成員——

每個尺寸都提供base和instruction-tuned兩個版本。

E2B和E4B負責端側，跟谷歌Pixel團隊、高通、聯發科聯合優化，能在手機、樹莓派、Jetson Orin Nano上離線運行，延迟接近零。

31B和26B面向開發者工作站和服務器，31B追求極致質量，26B靠MoE架構換取極致速度。

對開發者來説，31B的bfloat16權重可以塞進一張80GB的H100；量化版本在消費級顯卡上就能跑。

26B MoE因為只激活3.8B參數，出token速度極快，適合需要低延迟的Agent場景。

值得一提的是，Gemma 4還支持「被曝抄襲」的TurboQuant壓縮算法。

跑分碾壓，跨級暴打

看完定位看跑分。

31B在數學推理上的表現尤其驚人。AIME 2026拿到89.2%，對比Gemma 3 27B的20.8%，提升超過四倍。

GPQA Diamond（科學知識）84.3%，同樣把前代遠遠甩開。

編程能力同樣炸裂。LiveCodeBench v6上31B拿到80%，Codeforces Elo達到2150，相當於一個紫名選手的水平。26B MoE也不弱，LiveCodeBench 77.1%，Codeforces 1718。

多模態方面，MMMU Pro（多模態推理）31B拿到76.9%，26B拿到73.8%，都大幅領先前代的49.7%。

長上下文能力同樣有質的飛躍。MRCR v2 8-needle 128K測試中，31B拿到66.4%，26B拿到44.1%，Gemma 3 27B只有13.5%。

小尺寸也沒拉胯，E4B在AIME上42.5%，LiveCodeBench 52%，對一個只有45億有效參數的選手來説，這個成績放在一年前是旗艦級的。

三個架構設計

讓小模型打出大模型的牌

Gemma 4的架構沒有堆砌花哨的新概念，反而是把幾個經過驗證的技術組合到了最優狀態。

谷歌明確表示，他們去掉了Altup等「效果不確定」的組件，只保留了真正有用的東西。

逐層嵌入（Per-Layer Embeddings，PLE）

傳統Transformer里，每個token在輸入層獲得一個嵌入向量，后面所有層都基於這個初始表示做計算。問題在於，這要求嵌入層一次性把所有信息打包進去，負擔很重。

PLE的做法是給每一層都配一個專屬的低維信號通道。

每個token在每一層都能收到一個定製化的向量，由token本身的身份信息和上下文信息共同生成。

打個比方，傳統做法像是出門前把一天要用的所有東西塞進一個揹包；PLE像是每到一個地方，都有人遞給你當下最需要的工具。

因為PLE的維度遠小於主隱藏層，額外開銷很小，但每一層都獲得了專屬的調節能力。這個設計在小模型上效果尤其明顯，是E2B和E4B能以極小體量跑出好成績的關鍵。

共享KV緩存

最后N層不再自己計算Key和Value投影，而是直接複用前面層的KV張量。同類型的注意力層（滑動窗口或全局注意力）共享同一組KV狀態。

效果是推理時的顯存佔用和計算量都下降了，長上下文生成和端側部署尤其受益。谷歌稱這對質量的影響「微乎其微」。

交替注意力機制

模型交替使用局部滑動窗口注意力和全局全上下文注意力。

小模型用512 token的滑動窗口，大模型用1024。全局層配合等比例RoPE拉長上下文覆蓋範圍，滑動層用標準RoPE保持局部建模效率。

這三個設計的共同目標只有一個，讓每一個參數都儘可能高效地被利用。

看圖、聽聲、讀視頻

一個Gemma全搞定

Gemma 4全系能處理圖像和視頻輸入，E2B和E4B還額外兼容音頻。

視覺編碼器相比Gemma 3做了兩個關鍵升級，一是可變寬高比（不再強制裁切），二是可配置的圖像token預算（70/140/280/560/1120五檔可選）

低預算適合分類和描述，高預算適合OCR和文檔解析。開發者可以根據場景在速度和精度之間自由取捨。

GUI元素檢測。

給一張網頁截圖，問「view recipe按鈕在哪」，四個尺寸都能以JSON格式返回精確的邊界框座標，不需要任何特殊提示詞。31B的定位最精準，E2B稍有偏差但基本可用。

視頻理解。

用一段現場演唱會視頻做測試。E4B準確描述了舞臺畫面，也從音軌中提取了歌詞主題。

26B和31B沒有音頻輸入能力，但對純視覺內容的理解同樣到位，甚至識別出了屏幕上的贊助商品牌名。

音頻轉寫。

E4B對一段英文演講的轉寫幾乎完美，標點和斷句都很自然。E2B偶爾會出現幻覺，但整體可用。

多模態函數調用。

給一張曼谷寺廟的照片，問「這是哪個城市？幫我查一下當地天氣」。

四個尺寸都正確識別出曼谷，並自動調用了get_weather工具。全程不需要額外的提示工程。

函數調用是從訓練階段就內置的，基於去年底發佈的FunctionGemma研究成果，能處理多輪多工具的Agent工作流。這跟之前靠提示詞「哄」模型做工具調用的路線完全不同。

Apache 2.0，谷歌終於放手了

這次發佈最大的非技術新聞，是Gemma 4首次採用Apache 2.0協議。

之前的Gemma系列用的是谷歌自定義許可證，里面有「有害使用」限制條款和歸屬要求，企業法務團隊需要逐條審查才能確認是否可以商用。

Apache 2.0一步到位，沒有自定義條款，沒有灰色地帶，修改、分發、商用完全自由。

自Gemma初代發佈以來，累計下載量超過4億次，社區衍生版本超過10萬個。Apache 2.0的加持下，這個數字大概率還會加速增長。

開源模型，規則變了

Gemma 4的發佈，讓谷歌的雙線策略徹底成型。

頂層是Gemini系列閉源模型，佔據榜單前列，通過API變現。底層是Gemma系列開源模型，用同源技術餵養開發者生態，搶佔本地部署、端側推理、Agent開發的入口。

一個做收入，一個做生態。彼此不衝突，反而互相放大。

對開發者來説，選擇已經擺在面前。

一個31B的體量，能在單卡上跑出接近千億參數級別的效果，Apache 2.0隨便用，從手機到服務器全覆蓋，微調工具鏈完整。

參數效率這條路，谷歌跑在了最前面。31B打贏20倍體量的對手，2B塞進手機口袋。

開源模型的比賽，規則已經變了。

參考資料：

https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/

本文來自微信公眾號「新智元」，作者：新智元，編輯：好睏 桃子，36氪經授權發佈。