1. 当大模型装不进显存时我在想什么第一次在单卡24GB显存上尝试加载一个70B参数级别的模型时终端里跳出来的内存分配报错让我盯着屏幕愣了好一会儿。那个瞬间的感受很具体模型文件明明就安安静静躺在硬盘上权重加起来也就几十个GB可偏偏就是跑不起来。后来我才慢慢想明白问题不在于硬盘装不装得下而在于推理时这些权重必须被搬进显存而显存是个比硬盘贵得多、也小得多的空间。这就是airllm这类方案出现的背景。它要解决的核心问题非常朴素让参数量远超单卡显存容量的模型依然能在一张普通显卡上跑起来。注意这里的措辞是跑起来不是跑得飞快。它牺牲的是速度换来的是可行性。对于手里只有一张消费级显卡、却想亲手摸一摸大模型推理全流程的人来说这个取舍是划算的。我写这篇东西不是要复述某个库的官方说明而是想把这类分层加载、按需搬运的思路彻底拆开讲清楚。你会看到它背后的显存与内存的博弈逻辑、分层策略到底分的是什么、为什么推理速度会掉到某个量级、以及在实际操作中哪些参数值得调、哪些坑几乎一定会踩。适合的读者是有一定Python基础、了解Transformer基本结构、手头显卡显存不算宽裕、想自己动手把大模型跑起来的人。如果你只是想要一个开箱即用的API那这类方案可能不是你的最优解但如果你想搞懂显存不够时到底发生了什么那接下来的内容应该对你有用。2. 显存墙的本质为什么权重必须搬家2.1 推理时显存到底被谁吃掉了很多人以为显存只用来放模型权重其实不然。一次完整的前向推理显存里至少同时住着几类东西模型权重本身、激活值中间层的输出、KV Cache自回归生成时缓存的键值对、以及框架自身的一些开销。权重是静态的激活值和KV Cache是动态的而且后者会随着序列长度增长而膨胀。拿一个粗略的量级来感受一下假设模型有700亿参数用FP16存储光权重就是约140GB。这还没算激活和缓存。一张24GB的卡连权重的零头都放不下。这就是所谓的显存墙——不是算力不够是根本装不下。那为什么不能像操作系统用虚拟内存那样把权重放在内存里、用到哪块搬哪块答案是可以而且这正是airllm这类方案的核心思路。但代价在于GPU和CPU内存之间的传输带宽远低于显存内部带宽每一次搬运都是实打实的时间开销。2.2 分层加载的核心直觉把模型想象成一本很厚的书你的书桌显存只放得下一章。你要读完整本书就得读完一章、把这一章放回书架内存或硬盘、再取下下一章。这就是分层加载最直白的类比。具体到Transformer结构模型是由一层层的Block堆叠起来的。每一层Block包含注意力模块和前馈网络模块它们各自有独立的权重。推理时数据是逐层往上传的第1层的输出喂给第2层第2层喂给第3层以此类推。这意味着在任意一个时刻理论上只有当前正在计算的那一层权重是必须待在显存里的。这个观察是整个方案成立的基石。既然层与层之间是顺序依赖的那我们完全可以只把当前层搬进显存算完就把它挪走腾出空间给下一层。显存占用就从所有层之和降到了单层或少数几层的大小。2.3 为什么不是所有框架都这么做既然思路这么直接为什么主流推理框架不默认这么干因为它慢。GPU的设计哲学是让大量数据常驻显存、反复复用从而把计算单元喂饱。一旦权重需要频繁从内存搬运GPU就会大量时间处于等数据的状态算力利用率暴跌。所以分层加载是一个典型的用时间换空间的策略。它把能不能跑的问题解决了但把跑多快的问题留给了使用者去权衡。理解了这一点后面所有的参数调优、速度预期就都有了统一的解释框架。3. 把模型拆开分层策略里藏着的细节3.1 分层的粒度不是越细越好最直觉的做法是一层一搬也就是每次只把一层Block放进显存。但实际操作中很多实现会允许你指定一次加载多少层。这个粒度是个需要权衡的参数。粒度太细比如每次只搬一层好处是显存占用极低坏处是搬运次数极多每次搬运都有固定的启动开销累积起来非常可观。粒度太粗比如一次搬十层显存占用上去了但搬运次数少了单次搬运的数据量大传输效率反而更高。我自己的经验是在显存允许的范围内尽量加大单次加载的层数。因为GPU和内存之间的传输大块数据的单位带宽成本明显低于小块数据。你可以把它理解成搬家一次搬一个大箱子比来回搬十个小盒子效率高得多。3.2 权重在内存和显存之间的落脚点这里有个容易被忽略的细节权重从硬盘读进来之后是先放在内存里再从内存搬到显存。所以内存容量本身也是一个约束。如果你的内存也不够大那就需要更激进的策略比如直接从硬盘流式读取连内存都不常驻。这就形成了一个三级存储的层次硬盘 → 内存 → 显存。每一级的容量递增硬盘最大、速度递减。分层加载的本质就是在这三级之间做数据的调度。理解了这个层次结构你就能明白为什么有些配置下速度特别慢——因为数据可能被迫从最慢的硬盘层反复读取。3.3 量化在这里扮演什么角色如果只是分层搬运速度损失主要来自传输。但还有一个能大幅降低传输量的手段量化。把FP16的权重压成INT8甚至INT4数据量直接减半甚至减到四分之一搬运的负担自然就轻了。不过量化会带来精度损失而且不是所有层对量化的敏感度都一样。常见的做法是对大部分层做低比特量化对少数关键层保留较高精度。在分层加载的场景下量化还有一个额外好处单层权重变小了意味着一次能加载更多层或者显存占用更低。这两个方向都对整体体验有正面影响。需要提醒的是量化本身不是万能的。有些模型对量化特别敏感压得太狠之后输出质量会明显下降表现为重复、逻辑断裂或者答非所问。所以量化位数的选择最好结合具体模型实测而不是无脑选最低。4. 速度到底慢在哪一次推理的时间账4.1 把一次前向拆成时间片要理解速度问题最好的办法是把一次完整推理的时间拆开看。假设模型有N层每次加载K层那么需要搬运的次数大约是N/K次。每次搬运的时间取决于这一批权重的数据量和传输带宽。单次搬运时间 ≈ 数据量 / 传输带宽。数据量又等于 层数 × 每层参数量 × 每参数字节数。把这些串起来你就能估算出一次推理里纯搬运占了多大比例。在很多配置下搬运时间会远超计算时间这就是速度慢的根本原因。我做过一个粗略的对比同样一个模型全部常驻显存时每秒能生成十几个token改成逐层加载后可能掉到每秒一两个token甚至更低。这个差距不是实现得不好而是物理规律决定的。4.2 哪些因素能让它快一点既然搬运是瓶颈那所有优化都围绕减少搬运和加快搬运展开。减少搬运的思路包括加大单次加载层数减少搬运次数、使用量化减少单次搬运量、复用已经加载的层如果有多轮对话某些层可能可以缓存。加快搬运的思路主要是确保数据走的是最快的通道比如避免不必要的内存拷贝、确保内存和显存之间的传输没有被其他进程抢占带宽。还有一个常被忽视的点首次加载和后续生成的速度不一样。首次加载要把所有权重从硬盘过一遍慢是正常的。后续生成时如果实现得当权重已经在内存里只需要内存到显存的搬运会快不少。所以评估速度时要区分冷启动和热运行。4.3 和能跑就行的心态和解说实话用这类方案跑大模型心态很重要。如果你期待的是流畅的对话体验那大概率会失望。但如果你把它当成一个学习和验证的工具——想亲眼看看70B模型在24GB卡上到底能不能出结果、想研究不同量化对输出的影响、想理解推理框架的内部调度——那它的价值就体现出来了。我自己的用法是用它来做小批量的验证和实验比如测试某个prompt在不同模型上的表现或者验证某个微调后的权重是否正常。这些场景对速度不敏感对能跑很敏感正好匹配。5. 实操中绕不开的那些坑5.1 环境依赖的版本地狱这类方案通常依赖特定版本的深度学习框架和CUDA工具链。版本不匹配是最高频的报错来源。我踩过的典型坑包括框架版本和显卡驱动不兼容、量化库和主框架版本冲突、以及某些算子在不同CUDA版本下行为不一致。我的建议是先把环境固定下来再动模型。用一个干净的虚拟环境按照方案文档推荐的版本组合安装不要自作主张升级某个包。如果文档没写清楚就去翻它的依赖声明文件那里通常有版本范围。装好之后先跑一个最小示例确认环境通了再上大模型。5.2 内存不够导致的假死前面说过权重从硬盘到显存要经过内存。如果内存不够系统会开始使用交换空间而交换空间在硬盘上速度极慢。表现出来就是程序卡住不动看起来像死机其实是在疯狂读写硬盘。判断方法很简单跑的时候盯着系统内存监控。如果内存占用接近上限、硬盘读写灯狂闪那基本就是这个问题。解决办法要么是加内存要么是采用更激进的流式加载策略减少内存常驻的数据量。5.3 量化后的输出质量波动量化能省资源但输出质量可能不稳定。我遇到过同一个问题量化前回答得好好的量化后开始胡言乱语。也遇到过量化后反而在某些任务上表现更专注的情况。这说明量化对模型的影响是任务相关的不能一概而论。实用的做法是准备一组固定的测试问题量化前后各跑一遍人工对比。不要只看loss或者困惑度这类指标因为生成任务的质量很难用单一指标衡量。如果发现质量下降明显就提高量化位数或者对敏感层保留高精度。5.4 长序列下的显存反弹分层加载解决的是权重占显存的问题但激活值和KV Cache的显存占用并没有被解决。当输入序列很长或者生成很长的输出时这部分占用会持续增长可能重新把显存撑爆。这个坑比较隐蔽因为一开始跑短序列没问题一上长文本就崩。应对办法包括限制最大序列长度、使用KV Cache的量化或分页管理、以及在生成过程中及时释放不再需要的缓存。如果你的使用场景涉及长文档处理这一点必须提前考虑。6. 参数调优的取舍逻辑6.1 加载层数怎么定这是最核心的参数。定得太小搬运次数多慢定得太大显存不够崩。合理的做法是从显存容量的角度反推先算出单层权重占多少显存再用可用显存除以单层占用得到一个理论上限然后留出余量给激活值和缓存取一个保守值。举个例子假设可用显存20GB单层权重占1.5GB激活和缓存预留4GB那么理论上能放约10层。但实际中我会先设成6到8层跑通之后再逐步往上加观察显存占用和速度的变化找到那个再往上加就崩的临界点。6.2 量化位数的选择量化位数的选择本质是精度和资源的权衡。INT8通常是比较安全的起点资源节省明显精度损失可控。INT4更激进适合显存极度紧张的场景但要接受可能的质量下降。我的经验是先确定能不能跑再优化跑得好不好。如果INT8能跑就先跑起来看看输出质量是否可接受。如果可接受就没必要上INT4。如果INT8都跑不动再考虑INT4同时做好质量下降的心理准备。6.3 批处理大小的考量批处理能提高吞吐但在分层加载场景下批处理会成倍增加激活值和缓存的显存占用而权重占用不变。这意味着批处理大小对显存的影响是非线性的需要谨慎。一般来说这类方案更适合批大小为1的场景。如果你确实需要批处理建议从小批量开始测比如2或4观察显存和速度的变化。很多时候你会发现批处理带来的吞吐提升被显存压力抵消了得不偿失。7. 这类方案适合谁不适合谁7.1 适合的场景最典型的适合场景是学习和研究。想亲手跑通大模型推理、想对比不同量化策略、想理解推理框架的调度逻辑这些都不需要高吞吐只需要能跑。分层加载方案让这些实验在普通硬件上成为可能。另一个适合场景是低频的验证任务。比如你微调了一个模型想验证它是否正常工作跑几个样例看看输出即可。这种任务对延迟不敏感对能不能在现有硬件上完成很敏感。7.2 不适合的场景实时交互是第一个不适合的场景。每秒一两个token的生成速度做聊天机器人体验会很差。高并发服务也不适合因为单次推理就吃满了资源没法同时服务多个请求。长文本处理同样要谨慎前面提到的显存反弹问题在这里会集中爆发。判断标准很简单如果你的场景对延迟的要求是秒级以内那这类方案基本出局。如果延迟要求是分钟级可以接受那它就有发挥空间。7.3 和其他省显存手段的关系分层加载不是唯一的省显存手段。梯度检查点、模型并行、CPU卸载等思路各有适用场景。分层加载的特点是实现相对简单、对硬件要求最低但速度损失也最明显。模型并行需要多卡梯度检查点主要针对训练CPU卸载和分层加载思路相近但粒度不同。实际选择时可以组合使用。比如分层加载配合量化就是很常见的组合。理解每种手段的边界才能根据手头硬件做出合理取舍。8. 我在这条路上的一些真实体会折腾这类方案最大的收获其实不是跑起来了这个结果而是过程中对推理系统资源调度的理解。以前用现成API时模型对我来说是个黑盒输入进去、输出出来中间发生了什么完全不知道。自己动手分层加载之后显存、内存、硬盘之间的数据流动变得具体了每一层权重的搬运、每一次缓存的增长都变成了可以观察和调优的对象。另一个体会是对够用的重新认识。以前总觉得硬件不够好就没法做大模型现在明白了很多时候是方法问题而不是硬件问题。同样的显卡换个加载策略就能跑起原本跑不动的模型这种原来还可以这样的瞬间是折腾这类方案最让人上瘾的地方。如果你也打算走这条路我的建议是先接受它慢再去想办法让它快。不要一上来就追求速度先把流程跑通把每个参数的作用摸清楚再逐步优化。这个过程本身比最后跑出来的那个结果更有价值。
