一个名为 WASTE 的开源推理引擎，把参数量高达 2.78 万亿的 Kimi K3 完整跑在了一台 64GB 内存的 MacBook Pro 上。开发者强调，这不是蒸馏版、剪枝版或任何缩水变体，而是完整的开放权重模型。

一台笔记本，跑万亿级模型

WASTE 全称 Weight-Aware Streaming Tensor Engine（权重感知流式张量引擎），用 C 语言编写，运行时不依赖任何第三方库，没有 BLAS，没有 ONNX，推理路径里也没有 Python。

它给出的成绩单是：Kimi K3 转换后形成一个 982 GiB 的容器文件，引擎启动的内存下限为 29.05 GB，在 64GB 内存的机器上实测速度为每秒 0.45 到 0.62 个词元。项目文档里贴出的一次实际运行记录显示，回答”意大利的首都是哪里”这个问题，输出 16 个词元耗时 25.78 秒。

这个速度确实慢。但开发者认为，慢不是重点：目前没有找到另一份公开的、在消费级机器上通过磁盘流式运行万亿级模型的演示，而业内记录最完整的 6710 亿参数方案，前提是一台配备 1TB 内存的服务器。

原理：把闲置的权重放回硬盘

这套方案能成立，靠的是混合专家架构的稀疏特性。Kimi K3 每处理一个词元，只会从 896 个路由专家中激活 16 个，实际参与运算的权重约占总量的 4%。绝大部分权重在任一时刻都处于闲置状态，而闲置的权重不需要待在内存里，只需要”能及时取到”。

WASTE 的做法是把模型主干常驻内存，专家权重留在硬盘上，并按特定布局排列——每条专家记录按 4KiB 对齐，门控、上投影、下投影三个矩阵相邻存放，因此路由到一个专家只需要一次读取操作，而不是三次。剩余内存全部用作有界的专家缓存。

真正拉开差距的优化有两项。一是把专家读取与算术运算重叠执行，收益约 1.6 倍。二是”抢跑”：下一层的专家编号本来要等隐藏状态算出来才知道，但路由器本身是常驻内存的，于是引擎在每层结束时，直接用当前层的隐藏状态去跑下一层的路由器，提前把它点名的专家取回来。这个提前一个残差块的猜测，排名第一的命中率为 92%，前六名合计 81%，把缓存命中率从 14% 拉到 38%，而总读取字节数完全不变。

专家权重采用残差矢量量化存储，三级 256 条目码本作用于 8 维向量，平均每个权重 3.00 比特；模型主干则保持 4 比特和 8 比特精度。开发者试过把主干也压到 3 比特，结果输出直接崩溃。

硬盘速度决定一切

文档反复强调，存储速度不是细节问题。处理一个词元需要读取 17GB 的专家数据，走内部固态硬盘的实测带宽是每秒 12.78GB，模型能流畅串起来；换成 USB 外置硬盘只有每秒 0.94GB，同一个词元要等 13 秒。结论很直接：外置硬盘只用来下载，转换后的容器必须放在机器内置的 NVMe 上。

内存预算也存在反直觉的现象。在 64GB 的机器上，46GB 预算跑出 0.53 到 0.55 词元每秒，是曲线最高点；而预算调到 52GB 时结果在 0.04 到 0.46 之间剧烈跳动，完全不可复现；调到 58GB 更是稳定跌到 0.02 至 0.03。原因不是缓存失效，而是引擎虽然守住了自己的预算，机器整体却已经放不下，操作系统开始换页。

对于不想拿出一整块 TB 级硬盘的人，同一套引擎和格式可以运行 Kimi-Linear-48B，容器只有 19GB，内存门槛 1.87GB，速度能到每秒 10.7 个词元。

意义在哪

开发者对项目名字的解释是：每一个由云端服务生成的词元都被付费了两次，一次是账单，一次是数据中心的电费——而那个模型本可以（勉强、别扭但确实可以）跑在已经摆在桌上的硬件里。

这套方案指向的场景很明确：一个前沿规模的模型，回答问题时不需要联网，没有按词元计费的账单，也没有任何数据离开本机。对于”这些数据不能发给外部接口”的场合，差别就是能做和不能做。

作为验证对象的 Kimi K3 于 7 月 27 日由月之暗面公开权重，总参数量 2.8 万亿，支持 100 万词元上下文与原生视觉理解，是目前参数规模最大的开放权重模型。WASTE 项目方称，引擎和格式本身并不特别针对 K3，选它只是因为它是当下最难啃的一块骨头——能流式跑通 2.78 万亿参数，跑 480 亿参数自然轻松。

来源：GitHub 开源项目 sqliteai/waste 项目文档、Hacker News；Kimi K3 参数信息来自月之暗面官方发布