AirLLM：分层加载大模型，怎样算运行成本

AirLLM 是一个 Python 推理工具，会按层加载模型权重。完整 checkpoint 保存在磁盘上，计算某一层时才把它的权重传入内存。这样，大模型可以在装不下全部权重的 GPU 上运行；代价是反复搬运数据。因此，选机器时要一起算 SSD 空间、主机内存和等待时间。

原创原理图：磁盘、主机暂存与 GPU 各自承担不同的资源开销。

本文内容：AirLLM 分层加载改变了什么？ · 安装并发送一个短请求 · SSD 与主机内存怎样预算？ · 用户的计时记录说明了什么 · AirLLM 一次任务要花多少钱？ · 与常驻推理或 API 比较 · 来源与下一步

先看 AirLLM 官方仓库。想比较把更多权重留在内存里的方案，可以接着读本地推理工具指南English与 Strata 配置说明English。

AirLLM 分层加载改变了什么？

源码把 checkpoint 拆成磁盘上的分层文件，在某一层运行前加载权重，运行后释放；预取可以让下一层的加载与当前计算重叠。这降低了同时驻留在 GPU 的权重占用，也增加了传输和暂存工作。激活、缓存及运行时缓冲区仍需要空间。

项目宣传 70B 模型能在 4GB GPU 上运行，并列出了不同模型的配置。复现时要对应 checkpoint、架构、压缩方式、输入长度和机器条件。能加载并跑完回答，说明这个配置满足容量需求；完整响应时间和输出质量决定它是否适合你的任务。

如果只是偶尔做离线分析，又已经有一张小显存显卡，较长等待时间可能可以接受。若要做交互聊天或多人服务，应比较更小的常驻模型、更大内存的机器和托管 API，并记录各自的精度与运行方式。

安装并发送一个短请求

先创建独立 Python 环境，再按所选模型的要求安装依赖。官方示例使用 AutoModel 根据配置选择实现；部分架构要求特定 Transformers 版本或 CUDA 包，需要采用对应说明。

python -m venv .venv
source .venv/bin/activate
pip install airllm

下面根据官方 Qwen3-32B 示例改写，面向 CUDA 机器。首次运行会下载模型并创建分层文件，执行前先安排缓存目录和磁盘空间。

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
encoded = model.tokenizer(
    ["Explain why a delivery date might need manual review."],
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,
)
result = model.generate(
    encoded["input_ids"].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True,
)
print(model.tokenizer.decode(result.sequences[0]))

先确认拿到可解码的回答，再把输入和输出长度增加到实际任务规模。把下载、拆分与后续推理的耗时分别记录，保留 checkpoint 修订版和包版本，便于区分首次准备与重复运行成本。

官方安装与配置说明介绍了分层文件目录、预取和压缩选项；模型本身的访问及许可条件可从模型指南English继续查。

SSD 与主机内存怎样预算？

准备阶段可能同时保留原始 checkpoint 和分层文件。layer_shards_saving_path 指定分层文件位置。delete_original 会在拆分后移除原始文件；首次检查配置、或其他工具也用同一缓存时，先保留原始文件更方便排查。

按每个参数两字节计算，70B 原始权重约占 140 GB，使用十进制单位。若再保留一份同样大小的分层表示，原始权重合计约 280 GB，还没算元数据和临时文件。实际磁盘预算要看下载清单及压缩格式；MoE 模型的完整专家权重可能远多于每个 token 激活的参数。

GPU 只持有当前层，也仍需要主机 RAM 暂存数据和支撑运行时。某些架构还会增加主机常驻结构。官方新模型示例分别列出了 RAM、磁盘和依赖要求，买机器前应逐项核对。

官方 FAQ 将拆分时的 MetadataIncompleteBuffer 与磁盘耗尽联系起来。先检查剩余空间和部分分层文件的完整性，再重新运行。遇到因模型类不匹配导致的 max() arg is an empty sequence，项目建议改用 AutoModel。

用户的计时记录说明了什么

在 2026 年 10 月 2 日的 M4 Mac mini 测试中，Kunal Vohra 使用 16GB 统一内存、Crucial X9 USB SSD、AirLLM 2.11.0、MLX 0.29.3 和 Transformers 4.46.3。修正这套 Mac 环境的问题后，Llama 3.1 8B 生成 20 个 token 约需 6.5 分钟，即每 token 19.6 秒。结果段与计时算术的单位是 token；文中 70B 的耗时是推算，没有运行该 checkpoint。比较 Mac 结果时，要同时看软件版本、后端和硬件。

2026 年 8 月 4 日，TyrelCB 在 GB10 上比较压缩方式，使用 Qwen2.5-32B-Instruct、同一提示和十个输出 token。记录是未压缩 13.3 秒/token、8bit 50.5、4bit 106.7；分层文件从 62G 缩到 31G 和 18G。这组配置用更小文件换来了更长处理时间。为了速度选 compression='4bit' 或 compression='8bit' 前，先比较自己机器上的完整任务耗时。

AirLLM 一次任务要花多少钱？

AirLLM 软件采用 Apache 2.0；选用的模型有自己的许可证。部署主要开销是机器、租用时间、SSD、电费和配置工作。

以整台机器 $1/小时为示例，计费 30 分钟是 $0.50，两小时是 $2。把下载、拆分、推理及计费中的空闲时间都算进租用时长，再加单独收费的磁盘和传输。用自己的电脑时，比较硬件购置、整机电费，以及任务占用机器多久。

每份可用结果的成本等于总账单除以留下的结果数。例如 $2 的任务得到八份可用结果，计算成本是每份 $0.25。便宜的小时单价可能被更长运行时间或重试抵消，应比较完整任务成本。

LLM 成本计算器使用现有支持的常规部署档位，其模型内存公式没有描述 AirLLM 的分层加载。AirLLM 可用上面的时长算式配合实际耗时估算；现有档位的口径见计算方法。

与常驻推理或 API 比较

保持任务、提示和验收条件相同。分别记录首次运行与热启动运行的表现，以及精度、输入输出长度、VRAM 和主机 RAM 峰值、SSD 剩余空间及完整耗时；失败尝试也计入总成本。

来源与下一步

核验于 2026-10-13：官方 README 与模型要求、分层加载实现、Apache 2.0 软件许可证。

先选一个 checkpoint 和短任务，跑通后再扩到实际输入和输出长度。浏览模型指南English、本地工具选项English和预算包含项，比较适合你的完整部署方案。