本地部署 Gemma 4 26B QAT 实操记录

在32GB显卡上，Gemma 4 26B QAT模型跑出了433ms首字时延的惊艳成绩，真正实现了大模型的高效本地部署。
核心内容：
1. Gemma 4 26B QAT模型的性能优势与架构特点
2. 详细的硬件环境与从零开始的部署过程记录
3. 当前主流部署方案的对比与选择原因

写在前面

我之前发过Gemma 4 QAT 相关的文章，当时刚出来比较兴奋，但是26B的一直没有上线，最近（8天前），我看到hugging face 上架了 26b的QAT 版本，马上体验了下，先直接说结论：在32GB显卡上，Unsloth 的 Gemma 4 26B A4B QAT GGUF 量化版跑出了 433ms 首字时延、156 tokens/s 的成绩，128K 上下文只用了 83% 显存。

这不是实验室里那种"能跑但不好用"的模型——它是真的可以每天用的。

为什么是 Gemma 4

Google DeepMind 的 Gemma 4 是一个系列，从 12B 到 31B，这个 26B A4B 是 MoE（混合专家）架构：

• 总参数量 26B，但每次推理只激活约 8B 的参数
• 所以它既有大模型的知识广度，又有小模型的推理速度
• 原生支持 256K 上下文窗口
• 多模态：文字输入 + 图片理解（这个后面单独说）

而 QAT（Quantization-Aware Training）是 Google 和 Unsloth 合作的量化方案——在训练阶段就把 4-bit 精度约束加进优化目标，让模型学会在低精度下"自救"。结果就是用 4-bit 跑出了接近 BF16 的质量。

这对我们这种只有两张消费级显卡的人来说，意义很大。

部署过程：从零开始的真实记录

硬件环境

下载模型

模型来自 Unsloth 的 HuggingFace 仓库：unsloth/gemma-4-26B-A4B-it-qat-GGUF

GGUF 文件 9.8GB，在 HuggingFace 上下载的时候因为网络波动断了几次，用 curl -C - 续传每次都能接着断点继续，没有什么坑。

部署方案对比

可能有人会问：为什么不用 vLLM？

我试了。vLLM 0.22.0 的 GGUF 引擎只支持到 gemma3 架构——这个模型写的是 gemma4。

又查了最新版 vLLM（0.23.0），同样不支持。vLLM 的 GGUF 支持依赖于 gguf Python 包（llama.cpp 的 GGUF 协议绑定），而这个包目前最高版本（0.17.x）的 MODEL_ARCH_NAMES 里还没有 gemma4。这不是 vLLM 版本新旧能解决的问题——GGUF 协议层尚未收录 gemma4 架构，vLLM 的 GGUF 路径暂时无法走通。

目前能读 gemma4 GGUF 的是 Ollama 内置的最新版 llama.cpp，它有自己的 GGUF 引擎（不依赖 PyPI 上的 gguf 包）。

对比表：三种部署方案在 Gemma 4 QAT 上的实际情况

最终的选择是 Ollama（v0.30.6）。Ollama 底层是 llama.cpp，内置了 CUDA 12 的 GPU 支持库，双卡 tensor split 开箱即用。

部署命令极简：

ollama create gemma4-qat -f Modelfile

Modelfile 就一行：

FROM /path/to/gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf
PARAMETER num_ctx 131072

然后 ollama serve 就完了。

GPU 占用

加载后 nvidia-smi 输出：

GPU 0: 14.7 GB / 16 GB
GPU 1: 11.9 GB / 16 GB
合计: 26.6 GB / 32 GB (83%)

128K 上下文只用了 83% 的显存，余量还有 5.4GB。如果缩减到 32K 上下文，16G就够了。

Cherry Studio 实测

在 Cherry Studio 里配置 OpenAI 兼容接口，把地址指向 http://192.168.0.109:11434/v1，模型名填 gemma4-qat，直接就能用。

性能数据

最前面那句话的出处在这里：

433ms 的首字时延什么概念？就是你打字问他一个问题，手指还没完全离开键盘，第一个字已经开始往外蹦了。156 tok/s 是什么体验？就是你知道它正在生成，但几乎追不上它的速度。

这已经完全达到了实用级水平。

能力实测

看几个场景：

工具调用（Tool Calling） 配置了 MCP 工具后，Gemma 4 26B 能正确识别何时需要调用工具、返回格式正确的 function call 参数。本地代码补全、文件操作、网页搜索都可以自主完成。

推理能力 对比普通的 Qwen 3、DeepSeek V3 Lite，Gemma 4 26B QAT 在逻辑推理上确实有明显优势。它自带思考（reasoning）能力——每次回答前会先输出一段思考过程，然后再给出答案。

视觉理解 这是最惊喜的部分。Unsloth 版本的 GGUF 还附带了 mmproj 多模态投影文件，所以这个模型能看懂图片。在 Cherry Studio 里直接上传图片，它就能分析。

到底值不值

我把这个 QAT 版本和之前用的 AWQ 4-bit 做了对比：

QAT 在质量上应该也更好——它是训练时就做了量化优化，而不是事后适配。但这个需要跑 BenchLocal 来量化验证，等跑完了再单独写一篇。

视觉能力实测

Gemma 4 26B 原生支持多模态，但 Ollama 默认导入 不会自动带视觉能力。这个坑折腾了我好一阵。

问题：Cherry Studio 里发图片时返回 400 Bad Request，API 路径 http://192.168.0.109:11434/api/chat，请求体带了 images 字段。

原因：Gemma 4 的视觉能力不在主模型里——它通过一个独立的 mmproj（多模态投影文件）把图片编码成 token 序列。ollama create 只注册了主 GGUF，没注册投影文件。

修复：

1. 从 HuggingFace 仓库下载 mmproj-F16.gguf（1.1GB）
2. 计算 SHA256，复制到 Ollama 的 blob 存储
3. 修改模型 manifest，在 layers 中插入 application/vnd.ollama.image.projector 层
4. 重启 Ollama

Shell 操作大致是：

# 下载投影文件
curl -L -o mmproj-F16.gguf 
  "https://hf.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF/resolve/main/mmproj-F16.gguf?download=1"
# 计算哈希
SHA256=$(sha256sum mmproj-F16.gguf | cut -d' ' -f1)
cp mmproj-F16.gguf /data/ollama/blobs/sha256-$SHA256
# 更新模型 manifest
python3 -c "
import json
m = json.load(open('/data/ollama/manifests/.../gemma4-qat/latest'))
m['layers'].insert(1, {
  'mediaType': 'application/vnd.ollama.image.projector',
  'digest': 'sha256:$SHA256',
  'size': $(stat -c%s mmproj-F16.gguf)
})
json.dump(m, open('/data/ollama/manifests/.../gemma4-qat/latest','w'), indent=2)
"

修好之后实测发图，模型成功识别了测试图片中的文字："The text shown in this image is Hello Gemma 4."

视觉的代价是多占 1.1GB 显存（mmproj 文件本身），加上之后双卡各 13.3GB，总显存占用 26.6GB（83%），仍然在 32GB 的容限范围内。

部署架构概览：从 HuggingFace 下载 → Ollama 导入 → 双卡 GPU 推理 → Cherry Studio 调用

部署架构概览

一些真实的槽点

不是所有东西都完美，有几点值得说清楚：

1. Ollama 的局限性：它的并发处理能力不如 vLLM，高并发场景下需要排队。个人使用完全没问题，但做服务端部署要考虑这一点。

2. 128K 能跑，256K 要谨慎：虽然模型支持 256K，但双卡 32GB 跑满 256K 的 KV cache 会很紧张。128K 是实用、性价比平衡的档位。

3. 独立 llama-server 是 CPU-only：Ollama 0.30.6 附带的独立 llama-server 二进制是纯 CPU 编译的，没有 GPU 支持。但是通过 Ollama 本体调用时，CUDA 库会自动加载，GPU 加速正常。踩了这个坑才知道。

4. 下载需要有耐心：GFW 加持下 HuggingFace 的下载不太稳定，好在 GGUF 文件只有一个，不是 sharded 的多文件，续传机制靠谱。

未来计划

1. 跑一轮 BenchLocal，量化对比 QAT vs AWQ 的实际得分差距
2. 试试 MTP 草稿模型（speculative decoding），理论上可以再快 2-3x
3. 探索 Ollama 的并发优化配置，看能不能在高并发下进一步提升

最后

两年前要在本地跑一个 26B 级别的模型，需要至少一张 A100（80GB）。现在两张 32GB就够了，速度还很快。

技术进步的速度，比我们大多数人想象的要快。

如果你也在折腾本地部署，欢迎交流。

附：所有测试数据均在 Ubuntu 24.04, Ollama v0.30.6, CUDA 595.71.05 环境下测得。

往期相关

全系显存砍72%：Gemma 4 QAT深度拆解，本地部署门槛被踏平