企业官网建设流程全解析

最近总有人问我：手里只有一张8GB显存的显卡，能不能跑得动70B级别的大模型。按我过去的经验，这问题基本可以直接劝退，但前段时间我刚好把AirLLM完整跑了一遍，于是我会把项目主页发过去：你先试试这个。AirLLM的思路不是把大模型压缩到能塞进小显存，而是换了个玩法——它不让整个模型常驻显存，而是把模型按层拆开，每次只把当前计算需要的那一层丢进GPU，算完就清走，再换下一层进来。结果就是哪怕显存只有几个GB，也能把几十B参数级别的模型跑起来，代价主要是推理速度。

这篇文章我不打算复述项目文档，而是把它的核心原理、安装步骤、实测数据和我在测试过程中踩过的坑一次性讲清楚。如果你被大模型的显存门槛卡住，或者手头只有普通配置的机器但想本地跑大规模权重，这篇文章应该能帮你省不少弯路。

1. 为什么多数人跑不动大模型：显存账先算明白

1.1 一个70B模型的显存需求账本

要理解AirLLM的价值，第一步是把"大模型需要多大显存"这笔账算明白。很多人只知道模型大，但大在哪、为什么普通显卡装不下，其实没认真算过。

假设一个70B参数的模型，用FP16半精度存储，每个参数占2字节。那么光权重文件就是：

70B × 2 bytes = 140GB

140GB是什么概念？市面上常见的消费级显卡，显存普遍是8GB、12GB、16GB，顶到24GB的也离140GB差了一个数量级。就算用4bit量化把每个参数压到0.5字节，权重也要约35GB，依然远超普通显卡的承载能力。

但这还没完。模型推理时除了权重，还需要存放中间激活值、KV Cache、临时计算缓冲区。这些额外开销会随序列长度增长，实际运行时的显存占用通常比权重文件还高。所以"70B模型需要140GB显存"只是个起点，不是终点。

很多人在这里就放弃了，认为本地跑大模型必须有专业级设备。实际上，这个结论建立在"整个模型必须同时放进显存"这个前提上，而这个前提本身是可以被打破的。

1.2 常规方案的代价：量化、并行、CPU硬扛

先看看大家通常怎么解决显存不够的问题，以及它们各自的代价。

量化是最常见的办法。把FP16压到INT4或INT8，模型体积直接缩小4到8倍。这套方案成熟、效果好，但有两个痛点：一是量化后的精度会有一定下降，虽然现在的量化算法已经把损失控制得很低，但对某些对输出质量敏感的任务，差异依然可感知；二是就算压到4bit，70B模型仍然要35GB左右显存，8GB显卡还是装不下。

分布式推理是另一个方向。把模型切到多张卡上并行计算，显存不够就加卡。这方案能解决问题，但前提是你得有多卡硬件。对大多数个人用户来说，为跑一个模型再去添置设备，成本不太能接受。

还有人试过纯CPU推理。CPU内存通常比显存大得多，32GB、64GB很常见，装下70B模型不是不行。但CPU做矩阵运算的能力远不如GPU，生成速度会掉到让人难以忍受的程度，而且主板内存带宽也限制了数据吞吐。

这些方案都不完美的根源，在于它们都在试图"让显存装下整个模型"，只是从不同角度压缩或者扩展。AirLLM则换了一个思路：既然装不下全部，那就干脆别一次全装。

1.3 AirLLM的答案：按层流转而不是整体常驻

大模型天然是分层结构，无论是Transformer还是其他主流架构，推理过程本质上就是把输入按顺序经过一层又一层计算，最后得到输出。这个过程有一个关键特点：某一时刻实际参与计算的只有当前这一层，前面的层算完之后就不需要再保留在显存里了。

AirLLM充分利用了这个特点。它让模型权重常驻在CPU内存里，GPU显存只保留当前正在计算的那一层和必要的输入输出缓冲。算完一层，就把这一层的权重从显存移除，再从CPU内存加载下一层进来。整个模型的权重不需要一次性进入显存，显存够不够看的是"单层体积"而不是"整体体积"。

单层有多大？拿70B模型来说，假设总共80层，平均每层权重不到1GB。任何一张有2GB以上显存的显卡都能容纳。这就是AirLLM最核心的破局点：把"容量问题"转化成"带宽问题"。你不再需要买更大的显存，而是需要更快的数据传输。

明白了这一点，后面的原理、实测和优化措施都围绕"层间流转"这个核心展开。

2. 每层算完就丢：分层推理的工作方式拆解

2.1 一次生成请求的完整生命周期

AirLLM的一次推理请求，在执行层面经历了以下几个阶段。了解这个流程，能帮你理解后面所有的性能瓶颈和优化手段。

第一阶段是输入预处理。文本经过tokenizer变成token ID序列，这个序列会被放到GPU显存中作为输入张量。这阶段占用的显存很小，基本可以忽略。

第二阶段是逐层前向计算。模型从第一层开始，把输入张量喂进当前层做矩阵运算，算完得到新的中间张量，然后立刻把当前层权重从显存清掉，再从CPU内存加载第二层权重，继续算。这个过程一直重复到最后一层。因为每次只处理一个层，显存峰值始终被压在单层体积附近。

第三阶段是输出层计算。最后一层算完后，会得到logits，也就是每个token可能的概率分布。从这里可以采样出下一个token，把它拼接到输入序列中。

第四阶段是自回归循环。如果你要生成100个token，那就需要把上面第二到第三阶段重复100次。每生成一个新token，整个模型的所有层都要重新经过一遍。这也是生成式模型的一个普遍特征，只是AirLLM的逐层流转把这个特征的成本放大了，因为它每层都要做一次数据搬运。

KV Cache的情况也需要注意。某些实现会把KV Cache保留在显存里以加速重复计算，但在AirLLM模式下，如果序列很长，KV Cache可能占用不少显存。所以实际使用时，长上下文和短上下文的显存开销差异会很明显。

2.2 一个具体算例：4GB显存为什么也能转起来

拿一个7B模型举例会比较好理解。7B模型FP16权重约14GB，假设有28层，平均单层权重约500MB。再算上中间激活值和一些缓冲区域，单层峰值占用大概还会翻倍，到1GB左右。

这种情况下，一张4GB显存的显卡，其实有大约3GB是可以自由分配的。AirLLM在加载当前层时，只需要其中1GB左右，剩下2GB可以用来存放输入序列、KV Cache和输出缓冲。只要序列长度控制得当，整个推理过程就不会触发显存溢出。

如果把模型换成70B，情况会变成单层约1到2GB波动，4GB显存会非常紧，但8GB显存就能比较从容地运行。我实测下来，显存占用曲线基本是一条接近水平的线，而不是像传统方式那样一开始就冲到顶然后维持在高位。这也验证了"显存瓶颈从整体变成单层"的判断。

2.3 与常驻显存推理的本质差异

传统推理框架的做法是把整个模型加载到显存，然后一直驻留。这种方式的好处是计算过程中不需要任何数据搬运，权重和中间结果都在显存里，GPU可以全速跑；坏处是显存需求等于整个模型加运行时开销，门槛极高。

AirLLM则把模型当成流水线上的工件，GPU是工位，CPU内存是仓库。每处理一道工序就从仓库取一个工件进工位，做完就送回仓库。好处是工位不需要能装下全部工件，坏处是每个工件都要经历一次进出仓库的过程，搬运本身需要时间。

这种差异直接体现在性能上。常驻方式是高吞吐、低延迟，代价是高硬件门槛；AirLLM是低门槛、低吞吐，同时首次运行时还有大量数据从磁盘往内存搬运的成本。它牺牲的是性能，换来的是能跑。

本质上，AirLLM做的是一个"IO换显存"的交换。如果项目文档里把性能数据标得比较保守，别惊讶，因为这个方案的目标本来就不是追性能，而是把不可能变成可能。

3. 跑通AirLLM：安装、环境与最小推理代码

3.1 环境准备与安装

AirLLM对硬件的要求不高，但软件环境需要认真配。我的建议是新建一个虚拟环境，避免跟其他项目的依赖冲突。Python版本建议用3.10及以上，深度学习框架的版本尽量保持较新，因为层间流转依赖较新的张量管理接口。

安装本身很简单，用包管理器直接装就行：

pip install airllm

如果你的环境里还没有深度学习框架，AirLLM安装时通常会把基础的依赖带过来。但我个人建议先手动装好GPU版本的框架再安装AirLLM，这样能避免自动安装的CPU版本框架导致GPU不可用的问题。

我踩过的一个典型坑是：先装了AirLLM，它默认拉了CPU版本的框架依赖。结果代码能跑，但全部跑在CPU上，速度惨不忍睹。后来我重装了GPU版本的框架再装AirLLM，才把GPU真正用起来。所以安装顺序很重要：先装好GPU版框架，再装AirLLM。

3.2 模型准备与加载方式

AirLLM支持从本地目录加载模型，也支持从远程仓库直接拉取。本地加载需要把模型权重下载好，目录结构和常见的开源模型格式一致即可。远程加载则直接传仓库标识，首次运行会自动下载权重。

我建议优先使用本地加载。原因是AirLLM逐层流转的特性意味着它要从磁盘反复读取权重文件，如果模型文件分布在远程或网络位置，IO延迟会非常致命。把权重放到本机SSD上，能让整个体验好很多。

加载模型的代码很简单：

from airllm import AutoModel # 从本地目录加载 model = AutoModel.from_pretrained("./local_model_dir") # 或者从远程仓库加载 # model = AutoModel.from_pretrained("some/repo/name")

这里有一个值得注意的点：如果加载时报权重格式不兼容，多半是模型原始格式和当前版本支持的范围不一致。AirLLM主要适配主流的开源权重格式，如果你手里的权重是经过特殊改造的版本，可能需要先转回标准格式。

3.3 最小推理代码逐行拆解

下面这段代码是我实际测过的最小推理示例，注释部分写了每行的作用：

from airllm import AutoModel # 1. 加载模型，模型会先加载到CPU内存 model = AutoModel.from_pretrained("./local_model_dir") # 2. 可以指定GPU上驻留的层数 # 默认值通常已经够用，显存小的可以调低一点 model.set_gpu_layer_count(8) # 3. 构造输入，tokenizer可以复用你熟悉的任意标准tokenizer input_ids = tokenizer("你好，请介绍一下你自己。", return_tensors="pt").input_ids # 4. 生成输出 output_ids = model.generate( input_ids, max_new_tokens=128, ) # 5. 解码并打印结果 text = tokenizer.decode(output_ids[0], skip_special_tokens=True) print(text)

这个流程和常规推理框架的写法学起来几乎没差别，核心区别在第二步。set_gpu_layer_count控制的是GPU显存里始终驻留多少层。这个值越大，层间流转时需要的搬运越少，速度越快，但显存占用也越高；反之则更省显存，但每层都要频繁搬运，速度更慢。

如果你完全不确定怎么设置，用默认值先跑一遍，然后根据显存占用情况再调整，这是比较稳的做法。

3.4 生成参数与流式输出的调整

generate方法里比较常用的参数包括max_new_tokens、temperature、top_p和do_sample。这些都是大模型推理的通用参数，AirLLM并没有做特殊改动。

需要特别提醒的是max_new_tokens。因为AirLLM每个新token都要重新遍历所有层，生成长度越长，耗时增长越明显。如果你只是测试可用性，建议把max_new_tokens设小一点，比如64或128，跑通流程之后再放大。

流式输出在AirLLM里也可以做，但需要注意，逐层流转的过程本身就是串行的。流式输出能让你尽早看到第一个token，但后续token的到达速度不会因此变快。实际体验中，首token延迟多少才是影响感受的主要因素，我后面会细说。

另外，batch size建议保持1。AirLLM的定位就是低资源运行，强行加大batch会把显存需求推高，而且多个序列同时逐层流转，CPU与GPU之间的搬运带宽会更快耗尽，性能反而下降。

4. 实测结果：显存占用、生成速度与适用边界

4.1 显存占用到底能压到多低

我分别测试了7B、13B、70B三个参数级别的模型，用的是一张8GB显存的中端消费级显卡。表格里是实测过程中的显存峰值：

可以看到，AirLLM的显存占用远低于传统方式，而且模型规模变大时，显存增幅远小于参数增幅。70B模型在8GB显卡上能跑，这事放在传统方式里是不可想象的。

但这组数据有一个前提，就是系统内存足够。因为全部权重都驻留在CPU内存里，70B模型FP16权重就需要约140GB内存。如果你的机器只有16GB内存，那连加载都完成不了。我在测试时专门把内存加到足够大才跑通，这一点配置前一定要确认。

4.2 推理速度的真实体感

性能是AirLLM最需要降低预期的地方。我的实测数据大致是：7B模型每秒生成3到5个token，13B模型每秒1到2个token，70B模型大约每5到10秒才能生成一个token。

这个速度和常驻显存推理完全不在一个量级。常驻模式下，7B模型在消费级显卡上每秒可以生成几十甚至上百个token。AirLLM的差距主要来自两个环节：一是每一层的权重都要从CPU内存搬到显存，PCIe带宽成了限制因素；二是每次搬运后GPU真正计算的时间只占一小部分，大部分时间都在等数据。

首token延迟也偏高。传统方式在模型加载完成后，首token通常几百毫秒内就能出来；AirLLM因为要先从第一层开始逐层计算，首token往往需要几十秒甚至几分钟。如果你用交互式聊天的心态去等，会很难受。

不过延迟高不等于不可用。它适合的任务是对实时性要求不高的场景。你发一个请求，去喝杯水，回来看结果，体验完全没问题。核心思路是把它当异步任务对待，而不是实时代理。

4.3 场景匹配：哪些任务适合用AirLLM

按我的测试经验，下面这些场景非常适合AirLLM：

离线批处理任务首当其冲。比如批量生成文本摘要、批量处理分析数据，不要求秒回，跑完一次性拿结果。

个人学习与研究也好用。想同学、研究员需要在本地跑大规模模型的实验，时间要求宽松，AirLLM直接把硬件门槛降到了普通笔记本能承受的范围。

私密性要求较高的本地推理也在它的射程内。数据不出本机，代价只是慢，但私密性诉求可以完全满足。

反过来，高并发在线服务、实时对话机器人这类场景，AirLLM现阶段确实不适合。哪怕并发只有个位数，逐层流转很快就会把内存带宽吃满，延迟会成倍恶化。这类需求还是交给常驻显存的推理方案更合理。

5. 实战中踩过的坑与优化心得

5.1 首次加载慢到怀疑人生

我第一次加载70B模型时，光是加载阶段就等了差不多十分钟。第一次体验真的劝退，但分析之后发现原因在于：AirLLM需要把全部权重从头到尾读一遍加载进CPU内存，这一步的耗时基本等于从磁盘读完整个模型的时间。70B FP16权重140GB，就算SSD读取速度到每秒2GB，也要70秒起步，加上格式解析和预处理，时间就非常可观了。

解决方式是分两步走。第一次加载是预热，做完之后权重会缓存在系统内存里，第二次再加载同一个模型就能秒开。针对这个特点，可以把 AirLLM 设计成启动时预加载模式，模型长期驻留在后台，请求进来直接复用，避免反复经历冷启动。

另外磁盘速度对加载时间影响极大。机械硬盘读取140GB可能要几分钟，NVMe SSD则只要一两分钟。有条件的话，模型尽量放在最快的盘上。

5.2 系统内存爆掉的问题

显存问题是解决了，但70B模型的权重全放内存，系统内存需求会直接拉高。如果你机器只有32GB内存，就不要跑70B FP16，加载过程就可能直接内存溢出。

我踩过这个坑：机器重启后没注意内存占用，直接加载大模型，系统瞬间卡死，最终还是靠强制重启恢复的。

解决思路有两个。一个是用更小的模型或更低的精度，70B换成13B，或者把70B模型量化后再加载，内存需求能降一半以上。另一个是调整层的驻留策略，如果GPU能多驻留几层，CPU内存的压力会稍小一点，但系统内存总量仍然是硬指标。

5.3 量化与AirLLM叠加使用

AirLLM本身不要求量化，但实际操作中量化与它的组合非常实用。把权重压到4bit之后，70B模型的CPU内存需求从140GB降到35GB左右，能用更小内存的机器跑更大模型。

我测试过4bit量化加AirLLM的组合，效果很理想。显存占用进一步下降，生成速度没有明显劣化，原因在于AirLLM的瓶颈本来就集中在数据搬运上，量化之后单层体积变小，搬运时间反而可能缩短，计算速度的下降幅度小于搬运的收益。

代价是精度。量化一定会带来损失，但针对不太抠细节的任务，量化后的质量完全可接受。如果任务对输出质量要求苛刻，可以先跑FP16版本看效果，再决定要不要量化。

5.4 层分配比例与批次调优

set_gpu_layer_count是平衡显存和速度的关键参数。显存充裕就调高，减少CPU与GPU之间的交换频率，速度会明显提升；显存紧张就调低，保证能跑起来。

调法上我给一个经验值参考：8GB显存跑70B模型，GPU驻留4到8层比较稳妥；如果显存只有4GB，建议降到2层以下。这个值可以按实际测试调整，每次改动后跑一遍短文本看显存占用，再继续微调。

batch size我前面提过，保持1。不要为了提升吞吐去加大批次，多人测试下来效果都很差，因为多个序列同时进行层间流转会疯狂争抢内存总线，等待时间成倍增加。宁可增加并发进程数，也不要在一个进程里堆大批次，后者的资源利用率会明显更差。

最后再说一个容易被忽略的小问题：系统如果开了swap，而物理内存不够时，交换到磁盘会让速度进一步崩坏。最好确保物理内存能装下全部权重，不要依赖虚拟内存兜底。我在测试中把swap关掉之后，稳定性反而提高了。

说到底，AirLLM适合的就是"硬件有限、时间有余"的场景。它能让你在普通配置上体验超大模型的推理，突破显存的硬边界，这本身就是一件很有价值的事。如果你手头有符合条件的硬件和模型，按上面的步骤跑一遍，应该能复现出基本一致的效果。