如果你用消费级显卡跑过大模型，大概率遇到过这个场景：下载了 70B 参数的模型权重，兴致勃勃地运行，显存直接爆了。然后你开始研究量化、剪枝、蒸馏这些优化手段，最后妥协到 4-bit 量化版本，效果勉强能用，但总感觉差了点什么。

AirLLM 走了一条不依赖量化的路。 它的核心思路很简单：推理时每次只在 GPU 显存中保留一层模型参数，计算完就换下一层。这意味着显存需求取决于模型的层大小，而不是总参数量。具体来说，一个标准的 70B Llama 模型，在 airllm 下只需要大约 4GB 显存就能跑起来。

更关键的是它对 MoE 架构的针对性优化。 MoE（混合专家）模型中，每个 token 实际上只经过少数几个专家的计算，但传统加载方式会把所有专家都塞进显存。airllm 的做法是只流式加载当前 token 路由到的那个专家，不碰其他几百个。671B 的 DeepSeek-V3 因此可以在约 12GB 显存上运行，而最新支持的 Kimi K3——参数量高达 2.8T——在单张 RTX 6000 Ada 上仅占用 3.72GB 显存。

安装：

pip install airllm

调用方式也很直接，这代码直接摘自 README：

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
# 换更大模型只需改一行：
# model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")

input_tokens = model.tokenizer(input_text,
    return_tensors="pt", return_attention_mask=False,
    truncation=True, max_length=128, padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20, use_cache=True,
    return_dict_in_generate=True)

AutoModel 会自动识别你传入的模型类型，不用手动指定是 Llama 还是 Qwen 还是 ChatGLM。基础版不需要额外依赖，直接就能跑。如果想提速，装一个 bitsandbytes 后加 compression='4bit' 参数，能获得约 3 倍的推理速度，仅量化权重不量化激活值，精度损失几乎不可察觉。

项目支持的模型覆盖面相当广。除了 Llama、Qwen、DeepSeek 这些热门系列，还包括 ChatGLM、Baichuan、InternLM 等国产模型，以及最新的 Kimi K3。作者是华人开发者 Gavin Li，项目从 2023 年底开始迭代到现在，v3.1.0 是 7 月 29 日刚发的版本。

但 airllm 的代价也很实在：速度。 因为每次都要从磁盘读一层模型到 GPU，推理延迟会比全量加载的方案高出不少。默认模式的瓶颈在磁盘 I/O，改用 4-bit 压缩后加载体积变小，但依然不如直接全量跑在显存里快。README 中提到的 prefetching 机制可以重叠加载和计算，提升约 10%，但整体延迟仍然不适合需要实时响应的场景。

另一个容易踩的坑是磁盘空间。首次运行时，airllm 会先把原始模型按层拆分保存到磁盘。这个过程非常消耗空间，如果 HuggingFace 缓存目录所在的磁盘不够大，会报 SafetensorError 或者 MetadataIncompleteBuffer 错误。README 的 FAQ 部分专门列出了这个问题的解决方法：扩展磁盘空间或清理 HF 缓存后重试。

Kimi K3 的配置门槛尤其需要注意。它强制依赖 flash-attn，而 flash-attn 目前只有 CUDA 12 的预编译 wheel，所以必须用 CUDA 12 编译的 PyTorch。此外还需要 transformers 4.56.x 版本，5.x 上会报错。这些约束是 K3 模型代码本身要求的，不是 airllm 的设计问题，但配置起来确实比普通模型麻烦。

如果你属于这几类人，airllm 会很适合你。 第一类：手上只有一张 4-8GB 显存的消费级显卡，但想玩 70B 或更大的模型，又不想接受量化带来的质量损失。第二类：做模型评估和对比的开发者，需要在多模型之间快速切换，airllm 的 AutoModel 接口让你一行代码换模型。第三类：对 MoE 模型的工作原理感兴趣的研究者，airllm 的分层加载机制让你能直观观察每个 expert 的加载过程。

如果你追求的是低延迟交互或高吞吐量服务，airllm 不太适合。 它的设计目标是在极端受限的硬件上"能跑"，而不是"跑得快"。生产环境中需要高并发推理的场景，应该考虑 vLLM 或 llama.cpp 这类注重吞吐量优化的方案。同样，如果你已经有大显存显卡（比如 48GB 以上），用标准 transformers 加载全量模型会获得更好的响应体验。

同类方案中，llama.cpp 走的是量化路线，通过 GGUF 格式把模型压缩到低比特位宽，典型用例是 4-bit 量化的 70B 模型跑在 48GB 消费卡上。airllm 和 llama.cpp 的差异在于：前者完全不依赖量化就能跑原始精度的模型，代价是更慢；后者通过量化大幅压缩模型体积，在速度和精度的平衡上做得更好。Ollama 底层用的就是 llama.cpp，面上多了一层易用封装。vLLM 侧重的是推理服务的吞吐量优化，需要足够的显存来存放完整模型，和 airllm 的场景几乎没有重叠。

项目地址：https://github.com/lyogavin/airllm

竞品参考：
- llama.cpp：https://github.com/ggml-org/llama.cpp
- Ollama：https://github.com/ollama/ollama
- vLLM：https://github.com/vllm-project/vllm