Overspill：为 FreeToken 增加磁盘层，85GB MoE 模型跑在 12GB 显卡上

一名本地推理爱好者在 Reddit 上分享了名为 Overspill 的实验性项目：它作为 FreeToken 推理引擎的磁盘分层扩展，借鉴 Colibri 处理 MoE 专家在磁盘 / 内存 / 显存之间分布的思路，让超出物理内存的 MoE 模型也能在消费级硬件上运行。作者在他的机器上加载了约 85GB 的 DeepSeek-V4-Flash REAP-150B（FP4 专家量化版本），解码速度达到 2.8–3.4 tok/s，而相同模型在 llama.cpp 下仅约 0.4–0.5 tok/s。

硬件与测试对象

• GPU：RTX 3060 12GB
• CPU：Ryzen 9 7900（Zen 4，支持 AVX-512）
• 内存：64GB DDR5-6000（WSL2 下封顶 48GB）
• 存储：NVMe，通过 WSL2 访问
• 系统：Windows 11 + WSL2 Ubuntu 24.04
• 测试模型：puwaer/DeepSeek-V4-Flash-0731-reap-150b，FP4 专家，约 85GB

性能对比

冷启动、贪心解码、同一台机器上的结果如下：

• Overspill：解码 2.8–3.4 tok/s；6.4k prompt 的 TTFT 约 102 秒；冷启动后首条短 prompt 的 TTFT 约 43 秒；之后短 prompt 的 TTFT 约 10 秒
• llama.cpp：解码 0.4–0.5 tok/s；6.4k prompt 的 TTFT 约 373 秒
• Colibri：解码 1.1–1.2 tok/s；6.4k prompt 的 TTFT 约 26 分钟

需要注意的是，三者的非专家权重并不完全相同：llama.cpp 的 GGUF 将约 8GB 的非专家（注意力等）权重存为 Q8_0，而 FreeToken 和 Colibri 使用 DeepSeek 原生的 FP8，因此结果并非逐位一致。

主要改动思路

作者在 FreeToken 之上叠加了一层相对薄的实验代码，核心做法包括：

• 使用 mmap 把放不进 RAM 的专家映射为文件，借助操作系统页缓存作为另一层缓存
• 使用 madvise(WILLNEED) 让 Linux 在大块顺序读取时并行预取每层的路由专家，而不是按缺页逐块拉取
• 将 embedding / 输出层常驻 RAM，以腾出部分显存
• 增大 prompt 分块，减少专家流式加载的次数
• 短 prompt 直接走 CPU 路径，避免整套专家集过 GPU

最显著的提升来自专家从磁盘的加载，作者称在他的环境下比此前快约 4 倍。他还顺手修了 FreeToken 自带的 checkpoint converter 在「比 RAM 大的模型」上 OOM 的问题，并希望 FreeToken 官方确认这一修复方向是否合适。

局限性

• 仅在单台机器、单模型、WSL2、单请求场景下测得，作者明确称之为「概念验证」
• 磁盘路径下专家计算跑在 CPU（FreeToken 的 CPU executor，在 Zen 4 上走了 AVX-512），专家从磁盘经 RAM 流式送入 CPU，因此结果高度依赖 CPU、内存带宽（DDR5-6000）和存储速度
• 不带 AVX-512 的消费级 Intel CPU 会回落到较慢路径；核心数更少、更慢的 RAM、更慢的 SSD 或更小的页缓存都会拉低解码速度
• 尝试过从 RAM → GPU 预取下一层专家，但实际慢 9–29%，作者猜测是传输与 GPU 计算竞争，但表示自己也不完全确定原因
• 在 Qwen3.6-35B-A3B（能完整装进 RAM）上输出与原生 FreeToken 逐字节相同，但 150B 模型未做完整评估

适用范围与开源

Overspill 当前以 Apache-2.0 协议开源，仓库地址为 https://github.com/IvanAdriazola/overspill，作者标注为 experimental。作者欢迎有原生 Linux、更快存储、更大内存或其他硬件配置的人复现测试，也希望熟悉 FreeToken、Colibri、mmap/页缓存机制的读者指出潜在误解。整体来看，这是社区层面在「把超大 MoE 模型塞进消费机」方向上的一次小规模探索，对本地推理玩家有参考价值，但对行业整体格局影响有限。