大模型本地推理最常见的限制之一就是显存。

普通消费级显卡通常只有 8GB、12GB 或 16GB 显存，而 70B、235B 甚至更大的模型，完整加载权重时往往需要远高于这个数字的显存容量。

lyogavin/airllm 提供了一种不同的思路：不把整个模型一次性加载进 GPU，而是在推理过程中按层加载。

这样做的结果是，显存需求可以明显下降。

官方项目目前给出的示例包括：

• 8B 级模型约 1～2GB 显存；
• 30B～47B MoE 模型约 1～3GB；
• Qwen3-235B 约 3GB；
• Llama 70B 全精度约 4GB；
• Llama 3.1 405B 约 8GB；
• DeepSeek-V3 约 12GB。

AirLLM 近期还增加了 Kimi K3 支持。具体显存占用仍会受模型结构、框架版本和运行环境影响，因此这些数字更适合作为项目示例，而不是所有机器都能完全复现的固定值。

AirLLM 是怎么降低显存需求的？

传统模型推理大致是：

模型全部权重
    ↓
加载到 GPU
    ↓
开始推理

因此显存不足时，模型根本无法启动。

AirLLM 的思路更接近：

模型权重在磁盘
     ↓
加载第 1 层
     ↓
GPU 计算
     ↓
释放
     ↓
加载第 2 层
     ↓
继续计算

也就是说：

显存占用
≈
单层模型大小

而不是整个模型大小。

官方说明也明确表示，AirLLM 只会让一层权重同时驻留在 GPU，因此显存需求更多取决于“单层大小”，而不是模型的总参数量。

这种方式有什么代价？

显存降低并不等于没有成本。

最大的代价通常是：

磁盘 IO。

因为推理过程中要不断从磁盘读取模型层。

因此一台机器的整体性能会变成：

SSD
 ↓
PCIe / 内存
 ↓
GPU
 ↓
计算

如果磁盘速度比较慢，即使 GPU 性能不错，也可能被模型加载速度拖慢。

所以使用 AirLLM 时，磁盘往往比普通 LLM 部署更加重要。

AirLLM 适合哪些场景？

比较适合：

• 低显存 GPU 实验；
• 超大模型功能验证；
• AI 模型兼容性测试；
• 个人研究环境；
• 大模型开发实验；
• 模型架构研究。

不太适合：

• 高并发在线 API；
• 对低延迟要求很高的聊天服务；
• 大量用户同时访问；
• 对首 Token 延迟敏感的生产业务。

因为 AirLLM 的主要目标是：

让模型“跑得起来”

而不是：

让模型“跑得最快”

是否一定需要 GPU？

不一定。

AirLLM 在 2024 年后已经加入 CPU inference 支持。

但从实际体验来看，大模型纯 CPU 推理速度通常会明显低于 GPU。

因此更常见的用途还是：

CPU + GPU + 大容量 SSD

服务器配置怎么选？

AirLLM 的服务器配置和普通 Web 项目完全不同。

重点不是：

带宽多大

而是：

GPU 显存
SSD 容量
SSD 速度
系统内存

小模型测试

例如 7B、8B：

• 4～8 核 CPU；
• 16GB 内存；
• 50GB～100GB SSD；
• 4GB 以上 GPU 显存。

70B 模型实验

可以考虑：

• 8 核 CPU；
• 32GB 内存；
• 150GB～300GB NVMe；
• 4GB～8GB GPU 显存。

200B 以上模型

更建议：

• 16 核以上 CPU；
• 64GB 内存；
• 500GB 以上 NVMe；
• 根据模型选择 GPU。

需要注意：

显存小 ≠ 磁盘需求小

AirLLM 首次运行模型时会把模型拆分成多个 layer shard，并保存在磁盘。官方 README 也特别提醒，这一步非常占用存储空间。

云服务器怎么选？

如果准备部署 AirLLM，建议重点看：

• 是否提供 NVIDIA GPU；
• GPU 型号；
• CUDA 兼容性；
• NVMe 容量；
• NVMe 读写性能；
• 系统内存；
• 是否方便扩展磁盘。

如果使用莱卡云，可以把它作为 AirLLM 实验环境的一个候选方案，根据实际 GPU、内存和 NVMe 配置进行选择。

对于 AirLLM 来说，服务器品牌本身不是关键，更重要的是硬件组合是否匹配目标模型。

如果已有其他 GPU 云服务器、自建工作站或闲置显卡机器，也可以采用相同方案。

Ubuntu 环境准备

建议使用比较新的 Ubuntu。

更新系统：

apt update
apt upgrade -y

安装基础工具：

apt install -y \
git \
curl \
wget \
python3 \
python3-pip \
python3-venv \
build-essential

创建 Python 环境：

python3 -m venv ~/airllm-env

启用：

source ~/airllm-env/bin/activate

升级 pip：

pip install -U pip

安装 AirLLM

官方最简单的安装方式：

pip install airllm

检查：

python -c "import airllm; print('airllm ok')"

官方 Quick Start 当前也是直接通过 PyPI 安装 airllm。

最简单的推理示例

可以创建：

nano test_airllm.py

写入：

from airllm import AutoModel

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B"
)

input_text = [
    "What is the capital of China?"
]

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=32,
    use_cache=True,
    return_dict_in_generate=True,
)

print(
    model.tokenizer.decode(
        generation_output.sequences[0]
    )
)

运行：

python test_airllm.py

官方现在推荐使用 AutoModel.from_pretrained()，可以自动识别多种模型类型。

模型第一次运行为什么很慢？

第一次加载模型时，AirLLM 会：

下载模型
 ↓
拆分模型
 ↓
生成 layer shards
 ↓
保存到磁盘

因此第一次启动往往明显慢于后续运行。

官方也特别说明：

模型会先被拆分并按层保存。

因此需要确保 Hugging Face cache 有足够空间。

建议单独准备模型盘

如果服务器系统盘只有：

50GB

很容易不够。

更合理的结构可以是：

/
系统盘

/data
大容量 NVMe

/data/huggingface
模型缓存

/data/airllm
layer shards

然后设置：

export HF_HOME=/data/huggingface

可以写进：

~/.bashrc

layer_shards_saving_path

AirLLM 支持指定拆分模型保存路径。

例如：

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    layer_shards_saving_path="/data/airllm/qwen3-32b"
)

这样可以避免大量模型文件堆积在系统盘。

官方配置项中也明确提供了 layer_shards_saving_path。

磁盘不够怎么办？

AirLLM 还提供：

delete_original=True

例如：

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    delete_original=True
)

这个选项会在完成模型转换后删除原始 Hugging Face 模型，只保留拆分后的版本。

官方说明，这可以显著降低磁盘占用。

但建议第一次操作前确认：

• 模型已经成功转换；
• 不需要保留原始文件；
• 网络能够重新下载模型。

开启模型压缩

AirLLM 支持：

4bit
8bit

模型压缩。

先安装：

pip install -U bitsandbytes

然后：

model = AutoModel.from_pretrained(
    "garage-bAInd/Platypus2-70B-instruct",
    compression="4bit"
)

或者：

compression="8bit"

官方表示这种基于 block-wise 权重量化的压缩主要用于减少磁盘加载量，从而提升推理速度。

AirLLM 和普通量化有什么区别？

传统量化通常会同时考虑：

权重
+
激活值

而 AirLLM 的主要瓶颈是：

磁盘 → GPU

因此它更关注权重体积。

官方解释也指出，AirLLM 的压缩主要是为了减少磁盘读取的数据量。

Kimi K3 需要特别注意

AirLLM 近期已经加入 Kimi K3 支持。

但是官方说明 Kimi K3 当前还额外要求：

• compressed-tensors；
• flash-attn；
• CUDA 12 构建的 PyTorch；
• Transformers 4.56.x。

尤其需要注意：

Transformers 5.x

当前可能无法加载 Kimi K3 的 remote code。

因此不要直接：

pip install -U transformers

升级到最新版。

部署 Kimi K3 前应该固定依赖版本。

检查 GPU

运行：

nvidia-smi

确认：

• GPU 型号；
• CUDA Driver；
• 显存；
• 当前使用量。

PyTorch 检查：

python - <<'PY'
import torch

print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))
print(torch.cuda.get_device_properties(0).total_memory / 1024**3)
PY

为什么 NVMe 很重要？

AirLLM 的工作流程不断执行：

读取模型层
 ↓
传输
 ↓
GPU 运算

因此 SATA SSD 和 NVMe 的体验可能差别很大。

如果准备长期使用 AirLLM，建议优先选择：

NVMe SSD

而不是单纯为了节省成本选择机械盘。

尤其是 70B、235B、405B 这类模型，模型文件很大，磁盘性能会直接影响推理速度。

常见磁盘报错

官方 FAQ 中有一个比较典型的错误：

MetadataIncompleteBuffer

很多情况下是因为：

磁盘空间不足

导致模型拆分过程中生成了不完整文件。

可以先检查：

df -h

Hugging Face 缓存：

du -sh ~/.cache/huggingface

如果模型放在数据盘：

du -sh /data/*

做成 API 是否合适？

可以自行使用：

• FastAPI；
• Flask；
• Gradio；

封装推理接口。

例如：

客户端
 ↓
FastAPI
 ↓
AirLLM
 ↓
GPU

但需要注意：

AirLLM 并不是以高并发推理为主要目标。

如果同时来了很多请求：

Request 1
Request 2
Request 3
Request 4

所有任务都会争抢：

• GPU；
• SSD；
• 内存；
• 模型层读取。

因此不建议把它直接当成高并发生产推理框架。

更适合什么用途？

AirLLM 更适合：

研究
实验
低成本验证
超大模型测试

而不是：

商业高并发 API

如果需要真正高吞吐在线推理，更应该考虑：

• vLLM；
• SGLang；
• TensorRT-LLM；
• 多 GPU Tensor Parallel。

但这些方案通常需要更多显存。

一个比较合理的部署结构

可以采用：

莱卡云 / 其他 GPU Server
│
├── Ubuntu
├── NVIDIA Driver
├── CUDA
├── Python venv
├── AirLLM
│
├── /data/models
├── /data/airllm
│
└── FastAPI
       ↓
   Internal API

如果只是自己测试，可以完全不部署 Nginx。

通过：

ssh

直接运行 Python 即可。

日常监控

CPU：

htop

内存：

free -h

GPU：

watch -n 1 nvidia-smi

磁盘：

df -h

IO：

iostat -xz 1

如果没有 iostat：

apt install -y sysstat

对于 AirLLM 来说：

iostat

往往比单纯看 GPU 使用率更有参考价值。

部署建议

lyogavin/airllm 最大的特点并不是“让小显卡变成大显卡”，而是通过按层加载模型，把原本需要大量显存的问题转移到磁盘和数据搬运层面。

因此部署 AirLLM 时，不能只看 GPU 显存。

更值得关注：

GPU
+
系统内存
+
NVMe
+
磁盘容量

如果需要远程搭建实验环境，可以把莱卡云服务器作为候选方案之一，根据可提供的 GPU 型号、NVMe 空间和系统内存进行选择；已有其他 GPU 云平台或自己的显卡服务器也可以使用相同方案。

对于普通 7B、8B 模型，AirLLM 的意义并不一定很大；真正比较有意思的是显存明显装不下的 70B、235B、405B 等超大模型实验。

如果目标是研究和验证，可以优先保证大容量 NVMe 和合适的 GPU，再根据实际推理速度决定是否进一步升级硬件。相比盲目增加显存，理解 AirLLM 的“显存换磁盘 IO”机制更加重要。