工程
2.78 万亿参数的模型，如今跑在 8GB 内存和 179KB 的 C 代码里。真正要紧的数字是 1.7 TB
kimi-k3-in-c 把月之暗面最大的开放权重模型装进了普通机器，做法是彻底利用一个专家混合模型实际上有多少部分是闲着的。工程是真功夫，账也算得对——但标题掩盖了硬件门槛究竟挪到了哪里。
MAI
一个由单人开发的项目 kimi-k3-in-c，把月之暗面（Moonshot AI）的 Kimi K3——2.78 万亿参数，迄今公开的开放权重模型中规模最大的一个——的推理跑在一颗 CPU 上，峰值常驻内存 8.24GB。引擎用 C99 写成，不依赖 BLAS、不依赖 PyTorch、没有 GPU 代码路径，编译产物不到 180KB。仓库有 8.1k 星标、1.3k 复刻，许可证为 Apache 2.0。
这个说法听起来不可能成立。它成立，而它成立的方式比标题更有意思。
把账算一遍
以 bfloat16 计，K3 的权重约为 5,560GB。仓库把削减过程拆成四步，而每一步都是模型自身的性质，而不是对模型玩的花招。
| 阶段 | 体积 | 原因 |
|---|---|---|
| bf16 权重 | 5,560GB | 基准 |
| 已发布检查点 | 1,560GB | 专家本就以 MXFP4 分发——每个权重 0.53 字节 |
| 常驻集 | 113.49GB | 被路由的专家可流式读取，无需常驻 |
| 实测峰值 | 8.24GB | 稠密主干逐层流式载入 |
真正出力的是第二步，而它并不是量化。K3 为每个 token 在每层从 896 个专家中路由到 16 个，其余 880 个对该 token 而言是静止的。常规推理栈把它们全部留在内存里，因为搬运权重代价高昂；这个项目选择改付 I/O 的账，几乎什么都不常驻。月之暗面自己的架构说明给出的数字是：2.8 万亿参数中，每个 token 的活跃参数约 500 亿。换句话说，这个模型从一开始就有 98% 在闲着，只是此前没人写出一个真的照这个事实行事的引擎。
注意力机制受到同样的对待。93 层中有 69 层使用 Kimi Delta Attention，其递归状态固定为 217MB，与上下文长度无关。24 个全局注意力层使用 MLA，每个位置只缓存一个 576 维的潜在向量，而不是 96 头 × 320 维——仓库把这一项测为 53 倍的削减。两者都不是作者的发明，都是 K3 的设计选择，只不过以 GPU 为前提的推理栈没有什么特别的理由去利用它们在内存上的后果。
这里真正被造出来的东西
属于作者自己的工程都在管道层面，而且细致得少见。MXFP4 权重以打包形态直接参与乘法，不先反量化；按仓库的计算，这样每个 token 省下 194GB 的内存流量。一个手写的 JSON 扫描器只读文件头，就在 0.27 秒内为横跨 96 个 safetensors 分片的 497,220 个张量建好索引。BPE 分词器把 tiktoken 重新实现到逐字节一致，并通过覆盖 Unicode、表情符号与代码的往返测试验证。
最说明问题的，是那一节列出的五条不变量——弄错任何一条，输出都会静悄悄地变成看上去合理的垃圾：A_log 要按头而不是按通道索引；UT 变换逆矩阵的符号；KDA 的两个矩阵中哪一个保留对角元；MLA 缓存却从不旋转的那 64 个 rope 维度；以及路由器偏置只用于引导专家选择，而加权用的是未加偏置的 sigmoid 分数。没有在每一条上吃过亏的人，写不出这样一份清单。测试套件在生成之前设了三道对照 PyTorch 参考实现的一致性关卡——teacher forcing、贪心解码、带缓存的增量解码；而整个内核与分词器层，在你下载任何一份权重之前就可以先跑通。
代价
| 预设 | 峰值 RSS | 吞吐 |
|---|---|---|
| Laptop | 8.24GB | 约 32 秒/token |
| Desktop | 31.9GB | 约 28–31 秒/token |
| Workstation | 95.5GB | 约 24 秒/token |
| Server | 约 128GB | 约 19–21 秒/token |
每个 token 32 秒，大约是每分钟两个 token。一个三百 token 的回答要耗掉一个下午。而在小配置下，运行时间的 71% 花在存储读取而不是算术上——引擎在等磁盘。对于一个用内存换 I/O 的设计，这恰好是可以预料的结果。
这张表有两点需要提醒。数据是在一台 124 核的双路 AMD EPYC 7763 上测得的，各个预设改变的是内存预算上限，而不是机器本身。真实的 8GB 笔记本既没有 124 个核心，也没有那样的内存带宽，所以 Laptop 那一行是"内存预算收紧后的结果"，而不是"笔记本上的结果"。此外，关于保真度的说法——所有预设下输出逐字节一致——依据的是项目自己的测试套件。这套测试看起来做得扎实，但尚无独立复现的报告公开。
门槛究竟挪到了哪里
标题略掉的那一行在这里：这个项目需要约 1.7TB 的可用存储空间。其中 1.56TB 是检查点，另加首次运行前需要自行生成的 109GB 打包主干文件。
内存需求没有消失。它在存储层级里往下走了一级，从 DRAM 挪到了磁盘，并在这个过程中慢了三个数量级。磁盘便宜而 DRAM 昂贵，所以这是一笔正当且选得不错的交易。但它意味着，"在 8GB 内存里运行"描述的是工作集，而不是入场门槛。门槛是一次 1.7TB 的下载。
因此它的实用价值，并不在于你从此能用一台闲置台式机对外提供 K3 服务。价值在于：这个引擎用一份无依赖、可通读的代码，完整地陈述了 K3 推理究竟由什么构成——属于 Karpathy 的 llama2.c 那条谱系，你可以从头读到尾，几秒钟就能编译完。对于想把 K3 移植到不寻常硬件上的人，或者想弄清一个万亿参数级 MoE 到底把字节花在哪里的人，一个 179KB 的 C 程序、外加一份"有哪五种方式会让它悄悄出错"的清单，其价值远高于一个把这一切都藏起来的框架。
信息来源： kimi-k3-in-c（GitHub） · Kimi K3 模型概览（Hugging Face） · 月之暗面发布 Kimi K3（CNBC）