某个读者可能觉得不可能的场景：一台 2013 年的 HP StoreVirtual 存储服务器，双路 Xeon E5-2690 v2（Ivy Bridge），只有 DDR3 内存、没有 GPU、CPU 指令集只到 AVX1。这种机器在 eBay 上大概 $300 就能收到。但就是这台机器，现在以约 5 tok/s 的速度运行着 Google 的 Gemma 4 26B-A4B——一个 260 亿参数的 MoE 模型。
这个结果的实现过程本身比数字更有意思。
硬件约束与解决思路
Ivy Bridge 是 Intel 2013 年的架构，AVX1 是它能用的最宽的 SIMD 指令集。AVX2 和 FMA3 要等到 2014 年的 Haswell 才有。而今天主流推理框架（llama.cpp、ik_llama.cpp）里的 CPU kernel 几乎都默认针对 AVX2 编译——这意味着 2014 年以前的 CPU 根本跑不了这些优化好的路径。
文章作者一开始直接拿 ik_llama.cpp 跑，启动就崩。报错信息指向 AVX2 指令不存在。
（配图：Gemma 4 模型架构图，Google AI Blog 展示的 MoE 设计）
解决过程
作者把报错信息扔给 Claude，让它帮忙分析。Claude 很快定位到问题：特定 CPU kernel 假设了 AVX2 指令集可用，但 Ivy Bridge 上没有。需要改的是那些 hot path——把 AVX2 的 kernel 替换成 AVX1 兼容的 fallback 实现，同时尽可能保留其他优化。
这个过程不是一句"帮我修好"就完成的。需要有人读懂别人的 C++ 性能关键代码，理解为什么这个 kernel 在当前微架构上无效，然后绕过它而不丢弃这个 fork 的其他优化。Claude 完成了 C++ 改写的部分；作者的角色是跑实验验证输出是否正确，以及决定哪些优化路径可以保留。
最终结果是一套能在 AVX1-only 的 CPU 上正常运行的 ik_llama.cpp 版本。
实测数据
模型：Gemma 4 26B-A4B（MoE），Q8_0 量化
硬件：双路 Xeon E5-2690 v2（10 核/20 线程 each），DDR3-1600，无 GPU
Decode：约 5.2 tok/s（相当于阅读速度）
Prompt eval：约 16 tok/s
整机成本：约 $300（二手服务器）
部署层面的几点思考
-
硬件门槛已经很低。一台 $300 的旧服务器就能跑 26B 量级的 MoE 模型。对团队做模型试验、离线批量推理、或者搭建内部 demo 来说，GPU 不再是必要条件。
-
CPU 推理的经济账。5 tok/s 对实时对话不够，但对批量任务（文档处理、评分、离线分类）完全够用。双路 Xeon 满载约 300W，每天电费约 $1.35。对比云端 API 按 token 计费，持续运行的批量处理场景，CPU 自推在成本上有计算空间。
-
指令集兼容性是 CPU 推理中的隐藏问题。大部分推理框架针对 Haswell+（AVX2）优化，但企业退役的服务器很多是 Ivy Bridge 或更早。如果要利用这些低成本旧硬件，需要关注 AVX1 兼容性。这个 case 证明：只要有合适的 fallback 实现，较老的 CPU 一样能跑。
-
AI agent 辅助调试底层推理栈的能力已经实用。不是简单的"修 bug"，而是理解微架构差异、改 hot path、保持已有优化不被丢弃——这种级别的 C++ 改写，Claude 能完成大部分工作。
内容来源
neomindlabs.com 上的那篇文章（HN 289 upvote / 187 条评论）
“A 10 year old Xeon is all you need”——2016 Xeon 上跑 Gemma 4 的早期尝试
ik_llama.cpp——ikawrakow 维护的 llama.cpp fork，对 CPU 推理做了大量优化