WASTE：2.78 万亿参数的 Kimi K3，在 64GB 内存的消费级笔记本上跑起来了

原文来源：sqliteai/waste (GitHub) — WASTE 是一个 C 语言编写的零依赖推理引擎，通过 NVMe 流式加载专家权重，让 2.78T 参数的 Kimi K3 在 64GB 内存的消费级笔记本上以 0.5 tok/s 运行

"跑 Kimi K3 只需要 29GB 内存，速度 0.50 tok/s。"当这句话出现在 Hacker News 上时，不少人的第一反应是：又是个标题党。但 WASTE 项目用实打实的技术细节证明了自己——这不是蒸馏版、不是剪枝版、不是降级版，而是完整的 2.78 万亿参数模型，跑在一台 64GB 内存的 MacBook Pro 上。

这解决了什么问题

Kimi K3 是 Moonshot AI 2026 年 7 月发布的全球首个开源 3T 级大模型，2.78 万亿参数，发布即登顶 Hacker News。但它有个尴尬的现实：完整权重 1.42TB，即便转换成紧凑格式也有 982GB。主流消费级硬件根本装不下——此前所有万亿级模型的本地运行方案，都假设你有一台装着一TB DDR5 内存的服务器。

MoE（混合专家）架构给了一条出路。Kimi K3 虽然总参数 2.78T，但每个 token 只激活约 4% 的专家。也就是说，绝大多数权重在任何时刻都是闲置的——闲置的权重不需要常驻内存，只需要"来得及读"。

这正是 WASTE 的核心洞察：把模型主干部留在内存，专家权重按需从磁盘流式读取，剩余内存全部用作有界专家缓存。

技术拆解：四个关键设计

1. 一次读取一个专家。 模型转换成一个 .waste 容器：JSON 清单、常驻主干部、每层一个专家库。每个专家记录 4KiB 对齐，gate、up、down 矩阵相邻排列——路由到一个专家恰好一次 pread 系统调用，不是三次、不是每次 seek。瓶颈从来不在算力，而在 I/O 编排。

2. 绕过页面缓存。 读取用 F_NOCACHE（macOS）、O_DIRECT（Linux）、FILE_FLAG_NO_BUFFERING（Windows）直接绕过内核页缓存。这是故意的：如果容器小于内存，内核会把整个文件缓存进 RAM，测出来的命中率是假象——在 982GB 模型面前，这种假象毫无意义。

3. 每位权重 3 bit 的残差向量量化。 专家权重用三级 256 条目码本（8 维向量）做残差向量量化，压缩到 3.00 bits/weight，且矩阵从不物化。每个 token 引擎构建一张部分点积查找表，之后每个专家行就是三次查表加两次加法。有趣的是主干保持 4-8 bit 不做激进量化——模型训练时只对专家做了量化感知训练（QAT），主干没有训练出对压缩的容忍度，3-bit 主干实测输出直接崩溃。

4. 缓存地板 = 一个 token 的工作集。 这是整个项目里最有预测性的数字：K3 每 token 在 92 层里各触达 16 个专家，共 17.0GB。低于这个数，缓存的专家在下一个 token 到来前就被驱逐，命中率不是低，是零。高于这个数，曲线急剧改善。

最后两行揭示了一个反直觉的真相：缓存给得太多反而更慢。 58GB 预算下引擎命中率 37%，但机器本身已经进入换页状态——OS 把专家缓存换出到磁盘，"命中"变成了页错误，比引擎自己管理的磁盘读取更慢。可用窗口很窄：约 46GB 打开，52GB 已经关上。

实测数字与验证

WASTE 的正确性是经过验证的：每一层都与 PyTorch 参考实现比对，最终 logits 一致到 3.6e-06，视觉塔与自身 oracle 一致到 2.3e-06。项目组也坦诚它是慢的——半 token 每秒，上面那句"意大利的首都是罗马"花了 31 秒。

存储速度不是细节：一个 token 要读 17GB 专家权重。内建 SSD 上 12.78 GB/s，模型流畅运行；USB 硬盘盒上只有 0.94 GB/s，同样的 token 要 13 秒。所以转换必须在内建 NVMe 上做，外接盘只用来下载。

想先试水的用户可以用 Kimi-Linear 48B：19GB 容器、1.87GB 内存地板、10.7 tok/s，同一个引擎同一个格式——用 48B 跑通了再决定要不要给 K3 腾出一块 TB 级硬盘。

诚实到罕见的项目文档

这个项目的 README 值得单独拿出来说。它记录了所有被实测否决的优化：索引布局分块、3-bit 主干、GPU 卸载、按专家分配比特数——每个都带着杀死它们的数字。比如按专家分配比特数：重要性在层内专家间最多只差 1.15 倍，层间 1.01 倍，"最优分配器和抛硬币写出的容器一样"。它还明确标注哪些数字是错的、在哪里记录为错（docs/LEARNED.md），"而不是悄悄修正"。API 尚未冻结、AVX-512 从未实际执行过一条指令、Windows 只在 MinGW 单工具链上跑通——所有未完成事项都白纸黑字写着。这种工程透明度在开源项目里相当罕见，也是 WASTE 最可信的地方。

值得关注，但先别激动

WASTE 证明了一件事：万亿级模型的本地运行不再是可行性问题，而是工程问题。2.78T 能流式跑，48B 自然流式得舒服。对"数据不允许出网"的企业场景和隐私敏感的个人用户来说，这可能是本地跑前沿模型的第一条现实路径。

但要说它马上能替代 API 也不现实：0.5 tok/s 的速度意味着一个 2000 字的回复要等十几分钟；需要一块 1TB 的内建 NVMe；64GB 内存是真实需求而非建议。它更像是"本地大模型生态的里程碑"——证明了方向可行，把下一棒交给了读盘更快、内存更便宜的未来。就像项目名字说的：每一个云服务 token 都被付了两次钱，一次在账单上，一次在数据中心为"其实能塞进你桌上那台机器"的模型所耗的电费里——WASTE 想做的是终结这种浪费的第一步。