Kimi K3 在单颗 CPU 与 8GB 内存中跑起来：不是装下，而是从硬盘流式读取

一个推理引擎已经发布，它能在单颗 CPU、无 GPU、实测峰值 8.24GB 内存的条件下运行 Kimi K3。整个引擎用可移植的 C99 写成，编译后是一个 176KB 的二进制文件，不依赖 BLAS，不依赖任何框架，也不需要 CUDA。许可证为 Apache 2.0。

这个数字乍看不可能。2.78 万亿参数模型的权重装不进 8GB，事实上也确实没有装进去。这个项目改变的不是模型的大小，而是读取它的方式。

内存上限原来是加载方式的属性，不是模型的属性

Kimi K3 是混合专家（MoE）模型：每一步只用到权重中的一小部分。引擎正是直接利用了这一点。稠密主干常驻内存，而1.45TB 的路由专家留在硬盘上，通过绕过操作系统缓存的 O_DIRECT 调用从 NVMe 读取，前面再加一层 LRU 缓存来兜住最常用的部分。

由此带来一个有意思的结果：内存不再是一道门槛，而变成了一个旋钮。无论手上有多少内存，同一个模型给出的答案逐字节完全相同，变化的只有速度：

• 8GB 内存下，每个 token 26.5 秒
• 128GB 及以上，每个 token 5.6 秒

也就是说，一句话要几分钟，一段话要半小时。这是一次演示，不是一款产品。

代价落在哪里

内存上省下的，硬盘上要还回去：部署需要 1.56TB 的检查点外加 109GB 的打包主干，本地约 1.7TB 空间，下载时间以小时计。CPU 必须支持 AVX2 与 FMA。主要目标平台是 Linux x86-64，同时也支持 macOS/ARM64 和 Windows。

还有一处限制容易被标题盖过：这里跑起来的是基础模型，没有对话模板。它续写你给的文本，而不是回答问题，因此单独拿来当助手是用不了的。

意义何在

这个项目的价值不在速度，而在它让人看见的东西。任何研究本地部署的人都会说同一句话：「这个模型装不进我的显卡。」这项工作说明，这句话并不总是成立。装不下，往往源于我们一次性把全部权重塞进内存的习惯，而不是模型本身。既然大部分专家在某一步本来就用不到，把它们全部常驻内存就成了一种选择，而非必然。

实际操作中，没有人会用每 26.5 秒一个词的配置干活。但同样的思路用在更小的 MoE 模型和更快的存储上，就会落到相当合理的区间。代码作者 Fareed Khan 在仓库里用一句话概括了这套做法：同一个模型，同样的答案，速度取决于你手上的内存。

我们此前报道过 Kimi K3 登陆 CoreWeave 租用算力的消息。那篇文章问的是谁跑得起它；这个项目从完全不同的方向回答了同一个问题。