一台2013年出厂的双路Xeon E5-2690 v2服务器,本来是HP StoreVirtual存储阵列里的备件,没有GPU,内存是DDR3,网上淘来花不到300美元。就是这么一台十三岁的"存储盒子",最近跑通了Google今年发布的Gemma 4 26B混合专家模型,解码速度到了每秒5.2个token,大致是正常人阅读的速度。

这事真正值得写的地方,不是老硬件又秀了一次肌肉——网上这类"复古硬件跑大模型"的帖子每隔一阵就有一篇。值得写的是它是怎么跑通的:作者不会写C++,修复代码的是Claude。

指令集差了一代,模型直接输出乱码

故事的起点是Hacker News上一篇题为《A 10 year old Xeon is all you need》的热文,作者用2016年的Broadwell架构Xeon加128GB DDR3跑Gemma 4,拿到了"阅读速度"的效果。本文作者手里也有Xeon,型号更老——Ivy Bridge,Intel内部代号"v2",2013年的产品。他照着帖子里的方案跑了一遍,直接报错退出。

问题出在指令集上。这类CPU推理项目普遍依赖的高速内核默认要求AVX2和FMA3——这两套指令集直到2014年的Haswell("v3"代)才随芯片一起出现。Ivy Bridge只有更老的AVX1。换句话说,代码是照着比这台机器年轻一代的芯片写的,跑不起来不是bug,是CPU压根没有对应的指令。

关掉AVX2优化开关后,大部分代码能老实回退到标量运算,唯独两个MoE前馈网络里的融合算子——MOE_FUSED_UP_GATEFUSED_UP_GATE——被写死在AVX2分支里,计算图却仍然无条件生成这两个节点。结果是每次前向传播里,大约240个专家网络的输出张量根本没被计算,只是读了内存里本来就在那儿的脏数据。模型照样往外吐字,句子看起来通顺,实际上是全词表均匀分布的高质量胡言乱语,中文、泰文、韩文乱蹦,只是因为温度设为0所以每次错得一模一样。

Claude靠打印logits的均值和分布把这个问题揪出来:正常应该接近零的均值,跑出来常年卡在正十几,八成以上的词表概率都是正的——典型的"一大块隐藏状态是未初始化内存"的特征。定位到问题后,修复思路没有去碰底层调度器,而是让计算图在没有AVX2的机器上,改用两次已经存在的标准矩阵乘法加一次融合SiLU运算去拼出同样的结果,绕开那两个从未被执行过的分支。

会用AI,不是会订阅,是会诊断。
这台服务器的四个数字 13年 Ivy Bridge Xeon 2013年发布 <$300 整机成本 报废存储阵列 5.2 tokens/秒 解码 Gemma 4 26B MoE 2 处融合算子被锁死 AVX2指令集

MoE省的是算力,不是内存

Gemma 4这个"26B"的命名容易让人误会。Google官方口径里,它总参数约25.2B,但每个token只激活约3.8B参数——这就是名字里"A4B"的来源。架构上是128个专家里选8个,再加1个常驻的共享专家。

问题是,MoE省下来的只是每个token的计算量,不是内存占用。哪个专家会被选中是逐token动态决定的,所以全部128个专家的权重都得常驻内存,一个都不能卸载。按Google给出的数字,Q8_0量化下模型大约要吃掉近30GB内存。这台老服务器能扛住,靠的不是CPU多快,是它原本作为存储阵列留下的大内存插槽——这恰好是GPU的软肋:显存贵、扩不动,内存便宜、插得多。

这也是为什么这类"报废企业级硬件+大内存"的玩法这两年在CPU推理爱好者圈子里越来越常见:MoE架构天生就更适合内存带宽型机器,而不是显存受限的GPU。

  • 结论.真正稀缺的资源换了一个,从显存变成内存,这让一批本该进废品站的旧服务器有了第二次利用价值。

5.2 tokens/秒,放到坐标系里什么水平

单独看"5.2 tokens/秒"没有参照系,容易被"阅读速度"这种模糊说法带偏。Hacker News上另一个案例可以拿来对比:一台配了8通道DDR5-6400内存、代际比这台Xeon新得多的Xeon W5-3435X,跑DeepSeek R1 70B(Q8量化)时,速度大约只有每秒1个token。

两边模型规模、量化方案都不一样,不能算严格对照,但至少给了一个量级参照:十三年前的老古董靠更小的激活参数量和一处指令集修复,速度反而比更新的机器跑更大模型快出好几倍。

CPU推理速度对照(tokens/秒) 本机解码 Gemma 4 26B MoE 5.2 本机提示词处理 16 新款Xeon+DDR5-6400 跑70B模型 1 模型规模与量化方案不同,仅作速度量级参照

这个数字对谁有用,边界也很清楚。它对手上有闲置企业级旧机、想找个离线跑模型的备用方案,或者要跑不在乎延迟的批量任务的人有意义——省下的是按token计费的钱。对追求实时对话体验的用户,5 tokens/秒的老古董没有实用价值,该用云端还是用云端。

  • 提醒.修复补丁ikawrakow/ik_llama.cpp#2138目前仍是open状态,还没被上游合并,照着复现之前得有心理准备。

补丁能不能被维护者接受,还要看社区愿不愿意为一批更老的CPU背上额外的维护成本。但这次事情本身已经说明一件事:诊断一段陌生代码里的架构级bug、追问到底、判断答案对不对,这套能力和会不会写C++是两码事——后者决定你能不能自己动手改,前者决定你知不知道该改哪。