AirLLM专家级加载实现2.8T Kimi K3仅需3.72GB显存
当2.8万亿参数量的大模型连单层都塞不进单张48GB显存的专业显卡时，还能完成完整推理吗？开源项目AirLLM给出了肯定答案：在RTX 6000 Ada上跑通了完整的Kimi K3，端到端测试显示峰值显存仅为3.72GB。不过这份成绩背后，生成速度相当有限，大约需要5分钟才能产出一个token。
从逐层加载到专家级调度
AirLLM的核心目标一直是让远超显存容量的大模型，能够在普通设备上完成推理。项目最早在2023年发布，最初的方案是逐层加载模型：从硬盘读取当前计算需要的模型层，送入GPU完成计算后立即释放显存，再读取下一层模型。依靠这种方式，项目先后支持了Llama 3.1 405B、DeepSeek-V3 671B等超大规模模型，只要单层模型能够适配显存，整个模型就可以完整运行。
不过到了Kimi K3这套方案遇到了瓶颈。作为一款超宽的MoE模型，Kimi K3总参数量达到2.8万亿，每次生成token时仅会调用约1040亿参数。模型内部共有896个路由专家，每个token只会从中选中16个参与计算。按照开发者的估算，K3的单层权重在保存时约17GB，展开计算后则接近56GB，这已经超过了测试所用的48GB显存，传统的逐层加载方案根本无法启动。
把加载单位压缩到专家级别
为了突破显存限制，开发者将模型加载的单位从“层”进一步缩小到了“专家”。当路由系统选中16个需要调用的专家时，AirLLM只会从硬盘读取这16个专家的权重，计算完成后立即释放对应的显存空间，其余未被选中的880个专家则继续留在硬盘中，无需占用任何系统资源。
按照测算，K3单层全部专家展开后约55GB，但当前token实际需要的专家权重仅约1GB，大幅降低了单次加载的数据量。整个模型的参数量没有任何缩减，只是每次仅加载当前计算必需的极小一部分权重。
3.72GB显存背后的细节优化
仅仅缩小加载单位还不够，项目还针对数据传输和存储做了额外优化。Kimi K3的专家权重采用MXFP4格式保存，AirLLM让这些权重在从硬盘通过PCIe总线传输到GPU的过程中，始终保持打包状态，直到抵达GPU端后才会按照专家展开，进一步减少了显存占用和数据传输量。
硬盘存储方面也有一笔额外的节省。AirLLM通常会先将模型重新切分，原始权重和处理后的分片各占一份，但K3的权重分片本身已经按照模块划分得十分清晰，开发者直接使用硬链接指向原文件，省去了复制第二份1.56TB权重的步骤，不仅节省了硬盘空间，还将模型准备过程从大规模文件复制缩短到了几秒的链接创建时间。
至此，3.72GB的峰值显存占用就不难理解了：显存中从未存放过完整的K3模型，仅临时保存当前正在计算的专家权重，节省下来的显存资源，最终转化为硬盘I/O开销、PCIe传输带宽占用和更长的等待时间。
和M1 Max方案的差异对比
此前有项目在64GB M1 Max上完成了Kimi K3的推理，速度约为14.6秒生成一个token，而AirLLM的方案仅能达到约5分钟一个token，纸面速度相差近20倍。不过这两组测试并没有直接可比性：前者围绕K3做了专门的Metal路径优化、专家预取和缓存优化，目标是尽可能提升推理速度；而AirLLM的核心目标是先让原本无法在显卡上运行的模型完整跑通，优先压低峰值显存占用。
当权重无法常驻显存时，大模型的推理工作就会从“计算主导”转向“数据搬运主导”，SSD读取速度、专家预取的准确性、缓存命中率、PCIe传输效率都会直接影响最终的推理速度。
工程价值大于实际实用性
以当前的速度来看，这套方案显然还无法满足日常使用需求，但它的工程意义却十分扎实。一条完整的大模型推理链路跑通后，后续的优化就有了明确的基线可以参考：比如提升专家缓存的命中率、优化磁盘延迟的预取策略、实现I/O和计算的并行处理、减少连续token对同一批专家的重复请求等，每一项优化都可以直接和当前的基线数据对比。
这种逐专家流式加载的思路，也为更大规模的MoE模型提供了可行的推理路径。当遇到单层模型超过显卡显存容量的情况时，开发者不必在入口处停滞，可以继续将调度单位向下拆分，找到适配当前硬件的最小加载单元。
这套方案目前也有一些明确的实用场景：比如在租用大量GPU前验证模型权重是否完整、测试模型架构和远程代码的兼容性、运行小规模离线研究任务，或是作为新型存储与缓存方案的原型验证平台。虽然无法让普通用户立刻拥有本地的Kimi K3，但它为后续的开发者扫清了部分技术障碍。
部署的基础要求
想要尝试运行Kimi K3，首先需要满足一定的环境条件。项目提供了快速安装命令：
pip install airllm compressed-tensors flash-attn不过实际的环境要求远不止这些：当前需要CUDA 12版本的PyTorch，transformers库需要锁定在4.56.x版本，同时模型代码会强制使用Flash Attention。完整的K3权重约占用1.56TB存储空间，因此必须准备高速固态硬盘作为存储载体。
总体来看，这项工作的评价可以简单总结为：实用性暂时有限，但工程探索价值显著。开发者已经完成了让超大规模模型在有限显存设备上运行的第一步，后续的速度优化还有很大的提升空间。
相关参考资源
- AirLLM官方项目仓库：https://github.com/lyogavin/airllm
- Kimi K3模型官方介绍：https://huggingface.co/moonshotai/Kimi-K3
- Deltafin项目仓库：https://github.com/gavamedia/deltafin
