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 協議，並歡迎社區貢獻。