你有一只很快但很小的随身包、一只较大的行李箱，还有一个容量充足却取用麻烦的仓库。现在要搬的东西远超随身包容量，办法不是硬塞，而是把最常用的留在手边，其余按需调取。Overspill做的正是这类安排：让显存、内存和磁盘接力，尝试在一张12GB显卡上运行约85GB的模型。
这项工作目前只是作者发布的实验性开源项目，采用Apache-2.0许可证。下文的模型信息和性能数据均来自作者在Reddit发布的单机测试，尚无独立复现。
模型装不下，计算却未必做不了
Overspill接在推理工具FreeToken下面，为它增加一层磁盘存储。它瞄准的是MoE——Mixture of Experts，中文常译为“专家混合”。这类模型包含许多分工不同的“专家”，生成每个词时只调用其中一部分。它不必每次都动用全部参数，但所有专家的权重仍得有地方存放。
权重就是模型训练后留下的大量数值，也是模型文件占空间的主体。作者测试的DeepSeek-V4-Flash REAP-150B约为85GB，其中专家权重采用FP4——大约用4位浮点格式保存数值，以减少体积和读取量。
测试机器配有RTX 3060 12GB显卡、Ryzen 9 7900处理器、64GB DDR5-6000内存和NVMe磁盘；不过WSL2环境把可用内存限制在48GB。显存和内存加起来仍放不下整个模型，Overspill便把剩余专家留在磁盘上。
关键不是“塞进去”，而是及时送到
显存最快，但最小；内存更大，也更慢；磁盘容量最大，取数延迟最高。Overspill把放不进内存的专家做成内存映射，让操作系统的页缓存充当额外一层仓库。模型运行到某一层、确定需要哪些专家后，它再用madvise(WILLNEED)提示Linux提前读取，把原本零碎、逐页触发的取数改成并行的大块读取。
它还把embedding和output layers——负责把输入转成模型内部表示、再把结果转回输出的层——常驻内存，以腾出部分显存；增大prompt chunks，也就是每批处理的提示词片段，减少反复搬运专家的次数。遇到短提示词时，它干脆让CPU运行，避免把整套专家来回送进GPU。
作者还记录了一次反直觉的失败：提前把下一层专家从内存搬进显存，原以为会更快，在RTX 3060上却慢了9%至29%。他的推测是数据传输和GPU计算争抢了资源。真正明显的改善来自加快磁盘加载，而不是更激进地预取到显存。
约3 tok/s，意味着什么？
在冷启动和greedy decoding——每一步都直接选择当前最可能词元的生成方式——下，作者测得Overspill约为2.8至3.4 tok/s，即每秒生成2.8至3.4个词元。相同机器上，他记录的llama.cpp为0.4至0.5 tok/s，Colibri为1.1至1.2 tok/s。
处理6.4k长度提示词时，TTFT——从提交请求到看到第一个输出词元的等待时间——分别约为102秒、373秒和26分钟。短提示词冷启动后的首次TTFT，三者为43秒、44秒和25秒；再运行一次，则为10秒、40秒和18秒。
这些数字谈不上流畅，更不能证明Overspill普遍更快。它真正值得关注的地方，是把“模型必须完整装进高速内存”改成了“只要能及时调来当前需要的部分”。对于MoE，这为消费级设备越级加载大模型展示了一条可行但仍缓慢的路线。
局限与未知
- 所有结果均为作者在一台机器上的个人测量，未披露重复次数、误差、功耗、具体磁盘型号与带宽、生成长度等完整条件。
- 三套引擎并非严格同条件：专家权重相同，但llama.cpp约8GB的非专家权重采用Q8_0，FreeToken和Colibri使用原始FP8，不能据此下普遍性能结论。
- 作者称项目仍属experimental，并坦言包含大量“vibe coding”、自己并非专家。模型名称、约85GB体积和硬件运行结果也尚未获得其他测试者交叉印证。