313B 参数的 fp8 权重要占 328GB 磁盘,而一台 16GB 内存的笔记本连零头都装不下——这是所有"本地跑大模型"方案面对的第一堵墙。常规答案无非三条:暴力量化、蒸馏小模型、或者干脆交给云端。SQLite Cloud 开源的 WARP 引擎(前名 WASTE)给出了第四条路:权重大部分住 NVMe,内存只留缓存。
把专家流进 NVMe,而不是塞进内存
WARP 是一个纯 C 编写、推理路径只依赖 libc 和 pthreads 的嵌入式引擎,Apache 2.0 协议,GitHub 已有 2.3k star。它的思路针对 MoE 架构量身定做:共享主干(trunk)常驻内存,每个 token 实际激活的专家按需从磁盘流式读取,剩余内存全部充当有界专家缓存。容器格式经过精心排列,一个专家恰好对应一次对齐读;前瞻路由器还会预测下一层要用的专家、提前发起 IO,与计算重叠。
量化策略是分层的:专家用 3-bit 残差矢量量化,更敏感的共享权重保留 4/8-bit。再加上 Kimi K3 的线性注意力与压缩 latent KV cache——4K 上下文时 KV 缓存只要约 0.21GB 而非 11.25GB——打开整个 K3 只需 29.19GB 内存。
实测:数字与翻车点
项目在 64GB MacBook Pro(M5 Pro、内置 SSD)上的测量:
- GLM-5.3-Flash(313.89B 总参、17.31B 激活):最低 5.14GB 内存可跑,实测 3.32 tok/s(64 token)/3.86 tok/s(200 token);16GB 内存机器自动降到 3.06 tok/s,约为 64GB 机器的九成
- Kimi K3(2.78 万亿参数):完整模型、非蒸馏非剪枝,0.45–0.62 tok/s,一个冷 token 要读约 17GB 专家
- Kimi-Linear 48B:17.22 tok/s,最低 1.32GB 内存
README 里最诚实的是两类"负结果":专家缓存不是越大越好——超过预算后命中率仍在涨、吞吐却暴跌八倍,因为 cache hit 变成了 page fault;每 token 专家数从 16 降到 8 可以换 1.49 倍速度(KL 散度 0.037),降到 4 则模型直接跑飞。存储才是主约束:内置 SSD 12.78GB/s,测试用的 USB 硬盘柜只有 0.94GB/s。
几个值得记住的细节
- 整个项目"人类主导、LLM 写码",作者说这是迭代算法假设速度的唯一方式,终极目标是让 K3 在本地改进引擎本身
- 所有层对着 PyTorch 参考实现校验,GLM 最终 logits 相对 L2 误差 2.41e-5,argmax 与 top-10 完全一致
- 0.6.8 起支持 DeepSeek V3/R1/Kimi K2 家族转换;GLM-5.3-Flash 的视觉塔(282MB)按需加载,一张 200×140 图只占 40 个 token 位置
对"本地能不能跑大 MoE"这个问题,WARP 给出的答案是把瓶颈从 RAM 挪到了 NVMe 带宽——而后者每台笔记本都有。项目名字原本就叫 WASTE,作者的注脚是:每个云端 token 都付两次钱,一次在账单上,一次在数据中心电费里。当开源权重越来越大方、SSD 越来越快,"桌上这台机器其实跑得动"正在从安慰变成工程事实。详见 GitHub 仓库。