内存墙：十年前的至强就够了

cafkafk 在 point.free 上发表了一篇很有意思的实操记录：在一台回收来的旧服务器上跑 Gemma 4 的 26B 模型。这台机器的配置是 2016 年的 Xeon E5-2620 v4，8 核 16 线程，128 GB DDR3 内存，没有任何 GPU。

DDR3 的带宽大约是当今最快笔记本内存的五分之一。这颗 CPU 的算力也大概是现代笔记本的五分之一。按常理，这种配置跑 26B 参数的 LLM 是不现实的——用 ollama 直接跑根本不可能，即使用标准的 llama.cpp，速度也会慢到无法忍受。

但作者用了 25 个参数，把 ik_llama.cpp 的每一个优化杠杆都拉满了。最终的结果是：这台机器真的跑通了，速度甚至达到了"阅读速度"。

关键不是它跑通了，而是它揭示了 LLM 推理中一个经常被忽略的结构真相。

LLM 推理是内存带宽受限的，不是计算受限的。生成每个 token 时，系统必须把几十 GB 的权重矩阵从内存拖到 CPU 缓存里。处理器算得比内存搬得快，所以大部分时间计算核心都在等数据。这个瓶颈被称为"内存墙"——无论是在 DDR3 上还是在 H100 的 HBM 上，本质问题完全一样。

那为什么这台老机器能跑？因为作者用的不是暴力计算，而是对内存访问模式的系统性优化。

推测解码是其中最重要的一环。它用小 drafter 模型先猜最多 3 个 token，然后用 26B 的 verifier 模型一次性验证。在 CPU 上这个策略特别有效：drafter 的工作集完全放进 L3 缓存，验证器虽然会溢出，但因为它只需要做一次前向传播而不是逐个 token 推理，整体吞吐量反而提升了。在 GPU 上推测解码也有价值，但在 CPU 上更显著——因为 CPU 的算力相对于内存带宽更"便宜"，花额外周期让小 drafter 猜 token 的边际成本很低。

还有运行时重排。它会在启动时把权重矩阵在内存中重新排列，以匹配 CPU 的缓存布局。默认情况下权重矩阵按通用 GPU 使用场景存储，CPU 读取时会产生大量缓存缺失。重排后，数据按 CPU 期望的形状和大小组织，一次性读取的效率大幅提升。日志显示重排了 265 个张量。

MoE 路由优化针对的是缓存抖动。Gemma 4 26B 有 128 个专家，每 token 激活 8 个。如果不加优化，CPU 要在 128 组权重之间频繁跳转，不断清空缓存重新从 DDR3 拉数据。--cpu-moe 让路由更聪明地组织专家调度顺序，尽量让权重在 CPU 的本地缓存里停留。--merge-up-gate-experts 把两个 per-expert 的投影融合成一次矩阵乘法，减少了一次跨内存总线的数据传输。

内存锁 --mlock 防止系统把 27 GB 的模型换页到磁盘——一旦触发 swap，生成速度会瞬间归零。这是一个 ulimit 配置问题，不是 LLM 问题。大多数黑盒工具根本不会暴露这个参数，默认就让内核自己决定要不要 swap。

把这些优化放在一起看，一个更深层的问题浮出水面。

我们习惯了把 AI 能力等同于拥有最新 GPU。但真正决定你能做什么的，不是硬件的代际，而是你对底层机制的理解深度。懂内存墙的人，在老机器上也能让模型跑起来。只懂 ollama 的人，换了新卡也只能用默认配置。硬件差距可以用知识弥补，但知识差距没有硬件能弥补。

这篇文章的作者 eza 的创作者，NixOS 指导委员会成员。他不是 AI 研究员，而是系统工程师。他解决 LLM 推理问题的方式跟解决文件系统问题是一样的：看数据怎么流动，找瓶颈，优化布局。

这个视角的迁移本身就有意义。当 LLM 推理变成工程问题而不是算法问题时，最擅长的人不是那些训练模型的人，而是那些理解内存、缓存和调度的人。这是一个安静的权力转移——从算法研究者到系统工程师。AI 的未来不只在模型参数里，也在内存总线和 CPU 缓存中。