13 年前无 GPU 的 Xeon 服务器，竟能每秒 5 个词元速度运行 Gemma 4 26B！

在一台 13 年前无 GPU 的 Xeon 服务器上以每秒 5 个词元的速度运行 Gemma 4 26B

作者地下室里有一台约 13 年历史的改装后的 HP StoreVirtual 存储盒服务器，配备两颗 Ivy Bridge Xeon 处理器，无 GPU，原本用于存放磁盘。但从本周起，它能以每秒约 5 个词元的速度运行谷歌的 Gemma 4，这是一个拥有 260 亿参数的开放权重混合专家模型，此速度相当于阅读速度。

硬件为改装后的 HP StoreVirtual：双 Xeon E5 - 2690 v2（Ivy Bridge，2013 年），DDR3 内存，无 GPU；指令集仅支持 AVX1，不支持 AVX2 和 FMA3；模型是 Gemma 4 26B - A4B（混合专家模型），Q8_0 量化；解码速度约 5.2 个词元/秒；提示词评估速度约 16 个词元/秒；设备成本低于 300 美元。

任何人都可租用 GPU，但让现代混合专家模型在老旧企业级设备上运行不易，这也是作者写文章的原因。如今，“擅长人工智能”悄然变成“花钱订阅服务”，但作者认为真正的技能是了解模型、用其解决无现成解决方案的问题并判断答案是否正确。下面作者以这台本不该支持运行该模型的硬件为例详细说明。

故事的开端

几周前，一篇题为《你只需要一台 10 年前的 Xeon 服务器》的文章在 Hacker News 上广为流传。作者在一台 2016 年生产的、无 GPU 且配备 128GB 低速 DDR3 内存的单颗 Xeon 服务器上运行 Gemma 4，使用了 ik_llama.cpp 以及大约 25 个精心挑选的参数。这篇文章运用了现代推理中的各种技巧，是真正的技术实践。

作者心想自己也有 Xeon 服务器，实际上有好几台，于是尝试运行，但失败了。

AI 助手的真正价值

编译在启动时就失败了，作者把错误信息交给 Claude 询问原因，它很快给出答案。原来文章作者使用的 2016 年芯片是 Broadwell 架构，而作者的是 Ivy Bridge 架构，英特尔称为“v2”代。该分支中的快速内核假定支持 AVX2 和 FMA3 指令集，但这些指令集直到 2014 年的 Haswell（“v3”代）才开始支持，作者的 CPU 比代码所依赖的指令集老，无法执行优化路径。

作者接着问能否让它继续运行，之前用免费模型试过没成功，Claude 接过未完成方案，认为方向正确并完成后续工作。它重新编写关键路径，使代码在不支持 AVX2 的芯片上能顺利回退，不调用不存在的指令。

这才是作者关心的部分，不是简单输入“修复它”就能得到可用补丁，有人需阅读他人编写的对性能要求极高的 C++ 代码，找出内核在特定微架构上无法运行的原因，并在不丢弃优化效果的前提下绕过问题。Claude 完成这些工作，作者任务相对简单，运行正确实验并判断输出结果是否正确，这让作者印象深刻。

最终结果

现在，Gemma 4 的 26B 混合专家模型能在这台早在该模型架构出现之前就已淘汰的硬件上以阅读速度生成文本。原文章未公布每秒词元数，只提到“阅读速度”，这里给出具体数据：在这台有 13 年历史的芯片上，每秒大约能生成 5 个词元，而且成本几乎为零。

运行证明显示，仅使用 CPU 的地下室服务器上，Gemma 4 26B 正在作答。

若想查看具体的代码差异，补丁已提交，但在作者写文章时，该补丁仍在等待维护者审核，所以目前请从该分支运行代码。希望其他拥有老旧企业级硬件的人也能在本地运行模型，作为付费 API 不可用时的备用方案，或者在按词元付费不划算时，以低成本处理缓慢的批量任务。

问题根源揭秘

问题所在

需要的引擎是 ik_llama.cpp，它是 llama.cpp 的一个分支，添加了 Gemma 4 混合专家推理所需的优化，默认最低支持 AVX2 指令集。而这台服务器中的 Xeon E5 - 2690 v2 只支持 AVX1，不支持 AVX2。在编译时关闭 GGML_USE_IQK_MULMAT 选项后，大多数代码能正常处理，但有两个图操作例外。

Gemma 4 混合专家前馈网络会生成 MOE_FUSED_UP_GATE 和 FUSED_UP_GATE，这两个操作在计算调度器中由 #if 语句根据 GGML_USE_IQK_MULMAT 进行控制，但图构建器仍然会无条件地生成它们。在这个编译版本中，调度器的开关没有针对这些操作枚举的处理情况，所以它们会直接进入默认情况，每个专家前馈网络的目标张量就会默默地不被计算。Gemma 4 26B 每个词元有 30 层和 8 个活跃专家，所以每次前向传播都会消耗大约 240 个张量，而这些张量的值就是内存缓冲区中已有的数据。

问题表现为看起来流畅但实际上是多语言乱码。词元 ID 在 262K 的词汇表中均匀分布，模型可以随意输出泰文、韩文、 占位符或英语片段。在温度为 0 时结果是确定性的，单线程和多线程运行时字节完全相同，且没有 NaN 值。只是每个层的隐藏状态都会被一个大常量偏移，直到最后的 softmax 变得平坦。

正是这种确定性让问题得以解决。Claude 在采样前对原始对数概率进行了检测，打印出前 5 个词元以及范围、均值和 NaN 计数。这些数据暴露了问题：第一个预测词元的对数概率均值为 +16，而正常情况下应该接近零，大约 80% 的词汇表对数概率为正值。随机损坏不会出现这种情况，只有当隐藏状态的大部分是未初始化的内存且恰好包含小的正浮点数时，才会出现如此规律的偏差。

解决方案

在该分支的 main 分支基础上进行了三次提交：

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 保护，同时添加了一个缺失的包含项，以便 iqk_cpu_ops.cpp 可以独立编译。如果没有这些修复，该分支在不支持 AVX2 的硬件上根本无法编译。

2. 运行时错误修复：修复方案没有修改调度器，而是让图构建器生成在这个编译版本中有计算路径的操作。在 ggml_moe_up_gate 中，当 GGML_USE_IQK_MULMAT 关闭时：如果权重是组合的 up_gate_exps 张量，将其拆分为两个 ggml_view_3d 切片，分别运行两个 ggml_mul_mat_id 调用，然后使用 ggml_fused_mul_unary(gate, up, SILU) 进行组合。如果门控和上采样权重已经分开，则跳过拆分步骤，直接进行两个矩阵乘法和融合乘法一元操作。非混合专家层中使用的密集版本 ggml_fused_up_gate 也进行了相同的处理。涉及的每个操作都已经有一个可用的非 IQK 实现，整个更改都在 #if !GGML_USE_IQK_MULMAT 条件下进行，因此支持 AVX2 的编译版本与之前的版本保持位级一致。

3. CI 存根修复：iqk 源文件的 #else 存根部分与 iqk_mul_mat.h 不同步，导致 ci/run.sh 在不支持 AVX2 的硬件上无法编译，存在缺少 、存根的签名错误、有几个函数根本没有存根等问题，意味着链接时会出现未定义引用的错误。虽然这是一项繁琐的工作，但如果不进行修复，使用这种硬件的人就无法运行测试套件。

回退方案会有一定的代价，需要进行两次单独的矩阵乘法，而不是一次融合内核操作，但这台 CPU 的性能受限于内存带宽，而且融合内核仅支持 AVX2，所以并没有损失什么。最终，在 26B - A4B 混合专家模型上，实现了每秒约 5.2 个词元的解码速度和约 16 个词元的提示词评估速度。

还有一个问题需要注意。--run - time - repack 选项会在启动时将量化权重重新排序为仅支持 AVX2 的交错布局（Q8_0_R8），这会导致在支持 AVX1 的硬件上输出混乱。这是另一个独立的问题，补丁并没有尝试修复它，运行脚本只是去掉了这个选项。

指令集不匹配的问题很容易发现，但无声失败的问题却很难察觉。阅读代码时，明显的嫌疑对象都被排除，直到对对数概率进行检测，发现均值固定在 +16，长尾词元的概率大致相同，才将问题范围缩小到“残差流的大部分未初始化”。在调度器中搜索 #if GGML_USE_IQK_MULMAT，大约一分钟后就找到了两个缺失的情况。

复现步骤

如果有一台不支持 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 的硬件上输出混乱。

最终可以实现仅使用 CPU、无 GPU 的情况下每秒约 5 个词元的解码速度。

为何发布在公司博客

订阅服务很简单，但更重要的是愿意深入研究，阅读陌生人的代码，并不断尝试，直到让一台 13 年前的 CPU 完成它原本无法完成的任务。这和维护一个 15 年前的 Rails 应用，或者处理一个团队中已经没有人能理解的数据库是一样的，需要有人深入挖掘，找到问题的关键，以及工具本身不会告诉你的信息。

如果有闲置的不支持 AVX2 的硬件，并尝试了这个分支，作者很想知道它在硬件上的表现，PR 线程是反馈问题的合适地方。如果正在维护的是一个 15 年历史的 Rails 应用，而不是 13 年历史的 Xeon 服务器，可联系 hello@neomindlabs.com。

这台服务器本身的成本不到 300 美元，另外，让一台吵闹的企业级设备安静下来并能够启动本身就是一个项目。

由专业工程师撰写的关于 Rails 维护的不定期文章，无垃圾邮件，可订阅获取更多类似文章。

这是一家远程优先的公司，办公地点分布在费城、纳什维尔、弗吉尼亚和克利夫兰。探索超越传统维护的合作模式，与 Neomind 合作，体验积极主动、灵活适应且专注投入的服务，助力 Rails 应用持续取得成功。开启迈向不断发展、高性能 Rails 应用的旅程，可开启对话，联系 hello@neomindlabs.com，也可订阅时事通讯。

开发者的见解包括在一台 13 年前无 GPU 的 Xeon 服务器上以每秒 5 个词元的速度运行 Gemma 4 26B、300 美元的地下室服务器 vs 每月 1500 美元的云服务、修复一台 StoreVirtual 存储盒、杰文斯悖论在软件领域的体现、真正实现快速发展的唯一途径是稳健前行等内容。