一句话总结
一个程序员用纯 C99 写了 176KB 的推理引擎，让 Kimi K3 的 2.78 万亿参数模型在 8GB 内存的单 CPU 上跑了起来。零 BLAS、零框架、零 GPU——这是 2026 年最硬核的 AI 基础设施项目。
为什么这件事让人震惊？
Kimi K3 是月之暗面（Moonshot AI）在 2026 年 7 月开源的 2.78 万亿参数 MoE（混合专家）模型，刚发布时就以「超越 GPT-5 的国产开源大模型」刷屏。但大多数人默认它的最低运行门槛是 8 张 H100 GPU——毕竟是万亿级模型。
然而，就在 2026 年 8 月 1 日，一个名为 kimi-k3-in-c 的开源项目三天内获得 1250+ Star，因为它做到了几乎不可能的事：
| 指标 | 数值 |
|---|---|
| 模型参数 | 2.78 万亿 |
| 磁盘占用（checkpoint） | 1.56 TB |
| 运行时内存峰值 | 8.24 GB |
| 推理引擎大小 | 176 KB |
| GPU 需求 | 0 |
| 外部依赖 | 0 |
| 代码语言 | 纯 C99 |
用作者的话说：「同一份模型在 8GB 内存和 224GB 内存上运行，输出逐字节完全相同。」
项目是怎么做到的？四大降维打击
作者 Fareed Khan 在 README 中用一张图概括了整个思路：
「从服务器集群到笔记本的四步降维——两端的输出完全相同。」
降维一：MoE 专家天然半字节存储
Kimi K3 有 896 个专家，每次推理只激活其中 16 个。专家权重以 MXFP4（4-bit） 格式存储在磁盘上——直接就是半字节，无需额外量化。
这意味着 1.45 TB 的路由专家参数，存储时已经压缩到了约 180 GB，且在推理时直接在半字节状态下做矩阵乘法，不需要解压到 FP16。
降维二：KDA——注意力内存永不膨胀
标准 Transformer 的 KV Cache 会随生成长度线性膨胀——这是推理内存的主要杀手。Kimi K3 使用 KDA（Kernelized Dynamic Attention，核动态注意力） 替代标准注意力，将注意力状态压缩为固定尺寸的核特征向量，O(1) 内存复杂度，无论生成 8 个 token 还是 8000 个，内存占用不变。
降维三：MLA——一个潜变量替代 96 个注意力头
MLA（Multi-head Latent Attention，多头潜注意力） 是 Kimi K3 的核心架构创新。传统 Transformer 的每个注意力头都需要独立的 KV 投影矩阵——96 个头就是 96 套。MLA 将 Keys 和 Values 压缩到一个共享的低维潜空间中，然后通过一个轻量上投影展开到各个注意力头。
对推理引擎来说，这意味着：只需维护一份压缩潜向量，而不是 96 份完整的 KV 状态。
降维四：流式加载主干——把「地板」变成「旋钮」
前三个降维已经将运行时内存压到了 ~130GB 左右——对数据中心服务器足够，但对笔记本来说还是太远。
第四步是真正的神来之笔：流式加载 Transformer 主干层。93 层 Transformer，不是一次性全部加载到内存，而是按需流式读取——处理完一层、释放、再读下一层。
通过一个 --preset 旋钮控制常驻层数：
| Preset | 常驻层数 | 内存占用 | 推理速度 |
|---|---|---|---|
| laptop | 最少 | 8.24 GB | 32.69 s/token |
| desktop | 中等 | ~40 GB | 更快 |
| server | 全部 | 127.92 GB | 10.69 s/token |
同一个模型、同一份权重、逐字节相同的输出——区别仅在于「多少层常驻内存」和「多快」。
性能实测数据
作者的测试环境是普通 Linux x86-64 机器，AVX2 + FMA 指令集：
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
--tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental
--- generated text ---
Paris.", "The Eiffel
----------------------
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB
在服务器模式下速度显著提升：
28 tokens in 299.3 s, 10.69 s/token average
PEAK RSS for the whole run: 127.92 GB
32 秒一个 token 听起来很慢——但这可是 2.78 万亿参数 的模型，跑在一台普通电脑上。作者在博客中写道：
「慢，但正确。给它更多内存，答案不变，只有时钟在走。」
技术亮点：不止是「能跑」
零依赖，纯 C99
整个推理引擎 176KB，没有链接任何外部库——没有 BLAS、没有 OpenMP、没有 Python。所有矩阵运算（包括 MXFP4 解量化、注意力计算、MoE 路由）全都是手写的 C 代码，使用 AVX2 SIMD 指令集优化。
确定性输出
同一份 checkpoint + 同一份 preset = 逐字节相同的输出。这对工程验证至关重要——可以从小规模测试开始，确信扩展到全量后结果不变。
分层验证体系
项目包含五层验证（作者称为「gate ladder」）：
- 单组件单元测试
- 微型 Oracle 模型验证
- 与 HuggingFace transformers 的逐层对比
- 全量 checkpoint 的端到端验证
- 持续生成的一致性检查
每一层通过后才进入下一层——这种工程严谨性在开源项目中极为罕见。
可复现的测量数据
所有性能数据都来自 docs/data/ 目录下的实测记录，包含完整的内存阶梯（8GB → 224GB 逐级测量）。
对 AI 基础设施的启示
这个项目至少说明了三件事：
1. MoE 架构天生适合消费级部署。 896 个专家中每次只激活 16 个，意味着 98% 的参数不参与当前推理——这让流式加载成为可能。
2. 极简主义工程可以打败重型框架。 176KB 的纯 C 引擎 vs 几个 GB 的 PyTorch 运行时——后者在万亿级模型面前本身就是瓶颈。
3. 「在家跑大模型」的门槛正在迅速降低。 一年前，GPT-4 级别的模型还需要数据中心。今天，2.78T 参数的模型已经能在笔记本上运行——虽慢但正确。摩尔定律在模型优化领域的表现可能比硬件更快。
适合人群
- AI 工程师：想深入理解 MoE 推理的内部机制
- 系统程序员：欣赏零依赖、可移植 C 代码的极致工程
- 研究者：需要可复现、确定性的推理基准
- 硬件极客：想在自有硬件上验证「万亿模型，家用 CPU」
访问说明
- 需要 ~1.7TB 磁盘空间存储 checkpoint
- Linux x86-64，AVX2 + FMA
- 从 8GB 内存起步
- 模型权重需从 Kimi K3 官方获取
数据来源：GitHub API，项目创建于 2026-08-01。截至 2026-08-04 获得 1251 Star，192 Fork。作者 Medium 博客：Building Kimi K3 in C
