七月 Kimi K3 刚开源那会儿，社区摸索出的最低能跑配置，是一台插满 8 张 AMD MI355X 的服务器。普通人看着 2.8 万亿参数，直接默念「与我无关」。知乎
结果八月初，一个叫 Fareed Khan 的开发者甩出个项目 kimi-k3-in-c：纯 C99 写的推理引擎，代码总共 176KB，不要 GPU、不要 CUDA、不要框架，在一台只有 8.24GB 内存的旧笔记本上，把 2.78 万亿参数的 K3 跑通了。项目很快引发关注，这两天又有 B 站 UP 主把整套实测重做一遍，把这个老话题重新捞回大家视野。哔哩哔哩微博
先泼盆冷水：这不是「把 2.78 万亿参数塞进 8GB 内存」
这是最容易被误读的一点。K3 是 MoE（混合专家）模型，每生成一个 token，并不会动用全部参数，只激活路由挑中的少数「专家」。Fareed 就是吃准了这个稀疏性：1.56TB 的权重平时躺在硬盘里，推理时只把当前要用的专家流式读进内存，用完就扔。一句话——SSD 被当成了模型的主仓库，内存只是个「中转站」。微博微博
省内存的几招，说人话版
结合 B 站实测和项目说明，核心就几件事：专家用半字节打包、留在 NVMe 硬盘上；MLA 把 96 个注意力头压成一个隐变量，内存不随上下文膨胀；93 层主干流式打包成 109GB 的单文件；再加上那个 176KB、零依赖的引擎本体。好处是，输出跟云端「逐字节一致」——因为它没在精度上偷工，只是拿速度换了内存。哔哩哔哩GitHub
再来第二盆冷水：能通，不等于能用
存储门槛约 1.7TB，你的硬盘得先够大。哔哩哔哩
8GB 机器上，一个 token 要约 26.5 秒，网友吐槽「30 秒蹦一个字，慢得像看日出」，甚至怀疑这是在测 SSD 寿命。微博
B 站那条实测视频底下，就有评论说得直白：「能通和能用不是一回事啊。」
所以别指望装上它日常聊天，它连一句话都答得让你想睡一觉。
那它这么「没用」，为啥还值得看？
因为它把问题换了个问法。以前本地大模型能不能跑，是个死指标：显存够不够。这个实验证明了，靠 MoE 的稀疏性，参数规模和内存占用可以解耦，门槛从「显存容量」变成了一个「有多少钱买多少速度」的调节阀，真正的瓶颈也从显存挪到了存储 I/O。微博
对本地部署的玩家来说，它更像一个架构样本、一份学习素材，别急着照搬。但方向值得记住：以后一个大模型能不能在你机器上跑起来，可能越来越不看「显存装不装得下」，而是看「硬盘上的权重，你调度得够不够快」。
