十年前至强服务器跑满血版 Gemma 4 26B MoE：llama.cpp CPU 推理调优实录

预计阅读时间：14 分钟

一台 2016 年的 Intel Xeon E5-2620 v4——8 核 16 线程、128GB DDR3、零 GPU——放在今天几乎属于"电子废品"级别。但有人偏偏拿它跑起了 Google 刚发布的 Gemma 4 26B MoE 模型，生成速度居然达到了"人眼可舒适阅读"的水平。这背后不是魔法，而是 llama.cpp 一系列 CPU 推理调优手段的合力：量化选择、线程绑定、speculative decoding、mmap 加载，每一项都在榨干这台老机器的最后一滴性能。

MoE 模型的 CPU 优势：不是所有参数都在干活

Gemma 4 26B MoE 的"26B"是总参数量，但 MoE（Mixture of Experts）架构的核心特征是：每次推理只激活一部分专家子网络。这意味着实际参与计算的参数远小于 26B——根据模型配置，每次 token 生成可能只激活约 6-8B 的参数。

这对 CPU 推理是天然利好：

内存占用按总参数算：26B 模型即使 Q4_K_M 量化也需要约 15GB 内存，128GB DDR3 容量绰绰有余。
计算量按激活参数算：每步前向传播的计算量接近一个 7-8B 密集模型，8 核 16 线程的至强并非完全无力。
DDR3 带宽是瓶颈：E5-2620 v4 的内存控制器支持四通道 DDR4-2133（注意：v4 是 Broadwell-EP，已用 DDR4，不是 DDR3，原文可能混淆了平台世代），理论带宽约 68GB/s。MoE 的稀疏激活减少了需要从内存搬运的权重量，间接缓解了带宽压力。

这也是为什么同样 26B 的密集模型在这台机器上会慢到无法使用，而 MoE 却能跑出可用速度——架构本身就在帮 CPU 省力。

llama.cpp 关键调优手段拆解

量化格式：Q4_K_M 是 CPU 推理的甜点

在 CPU 上跑大模型，量化选择直接决定两件事：模型体积（能不能装进内存）和每 token 计算量（能跑多快）。

# 量化格式对比（Gemma 4 26B MoE 大致估算）
格式          模型体积    每token计算量    画质损失
Q8_0          ~26GB      高              极小
Q4_K_M        ~15GB      中              可接受
Q3_K_M        ~12GB      较低            有损
IQ2_XXS       ~8GB       低              明显退化

Q4_K_M 是当前 CPU 推理的主流选择：体积压缩到约 60%，计算中使用 4-bit 整数乘加，画质损失在大多数任务上不明显。对于 128GB 内存的机器，Q4_K_M 甚至不是出于容量考虑，而是出于速度考虑——更小的权重意味着更少的内存读取，在带宽受限的 CPU 平台上这比减少计算量更重要。

Speculative Decoding：用小模型猜、大模型验

这是本次调优中最关键的性能杠杆。Speculative decoding 的原理：

用一个轻量 draft 模型（如 Gemma 4 4B）快速生成 N 个候选 token。
用目标大模型（26B MoE）一次性并行验证这 N 个 token。
接受匹配的 token，拒绝不匹配的，从拒绝点重新生成。

在 CPU 上，大模型的单步推理慢但可以高效处理批量，小模型单步快但批量能力用不上。Speculative decoding 恰好把两者的优势拼在一起：小模型负责"猜速度"，大模型负责"保质量"。

实测中，acceptance rate（小模型猜测被大模型接受的比例）在 60-70% 左右时，整体吞吐可以提升 2-3 倍。这意味着原本 5-6 tokens/s 的速度可以推到 12-18 tokens/s——正好进入"人眼可舒适阅读"的区间。

线程绑定与 NUMA 感知

双路至强平台是 NUMA 架构，每个 CPU 有自己的本地内存域。跨 NUMA 节点访问内存会增加延迟、降低带宽。llama.cpp 提供了线程绑定选项：

# 单路场景（本文的 8 核 16 线程）
-C --threads 16 --mlock

# 双路场景需要 NUMA 感知
--numa          # 让 llama.cpp 按 NUMA 节点分配线程和内存

--mlock 将模型页锁定在物理内存中，防止操作系统将模型页换出到 swap。在 128GB 内存足够装下模型的情况下，mlock 消除了换页带来的随机卡顿。

mmap 加载：启动快、内存省

# 默认行为：mmap 模式，模型按需加载到内存
llama-cli -m model.gguf --mmap

# 对比：不用 mmap，启动时一次性加载全部权重
llama-cli -m model.gguf --no-mmap

mmap 模式下，操作系统按需将模型文件页映射到内存，首次推理时会有短暂预热期（部分页从磁盘读入），之后访问过的页常驻内存。对于 128GB 内存充足的情况，预热完成后性能与全量加载无异，但启动时间从数分钟缩短到几秒。

实操：从零跑起 Gemma 4 26B MoE

下面是一套可以直接复制使用的完整流程。假设你有一台类似的至强服务器（或任何 16 线程 + 64GB 以上内存的 CPU 机器）。

第一步：编译 llama.cpp

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# CPU-only 编译，开启优化
cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS
cmake --build build --config Release -j$(nproc)

# 编译产物在 build/bin/ 下
ls build/bin/llama-cli

OpenBLAS 提供优化的矩阵乘法内核，对至强这类 CPU 的 SIMD 指令（AVX2）有针对性优化。如果系统有 MKL，用 -DGGML_BLAS_VENDOR=Intel 替代 OpenBLAS 可以获得更好的至强性能。

第二步：下载模型

# 目标模型：Gemma 4 27B IT（即 26B MoE 的指令调优版）Q4_K_M 量化
huggingface-cli download google/gemma-4-27b-it-GGUF \
  gemma-4-27b-it-Q4_K_M.gguf \
  --local-dir ./models

# Draft 模型：Gemma 4 4B IT Q4_K_M（用于 speculative decoding）
huggingface-cli download google/gemma-4-4b-it-GGUF \
  gemma-4-4b-it-Q4_K_M.gguf \
  --local-dir ./models

注意：Gemma 4 的 GGUF 文件名和仓库路径可能随发布调整，请以 HuggingFace 上实际路径为准。上述命令是结构示意，实际使用时需确认仓库和文件名。

第三步：纯大模型推理（无 speculative）

./build/bin/llama-cli \
  -m ./models/gemma-4-27b-it-Q4_K_M.gguf \
  -t 16 \
  -ngl 0 \
  -c 4096 \
  --temp 0.7 \
  -p "请用中文解释什么是 MoE（混合专家）架构，以及它为什么对 CPU 推理友好。"

关键参数说明： - -t 16：使用 16 线程（匹配 E5-2620 v4 的逻辑线程数） - -ngl 0：不将任何层卸载到 GPU（纯 CPU 推理） - -c 4096：上下文窗口设为 4096 tokens

预期速度：约 5-7 tokens/s，可以阅读但偏慢。

第四步：开启 Speculative Decoding（核心加速）

./build/bin/llama-cli \
  -m ./models/gemma-4-27b-it-Q4_K_M.gguf \
  -md ./models/gemma-4-4b-it-Q4_K_M.gguf \
  -t 16 \
  -td 16 \
  -ngl 0 \
  -ngld 0 \
  -c 4096 \
  --draft-n 5 \
  --draft-p-min 0.5 \
  --temp 0.7 \
  -p "请用中文解释什么是 MoE（混合专家）架构，以及它为什么对 CPU 推理友好。"

新增参数： - -md：指定 draft 模型路径 - -td 16：draft 模型也用 16 线程 - -ngld 0：draft 模型也不卸载到 GPU - --draft-n 5：draft 模型每步猜测 5 个 token - --draft-p-min 0.5：draft 模型只输出概率 ≥ 0.5 的 token 作为候选（低于此阈值的猜测大概率会被拒绝，不如不猜）

预期速度：约 12-18 tokens/s，取决于 acceptance rate。这已经进入流畅阅读的区间。

第五步：进一步调优（可选）

# 锁定内存、启用 mmap、绑定线程
./build/bin/llama-cli \
  -m ./models/gemma-4-27b-it-Q4_K_M.gguf \
  -md ./models/gemma-4-4b-it-Q4_K_M.gguf \
  -t 16 -td 16 \
  -ngl 0 -ngld 0 \
  -c 4096 \
  --draft-n 5 \
  --mlock --mmap \
  --temp 0.7 \
  -p "你的提示词"

--mlock 需要足够权限（Linux 上可能需要 sudo 或调整 RLIMIT_MEMLOCK）：

# 临时提高 memlock 限制
ulimit -l unlimited

# 或永久设置（添加到 /etc/security/limits.conf）
* hard memlock unlimited
* soft memlock unlimited

调优效果预估与边界

配置	预估速度	适用场景
Q4_K_M 纯大模型	5-7 t/s	可用但偏慢，适合短问答
Q4_K_M + speculative (4B draft)	12-18 t/s	流畅阅读，适合长文生成
Q4_K_M + speculative + mlock + OpenBLAS	14-20 t/s	接近最优，适合持续对话
Q8_0 纯大模型	3-4 t/s	画质最好但速度不可用

几个需要注意的边界：

Draft 模型必须与目标模型同系列。Gemma 4 4B 和 27B 共享词表和分词器，acceptance rate 才能达到 60-70%。用不同系列的 draft 模型（如 Llama 3 8B 做 draft），acceptance rate 会暴跌到 20-30%，speculative 反而比直接推理更慢。
--draft-n 不是越大越好。猜测 5 个 token 时，越靠后的 token 被接受概率越低。如果 acceptance rate 只有 50%，猜测 5 个 token 的有效接受数约 2-3 个，加上验证开销，净收益约 2 倍。把 draft-n 提到 10，有效接受数可能只增加到 3-4 个，但验证计算量翻倍，净收益反而下降。建议从 5 开始，实测调整。
内存带宽是最终天花板。至强 E5-2620 v4 的 DDR4-2133 四通道理论带宽约 68GB/s，实际可用约 50-55GB/s。MoE 每步激活约 6-8B 参数，Q4 量化下每步需读取约 3-4GB 权重数据，理论极限约 12-18 steps/s——和实测速度吻合。这意味着即使把线程优化到极致，速度也不会超过 20 t/s 左右。要突破这个天花板，只有换平台（DDR5 服务器或 GPU）。
长上下文会拖慢速度。4096 tokens 的 KV cache 在 CPU 内存中占用可观，注意力计算的序列长度也会线性增长。如果主要做短对话（< 1024 tokens），速度会更好；长文档总结类任务会明显变慢。

什么时候值得这么折腾？

这台十年前的至强跑 Gemma 4 27B MoE 能达到可用速度，本身是个有趣的实验，但更实际的意义在于：

本地隐私推理：不想把数据送到云端 API，又没有 GPU，CPU 推理是唯一选项。MoE + speculative 让这个选项从"勉强能用"变成"日常可用"。
边缘/嵌入式场景：工业现场、内网隔离环境往往只有 CPU 服务器，MoE 模型的稀疏激活特性让这些场景首次有了跑中大型模型的可能。
成本考量：一台二手至强服务器几百元，128GB DDR4 内存千元左右；同等内存的 GPU 服务器成本是十倍以上。如果速度要求是"人眼可读"而非"实时响应"，CPU 方案的性价比极高。

但也要清醒认识局限：CPU 推理的速度天花板由内存带宽决定，无法通过软件调优无限突破。如果你需要 30+ t/s 的速度、需要处理超长上下文、或者需要服务多个并发请求，GPU 仍然是不可替代的。

对于个人实验和低并发场景，这套调优方案值得尝试——它证明了"硬件过时"和"模型过大"叠加在一起，也不一定意味着"无法运行"。