一台十年前的 Xeon 服务器如何运行 26B 大模型？

背景

在之前的讨论中，我们介绍了如何将 Gemma 4 的 MTP（Multi-Token Prediction，多令牌预测）草稿模型进行量化，并将其与验证器（Verifier）配对。而本文的重点在于：如何在完全没有 GPU、且硬件配置极其陈旧的机器上运行这一组合。

作者拥有一台回收的服务器，其硬件配置如下：

• CPU：Intel Xeon E5-2620 v4（2016年发布），主频 2.10 GHz。
• 内存：128 GB DDR3。
• GPU：无（且 CPU 无集成显卡）。

这台机器的内存速度仅为当前顶级笔记本内存的 1/5 到 1/6，CPU 性能也比现代笔记本慢约 5 倍。对于大语言模型（LLM）推理而言，内存带宽通常是最大的瓶颈。传统的工具如 ollama 或标准的 llama.cpp 默认配置无法在这种硬件上高效运行，因为它们缺乏针对这种极端场景所需的底层优化，且 ollama 等黑盒工具暴露的控制参数不足。

因此，作者决定深入 llama.cpp 的底层，通过手动调整每一个可能的优化参数，让这台“过时”的机器能够运行 Gemma 4 26B-A4B 模型。

核心内容

1. 理解性能瓶颈：内存墙（Memory Wall）

LLM 推理中的“解码阶段”（Decoder Pass）是生成文本的过程，模型一次生成一个令牌（Token）。在这个过程中，处理器需要不断从 RAM 中读取巨大的权重数据到 CPU 缓存中进行计算。

由于矩阵计算速度极快，CPU 大部分时间都在等待数据从内存总线传输过来。这就是所谓的“内存墙”问题——系统受限于内存带宽，而非计算能力。无论是 Xeon 还是 H100，这一瓶颈都普遍存在。在 DDR3 内存且无 GPU 的情况下，直接运行 llama-cli 会极其缓慢，因为默认优化是针对通用 GPU 场景设计的，并未针对 CPU 缓存层级进行优化。

2. 推测解码（Speculative Decoding）

为了绕过内存墙，作者使用了推测解码技术。这是目前 AI 行业为缓解内存带宽压力而发明的最巧妙的软件解决方案之一。

• 原理：使用一个小参数的草稿模型（Drafter）快速生成多个候选令牌，然后由大参数的验证器（Verifier）并行验证这些令牌。如果验证通过，这些令牌可以直接被接受，从而减少大模型单独生成每个令牌所需的内存读取次数。
• 参数配置：
  • --spec-type mtp --draft-max 3：将 26B 验证器与之前量化的小草稿模型配对，每次草稿最多生成 3 个令牌。
  • --draft-p-min 0.0：接受所有概率的草稿令牌。
  • --spec-autotune：根据工作负载自动调整草稿链的长度，以榨取最大速度。

在 CPU 上，推测解码的优势尤为明显。CPU 的计算成本相对于将验证器权重通过缓存流式传输的成本来说很低。草稿模型的活跃层可以完全放入 L3 缓存中，因此增加草稿模型的开销极小，却能显著减少大模型权重的读取次数。

3. CPU 与 MoE 路由优化

Gemma 4 26B-A4B 是一个混合专家模型（MoE），拥有 128 个专家，每个令牌激活 8 个，总参数约 25.2B，活跃参数约 3.8B。

• 缓存抖动问题：CPU 依赖片上高速缓存（L1/L2/L3），而 GPU 拥有巨大的 HBM 内存。在 MoE 模型中，频繁切换不同的专家会导致 CPU 缓存频繁失效（Cache Thrashing），迫使 CPU 从慢速的主内存中重新加载权重。
• 参数配置：
  • --cpu-moe：针对 CPU 缓存层级优化专家路由策略，使权重尽可能长时间地保留在 CPU 本地缓存中。
  • --merge-up-gate-experts：将每个专家的“Up 投影”和“Gate 投影”融合为单次矩阵乘法（Matmul）。这减少了数据在内存总线上的往返次数，直接绕过内存带宽瓶颈。日志显示 fused_up_gate = 1 证实了融合生效。
  • -t 8：设置线程数为 8，匹配物理核心数。由于是内存密集型任务，开启超线程（16 线程）只会增加调度开销，而不会提升吞吐量，因为核心是在等待 DDR3 内存，而不是在等待彼此。

4. 内存锁定与重组

为了最大化内存带宽利用率，作者使用了以下内存管理参数：

• --run-time-repack：在推理开始前，重新组织内存中的权重矩阵，使其与 CPU 缓存的预期布局完美对齐。如果权重矩阵在 RAM 中是通用布局，CPU 会以碎片化的方式拉取数据，导致缓存未命中（Cache Misses）。该参数会在启动时花费几秒钟物理重组这些巨大的数字表，以换取推理期间最大的内存带宽。日志显示重组了 265 个张量。
• --mlock：内存锁定。防止操作系统将模型数据交换（Swap）到磁盘。如果 27GB 的 AI 权重被交换到磁盘，生成速度将瞬间降至零。mlock 告诉 Linux 内核：“将这 27GB 严格锁定在物理 RAM 中，绝对不要移动到磁盘。”
  • 注意：如果系统物理内存不足，可能会遇到 Cannot allocate memory 错误，因为 mlock 需要预留足够的物理 RAM。
• --no-kv-offload：禁止将 KV 缓存卸载到磁盘或 CPU 内存的次要区域，确保 KV 缓存始终处于高速访问状态。

关键要点

• 硬件限制与突破：即使使用 2016 年的 Xeon E5-2620 v4 和慢速 DDR3 内存，通过极致的软件优化，也能运行 26B 参数的大模型。
• 内存带宽是关键：LLM 推理在 CPU 上是内存绑定（Memory-bound）而非计算绑定（Compute-bound）。优化重点应放在减少内存访问次数和提高缓存命中率上。
• 推测解码的价值：在 CPU 上，推测解码通过小模型在 L3 缓存中运行，大幅减少了大模型权重的读取频率，是绕过内存墙的有效手段。
• MoE 模型的 CPU 适配：对于混合专家模型，必须优化专家路由以避免缓存抖动，并融合投影操作以减少内存总线传输。
• 底层参数的重要性：像 ollama 这样的黑盒工具无法提供足够的控制粒度。必须直接使用 llama.cpp 并理解每个标志（Flag）的作用，如 --mlock、--run-time-repack 和 --cpu-moe。
• 线程数匹配物理核心：在内存密集型任务中，开启超线程通常弊大于利，应使用与物理核心数相同的线程数。

意义与影响

这篇文章展示了 AI 推理领域的一个重要趋势：软件优化正在弥补硬件差距。

1. 降低部署门槛：通过精细的优化，用户可以在没有昂贵 GPU 的情况下运行中等规模的大模型。这对于边缘计算、个人开发者或预算有限的中小企业具有重要意义。
2. 硬件利用率最大化：许多老旧服务器或闲置 PC 可以通过软件调优重新焕发活力，用于本地 AI 推理，减少电子垃圾并提高资源利用率。
3. 对框架设计的启示：主流工具如 ollama 虽然易用，但在极端硬件或特定场景下缺乏灵活性。深入底层引擎（如 llama.cpp）并暴露更多优化选项，对于满足多样化硬件需求至关重要。
4. 技术普及：通过详细解释 mlock、缓存重组、推测解码等概念，作者降低了技术门槛，