Gemma 4 全系列本地部署指南：Ollama / llama.cpp / MLX / vLLM，附 TurboQuant 显存优化|cuda|nvidia|上下文|全系列|内存

一句话总结：这是目前参数效率最高的开源模型家族，十分之一参数量，媲美旗舰模型

四款模型，各有定位

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 更少，推理成本更低。

说到开源模型，现在绕不开中国选手。来看 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 的核心价值：

优势：