2016年的Intel Xeon E5-2620 v4服务器，8核16线程、128GB DDR3内存、没有任何GPU——这样的硬件配置在今天看来已经相当落伍。但一位开发者偏偏要用这台"10年前的服务器"运行Google最新发布的Gemma 4 26B MoE模型，结果出乎意料：推理水平达到了"人眼可阅读"的生成速度。

作者使用的llama.cpp命令行工具，通过speculative decoding、CPU MoE路由优化、Flash Attention等一系列开关，让10年前的服务器硬件"榨干"了模型的性能潜力。

Gemma 4 26B-A4B是一个混合专家模型（MoE），总参数量260亿，但每次推理只激活其中4位专家，实际调用约70亿参数。MoE架构本就是为低资源场景设计——问题是，市面上的主流工具链对此支持并不完善。Ollama至今没有添加这个模型的支持，标准llama.cpp也缺少足够的调优选项。作者转向了ik_llama.cpp，这是llama.cpp的一个社区分支，包含了更多高级优化选项。

要在DDR3这种慢速内存上跑LLM，关键在于理解"内存墙"问题。LLM推理是内存带宽受限的场景，而非计算受限——处理器计算速度远快于数据从内存搬到缓存的速度。以ChatGPT为例，用户看到token一个个蹦出来，这个解码过程的核心瓶颈是内存带宽，而非CPU算力。任何试图提升推理速度的优化，都必须围绕减少内存带宽压力展开。

ik_llama.cpp暴露了约25个优化开关，作者逐一调校出了最佳组合。Speculative Decoding with MTP drafters是其中最关键的一项：用一个轻量的小模型（MTP）预测接下来几个token，再用主模型验证这些预测。正确预测的token可以"跳步"——这相当于在内存带宽受限的条件下，用计算换带宽。CPU MoE路由优化则确保每次推理只激活4位专家，而非全量调用260亿参数。--mlock参数将KV cache锁定在物理内存中，避免被交换到磁盘，这对于DDR3这种本身就慢的内存类型尤为关键。

KV cache repacking是另一个关键优化。随着对话长度增加，KV cache会产生大量碎片——而访问碎片化的内存远比连续块访问慢得多。定期repacking可以保持内存访问的局部性。Flash Attention和Multi-Head Latent Attention实验内核也在作者的测试清单中——这些原本为GPU设计的优化，在CPU推理场景下同样有效。

测试硬件规格：Intel Xeon E5-2620 v4 @ 2.10GHz，8核16线程，支持AVX2但不支持AVX-512或BF16，128GB DDR3内存，无GPU。作者没有给出具体token/s数字，但强调生成速度已达到"reading speed"——即人眼可阅读的速度，而非需要等待几十秒才有响应的"卡顿"状态。

作者认为，真正的门槛从来不是硬件算力，而是对推理引擎的掌握深度。开源权重模型有"可用性护城河"：大量优化选项没有被文档化，默认参数隐含了性能陷阱，各种封装工具屏蔽了底层细节。理解这些"25个flags"背后的逻辑，比购买一块H100或H200更实际。这篇文章的核心价值在于：它展示了一条可复制的路径——用消费级乃至企业级老旧硬件，通过精细调优，同样可以运行SOTA级模型。

参考来源：https://point.free/blog/gemma-4-on-a-2016-xeon/