写在前面
我之前发过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，直接就能用。
性能数据
最前面那句话的出处在这里：
| 首字时延 | 433 ms |
| 生成速度 | 156 tok/s |
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 做了对比：
| 训练级量化 | ||
| 156 tok/s | ||
| 9.8GB | ||
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，没注册投影文件。
修复：
从 HuggingFace 仓库下载 mmproj-F16.gguf（1.1GB）计算 SHA256，复制到 Ollama 的 blob 存储 修改模型 manifest，在 layers中插入application/vnd.ollama.image.projector层重启 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 调用
部署架构概览
一些真实的槽点
不是所有东西都完美，有几点值得说清楚：
Ollama 的局限性：它的并发处理能力不如 vLLM，高并发场景下需要排队。个人使用完全没问题，但做服务端部署要考虑这一点。
128K 能跑，256K 要谨慎：虽然模型支持 256K，但双卡 32GB 跑满 256K 的 KV cache 会很紧张。128K 是实用、性价比平衡的档位。
独立 llama-server 是 CPU-only：Ollama 0.30.6 附带的独立 llama-server 二进制是纯 CPU 编译的，没有 GPU 支持。但是通过 Ollama 本体调用时，CUDA 库会自动加载，GPU 加速正常。踩了这个坑才知道。
下载需要有耐心：GFW 加持下 HuggingFace 的下载不太稳定，好在 GGUF 文件只有一个，不是 sharded 的多文件，续传机制靠谱。
未来计划
跑一轮 BenchLocal，量化对比 QAT vs AWQ 的实际得分差距 试试 MTP 草稿模型（speculative decoding），理论上可以再快 2-3x 探索 Ollama 的并发优化配置，看能不能在高并发下进一步提升
最后
两年前要在本地跑一个 26B 级别的模型，需要至少一张 A100（80GB）。现在两张 32GB就够了，速度还很快。
技术进步的速度，比我们大多数人想象的要快。
