AirLLM（lyogavin/airllm）：用逐层流式加载把 671B 模型塞进 4GB 显存，代价是每个 token 重读一遍权重

一、导读

一张 4GB 的消费级显卡，能不能跑 70B 模型？AirLLM 给出的答案是：能跑，但不是能用的「跑」。它的做法是把 Hugging Face checkpoint 按层切成磁盘分片，用 transformers 的 forward hook 在每一层执行前把权重从磁盘流进 GPU、执行完立刻释放，同一时刻显存里只有一个模块。于是显存需求从「模型总大小」变成「最大单层 + 激活 + workspace」——70B 约 4GB、405B 约 8GB、671B 的 DeepSeek-V3 约 12GB、2.8T 的 Kimi K3 实测 3.72GB。真正值得研究的不是这些显存数字，而是它用 I/O 换容量的工程取舍，以及那个绕不开的代价：自回归解码每生成一个 token 都要重穿一遍模型，社区实测 70B 在 NVMe 上约 5–35 秒/token。它是「存在性证明」，不是「生产 serving」。

二、项目速览

项目	详情
仓库	`lyogavin/airllm`
作者	Gavin Li（@lyogavin），Anima AI 创始人兼 CEO；GitHub 公开仓库 68 个
主语言	Jupyter Notebook（核心为 Python 包）
Star 总数 / 当日涨星	36,402 / 541（GitHub Trending daily，抓取日 2026-10-11）
Fork / Open Issues	3,814 / 160
License	Apache-2.0
首次创建 / 最近推送	2023-06-12 / 2026-10-11
最新版本	v4.0.0（2026-09-05，PyPI 同步发布）：`6GB` 显存微调 125B 模型
近 30 天 Release	v3.1.0（Kimi K3 2.8T 单卡）、v3.2.0（Qwen3.8-27B @3.33GB）、v3.3.0（Flash-Next @5.95GB）、v4.0.0（训练）
核心主张	不量化、不蒸馏、不剪枝，仅靠分层流式加载降低显存峰值

三、为什么是它：问题背景与定位

痛点：参数量涨得比显存快。 70B 模型 fp16 约 140GB，常规推理要么两张 A100，要么靠量化/蒸馏/剪枝压到单卡。这三种「压缩」路线各有代价：量化牺牲精度且对异常值敏感，蒸馏要重训，剪枝要重新调。AirLLM 换了一条路——不动模型，动数据通路。

它的定位非常清楚：不是推理引擎，而是「让装不下的 checkpoint 至少能被执行」的访问层。README 的第一句话就是「让 70B 大模型在单张 4GB GPU 卡上运行」；而这个「运行」指的是功能上可执行，不是交互上可用。第三方评测把这一点总结得很到位：AirLLM 优先解决容量，把速度留给系统设计去追。

涨星动因（抓取日 2026-10-11，+541）有三重叠加：

叙事张力极强。 「4GB 跑 70B」是一句天然传播的话术，在显存焦虑最重的本地推理社群（r/LocalLLaMA、HN）反复被讨论与反驳，讨论本身带来持续曝光。
版本节奏密集且有硬数字。 2026 年 6 月底到 9 月初连发 5 个版本，每个版本都绑定一个具体模型的端到端实测显存（Qwen3.8-27B @3.33GB on RTX 3090、Flash-Next @5.95GB on RTX 4090、Kimi K3 @3.72GB on RTX 6000 Ada），并且每次都是「刚发布的新模型当天就能跑」。这一点对涨星贡献最大——它把自己变成了新模型的「第一个可用出口」。
v4.0.0 把能力从推理延伸到训练。 冻结权重逐层流式读盘、只让 LoRA adapter 常驻，使 125B 模型在 6GB 显存下可微调——这是 2026 年 9 月的主线更新，把受众从「想跑大模型的人」扩展到「想微调大模型的人」。

四、【重点】架构原理

4.1 整体架构：以 forward hook 为核心的三级数据流

AirLLM 最关键的架构决策是：不自研前向计算，而是把 transformers 的真实模型实例化在 meta device 上，只在模块边界挂钩子搬权重。airllm_base.py（44.5KB）的类 docstring 把这条主线写得非常明确：

The real transformers model is instantiated on the meta device (no memory used) and owns the full forward / generation logic. AirLLM only attaches forward hooks to each big module (embeddings, every decoder layer, the final norm and the lm_head) to stream that module's weights disk → GPU right before it runs and free them right after, prefetching the next module on a worker thread.

完整数据流如下：

┌── 磁盘层：完整 checkpoint + 逐层 shard ─────────────────────────────┐
│  首次运行：split_and_save_layers()                                 │
│  model.layers.0 → layer_0.safetensors … model.layers.N → layer_N  │
│  （原始模型与 shard 可能同时占盘；Kimi K3 源模型约 1.6TB）          │
└───────────────┬────────────────────────────────────────────────────┘
                │ ① 预取：worker thread 提前读下一模块
                │    pin 上限 max_pinned_layer_bytes = 2 GiB
                │    （超限的层退化为普通 pageable 内存）
                ▼
┌── 主机内存层：page-locked / pageable 缓冲 ─────────────────────────┐
└───────────────┬────────────────────────────────────────────────────┘
                │ ② H2D 拷贝：进入 GPU
                ▼
┌── GPU 层：同一时刻只驻留「一个模块」───────────────────────────────┐
│  embed_tokens → decoder_layer[i] → … → model.norm → lm_head        │
│  register_forward_pre_hook 装入权重                                │
│  register_forward_hook     释放权重（.to('meta') + clean_memory）  │
│  KV cache / activation 常驻显存（这部分不随分层而消失）            │
└───────────────┬────────────────────────────────────────────────────┘
                │ ③ 计算完成，权重逐出
                ▼
        自回归解码：下一个 token 重复 ①→②→③

这张图里最该被注意到的是最后一行。 常驻式推理（vLLM / llama.cpp）里权重只加载一次、被所有 token 和请求复用；AirLLM 的权重生命周期是「单模块、单次、用完即弃」，每个新 token 都要把所有层重新从磁盘搬一遍。这就是它「能跑」与「慢」的同一个根因。

4.2 分层模块拆解

层	职责	关键实现
切分层	把 checkpoint 按层切分并落盘	`split_and_save_layers()`、`layer_tensor_names()`、`load_layer_subset()`
调度层	构造 meta 模型、注册钩子、管理流式索引	`_streamed_indices` / `_streamed_set`、`_pre_hook` / `_post_hook`
传输层	预取、pin 内存上限、H2D 拷贝	`prefetching=True`、`max_pinned_layer_bytes = 2 GiB`
专家流式层	MoE 模型按路由专家流式，而非整层	`_setup_expert_streaming()`
压缩层	可选的 4bit/8bit block-wise 权重量化	`compression='4bit'`、bitsandbytes
训练层	冻结权重流式 + LoRA adapter 常驻	`airllm_lora.py`（21.7KB）、`chunked_ce.py`
兼容层	按模型家族分派子类；macOS 走 MLX	`AutoModel`、`airllm_llama_mlx.py`（16.7KB）

AutoModel 是唯一的推荐入口，它按 model_type 自动分派到对应子类。airllm/__init__.py 里对 13 个家族子类采用防御式导入——注释写明「某个小众家族的可选依赖缺失，绝不该让整个包不可用」，缺依赖只发 warning，通用流式路径照常工作。这是成熟的库设计取舍。

文件体积分布也说明了重心：airllm_base.py（44.5KB）+ utils.py（39.4KB）承载了全部核心逻辑，而 21 个模型家族子类大多只有几百字节到 3KB——说明「按架构写适配代码」这条路已经被放弃，改由 transformers 承担。

4.3 核心机制：钩子怎么把权重搬进搬出

(a) 权重「物理上不存在」——meta device 初始化。 device='meta' 时 PyTorch 只创建张量元数据（shape/dtype/stride），不分配任何存储。所以一个 671B 的模型可以在几秒内「被实例化」，占用内存接近 0。真实权重按需从 shard 覆盖上去。

(b) 钩子是搬权的唯一时机。 对每个流式模块注册一前一后两个 hook：

for idx in self._streamed_indices:
    module = self.layers[idx]
    module._airllm_idx = idx
    module.register_forward_pre_hook(self._pre_hook)   # 执行前：磁盘 → GPU
    module.register_forward_hook(self._post_hook)      # 执行后：释放

这是全项目最省力的设计：因为前向计算完全由 transformers 驱动，AirLLM 不需要跟踪各架构的 attention / rotary / KV cache 细节——只要 transformers 支持新架构，AirLLM 当天就能跑。官方原话是「new model architectures work as soon as transformers supports them」，这正是它能做到「新模型发布当天就支持」的原因。

(c) 预取：与计算重叠的 2GiB 上限。 释放当前层的同时，工作线程已开始读下一层。但代码对 pinned memory 设了硬上限：

# Upper bound on how much pinned (page-locked) host memory a single prefetched layer may use.
# Layers larger than this are loaded into ordinary pageable memory instead.
max_pinned_layer_bytes = 2 * 1024 ** 3

原因很实在：pinned（page-locked）内存不可被换出，能提供更快的 H2D 带宽，但过度占用会拖垮整个主机。对超过 2GiB 的大层退化为普通 pageable 内存——宁可慢一点，也不要让主机 OOM。

(d) 压缩：只压权重，不压激活。 这是 AirLLM 与常规量化最本质的分歧，README 自己做了对比：常规量化为了提速需要同时量化权重和激活，精度更难保；而 AirLLM 的瓶颈在磁盘加载，所以只需让「要搬的东西」变小，因此只量化权重，精度更容易守住。代价是：这一步只加速 I/O，不加速计算，官方给出的上限是约 3× 提速。

(e) MoE 按专家流式——区域「2.8T 反而只占 3.72GB」。 _setup_expert_streaming() 针对稀疏 MoE 只加载当前 token 路由选中的专家，而不是整个 decoder 层。以 Kimi K3 为例：93 层、896 个路由专家、每 token 选 16 个、激活参数约 104B——它的瞬时工作集可能小于一个 dense 70B 的整层，所以显存峰值反而更低。注意 2.8T 是专家总量，不是每 token 激活量，这是理解该数字的关键。

4.4 性能优化手段与设计取舍

手段	做法	为什么	代价
分层流式	单模块驻留，用完即释	显存峰值 ∝ 最大单层，而非总参数	每 token 全量重读权重
预取	worker thread 提前加载下一层	用 I/O 与计算重叠，官方称约 +10%	占额外主机内存
pin 上限 2GiB	超限退化 pageable	保护主机不被锁页内存拖死	大层传输变慢
只量化权重	4bit/8bit block-wise	瓶颈在 I/O，保精度	约 3× 上限，不加速计算
MoE 按专家流式	只读路由选中的专家	稀疏模型瞬时工作集更小	依赖模型可被切分
复用 transformers	不自己实现 attention	新架构当天支持	受 transformers 版本强约束
仅适配「过期」KV	让 `use_cache` 继续工作	KV cache 常驻可减少部分重算	KV 仍占显存，长 context 有限

取舍的本质：这是「容量优先」而非「吞吐优先」的架构。 常驻式引擎让权重长期在显存里被成百上千个 token 复用；AirLLM 反复从慢得多的存储层取回权重，因为它优先解决容量。第三方评测把这层逻辑点得很透：disk offload 先解决容量，系统设计再努力追回速度。

4.5 与其他架构路线的差异

与 vLLM / SGLang 类常驻引擎：它们假设模型能放进显存，然后用 PagedAttention / RadixAttention 优化吞吐与并发——优化目标是「每 GPU 每秒多少 token」。AirLLM 假设模型放不进显存，优化目标是「最低多少显存能把它执行起来」。两者不是竞品，是互补的两端。 与 llama.cpp / GGUF 量化路线：llama.cpp 追求「在给定硬件上正常可用」，靠量化把 70B 压进消费级显卡并保持每秒 8–15 token；AirLLM 不追求可用，追求完整精度下把 checkpoint 跑起来。与 Accelerate 的 device_map='auto'：Accelerate 做的是跨设备切分（多卡 + CPU 卸载），总量仍需接近模型规模；AirLLM 做的是时间维度上的分时复用，可以把需求量降到单层级别。

五、【重点】应用场景

场景一：硬件受限的模型架构研究——在一张 4GB 卡上做 layer probing

业务痛点：研究者想观察 70B 级别模型的中间层表征（激活值、注意力模式、逐层行为），但实验室只有一张 4GB 显卡。常规做法要求模型常驻显存，直接不成立。 如何解决：AirLLM 的显存峰值 ∝ 最大单层，与总参数量无关，因此 70B 可以在 4GB 卡上完整前向。关键是不要用 generate()，而是取中间层输出——因为研究场景通常只需要一次前向，不需要自回归解码，可以规避「每 token 重读权重」的最大代价。

# 最小可用：4GB 显存跑 70B 前向（不含解码）
pip install airllm
python - <<'PY'
from airllm import AutoModel
model = AutoModel.from_pretrained(
    "garage-bAInd/Platypus2-70B-instruct",
    compression='4bit',      # 只需缩小「要搬的东西」，约 3x 提速
    profiling_mode=True,     # 打印各阶段耗时，便于定位 I/O 瓶颈
)
print(model)
PY

收益与量化：官方 README 明确列出「70B 全精度约 4GB、Llama 3.1 405B 约 8GB、DeepSeek-V3 671B 约 12GB」；第三方评测确认 70B 的 VRAM 需求约从整个模型降到单层大小（约 1.75GB 量级）。关键是这批 checkpoint 原本会直接加载失败，现在至少可被研究与评估。 适用边界与不建议：仓库存在公开证据审计（issue #295，2026-06-21），指出 README 与包元数据宣称的「70B/4GB」「405B/8GB」「3× 提速、精度损失几乎可忽略」缺少可复现的 benchmark 脚本、硬件捕获、模型 revision 与验收标准；且 405B notebook 使用预量化 4-bit 模型、没有执行后的计时与显存输出。因此建议：把官宣数字当作上界参考，所有显存与速度数字都在自己的硬件上重测一遍。

场景二：把「当天发布的新超大模型」接进内部评估流水线

业务痛点：新模型（如 Kimi K3 2.8T、Qwen3.8-Flash-Next）发布当天，团队想做架构研究、能力抽查、prompt 敏感性测试，但量化版 GGUF 通常要等数天到数周，官方推荐的 serving 引擎又要多卡。等量化版的过程直接阻塞评估。 如何解决：AirLLM 的钩子方案把计算完全交给 transformers——只要 transformers 支持该架构，AirLLM 当天就能跑，无需等量化版本、无需多卡。

# Kimi K3 (2.8T) 单卡：官方标注三项前置条件
pip install compressed-tensors flash-attn      # 其模型代码强制 flash attention
pip install transformers==4.56.x               # 5.x 无法加载其 remote code
pip install torch --index-url .../cu12         # CUDA 13 尚无 flash-attn 预编译 wheel
python - <<'PY'
from airllm import AutoModel
m = AutoModel.from_pretrained("moonshotai/Kimi-K3")   # 实测 3.72GB（RTX 6000 Ada）
PY

收益与量化：v3.1.0（2026-07-29 Kimi K3 2.8T 单卡，实测 3.72GB）、v3.2.0（Qwen3.8-27B @3.33GB on RTX 3090）、v3.3.0（Flash-Next @5.95GB on RTX 4090）——每个版本都绑定一个新模型的端到端实测显存，这就是它作为「新模型第一个可用出口」的价值。 适用边界与不建议：注意 checkpoint 体量：Kimi K3 公开权重约 1.6TB，低显存不等于低下载；而 Moonshot 官方推荐的生产引擎是 vLLM / SGLang / TokenSpeed，AirLLM 是实验性的访问路径，不是官方标准 serving 方案。另外「无需量化」这句话需要纠正：Kimi K3 本身从 SFT 阶段就采用 quantization-aware training，公开权重为 MXFP4、激活为 MXFP8——把「运行时额外压缩」与「模型原生格式」混为一谈是不准确的。

场景三：小显存微调——6GB 上跑 125B 模型的 LoRA

业务痛点：微调大模型通常需要把权重全部驻留显存（哪怕用 QLoRA，基座也要能放下）。一张 6GB 的消费级卡在常规工具链下连加载都做不到。 如何解决：v4.0.0 引入的训练路径把「冻结基座逐层流式读盘」与「LoRA adapter 常驻」拆开——基座权重不进显存，只有 adapter 留下。数据集用最朴素的 .jsonl：

{"text": "Your first training document."}
{"prompt": "What is AirLLM?", "completion": "A library that runs huge models on small VRAM."}

python air_llm/examples/train_qwen38_flash_next_lora.py \
  --data my_data.jsonl --seq-len 512 --epochs 1 \
  --save-adapter qwen38-flash-next-lora.pt

from airllm import AirLLMLoRAQwen4Exp
trainer = AirLLMLoRAQwen4Exp("Qwen/Qwen3.8-Flash-Next", max_seq_len=512, lora_r=16, delete_original=True)
tok = trainer.tokenizer
tok.pad_token = tok.pad_token or tok.eos_token
enc = tok("Your training text here.", return_tensors="pt", truncation=True, max_length=512)
loss = trainer.train_step(enc["input_ids"].cuda(), attention_mask=enc.get("attention_mask"))
print(loss)
trainer.save_adapter("qwen38-flash-next-lora.pt")

收益与量化：脚本 docstring 给出明确指标——125B（MoE + 51B PLE）在 seq 512 下实测峰值低于 6GB（RTX 3060 Ti / 4090）；27B 在 seq 512 下约 2GB；Adam 在 rank 16 时只常驻约 168MB adapter 矩阵。脚本同时诚实地写明默认关闭 packed-expert 的 LoRA（48 层 × 512 专家的 adapter 加 Adam 放不下）。 适用边界与不建议：这不是 Hugging Face Trainer / bitsandbytes QLoRA；Flash-Next 需要带 qwen4_exp 的 transformers 构建（目前需从 git 安装）。不建议用于需要全参数微调或需要高吞吐训练的场景——它解决的是「显存不够」这一个问题。

场景四：长尾离线批处理——一次加载分摊多次 I/O

业务痛点：有一批不紧急性任务（夜间批量摘要、离线语料打分、一次性数据集标注），预算不允许租 A100，只能用手边的消费级卡，但模型又超出显存。 如何解决：AirLLM 的 I/O 成本主要在「每 token 重穿全模型」，但如果一次加载能服务多个 sequence，单位成本就被摊薄。社区实测已给出方向：1 个 prompt 需 35.354 秒/token，批量到 2 个 prompt 时总体 40.387 秒、即 20.19 秒/token；批量到 5 个时进一步下降到约 7.07 秒/token——即 batching 可以把固定的权重重读成本摊到多个序列上。

# 官方示例天然支持 batch：input_text 传列表即可
input_text = ['What is the capital of France?', 'Explain KV cache briefly.', 'Summarize: ...']

收益与量化：上组社区数据表明——从单条到 5 条批量，每 token 平均耗时约降为原来的 1/5。所以「用 AirLLM 做夜间批量」比「用它做交互式对话」的经济账要合理得多。 适用边界与不建议：不要用它做多用户 API 服务——没有 continuous batching 与调度器，并发请求会互相争抢同一条磁盘通路，吞吐无法线性扩展。官方与第三方在此点上口径一致：多用户 API 场景应选 vLLM / SGLang 或托管 API。

场景五：强数据隔离场景下的本地模型访问

业务痛点：某些环境（内网、受监管数据、离网机器）不允许调用任何云端 API，也不允许上传模型或数据；但团队需要访问一个巨大的开源 checkpoint 做可行性评估。 如何解决：AirLLM 是纯 Python 库、Apache-2.0、全流程本地运行，权重与数据都在自己机器上；且不强制对 checkpoint 再做一次量化（对已是原生 MXFP4 的模型尤其重要）。macOS 上走得是 MLX 路径（airllm_llama_mlx.py，16.7KB），仅支持 Apple Silicon。

pip install airllm mlx torch   # macOS: 需 Apple Silicon + python native

收益与量化：它把「重资产模型评估」的硬件门槛从「多卡 A100」降到「一张能装下最大单层的消费级卡」，且权重与数据不出机器，无需走安全审查就能开始做架构研究。 适用边界与不建议：受监管数据在完成安全审查前不应直接上；macOS 仅支持 Apple Silicon；--compression 需先 pip install -U bitsandbytes。不建议把它当成合规交付链路的一环——它是评估工具，不是生产组件。

六、快速上手（最小可用）

# 1) 安装
pip install airllm

# 2) 推理：一行 AutoModel，换模型只改 repo id
python - <<'PY'
from airllm import AutoModel

MAX_LENGTH = 128
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
input_text = ['What is the capital of United States?']
input_tokens = model.tokenizer(
    input_text, return_tensors="pt", return_attention_mask=False,
    truncation=True, max_length=MAX_LENGTH, padding=False)
out = model.generate(input_tokens['input_ids'].cuda(), max_new_tokens=20,
                    use_cache=True, return_dict_in_generate=True)
print(model.tokenizer.decode(out.sequences[0]))
PY

两个必须提前知道的坑：一是首次运行会把原模型分解并逐层落盘，原始模型 + 分片可能同时占盘，请先确认磁盘空间（Kimi K3 源模型约 1.6TB）；二是MetadataIncompleteBuffer 报错的最常见原因就是磁盘不足（官方 FAQ 明确如此），可清空 Hugging Face .cache 后重跑，或用 delete_original=True 只保留切分后的版本以省一半空间。性能对照建议必开 profiling_mode=True 定位瓶颈阶段。

七、横向对比

维度	AirLLM	vLLM / SGLang	llama.cpp (GGUF)	Accelerate `device_map='auto'`
优化目标	最低显存能跑起来	吞吐与并发	给定硬件上可用	跨设备切分
70B 显存需求	约 4GB	需多卡/大量 VRAM	量化后单卡可放	接近模型规模
权重驻留	单模块、用完即释	常驻 + 分页	常驻（量化）	分片常驻各设备
是否量化	可选，不强制	支持多种量化	以量化为核心	可配 bitsandbytes
精度	可保全精度	视量化而定	量化有损	视配置
并发服务	不适合	核心能力	弱	弱
速度（70B 参考）	约 5–35 秒/token（NVMe）	高（A100 级）	约 8–15 token/s（RTX 4090 量化）	慢于纯 GPU
新模型支持	transforms 支持即可跑	需适配 kernel	需转 GGUF	需适配
训练/微调	支持（LoRA + 流式基座）	不支持	有限	支持
License	Apache-2.0	Apache-2.0	MIT	Apache-2.0

一句话选型：装不下 → AirLLM；要并发 → vLLM / SGLang；要交互可用 → llama.cpp 量化；多卡切分 → Accelerate。这四者不是互斥的，而是覆盖不同预算与不同目标的四条路。

八、局限、风险与社区观察

一、速度是架构性的，不是调优问题。 权重「单模块、单次、用完即弃」意味着每个 token 都要重穿全模型，社区实测 70B 在 NVMe 上约 5–35 秒/token，MacBook 上甚至有低至约 0.07 token/s（约 14 秒/token） 的报告。对照同一张卡上 vLLM + AWQ 量化 70B 的首 token 约 4.1 秒、吞吐约 18 token/s，差距在数量级。「数学意义上的存在性证明」这个评价是公允的。

二、官宣数字缺少可复现证据。 仓库公开审计（issue #295，2026-06-21，审计 commit 75436d1）指出：README 与 setup.py 元数据重复宣称 4GB/70B、8GB/405B、3× 提速与「精度损失几乎可忽略」，但没有提供 benchmark 脚本、硬件捕获、CI 证据、模型 revision 与验收标准；405B notebook 无执行输出、无计时与显存捕获，且使用预量化 4-bit 模型（不是「无需量化」的强证据）。本文引用的官方显存数字因此只应视为「项目自报的峰值」，不是第三方复现结论。

三、磁盘与 I/O 是隐性成本。 4GB 显存这个数字完全没有回答：磁盘要多大、首次拆分要多久、首 token 等多久、长 context 是否可用、能服务多少用户。原始模型与分片可能同时占盘，冷层与冷专家要经过存储 → RAM → PCIe 三段搬运，预取无法把 NVMe 变成显存。

四、维护极度单一作者化。 GitHub contributors 接口抽样显示 lyogavin 一人 367 次提交，是唯一核心作者；项目由个人（同时也是 Anima AI 创始人）持续推进。优点是决策快、发版密（2026 年 6–9 月连发 5 个版本）；风险是巴士系数极低、长期路线依赖个人意愿。

五、许可证与兼容性。 代码为 Apache-2.0（air_llm/LICENSE，11,357 字节）；但模型各自的许可证另计（如 Llama 系为社区许可、DeepSeek 为自有许可），商用前需逐个核对。兼容性上强依赖 transformers 版本——Kimi K3 需 4.56.x（5.x 无法加载其 remote code）、Qwen3.8-27B 需 5.8+、Flash-Next 需带 qwen4_exp 的 git 构建，版本矩阵本身就是一个维护负担。

六、正面信号。 双周至月度级发版、每次绑定新模型、README 与 FAQ 对边界写得相对诚实（磁盘、hf_token、padding 等坑都明确列出）、测试目录有 8 个测试文件（含 test_kimi_k3_split.py 9.9KB、test_qwen38_flash_next_split.py 13.7KB），说明切分逻辑有基本回归保障；且在「让装不下的 checkpoint 能被执行」这个细分定位上，目前没有同等知名度的替代品。

九、小结与行动建议

一句话总结：AirLLM 是一台「用 I/O 换容量」的机器——它用每个 token 重读一遍权重的代价，换来了把 671B 甚至 2.8T 模型塞进 hobbyist 显卡的能力；它不是推理引擎，而是超大 checkpoint 的访问层与实验通道。

先明确你要的是「能跑」还是「能用」。 若要交互响应或多用户服务，直接放弃 AirLLM，选 vLLM / SGLang 或 llama.cpp 量化；只有当「checkpoint 太大、硬件太小」时它才是正解。
先算磁盘，再看显存。 首次运行需要承载「原模型 + 分片」，Kimi K3 源模型约 1.6TB；预算紧张时用 delete_original=True。MetadataIncompleteBuffer 十有八九就是磁盘不够。
开 profiling_mode=True 自己测一遍。 官宣显存数字尚无第三方可复现 benchmark（issue #295），请在固定模型 revision、prompt、context、硬件与输出长度后，分别记录下载 / 拆分 / 冷启动 / prefill / 首 token / decode 六段耗时。
优先用在离线批量与一次性前向。 批量到 5 条时每 token 平均耗时约降至 1/5；而 layer probing 这类只需一次前向的研究场景，可完全规避自回归重读的最大代价。
把它定位成评估通道，而不是交付组件。 上游演进（v4.0.0 的训练能力）值得跟进，但巴士系数低 + 无第三方 benchmark 这两点，决定了它不该进入受监管的生产链路。

资料来源（抓取日期 2026-10-11～12）：GitHub REST API（lyogavin/airllm：★36,402 / fork 3,814 / open issues 160 / Apache-2.0 / created 2023-06-12 / pushed 2026-10-11；Releases v3.0.0–v4.0.0；contributors 抽样 lyogavin 367）；仓库 README.md（18,891 字节）、air_llm/airllm/airllm_base.py（44,507 字节）、air_llm/airllm/__init__.py、air_llm/airllm/airllm_lora.py（21,721 字节）、air_llm/examples/train_qwen38_flash_next_lora.py、air_llm/LICENSE；PyPI airllm 4.0.0（2026-09-05）；GitHub issue #295（2026-06-21）证据审计；第三方评测 wavect.io（2026-08-20）、dev.to、feinterview.poetries.top、CSDN 社区实测、r/LocalLLaMA、HN item 49154228。已标注待确认项：官方显存/提速数字缺少可复现 benchmark；405B notebook 无执行计时与显存捕获，且使用预量化模型。