AirLLM：单张4GB GPU推理2.8T参数的Kimi K3

AirLLM 是一个开源推理框架，核心理念是打破“显存必须装下整个模型”的限制。它并非把完整模型常驻 GPU，而是在推理过程中逐层加载，每次只把一层放到显存中，因此所需显存主要由单层大小决定，而不是模型总参数量。项目最新更新（2026 年 7 月）加入了对 Kimi K3（2.8T 参数）的支持，成为目前最大的开源模型，并可在单张 RTX 6000 Ada 上以约 3.72GB 显存完成端到端推理。K3 使用了“按专家流式加载”机制，只加载当前 token 实际路由到的专家，进一步降低显存占用。

K3 的接入也带来一些额外要求：需要安装 compressed-tensors 和 flash-attn，因为 K3 的模型代码强制要求 flash attention；需要使用 CUDA 12 版本的 PyTorch，因为目前还没有为 CUDA 13 预编译的 flash-attn wheel；transformers 版本需使用 4.56.x，因为该模型的 remote code 无法在 5.x 上加载。使用方式非常简洁，安装 airllm 后，只需通过 AutoModel.from_pretrained() 传入 Hugging Face 模型 ID 或本地路径，就能像普通 transformer 模型一样生成。示例中，Qwen/Qwen3-32B 可直接运行，同一条代码也可切换到 Qwen3-235B-A22B（约 3GB 显存）或 deepseek-ai/DeepSeek-V3（671B，约 12GB 显存）。首次推理时，原始模型会被拆分并按层保存，因此 Hugging Face 缓存目录需要有足够磁盘空间。

AirLLM 还提供基于块级量化的模型压缩，开启后可带来最高约 3 倍推理加速，且精度损失几乎可忽略。启用方法是安装 bitsandbytes，并在初始化时传入 compression='4bit' 或 compression='8bit'。与常规量化不同，AirLLM 的瓶颈主要在磁盘加载，因此只量化权重、不需要处理激活值，更容易保持精度。配置方面，AirLLM 支持 compression、profiling_mode、layer_shards_saving_path、hf_token、prefetching、delete_original 等选项。prefetching 默认开启，可将模型加载与计算重叠，提升约 10% 速度；delete_original 可在拆分后删除原始模型以节省约一半磁盘空间。MacOS 用户也可以在 Apple Silicon 上运行，需安装 mlx 和 torch，并能用同样的 Python 代码跑 70B 级别模型。

在模型兼容性上，AirLLM 基本覆盖主流开源模型，包括 Llama 2/3/3.1/3.3/4、Qwen 1/2/2.5/3（含 MoE 和 FP8）、DeepSeek V2/V3/R1、Mistral 与 Mixtral、Phi、Gemma、ChatGLM、Baichuan、InternLM、Yi 等。按官方示例，约 8B 模型只需 1–2GB 显存，Qwen3-235B 约 3GB，Llama 3.1 405B 约 8GB，DeepSeek-V3 约 12GB。AirLLM 的版本迭代也记录了它的扩展路径：2023 年 11 月发布初始版本；12 月加入 safetensors 支持、ChatGLM/QWen/Baichuan/Mistral/InternLM 支持、AutoModel 自动检测、Mixtral 支持以及 MacOS 上运行 70B 模型的能力；2024 年 4 月原生支持 Llama3 70B 在 4GB 单 GPU 上运行，7 月加入 Llama3.1 405B 和 8bit/4bit 量化；2024 年 8 月加入 Qwen2.5 和 CPU 推理；2026 年 6 月的 v3.0 增加 FP8 模型支持并可运行 DeepSeek-V3 与 Qwen3-235B；2026 年 7 月则加入 Kimi K3 支持。

常见问题方面，如果遇到 MetadataIncompleteBuffer 错误，通常是磁盘空间不足，因为模型拆分过程非常消耗磁盘；如果加载 QWen 或 ChatGLM 时出现 ValueError，应改用 AutoModel 而不是 AirLLMLlama2；受门控模型需要传入 hf_token；tokenizer 缺少 padding token 时，可以关闭 padding 或手动设置。项目目前已有 25.1k stars、2.8k forks，采用 Apache-2.0 协议，并欢迎社区贡献。