在13年历史的Xeon无GPU服务器上以每秒5个token运行Gemma 4 26B

# 在13年前的至强处理器上以每秒5 token运行Gemma 4 26B，没有GPU 来源：https://www.neomindlabs.com/2026/06/08/running-gemma-4-26b-at-5-tokens-sec-on-a-13-year-old-xeon-with-no-gpu/ 我家地下室有一台服务器，按理说它完全没资格运行现代语言模型。这是一台翻新的HP StoreVirtual存储设备，大约十三年前的产品，两颗Ivy Bridge至强处理器，没有GPU。它本来是用来放磁盘的，不是用来做计算的。而就在本周，它运行了Google的 [Gemma 4](https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/) —— 一个260亿参数、开放权重的混合专家模型，速度大约是每秒5个token。阅读速度。 ## 硬件 - 翻新HP StoreVirtual：双路Xeon E5-2690 v2（Ivy Bridge，2013），DDR3内存，无GPU - 指令集：仅支持AVX1 —— 无AVX2，无FMA3 - 模型：Gemma 4 26B-A4B（MoE），Q8_0量化 - 解码速度：~5.2 tokens/sec - 提示词评估：~16 tokens/sec - 整机成本：不到300美元 任何人都能租到GPU。但要让一个现代的MoE模型与一台废弃的企业级设备相互配合，这更难。正是这个差距促使我写下这篇文章。“擅长AI”在不知不觉中变成了“愿意为订阅付费”。我认为真正的技能是不同的：足够了解一个模型，能够将它指向一个没人为你打包好的问题，并且判断返回的答案是否正确。所以我不会声称我们在这方面很厉害，而是提供一个具体的实例，用的是根本没有资格配合的硬件。 ## 那篇开启一切的帖子 几周前，一篇名为 [“A 10 year old Xeon is all you need”](https://point.free/blog/gemma-4-on-a-2016-xeon/) 的文章在Hacker News上流传。作者使用单个2016年的至强处理器，无GPU，128 GB慢速DDR3内存，通过 `ik_llama.cpp`（https://github.com/ikawrakow/ik_llama.cpp）和大约25个精心挑选的flag来运行Gemma 4。读起来很棒，它利用现代推理方案中的每一个技巧：推测性解码、CPU感知的混合专家路由、移植到CPU的Flash Attention、运行时权重重打包。真正的工程。 “我也有至强处理器，”我想。实际上有好几个。所以我尝试了。但它没有运行。 ## AI代理真正擅长什么 构建在启动时就失败了。我把失败交给Claude并询问问题所在。答案迅速而具体地回来了。作者的2016年芯片是Broadwell架构。我的芯片是Ivy Bridge，也就是英特尔称为“v2”的那一代。该分支中的快速内核假定有AVX2和FMA3指令集，而这些直到Haswell（“v3”代，2014年）才推出（https://www.microway.com/hpc-tech-tips/avx2-optimization-and-haswell-ep-cpu-features/）。我的CPU比这些指令集对应的代码还要老。优化路径根本无法执行。 所以我问了显而易见的后续：我们能否让它无论如何都能运行？我之前已经用免费模型进行过第一次尝试，接近目标但没能成功。Claude接过了这个半成品的方案，同意这是正确的方向，并完成了它，重新编写了热点路径，使其能在不支持AVX2的芯片上干净地回退，而不是去访问那些不存在的指令。 这是我在乎的部分。这并不是键入“修复它”一次就能得到一个可工作补丁。必须有人阅读别人性能关键的C++代码，找出某个内核在特定微架构上无效的原因，并在不丢弃使该分支值得使用的优化的情况下绕道而行。Claude完成了这项工作。我的任务更窄：运行正确的实验，并识别出输出什么时候最终是正确的。我对结果印象深刻。 ## 结果 Gemma 4的260亿参数混合专家模型现在以阅读速度在硬件上生成文本，而该硬件在模型架构存在之前就已经退役。原始文章从未发布过每秒token的具体数字，只说了“阅读速度”，所以这里给出具体数字：在十三年前的硅片上大约每秒5个token，几乎免费。 *证明它能运行：地下室服务器上Gemma 4 26B用CPU回答。* 补丁以 [ikawrakow/ik_llama.cpp#2138](https://github.com/ikawrakow/ik_llama.cpp/pull/2138) 的形式发布，如果你想要确切的差异 —— 在我写这篇文章时它仍然开放并等待维护者审查，所以现在从分支运行它。希望任何还在使用古老企业级硬件的人都能在本地保留一个模型：当付费API宕机时的备用方案，或者当按 token 付费不划算时用于低速批处理任务的廉价方法。 ## 给真正想要看实际bug的人 在我继续之前，先完全披露。我不是C++程序员。我能读懂堆栈轨迹（stack trace），也熟悉构建系统，但我没有手写量化矩阵乘法引擎的内核回退，也不会假装我写了。我所做的是驱动。我运行实验，读取输出，提出下一个问题，并且知道“正确”必须是什么样子。诊断和补丁来自运行在服务器上的Claude实例。我请它写下它修复了什么，本节剩下的部分就是那份总结，经过轻微编辑。如果你从Hacker News来，想看真正的拆解分析，这部分就是给你的。 ### 实际出了什么问题 我们需要的引擎是 `ik_llama.cpp`，ikawrakow对 `llama.cpp` 的分支，添加了Gemma 4的MoE推理所依赖的优化。它假定AVX2是最低要求。这个盒子里的Xeon E5-2690 v2有AVX1但没有AVX2。在构建时关闭 `GGML_USE_IQK_MULMAT`，大部分代码库会尊重这一点：快速路径被编译掉，模型回退到纯标量/SSE数学计算。对于普通的Q8_0矩阵乘法来说这没问题。但有两个图操作是例外。 Gemma 4 MoE前馈网络发出 `MOE_FUSED_UP_GATE`（每个专家的gate+up矩阵乘法与SwiGLU融合）和 `FUSED_UP_GATE`（其密集版本）。两者在计算调度器中都被 `#if GGML_USE_IQK_MULMAT` 守卫，但图构建器仍然无条件地发出它们。在这个构建中，调度器的switch没有这些操作枚举的case，所以它们落到默认分支，每个专家FFN的目标张量默默地从未被计算。Gemma 4 26B有30层，每层8个活跃专家，所以每次前向传播大约消耗240个张量，这些张量恰好是那个内存缓冲区中已有的内容。 症状看起来像流利的多语言胡言乱语。Token ID均匀分布在262K词汇表上，模型同样愿意输出泰文、韩文、哨兵token或英文片段。温度0时确定性，单线程和多线程运行之间字节相同，任何地方都没有NaN。只是每一层隐藏状态被一个大的常数推动，直到最后的softmax变得平坦。 正是这种确定性让我们破解了它。Claude在采样前对原始logits进行检测，打印前5个token以及范围、均值和NaN计数。数字出卖了它：第一个预测token的logit均值是+16（应该接近零），大约80%的词汇表具有正的logits。随机损坏不会看起来那样。一个如此干净的偏差只可能发生在大块隐藏状态是未初始化内存，而其中恰好包含小的正浮点数时。 ### 修复 在分支的 `main` 之上提交了三个commit。 1. **编译修复。** `iqk_quantize.cpp` 中 `quantize_row_q8_0_x4` 和 `quantize_row_q8_1_x4_T` 的标量 `#else` 分支实际上并不是标量的。它们仍然引用了 `hsum_i32_8` 和其他AVX2辅助函数。这些被重写为可移植的标量循环，并在 `ggml.c` 和 `ggml-quants.c` 中添加了少量漏掉的IQK调用周围的 `#if GGML_USE_IQK_MULMAT` 守卫，另外还缺少一个include以便让 `iqk_cpu_ops.cpp` 独立编译。没有这些，该分支在非AVX2硬件上根本无法构建。 2. **运行时bug。** 修复没有修改调度器，而是让图构建器发出在这个构建上有计算路径的操作。在 `ggml_moe_up_gate` 中，当 `GGML_USE_IQK_MULMAT` 关闭时：如果权重是组合的 `up_gate_exps` 张量（形状 `[n_embd, 2*n_ff, n_experts]`，前半部分是gate，后半部分是up），则将其分割成两个 `ggml_view_3d` 切片，运行两次单独的 `ggml_mul_mat_id` 调用，并用 `ggml_fused_mul_unary(gate, up, SILU)` 合并它们。如果gate和up已经是分离的权重，则跳过分割，执行同样的两次mul-mat-ID加上融合的mul-unary。非MoE层中使用的密集版本 `ggml_fused_up_gate` 也做同样的处理。涉及到的每个操作都已经有可工作的非IQK实现（`mul_mat_id` 是标准ggml，`fused_mul_unary` 一次性完成SILU和乘法）。整个更改位于 `#if !GGML_USE_IQK_MULMAT` 之后，因此AVX2构建保持与之前完全一致。 3. **CI存根。** iqk源的 `#else` 存根部分与 `iqk_mul_mat.h` 不同步，导致 `ci/run.sh` 甚至无法在非AVX2硬件上构建：缺少一个 `#endif`、存根函数签名错误（这里多了一个前导参数，那里缺少 `sinks`），以及一些函数根本没有存根，导致链接时未定义的引用。乏味的工作，但没有这些，任何人都无法在此硬件上运行测试套件。 回退是有代价的：用两次单独的matmul-ID代替一个融合的内核。但是这个CPU本身受内存带宽限制，而融合内核仅限于AVX2，所以我们并没有损失什么。端到端我们在26B-A4B MoE上获得约5.2 tok/s的生成速度和约16 tok/s的提示评估速度。 还有一个陷阱。`--run-time-repack` 在启动时将量化权重重排成仅AVX2的交错布局（`Q8_0_R8`），这会在AVX1上以相同方式扰乱输出。那是另一个bug，补丁没有尝试修复它。运行脚本只需弃用这个flag。 指令集不匹配很容易发现。无声的fall-through则不然。阅读代码不断清除明显的嫌疑：RMSNorm辅助函数看起来正确，`ggml_vec_dot_q8_0_q8_0` 中的AVX1回退看起来正确，而位一致的单线程运行排除了线程问题。只有在检测了logits，看到均值固定在+16且所有长尾token大致相等之后，搜索才缩小到“一大块残差流未初始化”。在调度器中grep `#if GGML_USE_IQK_MULMAT` 大约一分钟后发现了这两个缺失的case。 ### 复现 如果你有一个不支持AVX2的盒子并想尝试： - **硬件：** 双路Xeon E5-2690 v2（Ivy Bridge，AVX1，无AVX2），DDR3，无GPU。 - **构建：** 从上面的分支编译 `ik_llama.cpp`，并关闭 `GGML_USE_IQK_MULMAT`。编译修复正是让它能在非AVX2硬件上构建的关键。 - **模型：** Gemma 4 26B-A4B，Q8_0量化。 - **运行：** 使用常见的 `ik_llama.cpp` CPU标志，但弃用 `--run-time-repack`（它会在启动时将权重重排成仅AVX2的布局，并在AVX1上再次扰乱输出）。 这就是完整的配方：大约5 tok/s生成速度，仅CPU，盒子里根本没有GPU。 ## 为什么这出现在公司博客上 订阅是容易的部分。其余部分是愿意打开引擎盖，阅读别人的代码，不断提问，直到一台十三年前的CPU做了一件它永远不该做的事情。这与一个十五年的Rails应用或一个团队中没人再懂的数据库需要做的工作相同：有人会深挖直到找到杠杆作用点，以及工具本身不会告诉你的事情。 如果你有积灰的预AVX2设备并尝试了这个分支，我很想听听它在你的硅片上表现如何——它能下探到多老的CPU世代？[PR讨论串](https://github.com/ikawrakow/ik_llama.cpp/pull/2138) 是提交bug报告的正确地方。而如果你正在维护的是一个十五年的Rails应用而不是一台十三年的至强，那就是 [我们谋生的方式](mailto:[email protected])。 --- *给好奇者的一些提示。这台服务器本身花费不到300美元；[这里解释了为什么地下室盒子胜过每月1500美元的云服务](https://www.neomindlabs.com/2026/06/07/300-dollars-in-the-basement/)。而让一台尖叫的企业级设备安静且可启动本身就是一个项目，[为喜欢这类事情的人记录在此](https://www.neomindlabs.com/2026/06/06/restoring-a-storevirtual/)。*