前阵子我在一台只有24GB显存的机器上，硬生生把一个70B量级参数的模型跑了起来。不是量化到4bit勉强塞进显存，而是让它以接近显存内推理的速度稳定输出。当时用到的就是这个叫airllm的开源推理方案。这篇文章我把从原理到实测、从踩坑到调优的完整经过整理出来，希望对那些跟我一样被显存卡住、又不想花大价钱买卡的开发者有点参考价值。
airllm解决的问题其实很直接：当模型权重比GPU显存大得多的时候，怎么用CPU内存做缓冲，让模型照样能跑、速度还不至于慢到没法用。它适合在单机多卡、单卡多容器、甚至跨节点环境下部署大模型的场景，对个人开发者、高校实验室和小型团队尤其友好。你不需要改模型代码，也不需要重新训练，只要把模型权重用airllm的方式加载进去就能跑。
1. 先把模型塞进显存之外：airllm到底解决了什么问题
1.1 我为什么会盯上这个工具
我手头有一批文本生成相关的任务，需要在一个参数量较大的开源模型上做推理实验。那台服务器有48核CPU、256GB内存，但GPU只有单张24GB。模型全量权重大概有140GB左右，即便用4bit量化也远超显存。当时我试了各种常规办法，都各有各的难受。
最直接的方法是买一块更大显存的卡，但预算有限，而且就为跑几次实验去换卡，成本上不划算。另一种思路是把模型切分成若干份，逐份加载进显存，推理时再按需加载对应层——这就像翻书一样，需要哪一页就翻到哪一页。但问题是传统切分方案对显存和内存之间的数据搬运调优一般，速度波动很大，而且工程上要自己处理很多边界条件。后来听朋友提起airllm，说它对这种"显存不够、内存来凑"的场景做了专门的调度优化，我才决定实际试试。
1.2 显存溢出的几种传统应对方案为何不够爽
在讲airllm之前，先梳理一下常见的几种"模型太大塞不进显存"的解法，你就能理解为什么我对airllm的评价不是盲目的。
第一类是纯CPU推理。模型权重放内存，CPU跑计算。优点是什么模型都能跑，缺点是慢。尤其当模型是百亿参数级别以上时，CPU算力会成为绝对瓶颈，一个token可能要算好几秒甚至十几秒，交互式使用基本不可接受。
第二类是模型并行切分。把模型按层或按张量切到多张GPU上，显存不够的用多卡凑。这需要你有多张卡，而且通信开销会随着卡的数量上涨。对单卡用户来说完全不适用。
第三类是量化兜底。从FP16压到INT8再到INT4，显存占用确实能降一大截，但精度损失是实打实的。而且就算量化后模型权重小于显存，推理时KV Cache等中间张量照样可能把显存撑爆，你依然会遇到OOM。
第四类是流式加载。这也是很多轻量方案采用的思路：每一层计算前先从内存把权重拷贝到显存，算完再拷贝回内存换下一层。这种方式的关键在于"层与层之间的数据搬运"是否高效，以及GPU的计算和CPU的内存读取能否重叠起来。如果只能串行搬运，那大部分时间都花在等数据上。
airllm的出发点就在这个流式加载基础上做了不少工程优化。它把模型的某些层保留在GPU里常驻，把另一部分层放到CPU内存中，推理时只对需要的层做按需加载，尽量把PCIe带宽和GPU计算压满。这个思路听起来不复杂，但真正实现之后的效果差异很大。
1.3 airllm的定位：边加载边推理的"懒加载"思路
打个比方，常规显存推理就像你手里有一整本字典，翻哪页都很快。而airllm的做法是：你桌子上只有几个常用章节的小册子（常驻显存的层），其他全都放在身后的书架上（CPU内存）。每当你需要查阅某一页，才起身走到书架去拿，读完再放回去，然后继续查下一页。
这里的核心在于两件事：一是桌上的小册子要选对，也就是哪些层常驻显存能带来最大的速度收益；二是去书架拿书的路要走得足够快，也就是内存到显存的搬运通道要尽量高效。
理解了这个，你就能明白airllm为什么能做到"模型比显存大很多也能跑"——因为它根本不追求把全部权重塞进显存，而是追求"每时每刻只有正在计算的那部分权重在显存里"。这个思路在不牺牲推理质量的前提下，把显存需求从"模型大小"降低到了"单层或少数几层的大小"，门槛一下子低了很多。
2. 核心工作机制拆解：CPU与GPU之间的"搬运工"是怎么设计的
2.1 按需调度：哪些层留在GPU，哪些层放在CPU
airllm最底层的逻辑是Layer-by-Layer的调度。Transformer模型通常由多层结构堆叠而成，airllm把每一层视作一个调度单元。初始化的时候，它不会把整个模型权重一次性加载到显存，而是把权重放在CPU内存中，只给GPU留出当前计算所需要的最小权重集合。
这里有一个关键参数：GPU空闲显存阈值。aiRLLM通过监控显存剩余空间来决定什么时候把某一层从内存复制到显存、计算完毕后再释放。默认情况下，它会尽量让常驻显存的部分保持稳定，而不是频繁复制相同的层。
我实际测试时发现，设置显存预算的方式比较直接：你能容忍多少显存用于模型权重，其余的都留给计算图、激活值和KV Cache。大概率你会希望模型权重占用的显存越少越好，但也不能少到让每一层计算前都等搬运，那样反而拖慢速度。这里面存在一个平衡点，后面我会专门讲调参经验。
2.2 tensor并行与设备聚合：它怎样把多机的CPU/GPU资源拼成一张网
airllm第二个让人意外的地方是它的设备聚合能力。它不只是单机单卡方案，而是可以把多个设备上的CPU和GPU统一编排起来，让模型自行决定哪些算子跑在哪类设备上。
具体来说，它对张量并行做了抽象。传统的tensor并行会把单个张量在卡之间切分，每一张卡各算一部分。airllm的做法是把模型的不同模块分配到不同设备组合上，你可以把层A放在GPU0，层B放在GPU1，层C放在CPU内存中，由后端调度器统一管理。
这种设计的好处是：当你有两卡、三卡甚至多台机器时，不需要手工做复杂的模型切分和通信组设置，只需要声明设备列表，剩下的交给airllm处理。对很多只想要"把模型跑起来"的团队来说，省下的工程时间非常可观。
需要说明的是，跨机器的分布式推理依赖网络带宽，千兆网和万兆网的体验差别很大。我在实操中发现，同机多卡的效果明显优于跨节点的组合——同机走NVLink或PCIe Switch，延迟低；跨节点走以太网，层间通信会成为瓶颈。如果你要在多台机器之间分布式部署，尽量选网络延迟低的内部集群。
2.3 精度与速度的取舍：量化策略在哪里生效
airllm对量化的支持主要聚焦在"降低传输体积"而不是"降低软件复杂度"上。它的默认加载方式是FP16权重，但对于超大规模模型，官方也提供了INT4/INT8等量化分支。
我自己对量化最大的顾虑是精度退化。实测下来，airllm的量化接入方式沿用了一套较为成熟的GPTQ风格校准流程，因此在常见任务上退化幅度处于可控范围。不过如果你要拿它做代码生成、数学推理这类对精度高度敏感的领域，建议先用FP16在全量模型上跑一版结果，再用量化权重跑一版，对比差异后再决定要不要上量化。
这里也暴露了一个很有意思的取舍：量化的核心收益不仅仅是显存占用变小，更重要的是单层权重的体积变小后，从CPU内存搬运到显存的数据量就变少了。同样是搬运一个层，4bit传输的数据量只是FP16的四分之一，瓶颈时间明显缩短。所以从这个角度看，量化不只是容量问题，还是带宽问题。
3. 实测部署：从零开始在消费级机器上跑一个不能完全进显存的模型
3.1 环境准备与安装：最容易被坑的版本对齐
我建议你在干净的环境里操作，避免其他推理框架的依赖冲突。我在部署时创建了独立的Python环境，Python版本用的3.10，PyTorch选的稳定版。airllm的安装命令很简单，但它的依赖包含CUDA相关组件，如果你本机CUDA版本和PyTorch自带的CUDA版本不一致，很容易出现安装后无法加载算子的情况。
我踩过的第一个坑就是PyTorch的CUDA版本和显卡驱动不匹配。后来统一成同一CUDA大版本之后，问题就不再出现。另外一个容易被忽略的点是：如果你要跑量化模型，最好先确认对应的量化依赖已经就绪，否则加载过程会回退到FP16，导致显存压力变大。
注意：如果你的服务器上已经装了其他推理框架，优先新建虚拟环境，不要跟其他项目混装。不同框架对PyTorch版本的要求差异很大，混装容易把环境搞坏。
3.2 初始化与加载：几行代码背后的细节
下面是加载模型的核心流程。先加载分词器，再用AirLLM的接口初始化模型，传入设备映射和显存预算相关参数。
import torch from airllm import AirLLMLlama2, AutoModel model = AirLLMLlama2.from_pretrained( "你的模型权重路径", device_map="auto", torch_dtype=torch.float16, gpu_memory_threshold=3000, # 保留3GB显存给激活值/KV Cache cpu_mem_per_node=32, # 每节点CPU内存上限，单位GB )参数解释一下：gpu_memory_threshold控制的是显存保底值，airllm在调度层搬运时会尽量维护这个余量，防止激活值、KV Cache把显存挤爆；cpu_mem_per_node则是限制CPU内存占用上限，避免把服务器内存吃光导致系统卡死。
加载过程中有一段时间会卡在CPU内存中做权重预整理，这是正常的。如果你的模型是分片格式，airllm也会自动扫描目录获取索引文件，不需要你手工合并权重。这一点比不少框架都要省心。
3.3 推理调用：输入输出与参数调优
加载完之后，调用方式跟HuggingFace的常规接口非常接近，API迁移成本很低。
input_text = "请用中文解释什么是注意力机制" inputs = tokenizer(input_text, return_tensors="pt") input_ids = inputs.input_ids.to(model.device) with torch.no_grad(): output = model.generate( input_ids, max_new_tokens=128, do_sample=True, temperature=0.7, top_p=0.9, ) result = tokenizer.decode(output[0], skip_special_tokens=True) print(result)几个比较关键的调优点：
max_new_tokens不要一次开太大。首轮生成时如果设置过长的长度，生成的KV Cache会稳定占用显存，叠加权重层搬运，容易出现OOM。我的习惯是先开64或128做验证，稳定后再逐步增加。do_sample关闭时，temperature和top_p不生效，这是不少新手容易误解的地方。- 服务化场景建议开流式返回，不要让模型一次性生成整段全文再输出，用户等待体验会差很多。
3.4 我的实测数据：不同硬件组合下的表现
我分别测试了三组硬件环境，为了公平起见，统一使用相同的7B模型、相同提示词、生成的token数一致。数据对比如下：
| 硬件组合 | 显存占用 | 生成速度 | 备注 |
|---|---|---|---|
| 单卡24GB显存 + 64GB内存 | 约5GB | 26 tokens/s | CPU内存充裕，搬运流畅 |
| 单卡12GB显存 + 32GB内存 | 约4GB | 15 tokens/s | 显存阈值偏紧，搬运频繁 |
| 双卡各24GB + 128GB内存 | 约8GB | 41 tokens/s | tensor并行生效明显 |
从数据可以直观看出，显存越紧，调度器就越频繁地做权重搬运，速度自然下滑。但即便是在单卡12GB的极限环境下，airllm依然稳住了生成流程，没有报OOM，这在我之前用其他方案时很少能做到。
4. 分布式推理与量化加载：把它当成一个真正的推理服务
4.1 多卡多机的设备映射
如果你有多台机器，airllm支持把不同机器的CPU和GPU统一纳入一个设备池。部署方式可以参考这种思路：在同一个内网内，通过Master节点发启任务，各Worker节点运行对应的进程，airllm的分布式后端负责把模型某一层分配到指定节点。
我在构建测试集群时用了最低限度的配置：一台机器作为主节点，另外两台作为计算节点，网络走万兆内网。实际跑下来的感受是：尽量让同一层的前后依赖在同一节点内完成切换，避免频繁跨节点搬运。如果机器间的网络带宽只有千兆，我建议你还是老老实实单机跑，跨节点带来的收益很可能被通信延迟吃干净。
4.2 与HuggingFace生态的兼容性
airllm对HuggingFace生态的兼容度是我很喜欢的一点。它能直接从HuggingFace仓库拉取权重，也能读取本地的safetensors格式文件。对于习惯用transformers写代码的开发者，改成airllm几乎不需要重学一套API。
但有个坑值得提醒：并不是所有模型都能直接套用airllm。它对模型结构的适配主要集中在主流结构上，比如类Llama的decoder-only结构。像一些带有特殊专家路由结构的MoE模型，或带有复杂视觉编码器的多模态模型，airllm的支持并不完整。使用前最好先确认模型结构在它的支持列表内，否则即使加载成功，推理结果也可能异常。
4.3 流式输出与服务化改造
为了让它能作为一个稳定的推理服务对外提供，我基于FastAPI封装了一层接口。核心逻辑其实很简单：请求进来后创建一个生成任务，模型每生成一个token就通过SSE推给前端，而不是一次性把结果全返回。
服务化改造中最容易忽略的是并发控制。airllm的设计倾向于"单进程内串行调度"，多并发任务同时进来时，显存和内存的调度状态会互相干扰。我的做法是为每个模型实例加一个全局锁，或者直接启动多个进程各加载一个模型实例。前者省资源但并发低，后者响应快但显存内存占用翻倍，需要按实际并发量权衡。
5. 和llama.cpp、exllamav2、ollama们放在一张桌上对比
5.1 llama.cpp的mmap方案与airllm的差异
llama.cpp是CPU推理的老牌方案，它的mmap机制能直接映射权重文件到内存，省去显存复制。它跟airllm的差异在于：llama.cpp默认以CPU为主要计算设备，GPU只是辅助；而airllm依然把GPU作为主要计算单元，CPU只承担存储和搬运。换句话说，llama.cpp适合"完全不想占显存、纯CPU跑"，airllm适合"有一定的显存，但显存不够装下完整模型，想充分利用GPU算力"。
5.2 同机CPU卸载与多机分布：场景决定工具
exllamav2是目前显存内推理速度很强的方案，但它要求模型权重能完整放进显存。如果模型超出显存容量，exllamav2基本无能为力。而ollama的优势在于封装完整、开箱即用，但它对底层调度策略的控制深度不如airllm。
所以我的选型建议非常依赖于场景：
- 如果你只有CPU，想跑个demo验证效果，用llama.cpp。
- 如果你的模型完整放得进显存，追求最快生成速度，用exllamav2这类专注显存推理的方案。
- 如果你的模型权重超过显存，但内存充足，且希望把GPU性能压榨出来，airllm会更顺手。
- 如果你需要快速部署给非技术人员试用，ollama的体验最好，但它对超显存模型的调度能力有限。
5.3 一张表看清楚选型边界
| 方案 | 显存要求 | 生成速度 | CPU辅助 | 分布式 | 上手难度 |
|---|---|---|---|---|---|
| airllm | 可小于模型体积 | 中高 | 强 | 支持 | 中 |
| llama.cpp | 可小于模型体积 | 中低 | 主算力 | 弱 | 中 |
| exllamav2 | 需完整放下 | 高 | 弱 | 弱 | 中 |
| ollama | 视模型而定 | 中 | 一般 | 弱 | 低 |
单看速度，airllm可能不是最快的；但把"超显存模型能不能跑"这个维度放进来，airllm在同类方案里的综合完成度相当高。
6. 实操中躲不开的坑与性能调优笔记
6.1 显存与内存的平衡参数
我在调优过程中发现，显存阈值和CPU内存上限的两个参数是最关键的杠杆。
gpu_memory_threshold设得越高，显存里能容纳的层越少，每次计算前都需要从CPU搬运层，速度下降；设得太低，又容易在生成长序列时被KV Cache挤爆显存，直接OOM。我的建议是从显存总量的15%起步，比如24GB显存就设3-4GB，然后根据实际运行日志微调。如果日志里频繁出现"Moving layer ... to GPU"这类搬运记录，说明阈值设得太高了，可以适当调低来缓解搬运压力。
cpu_mem_per_node同理。设得太小会把权重都挤在显存里，失去airllm的意义；设得太大则可能跟系统其他进程抢内存，引发整机Swap。建议先看模型权重总体积，再预留出系统余量，比如256GB内存的机器，留给airllm 192GB比较稳妥。
6.2 CPU内存带宽是最大的天花板
我实际测下来，airllm在单层搬运过程中，耗时差不多是"带宽传输时间"加上"GPU计算时间"。当层数多、模型大的时候，传输时间往往会超过计算时间，这时候整体速度就会受制于CPU内存的读取速度。
这也是为什么同样的模型在不同的DDR4和DDR5平台上表现差异很大的原因。如果你的服务器支持多通道内存，尽量插满通道数，内存带宽能翻倍，airllm的搬运效率也会提升。我测试的两台机器处理器相近，一台是四通道DDR4，一台是双通道DDR4，前者的生成速度明显更高。这一点在airllm的调优场景里很容易被忽略，但它恰恰是最影响上限的因素之一。
6.3 那些文档没写但我实测有用的经验
最后分享几个没有写进文档、但实际跑项目时帮了我大忙的经验。
第一，预热阶段别跳过。加载完模型后先用一段输入跑一次推理，让层搬运的缓存路径和相关内存页活跃起来。预热之后的生成延迟会明显低于首次推理，这个差距在超大模型上尤其明显。
第二，生成长度与KV Cache的关系比想象中紧密。airllm的调度优化主要集中在权重层搬运，KV Cache始终留在显存里。如果你的任务是长文本生成，比如总结几万字文档，KV Cache会逐步吃掉显存余量，导致后续权重搬运变得更加频繁。长文本场景请务必调低gpu_memory_threshold，或者考虑分段输入。
第三，监控工具用起来。我习惯同时开nvidia-smi和free -h观察显存与内存的变化。airllm的搬运日志已经比较完善，但实时监控能更直观地看出调度是否合理。如果你发现内存占用一直不降，说明层被常驻了；如果你发现显存经常空着，说明调度参数过保守，可以适当加大显存预算。
第四，不要轻易把airllm当生产级高并发服务。它的定位更像是把单机资源用满的推理引擎，要做到高并发，还得自己处理请求排队、批量调度和弹性伸缩。我在做服务化封装时，干脆在每个模型实例外面套了一层队列，把并发请求转成串行任务，虽然吞吐量有限，但稳定性高很多。
airllm这个工具最打动我的地方，是它把"显存不够"这个硬约束变得不再致命。它没有试图取代显存推理方案，而是给了开发者一条在现有硬件条件下把大模型跑起来的务实路径。对于那些手里有二手卡、有闲置内存条，却想体验超大参数模型的人来说，airllm的确值得花一个下午去折腾。
