这条路线到底解决了什么问题
先把一件事说清楚：AirLLM 不是量化工具，也不是蒸馏工具，更不是剪枝工具。它什么都不做，只做一件事——把模型的每一层当成一个可以单独搬运的文件，需要哪一层就从磁盘或内存把哪一层搬上显卡，算完这一层就把它换下去。README 原文口径是 layer-wise streaming，靠这套机制把 70B 级模型塞进单张 4GB 卡，甚至让 Kimi K3（2.8T）这类超大开源模型在 4GB 以下跑起来。
这件事为什么值得写成 SOP？因为它是「显存不够」这条路上唯一一个不损失模型质量的选项。GGUF 量化会掉质量，蒸馏换的是能力，CPU offload 混合仍然受内存带宽牵制，而 AirLLM 的代价被集中到了一个点上：速度。你可以接受慢，但你没法接受慢之后答案还变差了。
仓库地址是 github.com/lyogavin/airllm，Apache-2.0 许可。截至 2026-10-12 的 GitHub API 实证数据：36,747 stars、3,829 forks、160 个 open issues，2023-06-12 建仓，最近一次推送就在 2026-10-12。一年多过去它还在活跃更新，训练支持是 2026-09 才补上的。
也要跟站内已有的几篇分清分工：本地部署工具横评比的是 Ollama / LM Studio / vLLM / llama.cpp / GPT4All 这五款部署工具；Ollama 本地部署 SOP讲的是量化档位与显存避坑；Qwen3.8-Flash-Next 三层部署 SOP讲的是同一个模型从托管 API 到端侧的路线图。本篇是第五条完全不同的分支：不量化、不蒸馏，只靠分层流式硬扛显存。
边界声明
AirLLM 的官方数字全是显存占用，不是速度。写这篇之前没有实机压测，因此本文不会给出任何 tokens/s 数字，也不会给出首 token 延迟。速度部分只讲结构性的慢——这是设计使然，不是 bug。160 个 open issues 也说明生态坑不少，别把「官方实测能跑」当成「你这台机器一定能跑」。
第一步：装环境，先锁版本（三重锁是头号坑）
AirLLM 的环境要求比多数人预期的复杂，因为它同时依赖三个互相牵制的组件。这一步装错，后面每一步都会失败，且报错信息通常不会告诉你真正的原因。
第一重是 torch 必须是 CUDA 12 构建。这不是风格偏好，是硬约束：flash-attn 目前没有 CUDA 13 的预编译轮子，torch 版本跟着 CUDA 走，torch 一旦装成 CUDA 13 构建，flash-attn 就编不出来。
第二重是 flash-attn，Kimi K3 的模型代码强制要求 flash attention，安装命令是 README 给的原文：
pip install compressed-tensors flash-attn第三重是 transformers 的分支随模型而变，这一重最容易踩：
- Qwen3.8-27B 需要 transformers 5.8+。
- Kimi K3 需要 transformers 4.56.x。
- Qwen3.8-Flash-Next（Qwen4ExpForConditionalGeneration）需要 transformers 主线的 in-tree qwen4_exp，安装方式是直接装 GitHub 源码版：
pip install git+https://github.com/huggingface/transformers.git。
这三者不是「装最新的就行」，而是一个模型对应一个矩阵。同一个虚拟环境里跑 27B 再跑 K3，需要切 transformers 版本。别指望一个环境通吃。
验证要双验证，缺一不可。 第一层是驱动与硬件层：
nvidia-smi它确认三件事：卡在不在、驱动版本是什么、当前显存占用多少。第二层是 torch 能否真正看到卡：
python -c "import torch; print(torch.version.cuda, torch.cuda.is_available())"这一行打印的 torch.version.cuda 应该是 12.x；如果打出来是 13.x，说明第一重锁已经没锁住，现在回头重装还来得及。torch.cuda.is_available() 打成 False 则是驱动或环境问题，跟 AirLLM 本身无关。
预期结果：nvidia-smi 正常列出显卡，第二条命令输出 12.4 True 这类内容（具体小版本随构建而异）。
失败信号：torch.cuda.is_available() 为 False 而 nvidia-smi 正常——这是 PyTorch 与驱动版本不匹配，不要去改 AirLLM 的代码。
第二步：选目标模型，按实测表对号入座
README 给了一张实测表，把「哪个模型需要多少显存」写得很清楚。选档逻辑很简单：先看你手上是几 GB 的卡，再看这张表。
| 目标 | 显存占用（README 口径） | 端到端实测硬件 | 额外硬性依赖 |
|---|---|---|---|
| Qwen3.8-27B（稠密 VL，Gated DeltaNet + Gated Attention） | 3.33GB | RTX 3090 | transformers 5.8+ |
| Qwen3.8-Flash-Next（125B，含约 51B n-gram 嵌入） | 5.95GB | RTX 4090 | in-tree qwen4_exp；检查点约 360GB |
| Kimi K3（2.8T 总参，激活 1040 亿） | 3.72GB | RTX 6000 Ada | compressed-tensors、flash-attn、transformers 4.56.x |
| DeepSeek-V3（671B） | 约 12GB | README 口径 | — |
| 70B 级模型（宣传口径 headline） | ≤4GB | README 口径 | — |
Qwen3.8-27B 的 3.33GB 是最现实的入门档。理由有三条：显存占用在 4GB 卡的可承受范围内、检查点体量是几十 GB 而不是几百 GB、只需要 transformers 5.8+ 这一重依赖而不是三重。如果你是第一次跑 AirLLM，从它开始能把「版本问题」和「磁盘问题」的变量降到最少。
Kimi K3 的 3.72GB 数字很诱人，但要算另一笔账：2.8T 参数、896 个专家每 token 激活 16 个、1M token 上下文，单节点跑它的磁盘代价是 TB 级的。另外它的权重是修改版 MIT 许可（不是标准 MIT），开源日期 2026-07-27，正式发布 2026-07-17——用之前务必自己读一遍 LICENSE 原文，别按印象套。
Qwen3.8-Flash-Next 那条路线有它自己的特殊之处：n-gram 嵌入表映射到主机内存，README 说 64GB 内存的主机够用，decoder 层做流式。所以它对主内存的要求比对小显存的要求更苛刻。
第三步：首次推理，最耗时的是下载
装完环境、选完档，真正的第一道关卡不是显存，是磁盘和时间。
分层推理的前提是每一层都得在本地以文件形式存在。首次运行要先把完整权重拉到本地，量级自己看：Qwen3.8-Flash-Next 的检查点约 360GB，Kimi K3 是 TB 级。这个下载过程中断几乎是必然事件，所以有两条纪律：
- 下载完先别动缓存目录。HF 缓存被清一次就是重新下几百 GB。把缓存目录当固定资产对待，别拿它当临时目录清理。
- 切分阶段用
delete_original=True回收原件。这个参数让 AirLLM 在把原始 checkpoint 切分成逐层文件之后把原件删掉。对 360GB 级别的模型，这是把磁盘占用砍掉一大半的关键动作。但它不可逆——确认切分完成、验证能加载之后再让它删，否则原件没了、切分又不全，就只能重下。
预期结果：首次推理前是一段以小时计的下载时间（TB 级模型是以天计），随后才是真正的推理。 失败信号：下载反复断在同一位置，先别怀疑网络，先看磁盘剩余空间够不够装完整 checkpoint 再加临时文件。
第四步：量显存，并且管理速度预期
跑起来之后要盯两件事：显存够不够，快不快。
显存用 nvidia-smi 盯。另开一个终端持续观察，峰值是判断「这张卡到底行不行」的唯一依据。README 那些 3.33GB / 5.95GB / 3.72GB 是官方实测口径，你的机器上跑出来的峰值不一定等于它——主板、驱动版本、同时跑的其他进程都会影响。
速度这一栏，本文不给你数字，因为官方也没给。 编一个 tokens/s 出来是最容易骗到自己的事。真正要理解的是结构性慢：AirLLM 每个 token 都要走一遍「搬层上卡、计算、搬层下卡」的循环，搬运的字节量远超计算本身。这意味着：
- 首 token 延迟会明显高于常规模型，因为要预取和搬运；
- 它不适合逐 token 交互式场景——人在对面等它一个字一个字吐出来，体感是「卡死了」；
- 一次要完整输出的批量任务才是它的正确形态。
判断标准很简单：如果你能接受「按下回车，去泡杯茶，回来读结果」，AirLLM 适合；如果你需要实时对话，它就是错的选择。
第五步：接 agent 与 API，以及训练这条岔路
推理侧接起来之后有两种典型用法。一是一次性任务型工作流：把一批材料丢进去，产出一份报告或一次分析，中间不需要人来回对话。AirLLM 在这类场景的价值最明显——它让你在一张 4GB 卡上摸到的是原本够不着的模型档位。
二是包成接口给 agent 用，但要清楚这类 agent 的交互模型必须能容忍长延迟。如果 agent 的设计假设是「模型每次回复都在几百毫秒内」，接上 AirLLM 之后 agent 的行为会明显退化——不是答错，是等不起。
训练是另一条完全不同的路径，别混着理解。README 在 2026-09 更新里说明：训练走逐层流式传冻结权重、adapter 留在显存的机制。也就是说训练时显存里常驻的只是 adapter（LoRA 之类的小参数），大权重依然在磁盘上流转。README 给的两个数字是 Qwen3.8-Flash-Next(125B) 训练小于 6GB（RTX 3060 Ti）、Qwen3.8-27B 训练约 2GB @ seq 512。这条路径的逻辑与推理完全不同，工程上要单独评估。
顺带一提，如果你最后发现自己在纠结「到底该量化还是该分层流式」，可以先看 AirLLM 资源页里的显存与部署路线梳理；本地编码模型横评按任务类型挑模型、Mellum 2.1 本地部署 SOP则是一条参数规模小得多的轻量路线，都值得在动手下载 TB 级权重之前先看一眼。
五个坑点专段
坑一：版本矩阵三重锁被当成一道锁。 CUDA 12 构建、flash-attn、对应 transformers 分支是三个独立的约束，对应三个不同的失败点。torch 装成 CUDA 13 构建，flash-attn 编译失败；transformers 装成 5.8+ 去跑 K3，模型代码找不到；transformers 装成稳定版去跑 Flash-Next，qwen4_exp 这个 in-tree 模块根本不存在。这三个报错长得都不一样，但根因都在这张矩阵表上——先对表，再动手。
坑二：把首次下载当成普通模型下载。 360GB 是 Qwen3.8-Flash-Next 的量级，Kimi K3 是 TB 级。按「下载一个 7B 模型」的耐心去等，中途清理缓存或换个目录重下，都是以百 GB 计的损失。下载这一段的唯一正确姿势是：给足磁盘、给足时间、别动缓存。
坑三：以为跑得慢是装坏了。 这是最常见的误判。看到一条 token 都要等几秒，第一反应是「装错了」「版本不对」「要不要重装」——其实分层流式本来就是这个速度，官方从未承诺交互级延迟。如果你开始怀疑环境，先回头读第四步，那一步讲的就是这个。
坑四：把训练当推理的附属品。 训练路径是冻结权重流式 + adapter 留显存，推理路径是逐层流式加载权重，两者工程上不是一回事。混着理解会导致你在显存预算、加载时机、优化器状态上做出一堆错误假设。
坑五：把 K3 当成「4GB 也能跑 2.8T」的免费午餐。 显存数字是真的，代价在别处：TB 级磁盘、强制 flash-attn 的硬依赖、以及修改版 MIT 许可。许可证这一条是最容易被忽略的——标准 MIT 和修改版 MIT 在分发条款上可能不同，用之前读原文。
上手 checklist
nvidia-smi能列出目标显卡torch.version.cuda打印 12.x，torch.cuda.is_available()为 True- flash-attn 装成功（K3 路线还需 compressed-tensors）
- transformers 版本已对表：27B 用 5.8+ / K3 用 4.56.x / Flash-Next 用 in-tree qwen4_exp 源码版
- 目标模型已按 README 实测表选定，且磁盘预留够完整 checkpoint + 临时空间
- 缓存目录被当作固定资产保护
delete_original=True只在切分验证通过后才启用nvidia-smi已开着盯显存峰值- 速度预期已按「结构性慢」校准，用一次性任务而非实时对话去验收
- 若走 K3，已读过修改版 MIT 许可原文
- 训练需求已单独评估，没有沿用推理路径的假设
一句话收尾：AirLLM 把「显存不够」从一道死题变成了一个取舍题——不量化、不蒸馏，逐层搬着跑，质量一点不掉，代价全在速度上。所以第一件该确认的不是显卡够不够 3.33GB，而是你的磁盘能不能先撑住那 360GB，以及你的工作流能不能接受按下回车后去泡杯茶。
常见问题
Q1: AirLLM 到底快不快？有没有 tokens/s 的官方数据？ A1：没有。官方 README 给的全是显存占用数字，没有给 tokens/s，也没有给首 token 延迟。本文因此不提供任何速度数字。结构性慢的原因是确定的：每个 token 都要走「搬层上卡、计算、搬层下卡」的循环，搬运字节量远超计算量。它适合一次性任务型工作流，不适合逐 token 的低延迟交互。
Q2: 为什么 torch 必须 CUDA 12？换个版本不行吗？
A2：因为 flash-attn 目前没有 CUDA 13 的预编译轮子，torch 的 CUDA 构建版本与之绑定。装成 CUDA 13 构建，flash-attn 就编不出来。验证方法是在环境里打印 torch.version.cuda，应该是 12.x；这一步要在装 flash-attn 之前做，而不是等编译失败了回头查。
Q3: K3 的许可到底是什么？能不能商用？ A3：Kimi K3 的权重是修改版 MIT 许可，不是标准 MIT，具体条款以仓库与模型页的 LICENSE 原文为准，不要按标准 MIT 的印象套用。商用前请人工读一遍原文并存档。另外要算清成本：2.8T 总参、激活 1040 亿、896 专家每 token 激活 16 个、1M 上下文，单节点跑的磁盘代价是 TB 级的。
Q4: 同一台机器能同时跑 27B 和 K3 吗？ A4：不能共用一个虚拟环境。两者的 transformers 分支不同——27B 需要 5.8+，K3 需要 4.56.x。跑完一个切版本再跑另一个，或者干脆建两个环境。Qwen3.8-Flash-Next 更特殊，它要的是 transformers 主线的 in-tree qwen4_exp，得装 GitHub 源码版。
Q5: 4GB 卡真的能跑 70B 或者 2.8T 吗？ A5：README 的实测表给了具体口径：Qwen3.8-27B 是 3.33GB（RTX 3090 端到端实测）、Qwen3.8-Flash-Next 125B 是 5.95GB（RTX 4090）、Kimi K3 2.8T 是 3.72GB（RTX 6000 Ada）、DeepSeek-V3 671B 约 12GB。70B ≤4GB 是 README 的宣传口径 headline。这些数字都是显存占用，成立的前提是磁盘够大、时间够长、速度够慢——也就是说你必须先接受第四步那套速度预期。
参考来源
- 官方仓库（2026-10-12 GitHub API 实证）：https://github.com/lyogavin/airllm ——Apache-2.0、36,747 stars、3,829 forks、160 open issues、分层流式定位
- 官方仓库 README：https://github.com/lyogavin/airllm/blob/main/README.md ——实测显存表、各模型 transformers 分支、
delete_original=True、训练支持与训练显存数字 - 关联阅读：本批姊妹篇 AirLLM 资源页；站内 本地部署工具横评、Ollama 本地部署 SOP、Qwen3.8-Flash-Next 三层部署 SOP、本地编码模型横评、Mellum 2.1 本地部署 SOP
本文所有命令与数字均为 2026-10-12 官方 README 快照，未经实机压测；速度数据官方未公布，本文不提供估算值。许可证与仓库状态请以你核验当日的官方页面为准。非官方合作推广，非投资建议。