你有一张只有4GB显存的显卡，却想运行一个70B——即约700亿参数——的大模型。常规思路像要把整套百科全书塞进一张小书桌，空间很快见底。AirLLM换了个办法：一次只摊开当前要读的一册，用完收走，再换下一册。这样确实能把模型跑起来，但每生成一些内容，都可能花大量时间搬书。
这个2023年11月发布的老项目近日突然翻红：单日新增548星，并登上Hacker News，获得230分。近三年前，“小显卡跑70B”已经引发过讨论；如今显存依然是门槛，模型规模又涨到数千亿乃至万亿参数，同一套办法因此重新受到关注。需要先说明：本文涉及的显存与性能数据主要来自项目仓库，缺少第三方实测和完整基准，适合看作项目方展示的能力边界，而不是普遍可复现的性能承诺。
它省下的不是模型，而是显存占用
AirLLM的核心是分层卸载（layer-wise offloading）——大模型由许多计算层组成，它只把眼下要计算的一层权重送进GPU显存，其余部分留在主机内存或磁盘。算完这一层，再搬入下一层。
项目方称，借此可在单张4GB GPU上运行70B模型，不需要量化、蒸馏或剪枝。量化是用较低精度保存权重；蒸馏是让较小模型学习大模型；剪枝则会移除部分参数。AirLLM在这个70B示例中强调的是：模型本身不必缩小，只改变权重进入显存的方式。它也原生支持Llama 3，并称Llama 3 70B同样可在4GB显存上运行。
但“4GB显存跑70B”不等于把整个模型装进了4GB，更不等于只需4GB硬件资源。首次推理时，AirLLM会把原模型拆成逐层文件并保存，因此还需要足够的磁盘空间；运行时，速度也会受磁盘、内存与GPU之间的数据传输限制。
模型越大，搬运策略越细
项目方给出的新例子把这种路线推得更远：Kimi K3（2.8T，即约2.8万亿参数）在一张RTX 6000 Ada上占用3.72GB显存。K3采用“专家”结构，模型会为不同输入调用不同部分；AirLLM只加载每个token——模型处理文本时使用的基本单位——实际路由到的专家，而非一次搬入全部专家。
另一个125B模型Qwen3.8-Flash-Next在RTX 4090上的记录是5.95GB显存。不过，这个数字背后还有约360GB的checkpoint磁盘占用；其约51B规模的n-gram表通过主机文件映射使用，项目方称64GB主机内存足够。换句话说，显存账单下降了，数据并没有消失，只是转移到了磁盘和主机内存。
AirLLM也支持量化，但要与70B的“无需量化”示例分开看。项目方称，v3.0加入FP8模型支持后，DeepSeek-V3（671B）约需12GB显存，Qwen3-235B约需3GB。2024年加入的Llama 3.1 405B支持也同时提供8bit与4bit量化选项。这里的低显存数字采用何种精度，不能一概而论。
“能跑”为什么仍然有价值
逐层搬运的代价是慢。GitHub Issues中的一名用户称，他在16GB显卡和NVMe固态硬盘上测试仅3B模型，生成4个新token仍耗时114.5秒；首次运行时CPU近乎空闲、GPU利用率约6%，他一度以为程序已经死机。另有用户指出，仓库没有提供足以复现70B、405B等宣传数字的统一基准脚本和硬件记录，相关争议仍未关闭。
这让AirLLM更适合“显存有限、可以等”的场景，而不是追求即时对话。社区有人通过批处理，把一次层搬运摊给多项任务，并自称获得约七倍提速；也有人愿意把判断题或代码审查留到夜间慢慢运行。项目方还在v2.5加入预取，让加载与计算重叠，并宣称提速10%，但没有披露测试模型、任务和基线。
项目如今还加入了小显存训练：冻结的大部分权重逐层传输，只把adapter——用于微调模型的一小组附加参数——留在GPU。项目方称，Qwen3.8-Flash-Next在RTX 3060 Ti上低于6GB，Qwen3.8-27B在序列长度512时约占2GB。这更接近参数高效训练，不能理解为完整更新全部模型参数。
局限与未知
- 目前大多数显存与提速数字都来自项目方，缺少第三方硬件监测和统一复现实验。
- 仓库没有系统披露首token延迟、持续生成吞吐量、主机内存及I/O开销；不同GPU上的结果也不能直接横向比较。
- AirLLM降低的是显存门槛，不是模型总体存储需求。它重新提醒人们：本地大模型的“能跑”和“好用”，是两条不同的线。