GitHub 上出了个项目，叫 kimi-k3-in-c。
5000 多个 star，纯 C 语言，声称在 8 GB 内存的普通电脑上跑通了 Kimi K3 的全部 2.78 万亿参数。不用 GPU，不用云服务器。K3 我之前接进过自己的工具，前阵子也把它换成了日常主力，对这个模型算是熟。看到这个项目的时候，我的第一反应跟评论区很多人一样：GPU 真的不需要了？
翻完仓库以后，结论正好反过来。
项目是真的，工程很硬
先把事实核对一遍。
| 项 | 核实结果 |
|---|---|
| 仓库 | 真实，截至今天 5,485 star / 892 fork，Apache-2.0 |
| 代码 | 约 25 万行 C99，零依赖，没有借用任何数学库，22 个 kernel 单元测试 |
| 验证 | golden test 拿 PyTorch 官方实现逐 logit 对比，误差在 tolerance 的 8% 以内 |
不是骗子项目。它有 tech report、完整的 CI、12 档内存配置（8 GB 到 224 GB），而且作者证明了一件很硬的事：所有 12 档的输出 token id 完全逐字节相同。 8 GB 和 224 GB 跑出来的结果一模一样。
但——每生成一个 token 要 32.7 秒。你问它一个问题，等回答的时间够你泡完一杯咖啡。而且你得先有一块 1.7 TB 的本地 NVMe 固态硬盘来存模型文件。
作者自己在 README 结尾写了一句："The point was never the speed."
四次搬家，不是四次压缩
看到"8 GB 跑 2.78T"，很多人的第一反应是：它把模型压缩了吧？
没有。一个权重都没扔，一个都没近似。 它做的全部事情是改变这些字节住在哪里。
用一个比喻：你在图书馆写文章，每写一个字之前都得把相关的百科全书翻一遍。这套百科全书——也就是模型的 2.78 万亿个参数——可以放在三种地方：
| 放在哪 | 对应什么 | 搬运速度 |
|---|---|---|
| 手边的超大工作台 | GPU 显存（HBM，焊在 GPU 芯片旁边的特殊内存） | 每秒 3–8 TB |
| 你的书桌 | 电脑内存（DDR5） | 每秒 50–100 GB |
| 地下三层仓库 | NVMe 固态硬盘 | 每秒 3–7 GB |
这个项目做的事情，就是把百科全书从"工作台"搬到了"地下三层仓库"。省了工作台的钱，代价是每写一个字都要跑一趟地下室。
具体分四步：
第一步（5560 → 1560 GB），不是它的功劳。 K3 出厂时就用了 MXFP4 格式——每个权重只占半个字节。这是月之暗面在训练模型的时候做好的，跟这个项目无关。
第二步（1560 → 113 GB），利用 MoE 的稀疏性。 K3 有 93 层网络，其中 92 层每层有 896 个"专家"——可以理解为 896 本分册——但每生成一个 token 只查其中 16 本。整个模型 96.3% 的参数在"睡觉"。这些沉睡的专家占了模型文件的 93%（1.447 TB）。做法是：让它们继续睡在硬盘上，要用哪本现取哪本，内存里留一小块地方（约 13 GB）做缓存——最近用过的专家先留着，下次还用就省一趟。
第三步（113 → 8.24 GB），连主干也不留。 剩下的 108.81 GB 是"主干"——路由器（决定该查哪几本分册的那个角色）、注意力机制、词表，每个 token 都要用。作者连这部分也不放内存里：预先打包成一个连续文件，推理时一层一层顺序读进来，用完就扔。内存里永远只放一层的量。
辅助条件。 K3 用了两种注意力优化（KDA 和 MLA），把模型的"短期记忆"压到了极小的体积。否则光是记住前面说过什么，8 GB 就不够了。
一个 token 32 秒，80% 在等磁盘
搬完家，代价就出来了。
README 里最诚实的一张图：在 8 GB 配置下，生成一个 token 的 32 秒里，80% 的时间在等磁盘把数据搬上来。真正在做乘法加法的时间占比很小。
加内存有用吗？用处不大。
从 8 GB 加到 64 GB，只快了 14%。从 8 GB 加到 224 GB——28 倍的内存——速度只快了 1.70 倍（32.69 → 19.21 秒/token）。
因为瓶颈不在内存容量。在存储带宽。
即使在 128 GB 的配置下，每生成一个 token 仍然要从磁盘读 25.83 GB。25.83 GB ÷ NVMe 约 3 GB/s 的速度 ≈ 9 秒。物理定律在这儿，没有魔法。
GPU 值钱的原因
现在可以回答那个问题了：这个项目是不是说明 GPU 不需要了？
恰恰相反。它用最直白的方式告诉你 GPU 为什么值钱——不是上面的计算单元多，是它旁边的内存搬运速度快了 1000 倍。
大模型推理在单用户情况下是一个纯粹的带宽问题：每生成一个 token，你得把所有激活的权重从存储搬到计算单元过一遍。算力反而是闲着的。GPU 贵不是因为芯片上的算术逻辑多，是因为 HBM 物理上就焊在芯片旁边——线极短、路极粗，数据搬运因此快出三个数量级。
回到图书馆那个比喻：GPU 不是一个算得更快的计算器。它是一张离书最近的工作台。 这个项目把书搬到了地下三层，然后发现无论搬运工多努力，也追不上在桌边直接翻书的速度。
这个思路本身不新——llama.cpp 的 mmap、KTransformers 的 MoE expert offload、DeepSeek 系模型的 CPU/GPU 混合推理，都在做类似的事。这个项目的独特之处是从零用 C 写、不借助任何框架，然后把每一步的数字都量化到了可复现的程度。
三个边界
这个方法不适用于所有模型，有三个前提：
只对极稀疏的 MoE 模型有效。 K3 每个 token 只激活 3.7% 的参数，这是个极端值。换成 Llama 这类稠密模型——没有"睡着的专家"可以留在磁盘上——每个 token 都得把全部权重搬一遍。同样的技巧对它们也有用（llama.cpp 一直在做），但效果完全不是一个量级。
只在服务一个人时成立。 同时服务两个用户，他们激活不同的专家，磁盘读取量翻倍。GPU 的经济性全靠 batch——一次搬书，几百个人共用。这个方案在生产环境里的经济学直接归零。
这不是一个能用的系统。 它只能续写文字——不是 ChatGPT 那样能对话的东西——只有 greedy 解码（每步挑概率最高的字，确定但呆板），没有图片理解能力。更重要的是，没有做过任何质量评测。作者原话：在他那台机器上 11 秒一个 token，跑一次 perplexity（衡量模型输出质量的常用指标）要好几天。
写在最后
我之前写过两篇 K3：一篇是把它接进自己工具后发现的成本问题，一篇是把日常主力换成它。两篇都是在"用"K3。
这次不一样。这次是有人把 K3 拆开放在桌上，让你看清楚每一层住在哪里、搬一次要多久、为什么 96% 的书可以不搬。
这个项目真正值得记住的，是它把"你需要一个数据中心"和"你需要一台台式机"之间的差距，拆解成了四个关于字节住在哪里的工程决策——然后用 25 万行手写 C 代码和逐字节比对，证明了这四个决策可以是无损的。作为一个工程 demo，我是佩服的。
如果你在家想跑大模型，正确的路径还是选一个跟你显存匹配的尺寸——30B 以下做个 4-bit 量化，大多数消费级显卡都能跑。把 2.78 万亿参数塞进 8 GB 内存然后每个字等半分钟，是一个漂亮的实验，不是一条实用的路线。
README 结尾那句话说得最好："The point was never the speed."
仓库：FareedKhan-dev/kimi-k3-in-c。性能数字来自仓库 README 和 tech report 的作者自测。