单卡跑大模型：airllm分层加载机制与实操调优指南

1. 单卡跑大模型的现实困境与破局思路

显存不够这件事，几乎是每个想在自己机器上跑大模型的人都会撞上的第一堵墙。一张消费级显卡，显存就那么十几到二十几GB，而一个70B参数的模型，光是权重按FP16存下来就要接近140GB，这还没算推理过程中的激活值、KV Cache这些额外开销。很多人第一反应是去租多卡机器，或者干脆放弃本地部署改用在线服务，但这两条路各有各的麻烦——前者成本高，后者数据不在自己手里。

airllm这个项目就是冲着这个痛点来的。它的核心主张非常直接：让你用一张甚至显存很有限的单卡，跑起远超显存容量的大模型。它做的事情不是量化压缩到失真，也不是蒸馏出一个小模型来替代，而是通过一套分层加载加按需调度的机制，把大模型的权重拆开，在推理时只把当前计算需要的那一层搬进显存，算完就换出去。听起来像是把内存当显存用的老思路，但真正落地时有一堆工程细节要处理，airllm把这些细节封装成了相对好用的接口。

这篇文章适合几类人看：手上有单卡但显存吃紧、想本地跑大模型的开发者；对模型推理底层机制感兴趣、想搞清楚分层加载到底怎么实现的技术爱好者；以及正在做推理优化、想借鉴airllm思路做二次开发的人。我会从它的整体设计思路讲起，把核心机制拆开，再给出一套可以直接照着做的实操流程，最后把我踩过的坑和排查经验整理出来。读完之后你应该能自己判断：这个方案在你的场景下到底值不值得用，以及用的时候要注意什么。

2. 整体设计思路与方案选型拆解

2.1 为什么是分层加载而不是量化

面对显存不足，业界最常见的两条路是量化（把FP16降到INT8、INT4甚至更低）和分层加载（把权重分块按需搬运）。airllm选的是后者，这个选择背后有明确的取舍逻辑。

量化的优势是显存占用直接砍半甚至砍到四分之一，推理速度也快，但代价是精度损失。对于很多对输出质量敏感的任务，比如代码生成、长文本推理、数学计算，4bit量化后的模型经常会出现明显的质量下滑，表现为逻辑断裂、重复、答非所问。而分层加载不改变权重的数值精度，模型还是原来的FP16，输出质量和全量加载完全一致，只是速度慢一些。

airllm的定位很清楚：它优先保证输出质量不打折，用时间换空间。这个取舍对于显存实在不够、又不想牺牲质量的场景是合理的。你可以把它理解成一种"用硬盘和内存的读写换显存"的策略——每一层权重平时躺在硬盘上，轮到它参与计算时才被读进显存，算完立刻释放。

2.2 分层加载的核心机制

要理解airllm怎么工作，得先知道Transformer模型的结构。一个典型的大模型是由几十层结构相同的Transformer Block堆叠而成的，每一层包含注意力机制和前馈网络两部分，各自带着自己的权重矩阵。推理时数据是从第一层依次流到最后一层，层与层之间是串行的。

这个串行特性正是分层加载能成立的前提。既然每次只需要一层参与计算，那就没必要把所有层同时放进显存。airllm的做法是：把每一层的权重单独存成一个文件，推理到第N层时，把第N层的权重从硬盘加载到显存，计算完这一层，把它的权重从显存里清掉，再加载第N+1层。这样显存的峰值占用就只取决于单层的大小，而不是整个模型的大小。

单层有多大？以一个70B模型为例，假设有80层，FP16精度下总权重约140GB，平均每层大约1.75GB。再加上推理时的激活值和KV Cache，显存占用可以控制在几GB到十几GB的量级，一张24GB的卡绰绰有余，甚至更小的卡也能跑。这就是它能把大模型塞进单卡的根本原因。

2.3 与同类方案的对比

市面上做显存优化的方案不少，airllm和它们相比有自己的位置。下面这张表把几种常见思路放在一起对比，方便你判断该选哪个。

从表里能看出来，airllm的独特价值在于"低显存+原始精度"这个组合。它牺牲的是速度，因为每一层都要从硬盘读一次，硬盘的读写带宽成了瓶颈。如果你用的是机械硬盘，速度会慢到难以忍受；用NVMe固态硬盘的话，情况会好很多。这也是为什么airllm的实操里，存储介质的选择非常关键。

2.4 适用边界与不适用场景

airllm不是万能的，用之前得想清楚它适不适合你的场景。

它适合的场景：显存有限但想跑大模型做实验、做demo、做低频推理；对输出质量要求高，不能接受量化损失；能接受较慢的推理速度，比如一次生成等几分钟甚至更久。

它不适合的场景：需要高并发、低延迟的在线服务；需要频繁大量推理的生产环境；硬盘是机械盘且模型很大的情况。这些场景下，要么加显存，要么用量化，要么用多卡，airllm的速度瓶颈会成为硬伤。

我个人的判断是，airllm最适合的是个人开发者和小团队做本地验证和原型开发。它能让你在没有昂贵硬件的情况下，先把大模型跑起来、把流程跑通，等验证完想法再考虑上更好的硬件或换更高效的方案。

3. 核心细节解析与实操要点

3.1 权重分层的存储格式

airllm要能按层加载，前提是权重得按层存好。原始的模型权重通常是一个或几个大文件，里面所有层的参数混在一起。airllm在第一次使用某个模型时，会做一次预处理，把权重按层拆分，每一层存成独立的文件，同时保留一份索引记录每层对应的文件路径和参数结构。

这个拆分过程只需要做一次，之后每次推理都直接读拆分好的文件。拆分的粒度就是Transformer的层，每一层内部的注意力权重、前馈权重、LayerNorm参数都放在同一个文件里。这样加载一层就是读一个文件，逻辑简单，也方便做缓存管理。

拆分后的目录结构大致是这样：一个索引文件记录模型配置和层数，然后每层一个文件，文件名里带层号。这种结构的好处是加载逻辑清晰，坏处是文件数量多，对小文件读写性能差的存储介质不太友好。所以如果你打算长期用，建议把拆分后的权重放在读写性能好的固态硬盘上。

3.2 显存与内存的调度策略

分层加载的核心是调度：什么时候把哪一层搬进显存，什么时候释放。airllm的调度逻辑是跟着推理的前向传播走的。前向传播从第一层开始，逐层往后，所以调度也是顺序的：加载第1层，计算，释放第1层，加载第2层，以此类推。

这里有个细节值得说：释放和加载的时机。如果严格做到"算完立刻释放、需要时才加载"，显存峰值就是单层大小加上激活值。但这样每一层都要经历一次完整的加载-释放，硬盘读写次数多。airllm在实际实现里会做一些优化，比如预取下一层，在当前层计算的同时就把下一层读进来，减少等待时间。预取需要额外的显存或内存做缓冲，所以显存占用会比理论最小值高一些，但换来的是速度提升。

内存（这里指系统内存，不是显存）在这个过程中扮演缓冲区的角色。硬盘上的权重先读到内存，再从内存搬到显存。如果内存够大，可以把多层的权重缓存在内存里，减少硬盘读取次数。airllm支持配置内存缓存的大小，缓存越大，硬盘读得越少，速度越快，但吃内存。这个参数需要根据你的机器配置来调。

3.3 关键参数与配置项

airllm的配置项不算多，但每一个都影响性能和稳定性，得搞清楚它们的作用。

• 模型路径：指向拆分后的权重目录，或者原始模型目录（首次使用会自动拆分）。
• 设备：指定用哪张卡，多卡机器上要明确。
• 分层加载的层数：控制一次加载几层，默认是一层。加载多层能减少加载次数、提升速度，但显存占用成倍增加。
• 内存缓存大小：决定系统内存里缓存多少层权重，影响硬盘读取频率。
• 数据类型：一般保持FP16，除非你有特殊需求。

这些参数里，最需要权衡的是"一次加载几层"和"内存缓存大小"。加载层数越多，显存占用越高但速度越快；缓存越大，内存占用越高但硬盘读得越少。你需要根据自己的显存和内存余量来调，找到一个速度和资源的平衡点。

3.4 存储介质对性能的决定性影响

这一点我要单独拎出来强调，因为它太容易被忽视了。airllm的性能瓶颈几乎完全在硬盘读写上。每一层权重都要从硬盘读一次，模型有几十层，一次完整推理就要读几十次，每次读的是GB级别的数据。

用机械硬盘的话，顺序读取速度大概在100-200MB/s，读一个1.75GB的层要十几秒，80层就是十几分钟甚至更久，这还没算其他开销。用NVMe固态硬盘，顺序读取能到3000MB/s以上，读一层不到一秒，整体速度能提升一个数量级。所以如果你打算认真用airllm，一块好的NVMe固态硬盘是必须的，这不是可选项。

提示：把拆分后的权重放在NVMe固态硬盘上，不要放在机械盘或网络存储上。网络存储的延迟和带宽会成为更严重的瓶颈。

3.5 首次拆分的耗时与注意事项

第一次使用某个模型时，airllm要做权重拆分，这个过程比较耗时，取决于模型大小和硬盘速度。70B模型的拆分可能要几十分钟甚至更久。拆分过程中会占用大量硬盘空间，因为拆分后的权重和原始权重会同时存在，直到你手动删掉原始权重。

拆分时的注意事项：确保硬盘有足够空间，拆分后的权重总量和原始权重差不多；拆分过程中不要中断，中断可能导致拆分不完整，需要重新来；拆分完成后可以删掉原始权重文件释放空间，但删之前确认拆分后的权重能正常加载。

4. 实操过程与核心环节实现

4.1 环境准备与依赖安装

先把环境搭起来。airllm是Python包，通过pip安装即可。建议用虚拟环境，避免和系统里的其他包冲突。

python -m venv airllm_env source airllm_env/bin/activate pip install airllm

安装airllm的同时会装上它依赖的深度学习框架和推理库。这里要注意版本兼容性，airllm对底层框架的版本有要求，装的时候留意一下pip的提示，如果有版本冲突，按提示调整。

硬件方面，确认你的显卡驱动和CUDA环境是正常的。可以用下面这条命令快速检查显卡是否可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出True和显卡型号，说明环境没问题。如果输出False，得先解决驱动或CUDA的问题，airllm本身不负责这些底层环境的配置。

4.2 模型权重的获取与拆分

环境好了之后，准备模型权重。你可以从模型仓库下载原始权重，也可以直接用已经拆分好的权重（如果有人分享的话）。假设你下载了原始权重，放在某个目录下，接下来用airllm做拆分。

from airllm import AutoModel model = AutoModel.from_pretrained("你的模型路径")

第一次调用from_pretrained时，airllm会检测权重是否已经拆分，如果没有，就自动执行拆分。拆分过程会打印进度，你可以看到当前拆到第几层。这个过程比较慢，耐心等。

拆分完成后，权重目录下会多出按层组织的文件。你可以检查一下文件数量和层数是否对得上。如果层数是80，那应该有80个左右的层文件，加上索引和配置文件。

注意：拆分是一次性的，拆分好的权重可以重复使用。如果你换了模型，需要重新拆分。拆分后的权重和原始权重不要混在一起，建议分目录存放。

4.3 加载模型与推理调用

权重准备好之后，加载模型并做推理。airllm的接口设计得比较接近常规的推理库，用起来不复杂。

from airllm import AutoModel model = AutoModel.from_pretrained( "拆分后的权重路径", device="cuda:0", layer_shards_saving_path="拆分权重的存放路径" ) input_text = "你的输入文本" input_ids = model.tokenizer(input_text, return_tensors="pt").input_ids output = model.generate( input_ids, max_new_tokens=128, do_sample=False ) print(model.tokenizer.decode(output[0], skip_special_tokens=True))

这段代码里，from_pretrained负责加载模型配置和索引，generate负责实际的推理。推理时你会看到显存占用在波动，因为每一层加载和释放都会改变显存使用量。这是正常现象，说明分层加载在工作。

4.4 参数调优的实操记录

默认配置能跑起来，但速度可能不理想。我拿一个中等规模的模型做过调优测试，记录一下过程。

初始配置是每次加载一层，内存缓存为0。跑一次生成128个token的推理，耗时大约几分钟。显存峰值占用不高，但硬盘读取频繁，速度慢。

第一次调整：把内存缓存调大，让系统内存缓存更多层。调整后，硬盘读取次数减少，速度有明显提升。内存占用上升，但机器内存够用，可以接受。

第二次调整：把一次加载的层数从1改成2。显存占用翻倍，但加载次数减半，速度进一步提升。继续加到4层时，显存开始吃紧，速度提升的边际效益下降，就停在2层。

最终配置是内存缓存适中、一次加载2层，速度和资源的平衡比较好。这个配置因机器而异，你需要根据自己的显存和内存来试。调优的思路就是：先加内存缓存减少硬盘读，再加加载层数减少加载次数，直到显存或内存成为瓶颈。

4.5 推理速度的实测参考

为了让你对速度有个预期，我记录了几组不同配置下的推理速度。测试用的是同一个模型，生成128个token，硬件是单张消费级显卡加NVMe固态硬盘。

从表里能看出来，内存缓存和加载层数对速度影响很大。配置D最快，但显存和内存占用也最高。你要根据自己的硬件选一个合适的配置。这个数据只是参考，实际速度受模型大小、硬盘性能、显卡性能影响，会有出入。

5. 常见问题与排查技巧实录

5.1 显存溢出（OOM）的排查

用airllm最常见的报错就是显存溢出。虽然它的设计就是为了省显存，但配置不当还是会OOM。

排查思路是这样的：先看是一次加载几层，如果设成了多层，先改回一层试试。如果一层还OOM，那可能是单层本身就超过了显存容量，这种情况比较少见，但超大模型上可能发生。再检查是不是有别的进程占着显存，用nvidia-smi看一下。还有一种情况是KV Cache占用过大，生成长文本时KV Cache会持续增长，如果max_new_tokens设得太大，KV Cache可能成为显存杀手，适当调小生成长度。

提示：OOM时不要急着加显存，先确认是不是配置问题。很多时候把加载层数改回1、把生成长度调小，问题就解决了。

5.2 推理速度过慢的优化

速度慢是airllm的固有特点，但慢到无法接受通常是配置或硬件问题。

先确认存储介质。如果权重放在机械盘上，换成NVMe固态硬盘，速度会有质的提升。再检查内存缓存配置，缓存太小会导致频繁读硬盘。然后看一次加载层数，适当增加能减少加载次数。最后确认没有其他程序在抢硬盘IO，比如后台的下载、同步任务。

如果这些都优化了还是慢，那可能是模型太大、硬件太弱，这种情况下要么换小模型，要么接受这个速度。airllm的速度上限受硬件限制，软件层面能优化的空间有限。

5.3 权重加载失败的排查

有时候会报权重加载失败，比如文件找不到、格式不对、层数对不上。这类问题通常是权重拆分不完整或路径配置错误导致的。

先检查权重目录，确认层文件都在，数量对得上。再看索引文件，确认它记录的层路径和实际文件一致。如果拆分过程中断过，很可能拆分不完整，需要删掉重新拆分。路径配置错误也常见，特别是相对路径和绝对路径混用的时候，建议统一用绝对路径。

5.4 输出质量异常的排查

airllm理论上不改变输出质量，因为它不做量化。但如果你发现输出异常，比如乱码、重复、逻辑混乱，可能是别的原因。

先确认模型权重本身没问题，用其他方式加载同一个模型对比一下输出。再检查输入的处理，tokenizer是否正确加载，输入格式是否符合模型要求。还有可能是生成参数的问题，比如temperature、top_p设得不合理，导致输出质量下降。这些参数和airllm无关，是生成策略的问题。

5.5 常见问题速查表

把上面这些问题整理成一张表，方便你快速定位。

5.6 几个容易踩的坑

第一个坑是低估了硬盘空间需求。拆分后的权重和原始权重会同时存在，硬盘空间要留够两倍模型大小。很多人拆到一半发现空间不够，很尴尬。

第二个坑是用了网络存储。有人图方便把权重放在网络盘上，结果速度慢到无法用。网络存储的延迟对分层加载是致命的，一定要用本地固态硬盘。

第三个坑是忘了释放原始权重。拆分完成后原始权重就没用了，占着空间。确认拆分后的权重能正常加载后，及时删掉原始权重。

第四个坑是生成参数没调。airllm只负责把模型跑起来，生成质量还取决于生成参数。默认参数不一定适合你的任务，该调的还是要调。

6. 二次开发与扩展方向

6.1 自定义调度策略

airllm默认的调度是顺序加载、顺序释放。如果你有特殊需求，可以改调度策略。比如做投机推理时，可能需要预加载多个候选层；做批处理时，可能需要把同一层在不同样本间的计算合并。这些都需要改调度逻辑。

改调度的地方在模型的加载和释放环节。你可以继承airllm的模型类，重写加载和释放的方法，实现自己的调度。这需要对airllm的内部结构有一定了解，建议先读一遍源码，搞清楚它的调用链路。

6.2 结合量化进一步省显存

airllm保证原始精度，但如果你能接受一点质量损失，可以在它的基础上叠加量化。把拆分后的权重转成INT8或INT4，单层大小进一步缩小，显存占用更低，速度也可能更快（因为读的数据少了）。代价是质量损失，需要你自己权衡。

这个方向的实现思路是：在权重拆分后，对每层权重做量化转换，存成量化格式；加载时读量化权重，反量化后参与计算。airllm本身不直接支持量化，需要你自己扩展。

6.3 多模型共享缓存

如果你要同时跑多个模型，可以考虑共享内存缓存。不同模型的层可以放在同一个缓存池里，按需加载。这样能更充分地利用内存，减少重复读取。实现上需要一个统一的缓存管理器，管理多个模型的层缓存。这个方向适合做多模型服务的场景。

6.4 分布式分层加载

单机内存和硬盘有限时，可以把层分散到多台机器上，通过网络加载。每台机器负责一部分层，推理时按需从对应机器拉取。这样能突破单机的资源限制，但引入了网络开销，需要权衡。这个方向适合集群环境，实现复杂度较高。

7. 我的实操体会与建议

airllm这个项目最打动我的地方，是它把"用有限硬件跑大模型"这件事做得足够简单。它没有追求极致的性能，而是优先保证能用、好用、质量不打折。对于个人开发者和小团队来说，这种定位很务实。

我在实际使用中最大的体会是：存储介质决定体验。同样的配置，机械盘和固态盘的体验天差地别。如果你打算认真用airllm，先把固态硬盘准备好，这是投入产出比最高的一步。其次是内存，内存越大，能缓存的层越多，速度越快。显存反而不是最关键的，因为airllm的设计就是让显存需求降到很低。

另一个体会是，不要指望airllm做在线服务。它的速度决定了它适合离线、低频的场景。如果你需要高并发低延迟，还是得回到量化或多卡的路子上。airllm的价值在于让你在没有好硬件的情况下，先把大模型跑起来，验证想法，等想法验证完了，再考虑上更好的方案。

最后分享一个小技巧：如果你要反复用同一个模型，把拆分后的权重和调优好的配置保存下来，下次直接用，省去拆分和调优的时间。拆分是一次性的，配置调好后也基本不用改，这两步做完，后续使用就很顺了。