谷歌把260億參數壓成4B用，本地AI終于不用看云端臉色了

凌晨兩點刷到這條推送時，我正躺在床上給手機充電——而谷歌說，以后這種場景下，我的手機可能根本不需要聯網就能跑一個40億參數的大模型。

Gemma 4 來了。谷歌給它定了調："迄今為止最智能的開放模型系列"。四個規格，從 Effective 2B 到 31B 稠密模型，全部 Apache 2.0 開源，商用隨便改。

最耐人尋味的是命名里的那個"E"。E2B、E4B，E 代表 Effective（有效參數）。打個比方：這就像一家餐廳宣傳"人均消費50元"，但進店才發現，后廚其實囤了夠500人吃的食材，只是每桌只給你上50元的量。PLE 技術讓每層解碼器給每個 token 配獨立小嵌入，內存占用比表面數字高，但推理時只激活標稱參數。

26B MoE 更像個精打細算的會計：260億參數全住進顯存，干活時只叫醒38億。速度保住了，知識儲備也沒丟。谷歌 DeepMind 的人管這叫"單位參數智能"的壓榨——31B 版本目前在開源榜單排第三，對手是參數大它20倍的模型。

多模態這次沒掉隊。E2B、E4B 原生支持視頻音頻輸入，所有型號都能看圖說話，上下文窗口拉到128K-256K。系統提示詞內置了，函數調用原生支持，140多種語言。前幾代 Gemma 做 Agent 還得開發者自己搭橋，現在出廠就是 Agent Ready。

有網友測完說 Qwen3.5-27B 略勝一籌，但另一條評論戳中了痛點："四種尺寸全為 Agent 準備，全都能本地跑。我們喊了多久'別每次思考都傳云端'，他們終于聽見了，而且給得比預期多。"

谷歌列了張內存需求表，但藏著腳注：官方數字只算靜態權重，框架開銷、KV Cache、微調時的批量大小，都是額外賬單。26B MoE 看著像4B的用量，實際顯存胃口接近稠密26B——畢竟260億參數得先全部請進內存，才能決定叫醒哪38億。

部署渠道鋪得很滿：Hugging Face、Ollama、llama.cpp、手機上的 AICore Preview……從 Jetson Nano 到 Blackwell GPU，從 AMD ROCm 到谷歌 TPU。Constellation Research 的分析師說，這適合"對數字主權有較高要求"的場景——翻譯過來就是：數據不想出境的人，終于有體面的選擇了。

我在 Hugging Face 的模型卡頁面停了一會兒。底下有條剛發的討論："測試了 E2B 在 Pixel 上的延遲，基本無感。"發帖時間是凌晨三點十四分，和我這邊差不多。