網易首頁 > 網易號 > 正文申請入駐

Gemma 4 全系列本地部署指南：Ollama / llama.cpp / MLX / vLLM，附 TurboQuant 顯存優化

2026-04-04 11:36:27　來源: Ai學習的老章

北京舉報

分享至

一句話總結：這是目前參數效率最高的開源模型家族，十分之一參數量，媲美旗艦模型

四款模型，各有定位

Gemma 4 一口氣發布了四個尺寸的模型：

來逐個看看它們的定位：

31B Dense —— 全密集架構，31B 參數全部激活，主打桌面工作站和單卡 H100。這是 Gemma 4 家族的當家花旦，在 Arena AI 開源模型排行榜文本賽道排名第三。不做量化的情況下，可以塞進一張 80GB 的 H100。

26B MoE（混合專家架構） —— 總參數 26B，單次推理只激活 3.8B 參數。在排行榜上排第六。MoE 的優勢是推理速度快、延遲低，同一張卡上的 TPS 遠超 Dense 版本。如果你更在乎推理速度，MoE 是更好的選擇。

E4B —— 有效參數 4.5B（加上 embedding 約 8B），為移動端 + Jetson / 樹莓派設計。是跟 Google Pixel 團隊、高通、聯發科聯合開發的。

E2B —— 有效參數 2.3B（加上 embedding 約 5B），主打手機 / IoT / 邊緣設備。這是整個家族里最適合端側部署的版本。

這里解釋一下 E2B 和 E4B 的「E」代表什么。小模型采用了 Per-Layer Embeddings（PLE）技術來最大化參數效率——每個 decoder 層都有自己的小型 embedding 表，這些表雖然體積大但只用來做快速查找，所以實際激活的參數遠少于總參數。「E」就是 Effective（有效）的意思。

全系列支持的能力統一且強悍：

多模態輸入 ：全系列原生支持圖像和視頻理解，小模型額外支持音頻輸入和語音識別
超長上下文 ：大模型 256K，小模型 128K
Agent 工作流 ：原生函數調用（Function Call）、結構化 JSON 輸出、System Instruction
140+ 語言 ：原生訓練支持 140 多種語言
代碼生成 ：高質量離線代碼生成，可以當本地代碼助手用

跑分表現

先看 Google 官方給出的基準測試數據：

Gemma 4 31B 在 Arena AI 開源排行榜文本賽道排第三，26B MoE 排第六，Google 說它們超過了體量大 20 倍的模型。

再看第三方評測機構 Artificial Analysis 的測試。在科學推理評估 GPQA Diamond 上，Gemma 4 31B（Reasoning）拿到 85.7%，在 40B 以下的開權重模型中排第二，僅次于 Qwen3.5 27B（85.8%）。差距只有 0.1 個百分點，基本算打平。

更有意思的是 Token 效率，Gemma 4 31B 在同一個評估里只用了約 120 萬個輸出 token，比 Qwen3.5 27B 的 150 萬和 Qwen3.5 35B A3B 的 160 萬都少。也就是說，達到差不多的準確率，Gemma 4 用的 token 更少，推理成本更低。

正面對決 Qwen3.5 27B

說到開源模型，現在繞不開中國選手。來看 Gemma 4 和 Qwen3.5 27B 的細項對比：

坦率講，逐項看下來基本每一項都是 Qwen3.5 27B 領先。不過 Gemma 4 31B 在 Arena AI 排行榜的 Elo 分和 Qwen3.5 差不多打平，說明在人類偏好評估上兩者體驗接近。跑分和實際使用體感有時候就是兩碼事。

架構解析：為什么沒變還能起飛

知名 AI 博主 Sebastian Raschka 第一時間拆解了 Gemma 4 的架構。他的結論很有意思：

? 架構幾乎沒變——還是經典的 Pre/Post-norm 設置 + 5:1 混合注意力機制（滑動窗口局部層 + 全注意力全局層） + 分組查詢注意力（GQA）

? 但性能直接起飛！基準測試里完勝 Gemma 3，和 Qwen3.5 27B 難分高下

? MoE 版本（26B 激活 4B 參數）跑分只比 Dense 版本差一點點，性價比極高

? 終于換成標準 Apache 2.0 許可，沒那么多限制了

所以架構沒什么創新，但性能提升巨大，大概率是訓練數據和訓練方法的功勞。有時候不需要架構革命，數據和訓練配方做對了，效果就是質的飛躍。

本地怎么跑

這才是大家最關心的部分。

Gemma 4 發布當天，主流推理框架全部跟進了適配，生態確實給力。

Ollama

Ollama 0.20+ 版本直接支持：

ollama run gemma4:e2b     # 2B 有效參數，端側
ollama run gemma4:e4b     # 4B 有效參數，移動端
ollama run gemma4:26b     # 26B MoE（激活 4B）
ollama run gemma4:31b     # 31B Dense

llama.cpp

llama.cpp 同步跟進，可以用 Homebrew 安裝最新版：

brew install llama.cpp --HEAD
llama-server -hf ggml-org/gemma-4-26B-A4B-it-GGUF:Q4_K_M

MLX（Mac 用戶看這里）

Mac 用戶的福音——mlx-vlm v0.4.3 發布當天就支持了 Gemma 4 全系列，包括視覺、音頻和 MoE 模型。社區大佬幾個小時內上傳了 125 個量化模型。如果你是 Mac 開發者，現在就可以跑起來了：

uv pip install -U mlx-vlm

更猛的是，MLX-vlm 0.4.3 搭配 TurboQuant KV 緩存壓縮，Gemma 4 31B 在 128K 上下文下的內存表現直接起飛：

KV 緩存內存 ：13.3 GB → 4.9 GB（減少 63%）
峰值內存 ：75.2 GB → 65.8 GB（直接省了 9.4 GB）
質量保持 ：壓縮后幾乎無損

TurboQuant 的壓縮效果跟序列長度成正比，上下文越長省得越多。想在 Mac 上體驗的話，一行命令搞定：

uv run mlx_vlm.generate --model google/gemma-4-31b-it --kv-bits 3.5 --kv-quant-scheme turboquant

目前已知解碼速度會有約 1.5 倍的下降（內核啟動開銷導致），官方說后續版本會修復。但光是內存省下來的這些空間，對于 Mac 用戶來說已經很值了——本來跑不下的上下文長度，現在能跑了。

Unsloth 量化版

我之前介紹過的 Unsloth 也第一時間出了量化版。E2B 和 E4B 大約只需要 6GB 內存就能跑，26B MoE 和 31B 大約需要 18GB。

有個好玩的演示：Gemma 4 E4B 在 Unsloth Studio 里只用 6GB 內存就能搜索并引用 10+ 個網站、執行代碼來找最佳答案。用 6GB 內存跑一個能搜網頁、寫代碼的 AI Agent，放兩年前說出來沒人信。

GGUFs 下載：https://huggingface.co/collections/unsloth/gemma-4

vLLM

vLLM 同步支持，原生多模態（視覺 + 音頻），支持 256K 上下文，跨主流 GPU 架構和 TPU。

已經有人用 vLLM v0.18.2 + transformers v5.5.0 跑通了 Gemma 4 31B 的工具調用：

工具調用能力測試

ToolCall-15 是一個專門測試大模型工具調用能力的基準，我之前介紹過。來看 Gemma 4 全家族的成績：

關鍵發現：Gemma 4 31B 和 Qwen3.5 27B 都拿到了滿分 15/15。在工具調用這個維度上兩者完全打平。

但差距在小模型上就明顯了：Qwen3.5 9B 就能拿到 13/15，Gemma 4 需要上到 26B 才能匹配這個水平。在小模型的工具調用能力上，Qwen3.5 還是有優勢。

實際運行性能

別光看跑分了，來看實際跑起來的速度。有人在單張 RTX 4090 上測試了 Gemma 4 26B MoE：

解碼速度：162 token/s
預填充：8,400 token/s
完整 262K 原生上下文
顯存占用：19.5 GB
Elo 分只比 31B Dense 低 10 分

雙卡配置（RTX 4090 + RTX 3090）跑 Q8_0 量化的 31B Dense：

預填充 10K token：9,024 token/s
全 262K 上下文：2,537 token/s —— 一部小說大約 100 秒就能處理完

配合 TurboQuant 分支做 KV cache 量化，還能再省 1.8 GB 顯存，幾乎沒有性能損失。

單卡 4090 跑滿 262K 上下文的命令（MoE Q4_K_M 量化版）：

llama-server -m gemma-4-26B-A4B-it-UD-Q4_K_M.gguf \
  -c 262144 -np 1 -ctk q8_0 -ctv turbo3 \
  -fa on --fit off --cache-ram 0 -dev CUDA0

MoE 版本的解碼速度是 Dense 版本的 3.7 倍。單張 4090 就能跑滿 262K 上下文，這個數據對于想本地部署長上下文 Agent 的開發者來說，非常有吸引力。

TurboQuant+ 權重壓縮（實驗性）

TurboQuant 不只是壓 KV 緩存，最新的 TurboQuant+ 分支還支持模型權重壓縮。原理是對模型權重施加 WHT 旋轉 + Lloyd-Max 極化量化，屬于訓練后量化，不需要重新訓練或校準，直接對 Q8_0 的 GGUF 模型操作就行。

Gemma 4 31B 的效果：30.4 GB 壓縮至 18.9 GB，全系列模型都能享受 TurboQuant+ KV 緩存同樣的好處。

目前支持 Apple Silicon（Metal）、NVIDIA（CUDA）和 AMD（ROCm/HIP）三大平臺。想嘗鮮的話，從實驗分支開始：

git clone https://github.com/TheTom/llama-cpp-turboquant.git
cd llama-cpp-turboquant
git checkout pr/tq4-weight-compression

 # Apple Silicon
cmake -B build -DGGML_METAL=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

 # NVIDIA
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

詳細文檔：https://github.com/TheTom/turboquant_plus/blob/main/docs/getting-started.md-compression-tq4_1s--experimental

對于顯存敏感的本地部署場景，30.4→18.9 GB 的壓縮意味著原來需要雙卡的配置，現在可能單卡就夠了。這個實驗分支值得關注。

英偉達優化

NVIDIA 這次也沒缺席。Google 和 NVIDIA 聯合對 Gemma 4 做了針對性優化，覆蓋了從數據中心到桌面再到邊緣的全棧場景——RTX GPU、DGX Spark 個人 AI 超算、甚至 Jetson Orin Nano 邊緣模塊都能跑。

NVIDIA 官方給出了性能基準：所有配置使用 Q4_K_M 量化，BS=1，ISL=4096，OSL=128，在 RTX 5090 和 Mac M3 Ultra 上用 llama.cpp 的 llama-bench 工具測試。

具體來說：

E2B / E4B ：為邊緣場景而生，在 Jetson Nano 上也能完全離線運行，延遲接近零
26B / 31B ：針對 RTX GPU 和 DGX Spark 做了優化，主打 Agent 開發工作流——代碼助手、推理引擎、函數調用都是強項
OpenClaw 兼容 ：Gemma 4 全系列兼容 NVIDIA 的 OpenClaw 本地 AI Agent 框架，可以直接從個人文件、應用和工作流中提取上下文來自動化任務

NVIDIA Tensor Core 對 AI 推理的加速在這里體現得很明顯——更高的吞吐、更低的延遲，加上 CUDA 生態的廣泛兼容性，新模型基本都是 Day-1 就能高效運行。

想了解完整部署指南，可以看 NVIDIA 的技術博客：https://developer.nvidia.com/blog/bringing-ai-closer-to-the-edge-and-on-device-with-gemma-4/

Simon Willison 的評價

知名開發者 Simon Willison 第一時間測試了 Gemma 4。他用 LM Studio 跑了 GGUF 版本，2B、4B 和 26B MoE 都運行正常，但 31B Dense 出了問題——對每個 prompt 都輸出 "---\n" 死循環。這種早期 bug 后續應該會修復。

他還發現了一個有趣的點：E2B 和 E4B 雖然支持音頻輸入，但目前 LM Studio 和 Ollama 都還沒實現這個功能。想在本地跑音頻理解，可能還得等等。

Google 特別強調了「前所未有的參數效率」。Simon Willison 認為這說明在當前 AI 研究中，如何做出好用的小模型正在成為最熱門的方向之一。

總結

Gemma 4 的核心價值：

優勢：

Apache 2.0 開源許可，商用無障礙，這是最大的進步
參數效率極高，31B 模型能和大幾倍的模型掰手腕
MoE 版本性價比炸裂，單卡 4090 就能跑滿 262K 上下文
原生多模態 + 工具調用 + 超長上下文，Agent 開發直接可用
端側模型能跑在手機和樹莓派上，6GB 內存就能跑 Agent
生態完善，Ollama、llama.cpp、vLLM、MLX 全部 Day-1 支持
TurboQuant+ 加持下，31B 權重從 30.4 GB 壓到 18.9 GB，MLX 上 128K 上下文 KV 緩存省 63%

不足：

跟 Qwen3.5 27B 正面比，多數跑分項目略遜
小模型的工具調用能力不如同參數量級的 Qwen
31B Dense 在部分推理框架上還有早期 bug
音頻輸入功能暫時只能通過 Google AI Studio 體驗，本地工具還沒適配

我的建議：

如果你需要商業部署開源模型，Gemma 4 的 Apache 2.0 許可證是一個很重要的加分項
本地跑推薦 26B MoE 版本，速度快、顯存占用相對小，性能只比 Dense 差一點點
有條件上 Dense 就上 Dense，畢竟是質量天花板
Mac 用戶直接走 MLX，體驗最佳
端側開發者可以重點關注 E2B 和 E4B，6GB 內存跑 Agent 的未來已經來了

官方博客：https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/

GGUFs 下載：https://huggingface.co/collections/unsloth/gemma-4

Unsloth 指南：https://unsloth.ai/docs/models/gemma-4

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.