2.78万亿参数大模型，现在普通笔记本就能跑

重大突破：仅通过从 NVMe 流式传输激活的专家，就能在消费级笔记本电脑上运行完整、未修改的 2.78 万亿参数 Kimi K3。

“你根本不可能在“那玩意儿”上跑 Kimi K3”——他们曾这么断言。但实现的方法有很多种，这就是其中一种：Marco Bambini 刚刚让完整 Kimi K3 跑在了笔记本电脑上。

来认识一下 Marco Bambini，他完成了一天前还看起来不可能做到的事。他开发了 WASTE，即权重感知流式张量引擎（Weight-Aware Streaming Tensor Engine），这是一个干净、无依赖的 C 语言推理引擎，它只需要直接从 NVMe 流式传输激活的专家，就能运行完整、未修改的 2.78 万亿参数 Kimi K3 模型。

没有蒸馏，没有剪枝，没有云端，就是完整的开权重模型。我们现在已经在实验室里跑起来了。

Marco到底做了什么
Kimi K3 是一个稀疏混合专家系统，对于任意一个 token，它只有约 4% 的权重会被激活。

Marco 的思路简单且直接：闲置的专家根本不需要放在 RAM 里，它们只需要能在需要的时候被及时调用就行。

WASTE 把模型的“主干”（注意力、共享组件、嵌入）保留在内存中——转换后的容器大约占 27 GB。82000 多个路由专家则以紧密打包的残差向量量化记录的形式保存在磁盘上。

当路由器为每层选中 16 个专家时，引擎会直接绕过缓存，从内置 NVMe 读取，再将它们送入容量受限的专家缓存。机器剩余的 RAM 就成为这个缓存的工作空间。

在容器放在内置 SSD 的 64 GB MacBook Pro 上，我们测得的速度是 0.32–0.34 token/秒，内存占用非常宽裕。预填充的速度稍高一些。视觉塔工作正常，对数与参考实现的误差在百万分之几以内，这就是真正的完整模型。

从原始 1.42 TB MXFP4 权重转换后，容器本身大小为 982 GiB。对于短上下文，最低内存要求仅略高于 29 GB。提高内存配额后，专家缓存命中率会上升；但提得太高就会开始分页，速度会暴跌。在当前消费级硬件上，最优区间清晰可测。

我们如何测试
在引擎稳定当天，我们就转换了官方权重、验证了容器，并且开始系统性运行测试。

首先，我们针对 PyTorch 参考实现，在短提示上确认了数值保真度。接着，我们转向更长的生成、视觉输入，以及使用 Kimi 原生 XTML 格式的多轮对话测试。

我们正在测量实际解码耗时、专家 I/O 与计算的占比、不同内存配额下的缓存命中率，以及持续负载下的发热表现。我们还测试了基于同一 C 库搭建的兼容 OpenAI 的服务端，这样我们就可以把模型直接接入现有代理循环，不需要重写任何代码。

早期观察结果：
•正如预期，专家 I/O 占用了大部分时间。在高速内置 NVMe 上，该引擎已经接近存储子系统的实际上限。
•该架构的稀疏性是实现这一切的核心。同等规模的稠密模型根本不可能本地运行。
•上下文长度