看了一圈大模型本地部署方案，你会发现绝大多数项目在做同一件事：让模型变小。量化、剪枝、蒸馏、稀疏化，本质都是"把权重塞进显存"。有一个项目反着来。lyogavin/airllm 的路线是：不量化、不蒸馏、不剪枝，而是把模型一层一层从磁盘搬进显存，算完一层换下一层。仓库地址：github.com/lyogavin/airllm。
按 README 的说法，这套逐层流式加载（layer-wise streaming）能让 70B 模型塞进单张 4GB 显卡，连 2.8 万亿参数的 Kimi K3 也能在 4GB 以下跑起来。项目目前 36,747 星、3,829 个 fork，Apache-2.0 许可，2023 年 6 月 12 日建仓，最近一次代码推送是 2026 年 10 月 12 日（以上均为 GitHub API 于 2026-10-12 的实测值）。
这条路线有意思的地方不在于数字有多大，而在于它换了一个维度解决问题：当装不下成为唯一的硬约束时，你可以选择牺牲时间，而不是牺牲模型本身。
它到底做了什么
常规推理的默认假设是所有权重常驻显存，模型有多大显存就得买多大。量化路线要先削权重，削到装得下为止，代价落在精度上。
airllm 的假设完全不同：显存可以很小，时间可以很长。它把检查点按层切开，推理时逐层从磁盘或内存读进显存，参与完计算立刻释放，只保留当前层和必要的中间状态。显存占用因此从"模型总量"变成了"单层权重加上激活值"。层切得越细，峰值越低，搬运次数越多。
这个设计的直接推论是显存占用与模型总参数量基本脱钩。2.8 万亿参数和 270 亿参数在显存曲线上的差距，被搬运次数吃掉了。
理解这个机制时有个容易搞错的点：airllm 省下的不是"权重本身要占的地方"，而是"所有权重同时占的地方"。任何时刻只有少数几层在显存里，其余躺在磁盘或主机内存上。这意味着模型的容量上限不再由显存决定，而是由磁盘和主机内存决定。买一张便宜的小显卡换来的不是便宜，而是模型规模的自由，账单转移到了别处。
同一套逻辑在 MoE 模型上收益更大。稠密模型每个 token 都要经过全部层，逐层流式的搬运量已经很大；稀疏专家模型每个 token 只激活少数专家，没被激活的专家完全不必进显存，于是"逐专家流式"能把 2.8T 的峰值压到几 GB。这解释了为什么 Kimi K3 这个月发布的模型会成为这个项目 README 上最抢眼的一行。
README 的实测数字，附带硬件前提
README 给了几个可核对的数字，全部为 README 口径，且每个都绑定了具体硬件与版本前提。数字很抓人，但脱离前提引用就没有意义：
- 70B 模型不超过 4GB 单卡，这是首页宣传口径（headline），未标注具体硬件。
- Qwen3.8-Flash-Next（125B，Qwen4ExpForConditionalGeneration 架构，含约 51B 的 n-gram 嵌入）5.95GB 显存，RTX 4090 端到端实测。
- Qwen3.8-27B（稠密多模态模型，Gated DeltaNet 加 Gated Attention 混合，原生视觉）3.33GB 显存，RTX 3090 端到端实测，需要 transformers 5.8 以上。
- Kimi K3（2.8T）3.72GB 显存，RTX 6000 Ada 端到端实测。
- DeepSeek-V3（671B）约 12GB 显存。
训练侧 README 也有数字（2026 年 9 月更新）：Qwen3.8-Flash-Next（125B）训练低于 6GB 显存，跑在 RTX 3060 Ti 上；Qwen3.8-27B 训练约 2GB 显存，序列长度 512。
请注意这些数字全部是显存，不是速度。官方没有给出每秒 token 数，本文也不编。
为什么 3.33GB 这个数能成立
Qwen3.8-27B 那一栏最值得琢磨：271 亿参数的稠密模型只占 3.33GB，显存里几乎只放得下当前层。能成立的前提有三条。
第一，权重以流式方式逐层送入，峰值只压到单层。第二，模型检查点需要预先切分落盘，这是安装环节的成本而非推理环节的开销。第三，3.33GB 是端到端实测的峰值而不是平均值，显存曲线会有锯齿。
与之配套的还有一段容易被忽略的工程要求。Qwen3.8-Flash-Next 的 n-gram 表文件被映射到主机内存，需要 64GB 级内存的机器才够用；它的检查点在磁盘上约 360GB，切分之后可以用 delete_original=True 回收原件。也就是说，显存省下来了，磁盘与主机内存的账单转手付了出去。
版本也是一道锁。Qwen3.8-27B 要求 transformers 5.8 以上；Qwen3.8-Flash-Next 依赖 transformers 的 in-tree qwen4_exp 支持，需要从源码装 transformers；Kimi K3 要求 transformers 4.56.x。三个模型三套版本要求，装错就是装不上。
Kimi K3 那一栏：2.8 万亿挤进 3.72GB
Kimi K3 是这套方案里最极端的案例。总参数 2.8 万亿，每个 token 激活约 1040 亿（896 个专家里激活 16 个），上下文 1M token。airllm 对它的处理不是逐层而是逐专家流式（per-expert streaming），因为 MoE 结构每个 token 只经过少数专家，其余上千个专家整块待在磁盘上。3.72GB 显存装下 2.8T，代价就是每个 token 都要做大量磁盘读取。
Kimi K3 自身的许可要说清楚：它采用的是修改版 MIT（modified MIT），不是标准 MIT 文本，二次分发或商用前请自行核对原始 LICENSE。环境上还有硬性要求——K3 的模型代码强制依赖 flash attention，必须装 compressed-tensors 与 flash-attn，并且需要 CUDA 12 的 torch 构建（flash-attn 没有 CUDA 13 的预编译轮子）。
跑 K3 的现实前提也要摊开讲。Kimi K3 于 2026 年 7 月发布、7 月底开放完整权重，单节点装下 2.8T 参数意味着 TB 级的磁盘代价。airllm 确实把显存门槛压到了 3.72GB，但它没有把存储门槛压到零——那句"4GB 以下跑 2.8T"描述的是显存，不是整台机器的规格。把这句话当成"一块小显卡就能摸 2.8T"的购买依据，大概率会在下载那一步就明白代价。
诚实的代价：速度是这笔交易的付款方式
上面所有数字都指向显存，没有一个指向速度，那话就必须说明白。
第一，这是用速度换显存。逐层搬运意味着每次前向都要把权重从磁盘或内存读进显存，PCIe 带宽与内存带宽直接决定 token 生成速度。在消费级硬件上，这个速度的体感通常在分钟到小时量级，而不是交互式对话的体感。
第二，官方数字是显存，不是速度。README 里没有一个每秒 token 数，第三方也没有同口径公开跑分，所以任何具体的吞吐说法都是自行推算，不是实测。
第三，生态坑不少。GitHub API 显示该项目当前有 160 个 open issues。对一个 36,747 星、仍在持续推送的项目来说这个数量偏高，说明版本矩阵、模型适配与硬件组合的分叉远比一页文档复杂，装之前要有心理准备。
值得单独说一句主语言字段：这个仓库的主语言被 GitHub 标为 Jupyter Notebook，而不是 Python 或 C++。对一个承担重计算任务的推理框架来说，这通常意味着核心实现收在 notebook 形态的示例与文档里，而不是一个打磨过的安装包。它与 Ollama、llama.cpp 那种工程化程度不在一个量级，把它当研究工具而非生产组件更合适。
第四，磁盘是隐形门槛。Qwen3.8-Flash-Next 检查点约 360GB，Kimi K3 是 2.8T 级别权重，TB 级磁盘是现实前提。"4GB 显存"这个数字听着轻巧，背后的存储代价并不轻。
训练支持：冻结权重也流式
2026 年 9 月的更新把同一套思路搬到了训练侧：冻结权重照旧流式送入，只把可训练的 adapter 留在显存里。README 给出的数字是 125B 模型训练低于 6GB 显存（RTX 3060 Ti），27B 模型约 2GB 显存（序列长度 512）。
这意味着全参微调的硬件门槛被压到了很低的水平，但边界要说清楚：这条路只适用于 adapter 或类似小可训练部分的场景，不是把 2.8T 全参数塞进 6GB 显存做全量更新。冻结权重仍然要从磁盘流式读进来，I/O 压力依旧存在。
它在生态里的位置
需要和站内已有内容划清界限。我们此前写过一篇本地大模型部署工具横评（本地大模型部署工具横评），比的是 Ollama、LM Studio、vLLM、llama.cpp、GPT4All 五款部署工具之间的取舍；airllm 换的是另一层维度——它讨论的是显存装不下时该用哪种内存策略，而不是该选哪个工具。两篇可以连着读。
放回整个策略图谱里，airllm 处在"显存最小、速度最慢"的那一端。另一端是把模型压到装得下为止，GGUF 量化路线生态最成熟，Ollama 的安装与避坑见 Ollama 本地部署大模型 SOP。中间还有几条路：CPU offload 混合、部分层留显存部分落内存，速度取决于 PCIe 与内存带宽；蒸馏换小模型，放弃旗舰能力；或者干脆走远程 API，显存问题根本不存在——这条路在 Qwen3.8-Flash-Next 三层部署 SOP 里有托管 API 一层的展开。
如果你的目标不是"跑起来看看"，而是一个每天都在用的编码助手，那还得看模型本身水平，选型参考 本地编程模型横评；想从特定体量起步，Mellum 2.1 本地部署 SOP 与 灵播世界小模型本地部署 SOP 覆盖了两种体量的落地路径。
谁适合用它
三类人适合。第一，想在 4GB 卡上摸一摸平时根本装不下的模型，只需跑一次看看输出，比如评估超大模型的推理质量，或者做一次性长文处理。第二，做模型可跑性验证，需要在受限硬件上确认某个 checkpoint 能不能加载、能不能出字。第三，研究逐层流式本身，这套实现是很好的参考代码。
两类人不适合：需要逐 token 交互的场景，比如实时对话、交互式编码补全；以及磁盘和主机内存都不宽裕的机器——airllm 把压力从显存挪到了存储，没有凭空省下资源，只是换了个地方付账。
还有一个时间维度的门槛值得提前算：首次部署要下载并切分检查点，Qwen3.8-27B 这一档还算温和，Qwen3.8-Flash-Next 的约 360GB 和 Kimi K3 的 TB 级就是以小时计的下载量，中途断流的概率不低。动手前先把缓存目录和断点续传准备好，比装完库再等一晚上更实际。
FAQ
Q1: airllm 是量化方案吗？
不是。README 明确的定位是不量化、不蒸馏、不剪枝，权重以原始精度从磁盘逐层流式加载进显存。显存数字比量化方案好看的原因是模型本身没被压缩，代价全部转移到了时间上。
Q2: 官方给出的速度是多少？
官方没有给。README 里的数字全是显存占用（3.33GB、5.95GB、3.72GB、约 12GB），训练侧给的也是显存而非吞吐。第三方同样没有同口径的公开每秒 token 跑分，所以任何具体吞吐都是自行推算，不是实测。
Q3: Kimi K3 可以用 airllm 跑吗？
可以，README 记录了 RTX 6000 Ada 上 3.72GB 显存的端到端实测，方式是按 token 路由逐专家流式。但要注意 Kimi K3 自身采用修改版 MIT 许可（非标准 MIT），且强制要求 flash attention，环境需要 CUDA 12 的 torch 构建与 transformers 4.56.x。
Q4: 为什么我按 README 装完还是跑不起来？
最高频的原因是版本矩阵不匹配：Qwen3.8-27B 需要 transformers 5.8 以上，Qwen3.8-Flash-Next 需要 transformers 的 in-tree qwen4_exp（要装源码版），Kimi K3 需要 4.56.x 且必须装 compressed-tensors 与 flash-attn。其次是磁盘与主机内存：检查点以百 GB 到 TB 计，n-gram 表映射要求 64GB 级主机内存。
Q5: 有了 airllm 还需要 Ollama 这类工具吗？
两条路线解决的是不同问题。airllm 保证模型完整、不损失精度，代价是速度；GGUF 量化路线（Ollama、llama.cpp）压权重换显存，速度可用但质量有损，生态也最成熟。按场景选：偶发跑一次超大模型用 airllm，日常交互用量化方案。