1. 显存不够，为什么还要在本地跑大模型

先说我最近遇到的一件真事。有位朋友攒了一台机器，显卡是消费级产品，显存只有8GB，他兴致勃勃地跟我说想跑7B参数级别的开源底座模型，结果刚把权重加载进去就报CUDA out of memory，整个人当场就泄气了。我跟他说，你这个问题不是卡不行，而是加载方式不对。很多人一听到大模型第一反应就是显存必须大，A100、H100这种服务器显卡才配碰，但如果你只是想在自己机器上做推理、做实验、跑本地方案，其实有另外一条路可以走，就是airllm这类逐层加载的工具。

先解释一下“为什么显存是硬门槛”。一个7B参数的模型，如果用FP16精度存储，光权重就需要大约7乘以2，也就是14GB的显存。你还没开始推理，权重就已经塞不进8GB的卡里了。更别说推理过程中还会产生中间激活值（activations）和KV Cache，这俩也都是吃显存的大户。所以传统加载方式确实是寸步难行。但注意，这个门槛的本质是“一次性把所有层都放进去”，而不是“每一层都需要那么多空间”。airllm的核心思路就是改变这个前置条件，它不要求你把整个模型常驻显存，而是每次只往显存里放正在计算的那一层，算完就换出，再加载下一层。这个思路听起来平平无奇，但实现好之后，8GB的卡就能跑7B模型，16GB的卡甚至可以去摸13B那一档。

这篇文章我打算把airllm从头到尾拆开讲清楚，包括它的逐层推理机制、环境准备、实际跑通的代码、我实测下来的性能表现，以及踩过的一堆坑。内容不分基础，哪怕你之前只跑过普通对话模型，也可以按步骤复现。想清楚一点：本地跑小一些的开源模型不是为了替代线上服务，而是为了数据不出门、方便反复调试、以及彻底搞明白模型在做什么。

1.1 “低显存推理”听起来很吸引人，但先搞明白它牺牲了什么

很多人一听“8GB显存能跑7B模型”就兴奋，觉得以后不用买大显存卡了。这话只对了一半。airllm这种方案解决的是“能不能跑”的问题，而不是“跑得爽不爽”的问题。我的实测体验是，逐层加载会让模型生成速度明显下降，说白了就是硬啃和细嚼慢咽的区别。你愿意用速度换容量，它才成立。

所以我一般建议别人先问自己做本地推理到底要干什么。如果是跑个对话Demo、验证模型行为、处理点敏感数据，那airllm非常合适。如果你要的是高吞吐、低延迟的批量推理，那就别折腾这条路，老老实实上大显存卡，或者用其他支持批量优化的推理框架。搞清楚这个前提，后面所有操作才有意义。

1.2 airllm和“模型量化”不是一回事，别混淆了

还有一层误解要澄清：airllm不等于量化。很多人看到低显存跑大模型就默认是4bit、8bit那些压缩技巧，其实airllm做的事情跟量化是两条独立的技术路线。量化是把权重精度降低，把原本需要16bit表示的数用4bit或8bit近似，从而压缩体积；而airllm靠的是运行时调度，把矩阵计算切到一层一层，配合内存换入换出。它们可以组合使用，比如先量化再逐层加载，效果更好，但基本原理完全不同。

这一点在实际选型时特别重要。如果你只缺显存但不太缺时间，可以不开量化直接用airllm；如果你既缺显存又希望速度稍微好一点，那量化加airllm两条腿走路会更划算。我在后面的调优部分会给一些具体组合建议。

2. Layer-wise逐层推理：airllm的核心机制拆解

这部分是重点，也是理解airllm的关键。我不打算泛泛而谈什么“智能调度”“优化内存”，我们要把机制拆到能想象出每个环节在干什么。只有理解了这一层，你才能在它不干活或者报错的时候知道问题出在哪。

2.1 前向传播怎么被“切片”

大语言模型的推理过程，本质上是让输入数据挨着走一遍模型的所有层。传统做法是一步到位：把整个模型放进显存，输入从第一层流到最后一层，最后一层吐出来的东西就是概率分布。airllm改变的是这个过程中权重的存在方式。

具体来说，当输入数据从第0层进入时，airllm会检查当前显存里有没有第0层的权重。没有？那就从CPU内存或者磁盘上把这一层的权重读进显存。计算完第0层，得到一组中间输出，然后把第0层的权重从显存里挪出去，再加载第1层的权重，继续计算。如此往复，直到最后一层结束。这个过程中，显存里同时存在的权重最多就是一两层，所以7B模型的14GB权重被拆成了几十份极小碎片，显存压力自然就降下来了。

这里有个关键点很容易被忽略：中间激活值怎么办？模型第0层输出的是一个高维张量，要传给第1层继续算。这些张量如果全放显存，量也很可观。airllm的做法是把它们落在CPU内存或者磁盘上，等下一层计算时再取回来。这实际上是一个“换页”机制，跟操作系统的虚拟内存很像。

2.2 为什么这个思路不能用来做训练

我刚理解这个机制的时候也想过：如果显存只放一层的权重这么省空间，为什么不能用它来微调模型？后来一查就明白了，训练和推理的核心差异在于反向传播。

推理只需要前向传播，每层的中间结果用完就可以丢，最多保留当前这一步。训练不一样，反向传播要从最后一层往前算梯度，每一层的中间激活值都必须存下来供后面使用。你想想，如果逐层加载但每一层的中间结果都要保留，那显存是省下来了，内存和磁盘直接变成新的瓶颈，而且训练过程中频繁换权重的开销比推理高好几个数量级。所以airllm这类方案的适用范围很明确：推理。你要是想训练，还是得想别的办法。

2.3 为什么逐层加载没有慢到完全没法用

理论上说，从磁盘读权重肯定比从显存读慢很多，为什么airllm跑起来还是有一定实用性？我观察下来有三个原因。

第一，模型权重一旦从磁盘或CPU内存加载过一次，操作系统往往会做页缓存，第二次读取同一层时速度会快很多。也就是说，只要你连续做多次推理，权重大概率已经有一部分驻留在系统内存里了。第二，模型结构中有很多参数是可以在连续计算中复用的，比如隐状态维度在整条链路里通常保持一致，分配好的内存缓冲区可以反复使用。第三，LLM生成是一个接着一个token的过程，前一个token计算产生的KV Cache可以保留，供后续token使用，这部分并不需要像权重那样整层换出。正是这些因素叠加，airllm虽然慢，但还不至于让人等到崩溃。

在这也顺带提醒一下：既然权重会被反复读，那磁盘速度就非常重要。如果你是机械硬盘，那体验可能是噩梦级别；换到NVMe SSD之后，同一个模型生成速度能明显感觉到改善。不要小看这块，我后面实测部分会具体说。

3. 环境准备与安装：先把基础踩牢

airllm的安装本身不复杂，但它对环境有一定要求，而且有一些细节不提前处理，后面跑起来全是问题。我把我的安装过程和环境配置记录在下面，你照做基本就能顺利跑通。

3.1 硬件、操作系统与依赖

从原理上也能猜出来，airllm依赖几个大件：一块支持CUDA的NVIDIA显卡、足够多的CPU内存、以及一个速度过得去的固态硬盘。操作系统我建议用Linux，Windows和macOS也能装，但很多坑都是在这两个平台上被踩出来的。

我先说一个我踩过的教训：CPU内存不能只有显存那么点。因为airllm会把很多中间状态放到CPU内存里，如果你系统内存只有16GB，跑13B模型的时候很容易直接把内存占满。我个人建议想跑7B模型至少准备24GB以上系统内存，想跑13B则最好有32GB以上。你可能觉得奇怪，显存8GB能跑，为什么CPU内存反而要那么大？因为被“换出”的权重不是消失了，它只是挪了一个地方，那地方就得有足够空间容纳。

依赖方面，主要是PyTorch版本和CUDA版本要匹配。安装之前先检查一下自己的CUDA版本。我个人比较保守，一般用稳定的PyTorch版本搭配对应CUDA版本。如果你机器上装过其他深度学习框架，建议用新一点的环境跑airllm，避免库冲突。

3.2 安装步骤与环境变量设置

安装airllm很简单，官方推荐的方式是直接通过包管理器完成。这一步没什么花活，但装完以后有几件事我建议立刻做。

先把环境变量设置好。为什么需要环境变量？因为airllm运行时需要知道两件事：一是它可不可以把中间状态写到磁盘上，二是要不要强制使用某种缓存策略。不同版本的airllm对环境变量支持不太一样，我这边比较常用的是把缓存目录指到一个大分区，防止默认目录在系统盘把空间撑爆。你可以在shell里这样设置：

export AIRLLM_CACHE_DIR=/path/to/large/disk export AIRLLM_USE_CPU=0

AIRLLM_USE_CPU=0的意思是优先使用GPU计算。如果你在调试阶段没有合适的显卡，想先让代码跑通看看流程，也可以临时设置成1，这时候它会走CPU推理，速度会更慢，但能验证整个链路是否正常。

装完之后我建议跑一个最小验证，用Python导入airllm包，随便创建一个很小的模型实例，或者加载一个很小的模型试试推理。这比直接上7B模型要稳妥得多，因为7B模型首次加载加运行，要下载权重、处理格式、分配内存，中间任何一个环节出错，排查起来都费时间。先小后大，能省很多事。

4. 跑通第一个推理案例

环境准备好之后，就该让模型真正说话。这一节我给出一个完整的示例，并解释每一步做了什么。我用的模型是开源社区常见的底座权重，你们可以替换成自己喜欢的同规模模型。注意不同版本之间API细节可能有微调，以你安装的版本说明为准，但整体流程大差不差。

4.1 初始化模型与分词器

核心Python代码如下。我尽量保持精简，方便你理解全貌：

import torch from airllm import AirLLMLlamaForCausalLM from transformers import AutoTokenizer model_name = "some-community/7b-base" model = AirLLMLlamaForCausalLM.from_pretrained( model_name, compression=4, # 可选：4bit量化，进一步降低内存占用 dtype=torch.float16, # 半精度推理，减少显存和带宽 ) tokenizer = AutoTokenizer.from_pretrained(model_name)

这里有个容易被忽略的坑：compression=4不是必填项，但如果你显存不太宽裕，强烈建议加上。它是把每一层的权重再做一次4bit量化，进一步缩小体积。代价是精度损失，但实际对话中感知不明显。如果你机器的CPU内存很充裕，也可以不开量化，速度会更稳定一些。

还有一点值得注意：AirLLMLlamaForCausalLM这个类名只适用于LLaMA系结构。如果模型是其他结构，airllm通常也会提供对应的类。你不确定的时候，直接看项目的模型说明文件就知道该用哪个类。

4.2 生成文本时的参数选择

初始化完了就可以走生成逻辑：

prompt = "模拟项目X的核心理念是什么？" inputs = tokenizer(prompt, return_tensors="pt") with torch.inference_mode(): output_ids = model.generate( inputs.input_ids, max_new_tokens=128, do_sample=False, temperature=1.0, ) result = tokenizer.decode(output_ids[0], skip_special_tokens=True) print(result)

这里我说几点可能影响你实际体验的细节。max_new_tokens不要一上来就设500，逐层加载的方式生成每个token都要经过整个前向传播，token数量越多，耗时越久。建议先设128，跑通看效果再调整。do_sample=False会让输出保持稳定，方便你验证是不是自己的输入有问题。

另外就是，airllm在加载模型权重时通常不会显示很明确的进度条，你可能会觉得“是不是卡死了”。实际上它只是在默默地从磁盘往内存里搬权重。那种安静不代表故障，耐心等一会儿就行。

4.3 如何确认模型真的在正常工作

我第一次跑完的时候其实不确定它是不是真的用了我的显卡，还是偷偷在CPU上算完的。这个检查很简单：模型开始推理后，在另一个终端窗口执行nvidia-smi，看显存占用和GPU使用率。如果某个进程的显存占用在几百MB到1GB之间浮动，同时GPU利用率不是0，就说明它确实在用显卡做逐层推理。

还有一个检查点是输出质量。如果模型输出充满乱码、重复或者明显语义断裂，大概率是精度问题或者加载问题。我建议你先用一段简短、逻辑清晰的prompt跑一次，比如“用一句话解释什么是缓存”，看看输出是否完整。如果这一步正常，再慢慢加长文本，加大生成长度。

5. 实测表现与调优：不同硬件上的效果

跑通只是第一步，真正决定你用不用得爽的是“实际速度有多快”。我整理了我在几套硬件环境下的实测感受，并把调优过程记录下来。

5.1 我在几套配置上的实际体验

先说明，我这里的数字都是个人测试环境下的体验值，不同机器、不同进程状态都会影响结果，但你大概能从中感受到量级。

这个表格很能说明问题：显存和内存大小决定“能不能跑”，但磁盘类型和内存总量决定“跑得是否痛苦”。同样的模型和显存，机械硬盘比NVMe固态慢非常多。我后来想想原因也简单：逐层加载的关键就是不断读取权重碎片，机械硬盘的随机读写能力实在太弱了。所以如果你的目标是认真用airllm，有一个NVMe SSD几乎算是硬性需求。

还有一个规律值得记住：模型规模从7B升到13B，生成速度不是线性变慢，而是明显变慢更多。因为模型层数更多、中间状态更大，换入换出的压力成倍增长。所以我的建议是，能跑7B绝不轻易上13B，除非你真的需要13B的能力。

5.2 调优方向：量化、批大小、缓存策略

调优第一步是量化。如果你显存紧张，先开4bit量化，这几乎是收益最明显的操作。开了量化之后，单个权重体积缩到原来的四分之一左右，换入换出的数据量也大幅减少，等于同时优化了几个环节。但量化会让输出质量出现细微下降，我一般会在“能开则开”和“必须保证输出质量”之间权衡。

第二步是调整批处理大小。batch_size设成1通常是逐层加载最稳妥的选择，因为更大的批意味着中间激活值也成倍扩大，对内存和显存都是额外负担。除非你是做吞吐测试，否则我建议保持单条推理。

第三步是缓存策略。前面提到系统内存足够的时候，权重第一次读进内存后，第二次读取会快很多。我实测发现，如果你连续跑两次相同的prompt，第二次速度明显比第一次快，这就是操作系统页缓存的功劳。所以如果你要在本地反复测试模型，可以设计成连续处理多个句子，不要每句话之间隔太久，这样缓存能持续发挥作用。

5.3 别忽视CPU内存和磁盘空间

这两点我在前面强调过好几次，为什么还要单独拿出来讲？因为我看群里不少人在这一块吃大亏。有个人说airllm跑起来了，但跑到一半系统直接弹“内存不足”，还以为是显卡爆了。我让他看系统内存，好家伙，32GB被吃了一大半。因为权重从显存换出后放在系统内存里，没有及时释放，而连续推理多轮之后，累积的内存量非常可观。

所以建议你在跑较大模型之前先用free -h看一下当前系统内存占用，确保没有其他吃内存的大程序在跑。磁盘方面同理，7B权重本身加上中间缓存，轻轻松松占用几十GB。开始跑之前看一眼磁盘剩余空间，别等到写到一半才发现满了。

6. 我在逐层推理中踩过的几个坑：从静默崩溃到速度骤降

airllm用起来不算复杂，但真正实操的时候，坑全在一些文档不太会写的细节上。我把踩过的几个问题整理出来，每个都包含排查链路和解决方法，希望帮你少走弯路。

6.1 显存没爆却报错，问题出在系统内存

我遇到的第一个诡异现象是：nvidia-smi里显示显存占用也就1GB多，按理说完全够，但程序在推理中途直接退出，日志里写的是内存分配失败。我一开始以为显卡驱动出了问题，折腾半天没解决。后来抱着试一试的心态看了一下系统内存，发现已经被占用了90%以上，才知道问题根本不是显存，而是airllm把大量中间层输出放到了CPU内存里，内存被吃完了。

排查链路很简单：当报错跟内存有关时，先同时看显存和系统内存相关命令，对比哪个在推理过程中持续攀升。如果系统内存涨得快，就是在不断累积中间状态。解决办法有两个：一是设置环境变量，允许airllm把一部分缓存写入磁盘，相当于用磁盘换内存；二是减少并发或者减小模型的批量大小。两个办法可以同时用，但第一种对速度影响较大，适合内存实在不够的情况。

6.2 中断之后，缓存残留导致的结果异常

有一次我调模型的时候中途按了两次Ctrl+C强杀进程，之后再跑同一个模型，发现输出质量突然变得很差，而且每次输入相同的文本，结果却不一致。这个现象很奇怪，同一个模型、同一个输入、关闭了采样，理论上应该稳定才对。

我排查了好久，最后怀疑是缓存目录里残留了上一轮中断时没写完的中间结果。airllm在推理过程中会把一些中间状态写到磁盘缓存，强杀进程后这些半成品文件不会自动清理。等下次再跑时，如果逻辑片段读取了这些不完整的缓存，后续计算结果就被污染了。

解决方式很粗暴：找到缓存目录，删掉里面的内容，重新跑一次。一般都能恢复正常。从此以后我养成了一个习惯：凡是要长时间运行的推理任务，尽量正常结束进程，不要频繁强杀。

6.3 量化开了之后，模型突然“不懂人话”

还有一次我图省事，直接给一个7B模型开了4bit量化，结果生成的回答颠三倒四，连简单的常识问答都出错。我当时差点怀疑是权重下载损坏，重新下载后问题依旧。后来才反应过来，问题出在我只量化了模型主体，却没有考虑数值分布差异。

排查方式是对比实验：同一段prompt，先用不量化的方式跑一遍，再用量化跑一遍，看差异到底有多大。如果你发现量化后质量下降严重，可以把量化位数从4提到8，或者反过来，直接用更高精度的加载方式。不要一上来就追求极端压缩，质量与资源需要取得平衡。

这里也想提醒一下：不同量化实现的效果差异很大，airllm的量化算子不一定适配所有模型结构。你换模型后最好重新做一次质量评估，不要因为上一个模型量化效果好就盲目沿用同样的配置。

6.4 长上下文场景下速度骤降

我实测发现，让模型生成200个token和生成50个token，后者的逐token速度明显更快。这不是错觉，因为随着生成越来越长，KV Cache会不断累积，这些缓存虽然不需要像权重那样整层换进换出，但它们本身也占据内存，并且每一步都要参与注意力计算。当上下文变得很长时，即使airllm只加载一层权重，注意力计算的压力也在增大。

所以如果你确实需要长文本生成，我建议分阶段处理：先让模型生成前半段，保存中间结果，再用后续的prompt继续生成。不要指望一次生成上千token还保持流畅。你的目标应该是在“能跑”和“跑得动”之间找到那个平衡点。

6.5 与其他推理框架共用显存导致的不稳定

我有一台机器上同时跑着其他常驻服务，监听了一些GPU端口。airllm运行的时候，偶尔会出现推理速度忽快忽慢的情况。排查后发现问题在于显存被其他进程占了部分空间，airllm试图动态加载层的时候，可用的显存空间在不停变化，导致调度不太稳定。

处理办法很简单：运行airllm之前，先把其他占用显存的任务停掉，或者给airllm进程设置可见的显卡范围，让它只能看到某张特定的卡，避免互相干扰。如果实在无法避免共用，那至少要把最大显存预算控制好，给airllm留出一块清晰、稳定的空间。

7. 跟其他低显存推理方案怎么选

很多人会问：既然已经有其他方案可以做显存优化，为什么还要用airllm？适合的场景完全不同。我把几个常见方案的定位说清楚，你就能自己做判断了。

7.1 方案对比一览

从表里能看出来，airllm的优势在于“门槛最低”，而不是“速度最快”。它在显存很小的情况下依然能跑动相对大的模型，这是其他方案很难做到的。但你也必须接受它的速度上限。如果你手里有一张12GB或者16GB显存的卡，先试试量化加传统推理，如果效果还行，那就不一定非得上airllm。只有当显存小到量化都救不回来的时候，airllm才是真正的救星。

7.2 我的选型建议

结合我自己的经验，我给不同需求的人这样建议：

如果你只是偶尔在带显卡的笔记本上跑个Demo，显存4到8GB，那airllm几乎是首选。至少它能让你跑起来，其他什么都不重要。

如果你是做Agent开发或者工具调用，每次推理的响应速度很关键，那我还是建议优先考虑用量化加常规推理框架，甚至用云端接口兜底。因为airllm的逐token延迟确实让人着急，交互式应用体验会打折扣。

如果你是研究模型的内部行为，需要反复查看中间隐藏状态，那airllm也有价值，因为它的逐层机制天然让你能观察每一层的输出。这种场景下速度慢反而不是大问题，能拿到中间结果才是关键。

7.3 最后再做一次取舍判断

说到底，airllm不是一个“万金油”工具，它是一个让“跑不起”变成“跑得动”的妥协方案。我的经验是，先确定你的瓶颈是显存还是速度，再选择合适的方案。如果显存是瓶颈，airllm值得一试；如果速度才是瓶颈，那再大的显存优化也救不了你。

还有一点小经验，很多人一开始用airllm是因为觉得它装起来方便，但真正用顺手之后会发现，最费时间的不是安装而是调优。量化位数、缓存目录、批量大小、环境变量，每一项都可能影响最终体验。建议第一次跑通之后，先记录一组基准数据，再逐项修改参数做对比，不要凭感觉乱改，那只会浪费时间。

我在实际使用中的体会是，airllm适合那些愿意多花一点时间换取更大模型可用性的人。它的逐层加载思路不复杂，但当你第一次在那张小显存显卡上跑起一个自己不敢想的模型时，那种成就感还是很真实的。如果你也想在低显存设备上探索大模型，不妨照着这篇文章的流程试一遍，跑通之后，再根据你自己的任务需求做裁剪和优化。