用纯C语言把1.56TB的Kimi K3模型塞进8GB内存运行

一个近乎偏执的工程实验

在AI推理动辄依赖成群GPU集群的今天，一位开发者做了一件反直觉的事情：他用纯C99语言编写了一个推理引擎，成功让1.56TB的Kimi K3大模型checkpoint运行在一台仅有8GB内存的单CPU机器上。

C99是C语言标准的1999年修订版，相比C89/C90增加了变长数组、内联函数、restrict关键字等特性。选择C99而非C++或更高级的语言来实现推理引擎，意味着完全避开了运行时多态、异常处理、内存管理抽象等开销。restrict关键字在此类项目中尤为关键——它告诉编译器两个指针不会指向重叠的内存区域，从而允许编译器进行更激进的向量化和指令重排优化，这对矩阵乘法内核的性能至关重要。这种选择在嵌入式系统和高性能计算领域很常见，因为开发者可以精确控制每一字节的内存分配和每一条CPU指令的执行路径。最终176KB的二进制体积就是这种精确控制的直接体现——作为对比，PyTorch的安装包通常超过2GB，即便是更轻量的推理框架如ONNX Runtime也在数十MB级别。

据这位开发者在Reddit上的分享，他此前在工作中将K3部署在32张H100上，但随后被一个问题困扰——没有任何办法能在自己的个人机器上摆弄它。于是他决定亲手实现一个推理引擎，不为生产使用，纯粹为了通过实现来理解模型架构。

这个项目的哲学非常清晰："Nothing clever going on"（没有什么花哨的技巧）。它不依赖BLAS（Basic Linear Algebra Subprograms，基础线性代数子程序库）、不依赖任何框架、没有GPU路径，仅由六个C文件构成，依赖libm（标准数学函数库）和OpenMP（一种多线程并行编程接口），编译出的二进制文件只有176KB。

不使用BLAS意味着放弃了如Intel MKL、OpenBLAS等经过数十年手工调优的矩阵乘法实现。这些库针对特定CPU微架构的缓存层级、SIMD指令集（如AVX-512）和内存预取模式进行了极致优化，通常能将矩阵乘法性能推到硬件理论峰值的90%以上。作者选择不使用它们，牺牲了计算效率，但换来了代码的完全透明性和零外部依赖——每一行计算逻辑都直接可读、可审计。

为什么1.56TB模型能装进8GB内存

这个实验之所以可行，核心在于对MoE（Mixture of Experts，混合专家）架构的深刻理解与利用。

MoE架构是近年来大规模语言模型扩展的核心技术路线之一。其基本思想源自1991年Jacobs等人的研究，但在2017年Google的Shazeer等人将其引入深度学习后才真正大规模应用。MoE的核心设计是在Transformer的前馈网络（FFN）层中引入多个并行的"专家"子网络，通过一个门控网络（gating network/router）动态决定每个输入token应该路由到哪些专家进行处理。

门控网络的工作机制值得展开：它通常是一个简单的线性层加softmax，输入当前token的隐藏状态，输出一个概率分布覆盖所有专家。然后通过top-k策略（K3中k=16）选择得分最高的k个专家参与计算，各专家的输出按门控权重加权求和。训练时通常还需要引入辅助的负载均衡损失（load balancing loss），防止路由器将所有token都送往少数几个"明星专家"而让其他专家饥饿——这是MoE训练中的经典难题之一。

这种设计使模型可以拥有巨大的参数总量，但每次推理只激活其中很小一部分，从而在计算成本可控的前提下获得更强的模型能力。DeepSeek-V2、Mixtral、以及本文的Kimi K3都是这一路线的代表。K3拥有896个专家，这个数字远超Mixtral的8个专家，代表了MoE架构向"细粒度专家"方向的演进趋势——更多但更小的专家可以实现更精细的知识分工。

专家权重永不常驻内存

据作者披露的数据，这个1.56TB的checkpoint中，有高达93%都是路由专家（routed experts）的权重。而MoE架构的关键特性在于稀疏激活——每处理一个token，896个专家中仅有16个被真正激活。

这意味着绝大多数专家权重在任意时刻都是"沉睡"的。作者据此设计了一个巧妙的策略：这些专家权重从不常驻内存，而是在需要时直接从NVMe固态硬盘按需读取，并且直接以打包的4-bit形式进行乘法运算，跳过了反量化（dequantization）步骤。

NVMe（Non-Volatile Memory Express）是专为固态硬盘设计的通信协议，通过PCIe总线直接连接CPU，绕过了传统SATA接口的瓶颈。现代NVMe SSD的顺序读取速度可达5-7 GB/s（PCIe 4.0）甚至14 GB/s（PCIe 5.0），随机读取IOPS可达百万级别。这使得将NVMe作为"扩展内存"成为可能——虽然延迟比DRAM高出约1000倍（微秒级vs纳秒级），但带宽差距远没有那么悬殊。在本项目中，专家权重从NVMe按需加载的策略正是利用了这一存储层级的性能特征。值得注意的是，由于路由器预先确定了哪些专家需要被激活，读取模式并非完全随机——系统可以精确知道需要加载哪些专家的权重块，从而发起针对性的I/O请求，这比操作系统的通用页面交换机制更高效。

关于4-bit量化与跳过反量化：模型量化是将神经网络权重从高精度浮点数（如FP16/FP32）压缩为低精度整数表示的技术。4-bit量化意味着每个参数仅用4个比特存储，相比FP16压缩了4倍。具体实现中，权重通常按组（group）量化——例如每128个参数共享一个FP16的缩放因子（scale）和零点（zero point）。打包格式将两个4-bit值存放在一个字节中。传统推理流程中，量化权重在参与矩阵乘法前需要先反量化回浮点数（即 weight_fp16 = (packed_int4 - zero_point) * scale），这一步骤本身会消耗计算资源和内存带宽，且会使内存占用瞬间膨胀4倍。作者直接以打包的4-bit形式进行计算，意味着在整数域中完成乘法和累加运算后，再统一乘以缩放因子——这避免了中间的内存膨胀和额外的数据搬运，是该实现能在极低内存下运行的关键技术之一。

稠密主干的流式加载

对于模型中稠密的主干部分（dense trunk），作者将其重新打包到一个文件中，让第L层位于一个已知的偏移位置，然后逐层流式读取。所谓"稠密主干"是指模型中不经过MoE路由、每次推理都必须参与计算的部分，包括注意力层的QKV投影矩阵、输出投影、层归一化（LayerNorm/RMSNorm）参数、嵌入层以及最终的语言模型头（lm_head）等。这部分虽然只占总参数的7%左右，但每次推理都不可或缺。

"逐层流式读取"的设计意味着系统在处理第L层时，只需要第L层的权重在内存中。当计算完成并将激活值传递给下一层后，第L层的权重即可释放。这种流水线式的内存复用模式将常驻内存需求降低到单层权重的大小加上激活值缓冲区，而非整个模型。作者通过将各层权重按固定布局排列在文件中（每层起始于已知的字节偏移），使得加载操作退化为简单的pread系统调用——无需解析复杂的文件格式，直接按偏移量读取固定长度的字节块。

真正常驻在RAM中的数据量，则成为一个用户可调节的旋钮。你想在内存里多缓存些东西以换取速度，还是极致压缩内存占用，完全由自己决定。这种设计本质上是手动实现了一个领域特化的缓存策略——哪些数据值得常驻（如高频激活的热门专家）、哪些可以每次重新加载，由用户根据自身硬件条件做出选择。

真实性能数据：速度与内存的权衡

作者在自己的机器上（双路EPYC 7763处理器、NVMe硬盘，机器里的四张GPU全程闲置）测得了一组颇具启发性的数据。AMD EPYC 7763是Milan系列的旗舰型号，基于Zen 3架构，拥有64核128线程，基础频率2.45GHz，Boost频率3.5GHz。双路配置意味着该机器拥有128个物理核心、256个硬件线程，以及16个内存通道（每颗CPU 8通道DDR4-3200），理论内存带宽可达约410 GB/s。

Zen 3架构的一个重要特征是其统一的L3缓存设计——每个CCD（Core Complex Die，核心复合体芯片）中的8个核心共享32MB L3缓存，且不再像Zen 2那样分为两个CCX。这对矩阵运算意味着更大的有效缓存工作集和更低的核心间通信延迟。然而，对于本项目中的大规模矩阵乘法，即使256MB的总L3容量相对于数GB的权重矩阵仍然微不足道，运算本质上是内存带宽受限（memory-bound）的。

尽管这台机器算力可观，作者刻意不使用其上的四张GPU，就是为了证明纯CPU路径的可行性。OpenMP在这种多核环境下可以将矩阵运算高效地分配到所有可用核心，通过#pragma omp parallel for等指令将循环迭代分发到线程池中。但需要注意的是，NUMA（Non-Uniform Memory Access，非一致性内存访问）架构下，跨socket的内存访问延迟会显著高于本地访问，这也是双路系统中并行效率无法线性扩展的重要原因。

实测数据如下：

• 最小预设下：峰值RSS（Resident Set Size，实际占用物理内存）内存占用仅 8.24 GB，速度约为 33秒/token
• 约128GB内存时：速度提升至 约20秒/token，这也是它能达到的最快速度
• 中间的所有预算档位：输出结果逐字节完全一致（byte-identical）

RSS是Linux系统中衡量进程实际物理内存占用的指标，区别于虚拟内存大小（VSZ）。VSZ包含了所有已映射但未必加载到物理内存的地址空间。在本项目中，如果作者使用了mmap系统调用来映射权重文件，则VSZ可能远大于RSS——操作系统会将文件映射到虚拟地址空间，但只有被实际访问的页面才会被调入物理内存（产生page fault后由内核处理）。8.24GB的RSS意味着在任意时刻，真正占用物理RAM的数据就只有这么多。

最后一点尤为重要。"逐字节完全一致"在数值计算领域是一个极高的正确性标准。由于浮点运算的结合律不成立（即(a+b)+c ≠ a+(b+c)），不同的计算顺序、不同的硬件指令（如FMA融合乘加）、甚至不同的线程调度都可能导致最终结果的微小偏差。能够在不同内存配置下保持位级一致，说明作者在实现中严格控制了计算顺序和数值精度，避免了任何非确定性行为——这可能意味着他使用了确定性的归约顺序（而非依赖线程竞争的原子操作），并且确保OpenMP的循环调度策略在不同配置下保持一致。这证明了这套流式加载方案在数值上是严格正确的，而非以牺牲精度为代价的近似方案。在工程上，这意味着该实现可以作为可靠的参考基准（reference implementation），用于验证其他优化实现的正确性。

当然，作者本人也坦言这绝非实用的部署方式。半分钟才能生成一个token的速度，加上需要1.7TB的空闲磁盘空间来存放checkpoint和打包后的主干，这套系统显然不适合服务任何真实业务。作为对比，在32张H100上运行同一模型，推理速度可能达到每秒数十甚至上百token——性能差距达到三到四个数量级。

工程价值：可验证的教学式实现

尽管不实用，这个项目的工程价值恰恰在于它的"纯粹"。它剥离了所有生产级框架的黑盒抽象，让K3的架构以最裸露的形式呈现出来。

无需下载1.56TB即可验证

作者贴心地考虑到了想要研究却不愿贸然下载1.56TB权重的开发者。他提供了一条快速验证路径：克隆仓库后运行 make && make test，整个过程约一分钟，无需权重、无需联网。

这个测试会构建一个13层的小模型，使用与完整模型相同的张量计算图，并对照已提交的PyTorch参考fixtures进行校验。fixtures是软件测试中的术语，指预先准备好的固定测试数据——在此场景中，就是用PyTorch运行相同输入后得到的中间激活值和最终输出，以二进制形式提交到代码仓库中，供C实现逐位比对。

校验范围包括：

• 贪婪解码（greedy decode）：即每一步都选择概率最高的token作为输出，是最简单也是最具确定性的生成策略。相比采样（sampling）方法如top-p、temperature scaling等，贪婪解码的输出是完全确定的，因此最适合用作正确性验证的基准
• 带KV缓存的增量推理路径：KV缓存（Key-Value Cache）是Transformer推理中的标准优化技术。在自回归生成过程中，每个新token的注意力计算需要用到所有历史token的Key和Value向量。如果不缓存这些中间结果，每生成一个新token都需要重新计算整个序列的注意力，计算量随序列长度二次增长（因为注意力矩阵的大小是序列长度的平方）。通过缓存已计算的KV对，增量推理只需处理最新的一个token即可。KV缓存的内存占用随序列长度线性增长，其大小等于 2 × num_layers × num_heads × head_dim × seq_len × dtype_size，对于大模型来说可能达到数GB，这也是本项目中常驻内存的重要组成部分
• 携带的KDA状态（carried KDA state）：KDA（Key-Driven Attention）是Kimi K3模型中采用的一种特殊注意力变体。与标准的Multi-Head Attention不同，KDA维护一个跨时间步传递的压缩状态矩阵，类似于线性注意力（Linear Attention）或状态空间模型（SSM）中的循环状态。这种设计允许模型在处理超长序列时避免KV缓存的线性内存增长——通过将历史信息压缩到固定大小的状态中。但这也意味着该状态必须在token之间正确传递和更新，任何数值偏差都会在后续生成中累积放大。验证KDA状态的正确传递对于确保多轮生成的一致性至关重要，也是该C实现正确性验证中最具挑战性的部分

换句话说，这不是一个"看起来能跑"的玩具，而是一个经过与主流框架逐位比对的严谨实现。

对开发者的启示

这个实验虽然极端，却揭示了几个值得深思的技术趋势。

首先，MoE架构的稀疏性为推理部署打开了新的想象空间。当激活的专家只占总量的极小比例时（K3中仅16/896≈1.8%），将权重放在更慢但更廉价的存储层级（如NVMe）上按需加载，可能比想象中更可行。这种"存储换计算"的思路实际上与操作系统中的虚拟内存/页面交换机制异曲同工——只不过这里的"页面"是神经网络的专家权重，而"换入"策略由路由器的门控决策精确指导，而非操作系统的LRU（Least Recently Used）等通用策略。这为在受限硬件上运行超大模型提供了一种思路，也暗示未来可能出现专门优化此类工作负载的存储硬件或文件系统。事实上，学术界已有研究（如FlexGen、PowerInfer等项目）在系统性地探索CPU-GPU-SSD混合推理的最优调度策略，本项目可视为这一方向的极端案例。

其次，理解一个系统的最佳方式往往是亲手重新实现它。作者没有满足于调用现成API，而是从C99和libm开始，一层层复现K3的完整计算图。这种"造轮子"式的学习，带来的架构理解深度是使用高级框架难以企及的。在高级框架中，一个model.generate()调用背后隐藏了数千行涉及内存管理、设备调度、数值优化的代码；而在这个C99实现中，每一步矩阵乘法、每一次内存分配都是显式的、可审计的。这种方法论在系统编程社区有着悠久的传统——从Linus Torvalds手写Git，到Fabrice Bellard用C实现的各种系统（QEMU、FFmpeg、TCC），再到Andrej Karpathy的llm.c项目（用纯C实现GPT-2训练），都体现了"从第一性原理出发"的工程哲学。

最后，这也提醒我们：性能与资源之间的权衡曲线远比"能否运行"这个二元问题丰富。从8.24GB到128GB，从33秒到20秒，中间存在一整条连续可调的曲线，而输出的正确性始终得到保证。对于追求极致理解与掌控的工程师而言，这样的透明度弥足珍贵。值得注意的是，从8GB到128GB内存增长了16倍，但速度仅从33秒提升到20秒（约1.65倍），这说明瓶颈并非单纯的I/O等待，CPU端的矩阵乘法计算本身也是重要的时间消耗——毕竟没有BLAS优化和GPU加速，纯C实现的矩阵运算效率远低于硬件理论峰值。更具体地说，这台EPYC双路系统的理论FP32峰值算力约为4.6 TFLOPS，而一张H100的FP16算力为990 TFLOPS（使用Tensor Core更可达近2000 TFLOPS），硬件层面的算力差距就已超过两个数量级。20秒/token的下限，本质上反映的是CPU算力天花板而非存储带宽瓶颈。

项目已在GitHub开源，感兴趣的开发者可以先跑一分钟的测试，再决定是否投入那1.7TB的磁盘空间。