1. 显存焦虑的解药：airllm到底是来解决什么问题的
先聊点真实的境况。手头有一张消费级显卡，显存 8GB 或 16GB，想跑一个 70B 甚至更大的开源模型。量化方案试了一圈，GPTQ 能压到 4bit，AWQ 也能凑合，但即使量化完，模型权重加上 KV Cache 还是能轻松把显存撑爆。硬跑的结果无非两种：要么 OOM 直接崩，要么把模型切成好几块，前向传播的时候在 CPU 和 GPU 之间来回搬运，慢到怀疑人生。
大多数人的第一反应是上 vLLM，上 Ollama，上 llama.cpp。这几个方案各有各的强项，特别是 vLLM 的 PagedAttention 确实在推理吞吐上做了大量优化。但它们的共同前提是：模型权重得能放进显存。放不进去的时候，要么加预算换卡，要么就只能降级用小模型。而 airllm 的思路不太一样，它不跟物理显存死磕，而是走了另一条路：既然显存放不下全部权重，那就把权重放在内存或者磁盘里，只把当前计算需要的部分拉进显存。
这个思路最直观的好处是：门槛被拉低了。不需要昂贵的专业卡，不需要管理员权限去改显卡的 BAR 大小，也不需要为了一个 70B 模型去租按小时计费的云 GPU 实例。手头这张卡就能跑起来，无非是速度上打点折扣。我用这东西跑过几次实际任务后，最大的感受是：它不完全是为了追求极限吞吐而生的，它更像是在回答一个问题——在硬件条件不变的前提下，怎么让开发者先用上一个远超显存规模的大模型。
所以这篇文章的核心内容就围绕airllm展开，从它的底层机制、安装配置、实测效果，到和一些常见推理框架的对比，以及我在使用过程中踩过的坑。如果你恰好也被“显存不够但模型太大”这个问题卡住，这篇文章应该能帮你省下不少试错时间。不管你是刚接触大模型推理的开发者，还是已经在用其他推理框架想换一个轻量方案的，都能在这里找到可以直接抄作业的部分。
2. 拆开airllm的底层设计：内存映射与按需加载的工作方式
2.1 为什么说它“借内存跑大模型”
airllm 的核心机制建立在操作系统的虚拟内存和文件映射之上。传统推理框架在加载模型时，会把整个权重张量读入显存，然后才开始前向计算。airllm 则利用内存映射（memory mapping）技术，把磁盘上的模型文件映射到进程的虚拟地址空间。表面上看，权重的指针已经“加载”了，但实际上数据还躺在磁盘上，只有当 CPU 或 GPU 真正访问到某个数据页时，操作系统才会把这一页从磁盘读到内存，再按需拷贝到显存。
这种懒加载的机制放在大模型推理的场景里，有一个非常实际的好处：并不是每一次前向传播都会用到模型的所有参数。以 70B 模型为例，Decoder 层的权重矩阵是按顺序被访问的，处理每个 token 时，当前层的权重进入显存参与计算，算完之后显存里的那些权重就不再需要了。airllm 正是利用了这个特点，把权重按层切分成块，每块大小经过精心设计，让显存里始终只驻留“当前正在计算的那一小部分”。
我刚开始接触的时候觉得这个想法有点反直觉，因为大多数框架都在想尽办法让更多权重常驻显存以提高缓存命中率，airllm 却反其道而行，接受“权重被打出去”这件事。但这种设计有一个前提条件：操作系统对文件映射的 IO 调度足够高效。实测中我发现，SSD 的随机读性能和内存带宽几乎决定了这个框架的体验上限。同样的模型文件放在机械硬盘和 NVMe SSD 上，推理速度能差出好几倍。
2.2 从 PageLoader 到连续批处理：关键组件的协作逻辑
airllm 里的一个重要组件是 PageLoader，这个名字一听就是受了操作系统虚拟内存分页机制的启发。模型权重不是作为一个整体被加载的，而是被切分成固定大小的页（page）。在推理过程中，当需要某一层的权重时，PageLoader 会检查这一层对应的页是否已经在显存中。如果在，直接取用；如果不在，它就从内存映射区域把这一页读入显存，同时把上一次使用的页释放出去。
这种页表管理机制让我想到 CPU 的 L1/L2 Cache 替换策略，虽然 airllm 的页替换算法远没有 CPU 里的那么复杂，但这个类比能帮你迅速理解它的运行逻辑：显存就是一块“高速缓存”，而内存或磁盘是“主存”。推理过程就是不断从主存往缓存里搬运数据，再在缓存里完成计算。
2.0 版本之后，airllm 还引入了连续批处理（continuous batching）能力。这个能力在 vLLM 里早就有了，但airllm把这些能力整合进来之后，在多用户请求场景下能显著提升 GPU 利用率。它的做法是把不同请求的 token 拼接成同一个序列，然后在一次前向传播中并行处理。由于每个请求的状态被独立维护，某个请求生成的 token 数量不会阻塞其他请求的进度。
2.3 关于“分块大小”和“页大小”的设计考量
要真正用好 airllm，理解分块大小的设定很重要。分块太大，显存里驻留的权重就多，缓存命中率自然高，但显存压力也大；分块太小，IO 请求变得频繁，推理速度会被磁盘读写拖累。airllm 默认会根据你的 GPU 显存大小自动计算一个合理的块大小，但我在实际使用中发现，手动调节这个参数能带来不小的性能差异。
如果你用的是 8GB 显存的卡，跑一个 30B 左右的模型，默认设置在大多数时候表现还可以，但对于比较长的生成序列，KV Cache 的增长会把显存挤得不够用，这个时候适当调小分块大小，把显存让给缓存，整体吞吐反而更好。反之，如果你的卡是 24GB 显存，分块可以调得大一点，减少 IO 次数，推理延迟会更低。
export AIRLLM_LOAD_THRESHOLD=0.7这是我比较常用的一个环境变量，作用是控制显存使用的上限阈值。默认情况框架会尽量用满显存，但在多任务并行的场景下，给其他进程留一些显存余量更稳妥。阈值调成 0.7 意味着显存占用达到七成时，PageLoader 就开始释放旧的权重页。这个值的设定没有绝对标准，需要根据自己的使用习惯去调。
3. 上手实操：从安装到跑通一次大模型推理
3.1 环境准备中最容易被忽略的两个细节
airllm 的安装本身很简单，Python 环境里一行 pip 就能搞定。但真正让我栽跟头的是两个环境细节。第一个是操作系统对文件映射性能的影响。Linux 下 airllm 会调用mmap系统调用，配合madvise给内核提供顺序访问的提示，性能表现最好。但在 macOS 上，同样的模型文件加载速度明显偏慢，我的实测猜测和内存映射的实现差异有关。如果你长期要用这个框架，建议优先准备 Linux 环境。
第二个细节是模型格式。airllm 支持 Hugging Face 上常见的 safetensors 格式，但如果你用的是老式的.bin权重文件，需要先转换。我一开始图省事，直接把一个.bin格式的模型路径传给 airllm，结果加载直接报错，后来查文档发现项目已经对齐到 safetensors 为主，.bin格式需要先通过转换脚本处理。
## 安装命令 pip install airllm装完之后可以跑一个最简验证：
from airllm import AutoModel model = AutoModel.from_pretrained("某个模型的HuggingFace路径") input_text = ["请介绍一下杭州"] output = model.generate(input_text, max_new_tokens=100) print(output)3.2 加载模型时看到的日志到底在说什么
第一次加载模型的时候，控制台会输出一些调试信息，包括模型层数、每层权重的大小、选定的页大小、显存预算等等。这些日志不是无用的，它们会直接告诉你当前配置下理论上的最大并发数，以及首次推理时预热的耗时。我当时看到的第一条关键信息是每层权重大约占多少显存，这让我初步判断出在生成过程中大约会有多少层被换进换出。
这里有个经验：第一次加载大模型的时候，日志里显示的加载时间往往很长，因为内存映射还没产生足够的页缓存，冷启动阶段读的是磁盘。第二次再加载同一个模型，速度会明显快很多，因为操作系统的页缓存已经把热数据留在内存里了。如果你在测试过程中反复重启进程，前后加载速度差异会非常明显，这不是代码出 bug，而是页缓存生效了。
不过要提醒一句，页缓存会占用系统内存，如果你的机器内存本身就比较紧张，加载超大模型可能会导致系统整体变慢。这个时候可以考虑用posix_fadvise或者手动清理页缓存的方式来缓解，但日常测试我觉得完全没必要折腾这些。
3.3 生成速度怎么样：一组我自己跑出来的参考数据
口说无凭，我把自己在本地环境里实测的一组数据放出来。测试机配置是某款消费级显卡，显存 12GB，CPU 是 16 核，内存 64GB，SSD 是普通的 PCIe 3.0 NVMe。
| 模型规模 | 量化精度 | 平均生成速度（tokens/s） | 首 token 延迟 |
|---|---|---|---|
| 7B | 不量化 | 12.8 | 1.2s |
| 13B | 4bit | 8.6 | 2.1s |
| 30B | 4bit | 3.4 | 4.5s |
| 70B | 4bit | 1.9 | 8.3s |
这个数据仅供参考，因为不同模型的自注意力层大小、序列长度、KV Cache 占用都会影响最终数字。但大致可以看出一个规律：模型规模翻倍，生成速度并不是线性减半，而是衰减得更厉害。原因在于层数变多之后，权重换入换出的次数增加，IO 开销占的比例越来越大。不过换个角度看，能在 12GB 显存上跑出每秒 1.9 个 token 的 70B 模型，在很多文本生成的场景下已经是可用的了。
4. AIRLLM 2.0：重度优化后的推理速度能提升到什么程度
4.1 从 “能跑” 到 “跑得更快” 的进化路径
airllm 的早期版本更侧重于解决“能不能跑”的问题，只要能把模型塞进显存，就算成功。但 2.0 版本的重心明显转向了推理速度和吞吐量。整个优化策略分成几个层面：更精确的页调度策略、对连续批处理的原生支持、以及权重加载路径上的 IO 优化。如果用一句话概括，就是让有限的显存更高效地服务于计算。
我记得最直观的一个变化是同一个模型在同一张卡上，2.0 版本的生成速度比早期版本提升了大约 40% 到 60%。这个提升一部分来自连续批处理带来的 GPU 利用率上升，另一部分来自权重预取（prefetch）机制。预取的意思是，当模型正在计算第 N 层的时候，PageLoader 已经根据顺序访问的规律，提前把第 N+1 层的权重页加载到显存里了。计算和 IO 重叠起来，等待时间被大幅压短。
4.2 连续批处理的实际收益：多用户场景下的吞吐对比
如果你只是自己一个人跑模型玩，2.0 的连续批处理感觉可能没那么明显。但在服务化部署场景下，连续批处理能同时处理多个请求，不同的请求在不同时间点生成各自的 token，所有请求的 token 都被拼接进同一个 batch。我做了个简单的压测，模拟 8 个并发请求的情况下，连续批处理模式相比逐个处理模式，总吞吐提升了大约 3 到 4 倍。
需要强调的是，这种提升不是没有代价的。当多个请求的序列长度差异很大的时候，batch 内会产生计算空洞，短序列的请求已经完成，长序列还在跑，GPU 有一部分算力是浪费的。airllm 目前对这种情况的处理方式是尽量把序列长度相近的请求分在同一批，内部的调度算法没那么激进，但胜在稳定。
4.3 长文本场景下的内存控制策略
用 airllm 跑长文本生成时，最需要注意的就是 KV Cache 的大小。对于一个支持 8K 上下文的模型，当序列逐渐变长，缓存占用的显存会一路增长，而 PageLoader 只管理权重页，不管理 KV Cache。所以长文本场景下需要观察显存使用情况，必要时手动调整 max_new_tokens，防止生成中途 OOM。
我自己在跑一个 30B 模型时，把最大生成长度设定到 2048 tokens，显存占用在生成后期明显走高，一度出现卡顿。解决方案是设置环境变量，把权重加载阈值调低，给 KV Cache 留出足够空间。
export AIRLLM_LOAD_THRESHOLD=0.6调低阈值后，卡顿问题明显缓解。代价是权重页被更频繁地换出，生成速度下降了一些。所以这里有个取舍：要长文本还是要速度，需要根据任务类型决定。短文本高频请求的场景，阈值高一点；长文本低并发的场景，阈值低一点更安全。
5. 实测踩坑：分块加载策略和显存调优中遇到的真实问题
5.1 最常见的报错：显存碎片化问题
用 airllm 跑了差不多两个星期之后，我开始遇到一些比较隐蔽的问题。最常见的是长时间的连续推理之后，报出一个显存分配失败的错误。这个问题的根源不是显存总量不够，而是显存碎片化。PageLoader 在推理过程中反复加载和释放权重页，在不同大小的显存块之间留下了很多零散的缝隙，后续需要一块连续的显存来放置新页时，明明总剩余空间够，却分配不出来。
这个问题的复现路径很清晰：跑一个 13B 模型，生成长度设置很大，让 PageLoader 频繁换页，跑上几十个请求之后，崩溃概率显著上升。如果只是偶尔跑几个短请求，基本上不会遇到。
我的解决方法是给进程增加定时重启的机制，或者在空闲时主动释放整个模型的显存占用再重新加载。本质上这是一个通过重启来做显存碎片整理的办法，笨但有效。如果想彻底规避这个问题，就需要在更底层去优化分配器，目前 release 版本里还没有看到这方面的明确优化。
5.2 闪存速度瓶颈：为什么升级到 PCIe 4.0 SSD 效果明显
前面提到 IO 开销是 airllm 的上限瓶颈之一。我做过一个控制变量的测试：同一个模型，同一个显卡，只把系统盘从 PCIe 3.0 的 SSD 换到 PCIe 4.0 的 SSD，生成速度提升约 25%。因为权重页的按需加载本质上是一个大量小 IO 的操作，顺序读性能对最终的推理速度影响很大。
如果你的机器用的是机械硬盘，我强烈建议至少把模型文件放到固态硬盘上。机械硬盘的随机读延迟比 SSD 高一个数量级，airllm 的换页效率会被严重拖累，跑 7B 模型都可能卡到不可用。如果你有条件，用内存盘（把模型放进 tmpfs）体验会更好，加载速度和换页延迟可以做到几乎无感，但这就需要足够大的系统内存来承载整个模型文件了。
5.3 用 AIRLLM_RANK 和 AIRLLM_WORLD_SIZE 做多卡并行时的注意事项
airllm 支持简单的多卡并行，通过环境变量控制进程的 rank 和 world size。我拿两张同型号显卡试着跑了一个 70B 模型，理论上可以把不同的层分配到两张卡上分别计算。实际用下来，跨卡通信的开销比较明显，吞吐收益没有想象中大，尤其是在单张卡也能勉强跑动的情况下，多卡并行反而因为通信开销导致端到端速度下降。
所以我的建议是：如果单卡能跑，优先单卡。只有在单卡完全 OOM 的情况下，才考虑多卡并行。而且多卡并行时要注意，两张卡之间的通信带宽决定了并行效率，PCIe 通道不够宽的话，跨卡传输会成为新的瓶颈。
6. 和其他推理框架的横向对比：什么时候选airllm，什么时候不选
6.1 与 vLLM、Ollama、llama.cpp 的定位差异
很多人在选推理框架时容易陷入一个误区：觉得越“强”的框架就越好。但实际工程里，没有绝对的最优框架，只有最匹配场景的选择。airllm 从设计目标上就和 vLLM 这类框架不太一样。vLLM 追求的是服务化部署下的高吞吐，它的 PagedAttention 为多请求场景做了大量精细优化，但对显存的要求也更高；llama.cpp 则更偏重 CPU 推理和边缘设备，GPU 支持也有，但显存容纳不了的模型处理方式没有 airllm 这么系统化。
拿 ollama 来对比的话，Ollama 的优势在于极低的使用门槛，装完就是一个类似 Docker 的体验，命令一行就能启动模型服务。但 Ollama 底层的显存调度策略更保守，模型放不进显存就只能整层搬到 CPU 上算，不会像 airllm 这样在页级别做精细的换入换出。所以在“显存不够但想跑大模型”这个特定场景下，airllm 的优势恰恰来自这种页级别的调度粒度。
6.2 一张表看懂不同框架的适用边界
| 框架 | 显存优化粒度 | 最大适配模型规模 | 最佳使用场景 | 部署门槛 |
|---|---|---|---|---|
| vLLM | Page 级别（KV Cache） | 受显存限制 | 高频多用户服务 | 中 |
| Ollama | 权重整体加载或整体卸载 | 显存能放下的模型 | 个人快速体验 | 低 |
| llama.cpp | 层级别加载 | 取决于内存 | CPU、边缘设备 | 中 |
| airllm | 权重页级别换入换出 | 远超显存规模 | 显存受限的大模型推理 | 低 |
从这个表可以很清楚地看出，airllm 的独特位置在于它把“权重管理”这个事做到了页级粒度，而不只是停留在 KV Cache 层面。它最适合的场景就是：你手上只有一张普通消费级显卡，又特别想跑一个大参数模型，同时对实时性的要求没有到毫秒级那么苛刻。
6.3 速度与便利的权衡：为什么短任务优先用airllm，长任务建议换方案
根据我的实测经验，如果把任务分成短任务和长任务两类，airllm 在短任务上的优势非常明显。短任务意味着生成的 token 数量不多，比如 100 到 300 个 token，模型权重页换入换出的总次数有限，IO 开销占比低，最终体验接近显存足够的场景。
但如果是长任务，比如生成几万字的长文档，权重页会被反复换入换出，累计的 IO 等待时间就会变得很明显。这种情况下，airllm 的每秒生成速度会逐步下降，最终的端到端耗时可能比显存足够的方案高出很多。所以我自己在跑长任务时，会优先考虑把任务切分成多个短片段，或者换用其他能完整驻留显存的模型。
7. 从使用airllm中学到的模型推理优化方法论
7.1 显存占用不是只能靠量化来解决的
在用上 airllm 之前，我面对显存不够的第一反应就是量化：从 FP16 降到 INT8，再降到 INT4。量化确实能显著降低显存占用，但它也有代价，模型精度损失、推理速度变化、部分层结构的兼容性问题，这些都是需要权衡的。airllm 提供的是另一条思路：不压缩权重，而是在时间维度上错开使用权重的时刻，让同一块显存被反复利用。
这两种思路可以组合使用。先用 4bit 量化把模型体积减小，再用 airllm 的按需加载机制跑超出显存的量化模型，效果很好。我试过一个 70B 的 4bit 量化模型，在 12GB 显存上跑，速度和精度都能接受。
7.2 设计推理系统时要考虑数据的“流动性”
airllm 给我的最大启发不是那个内存映射技术本身，而是它背后的思考方式：数据不一定都要常驻高速存储，只要能保证计算单元在需要的时候能快速拿到数据，系统就能工作。这个思想可以迁移到很多系统设计里。比如一些数据处理管道，不需要把所有数据都加载到内存里才开工，完全可以边加载边处理，用流的思路来降低内存峰值。
在实际做项目的时候，我会刻意评估一下自己的系统有多少数据是真正高频访问的，有多少数据其实是可以按需读取的。很多时候，构建系统时习惯性地把所有数据都塞进内存，浪费资源不说，还限制了系统能处理的数据规模。airllm 这种“小缓存 + 大存储”的架构思路，Scale 能力其实很强。
7.3 什么情况下应该复制 airllm 的方法而不是直接使用它
airllm 不是万能药。如果你的模型运行场景是高频低延迟，比如实时对话机器人，每一次请求都要严格控制延迟，那按需加载的机制本身就引入了一次不可避免的 IO 延迟，这种情况下你应该直接买更大的显存，而不是用 airllm。另外，如果你的模型不是 Decoder 架构，而是类似 BERT 这种双向编码器结构，权重页的访问顺序没有自回归推理那么规律，airllm 的预取策略就很难做到最优。
所以我把这种方法论定义为“资源受限场景下的妥协方案”。它适合的是那些对延迟不那么敏感、但需要大模型能力的应用，比如批处理任务、离线文本分析、定时生成的报表内容，等等。在这些场景下，airllm 能让你用很低的成本获得远超硬件上限的模型能力。
8. 最后留几个实用技巧
用 airllm 的时间不算长，但踩过的坑足够让我总结出几条实在的建议。第一，模型文件的位置尽量放在本机 SSD 上，不要放网络挂载盘。远程存储的网络延迟会直接放大每次换页的开销，表现就是生成的 token 像挤牙膏一样，一个词一个词地蹦出来。第二，启动时留意日志里的页大小信息，如果机器的显存比较大，可以尝试调大页大小的上限，能减少换页次数。第三，第一次跑大模型的时候，先把序列长度调短，确认基础链路通畅后再逐渐加长，不要一上来就挑战极限。
还有一个小技巧，用命令行直接运行 demo 时，如果发现后续生成速度明显变慢，可以先看看系统内存占用，绝大多数情况是页缓存被其他进程挤掉了，导致权重文件要重新从磁盘读取。这时候最简单的办法就是别管它，多跑几个请求之后页缓存自然就回来了。
airllm 这个框架还在持续迭代，社区讨论也比较活跃，预计后续版本会在显存碎片化管理和多卡通信上继续优化。如果你手头正好有显存不够用的问题，与其纠结于换卡还是降级，不如先把这套机制用起来。它能给你提供一种“软性扩展显存”的手段，而且整个上手成本很低，试错空间很大，值得花一个下午玩一玩。
