一名开发者在 6 月 1 日发布的技术文章中，展示了如何把 Google Gemma 4 26B-A4B 的 MTP drafter/verifier 组合跑在一台没有 GPU 的旧服务器上。这台机器使用 2016 年的 Intel Xeon E5-2620 v4，8 核 16 线程，128GB DDR3 内存，只支持 AVX2，没有 AVX-512、VNNI 或 BF16。
这件事的价值不在于证明旧 Xeon 能和现代 GPU 对打。它更像一次边界测试：当大模型推理越来越被默认绑定到 NVIDIA GPU 和 HBM 内存时，CPU 老硬件是否还能靠足够内存、MoE 稀疏激活、投机解码和推理引擎细调，换来“可运行”的本地能力。
旧服务器能跑，瓶颈主要不是算力
Gemma 4 26B-A4B 是 MoE 结构，约 128 个 experts，每个 token 激活 8 个 experts。原文给出的有效激活规模约为 3.8B 参数，而不是每一步都动用完整 26B 级别权重。这是旧 CPU 有机会参与游戏的前提。
但真正卡住它的不是“CPU 不会算”，而是内存带宽。LLM 解码阶段是一个 token 接一个 token 地生成，每一步都要从内存搬运大量权重。DDR3 的带宽远低于今天的 DDR5，更不用说 GPU 上的 HBM。CPU 经常不是在满负荷计算，而是在等数据穿过内存总线。
| 项目 | 这台旧服务器 | 对推理的影响 |
|---|---|---|
| CPU | Xeon E5-2620 v4，8 核 16 线程 | 只能依赖 AVX2，缺少新指令加速 |
| 内存 | 128GB DDR3 | 容量够大，带宽偏弱 |
| GPU | 无独显，无核显 | 无法做常见 GPU offload |
| 模型 | Gemma 4 26B-A4B MoE | 稀疏激活降低每 token 实际负担 |
这也解释了为什么普通“能加载模型”和“能舒服使用”之间差距很大。对本地大模型玩家来说，容量只是门票，内存带宽和引擎实现才决定体验下限。
真正起作用的是一整条优化链
原文中最关键的命令不是模型文件名，而是一串参数：--spec-type mtp、--cpu-moe、--merge-up-gate-experts、--run-time-repack、--mlock、--flash-attn on。这些参数共同把问题从“硬件太老”改写成“尽量少搬、尽量顺着缓存搬、尽量提前猜中”。
MTP 投机解码让小 drafter 先预测最多 3 个 token，再由 26B verifier 校验。CPU 上这类方法更有意义，因为 verifier 反复扫权重的代价很高，而小模型的额外计算相对便宜。
--cpu-moe 和 --merge-up-gate-experts 则是为了 MoE 在 CPU 缓存里少乱跳。前者针对 CPU cache 层级优化专家路由，后者把 expert 内部的 up/gate 投影合并，减少内存往返。--run-time-repack 会在启动阶段重排权重矩阵，让后续计算更贴合 CPU 访问模式；--mlock 则尝试把模型锁在内存里，避免被系统换到磁盘。
这里有一个容易被忽略的限制：这些开关不是按下就一定生效。原文提到 -sm graph 在 Gemma 4 external MTP 组合下不受支持，实际会降级为 layer split。--mlock 也可能被 Linux 的 RLIMIT_MEMLOCK 限制挡住。换言之，这不是给普通用户的开箱教程，而是给愿意读日志、改 ulimit、反复 benchmark 的工程师路线。
黑盒工具方便，但未必暴露足够底层旋钮
Ollama、标准 llama.cpp 这类工具让本地模型部署简单了很多，这也是它们流行的原因。但在这次实验里，作者选择 ik_llama.cpp，原因并不是“黑盒工具不能跑任何模型”，而是对 Gemma 4 26B-A4B MTP 这类组合，通用工具未必及时支持模型结构，也未必暴露足够多的 CPU/MoE/投机解码参数。
这反映了本地推理生态的一个分岔：普通用户需要少配置、少出错；极限硬件玩家需要更多不稳定但有效的底层控制。两者并不矛盾，只是目标不同。
受影响最直接的是两类人。一类是手上有旧服务器、预算买不起 GPU 的开发者，他们会重新评估“闲置内存机器”能不能承担低频本地推理、实验和数据处理任务。另一类是做推理引擎和量化工具的人：模型支持速度、MoE CPU kernel、Flash Attention CPU 实现、投机解码接口，都会变成竞争点。
接下来最该看的不是某个漂亮跑分，而是三个变量：ik_llama.cpp 这类引擎能否把 graph split 与 external MTP 组合补齐；Gemma 4 相关 GGUF 和量化链路是否稳定；以及在真实长上下文、并发和多轮对话下，旧 CPU 的延迟是否仍能被接受。原文没有给完整 tokens/s 或 benchmark 数字，任何“旧 Xeon 反超 GPU”的解读都越过了证据。