WASTE — 权重感知流式Tensor引擎Kimi K3 — 2.78万亿参数 — 在消费类笔记本电脑上运行。$ waste run ~/models/k3.waste '意大利的首都是什么？' waste: no --budget, 使用46.24 GB的64.00 GB（专家缓存17.56 GB）意大利的首都是**罗马**。 [16个标记，31.09秒，0.51 tok/s | 专家3357命中 / 20195未命中 = 14%] WASTE是一个可嵌入的推断引擎，用C语言编写，没有第三方运行时依赖。它将模型主干保留在内存中，从磁盘直接流式传输选定的专家，并使用剩余的RAM作为有限的专家缓存。它当前的有效证明是完整的开放权重Kimi K3模型：2.78万亿参数，转换为982 GiB的容器，并在64 GB的MacBook Pro上以0.49–0.54个令牌每秒运行。这不是一个蒸馏、剪枝或缩减的变体。模型容器最小内存测试速度 Kimi K3 2.78T 982 GiB 29.05 GiB 0.49–0.54 tok/s Kimi-Linear 48B 19 GiB 1.87 GiB 10.7 tok/s WASTE是为那一个模型和那一个约束而编写的：K3不适合当前主流消费系统的RAM。发布时它的大小为1.42 TB，转换后为982 GB。但混合专家每个令牌激活约4%，所以几乎所有的权重在任何时刻都是空闲的——而空闲权重不需要在内存中，而是需要在时间上可达。WASTE将其放在磁盘上，以一种布局，其中一个专家的成本恰好是一次读取，流式传输每个令牌实际需要的内容，并将剩余的每一个字节的RAM用于重复的部分。现状引擎是正确的：每一层都经过与PyTorch参考的验证，最终的logits一致到3.6e-06，视觉塔与自己的神谕一致到2.3e-06。它的速度也很慢——每秒半个令牌，以上句子花费了三十秒。这两点都很重要，第二点不应被视为免责声明。我们不知道有另一个已发布的演示能够在消费者机器上流式处理这种规模的模型：我们没有找到万亿级NVMe流式传输的实例，最佳的671B类别食谱则假定拥有一台一TB的DDR5服务器。这是一份我们搜索结果的报告，而不是调查——这个代码库没有书目，也没有比较表，所以请将其视为邀请您发送反例，而不是结果。有趣的部分不是速度，而是整个系统在单一消费机器上处于可达范围内——从这里出发，问题是工程，而不是可行性。杠杆的所在不在于它们现在的位置。重叠专家读取和算术的成本大约是1.6倍并已发货；看起来更大的两个——每个令牌读取更少的字节和在RAM中保留更多字节——都被测量过并且都被拒绝，一个是因为该家族的路由器没有被降级的尾部，另一个是因为机器不会常驻的缓存无法以任何价格购买。即使读取重叠，它们仍然占解码步骤的55%，而算术为27%，因此剩下的是更快的磁盘或更大的RAM，而不是对内核的另一次传递。docs/EFFICIENCY.md是每项价格如何计算的说明，包括两个在测量之前构建的项目。具体来说，这打开了一个前沿规模的模型，可以在没有网络、没有每个令牌发票的情况下作答，并且没有数据离开机器——这就是“您不能将该数据发送到API”与“在这里运行”之间的区别。格式和引擎在任何深层次上都不是K3特定的；K3只是今天存在的最困难的案例，一个以2.78T流式传输的模型在48B的情况下舒适流式传输。本文档中的每个数字都是在发布着的提交上测量的，错误的数字在docs/LEARNED.md中记录为错误，而不是静默更正。为什么会取这个名字每个由云服务回答的令牌都要支付两次：一次在发票上，另一次在运行模型所需的电力上——这个模型可以勉强、尴尬地但真的适应已经放在桌子上的硬件。WASTE的目的是成为终结这种令牌浪费的第一步。这个首字母缩略词是其次的。您需要的磁盘，模型982 GB用于转换容器——计划一个TB的磁盘，以便将另一个1.42 TB的暂存转换为已发布的分片，之后释放的RAM 29.05 GB最低，以在4K上下文中打开K3；此处数字为64 GB存储速度容器必须放在内部NVMe上——见下文构建C11编译器并进行编译。运行时没有BLAS，没有CUDA，没有Python。此处的大小都是二的幂，df和引擎都这样报告：容器是982 GiB，磁盘供应商会称其为1.05 TB。RAM底线是引擎拒绝在此以下启动的，几乎完全是27.28 GB的驻留主干。有效吞吐量的起始值更高：在64 GB的机器上，工程给自己提供了46 GB的预算，其中17.56 GB为专家缓存，这是测量曲线的最高点。一个32 GB的机器...