先放一个结论：8GB 显存，也能在本地把 70B 参数级别的大模型跑起来，速度虽然谈不上快，但真的能出结果。airllm 就是这类思路里比较有代表性的开源项目之一。楼上那些“显存不够就别碰大模型”的说法，其实只对了一半。我自己花了两个周末，在一台普通消费级显卡的机器上，把一套 70B 模型的离线批量推理流程完整跑通，这篇就是当时的记录、拆解和踩坑复盘。如果你手里也是小显存显卡，又想把大模型拉回本地跑，这篇文章会比较对胃口。
1. 为什么我会盯上这台 8GB 显存的机器，以及“跑不起来”背后的账
1.1 70B 模型到底需要多少显存
先算一笔最简单的账。一个 70B 也就是 700 亿参数的大语言模型，权重用 FP16 半精度存储，每个参数占 2 字节，那么仅权重部分就是 700 亿乘以 2 字节，约 140GB。这是什么概念？一张旗舰级数据中心显卡的显存也就 80GB 左右，消费级显卡普遍是 8GB 到 24GB，140GB 的权重根本不可能完整装进显存。
所以大家会立刻想到量化。把权重压缩到 4bit，每个参数占 0.5 字节，那么 70B 模型的权重大约 35GB。35GB 依然装不进 8GB 显存，但至少比 140GB 小多了，普通电脑的物理内存也就是这个量级。到这里，问题已经不是“显存能不能装下”，而是“35GB 的权重放在哪里，以及怎么喂给 GPU 算”。
这是一个很多人第一次真正卡住的地方。大家潜意识里认为，GPU 推理就必须把模型完整加载到显存，显存不够就是不行。但实际的推理过程不是这样的：模型是一层一层往前计算的，每一层只依赖上一层的输出，并不需要所有层的权重同时驻留在显存。这就是后面 airllm 能跑起来的逻辑基础。
1.2 量化只是第一步，瓶颈不只在显存
量化解决了“体积”问题，但没解决“位置”问题。即使你有一个 35GB 的 4bit 模型文件，把它完整扔进系统内存，你的 GPU 依然不知道该怎么计算，因为 GPU 需要数据在显存里才能访问。
于是出现了一个中间方案：CPU 也能跑推理。CPU 的内存通常远大于显存，32GB 或者 64GB 很常见，35GB 的 4bit 模型放得下。但 CPU 推理的速度，和 GPU 完全不是一个量级。我实测过纯 CPU 跑 70B 4bit 模型，生成一个 token 可能需要数秒甚至更久，用来跑一个 500 字的回答，等待时间长到让人怀疑程序卡死。
这就形成了一个两难：GPU 快但装不下，CPU 装得下但太慢。airllm 的思路很有意思，它试图同时利用 GPU 的算力和 CPU 的内存容量，做一个“显存工作区 + 内存仓库”的调度系统。
1.3 算一算 CPU 侧内存能不能兜底
在动手之前，先确认机器配置。我用的是一张 8GB 显存的显卡，物理内存 64GB，CPU 是 12 核。跑 70B 模型 4bit 量化，权重 35GB，加上 KV Cache 和临时激活值，运行时内存占用大概在 40GB 到 45GB 左右。恰好 64GB 内存能覆盖，这就是能继续的前提。
如果你是 32GB 内存的机器，跑 70B 4bit 会非常紧张，建议换成 13B 到 34B 量级的模型。这个判断不是看显存，而是看物理内存，airllm 这类方案对物理内存的依赖远大于显存。
另外还要考虑 PCIe 带宽。GPU 和 CPU 之间通过 PCIe 总线传输数据，普通消费级主板是 PCIe 3.0 或 4.0，实际传输带宽在 12GB/s 到 28GB/s 之间。这个数字看起来不小，但和显存内部动辄几百 GB/s 的带宽相比，差了十倍以上。也就是说，一旦数据需要频繁在内存和显存之间搬运，传输就会成为新的瓶颈。理解了这一点，后面遇到速度问题时就不会慌。
2. airllm 的分页调度逻辑：把大模型当硬盘一样换进换出
2.1 layer-wise 分页与一次只加载一个层
airllm 这个名字从一开始就说明了它的核心机制，来自分页内存管理的思路。操作系统在物理内存不够时，会把不常用的数据页换到磁盘，等需要再换回来。airllm 做的事情，是把大模型的每一个 transformer layer 当作一个“页”，把显存当作工作区，把系统内存当作仓库。
具体执行时是这样的：推理开始，先加载第一层的权重到显存，完成这一层的计算，然后把第一层权重从显存清掉，加载第二层，再计算。几十层模型就这样一层一层“流水式”跑完。因为每一层计算完成后，中间结果很小，不需要保留整层权重，所以显存里永远只住着一层或少数几层权重，8GB 显存完全够用。
这个设计和我想象中的“把模型切成很多小块微调”不同，它不涉及修改模型结构，也不需要特殊网络。模型的每一层还是原来的层，只是加载和计算的顺序被重新编排了。
2.2 它和“直接 swap 到显存”有什么本质区别
很多库也提供了“显存不足自动交换到 CPU 内存”的能力，看起来和 airllm 类似，但逻辑完全不同。
常规的显存 swap 策略，通常是模型加载时尽量把权重存在显存里，当新的张量需要显存空间时，系统把旧的权重腾挪到 CPU 内存，之后如果需要再换回来。这种策略是“被动应对显存不足”，它的前提还是“模型主体尽量住显存，显存不够才往外换”。
airllm 则是从一开始就假设显存只承担“计算工作区”，而不是“存储区”。它主动把几乎所有权重放在系统内存里，显存里只保留计算所需的当前层和缓存。这种“主动设计”避免了 swap 策略下的频繁意外，调度行为更可控，也更容易预测内存占用。
实际体验中，这种设计的另一个好处是：支持在不改动代码逻辑的情况下，运行远大于显存容量的模型。你不需要精确计算显存还剩多少，只需要保证物理内存能装下整个量化模型。
2.3 单卡上的分页与多卡分布式切分的配合
airllm 也支持多 GPU 场景。多卡环境下，它会结合分页和分布式张量并行：模型权重仍然按层组织，但每一层内的张量会被切分到多张显卡上，共同完成计算。这样每张卡的显存占用进一步摊薄，同时算力也叠加起来。
不过我的测试环境只有单卡，所以重点还是单卡场景。多卡配置的复杂度在于，你要保证每张卡都被正确识别，并且显存工作区大小设置合理。如果工作区设置太大，多卡总占用可能超出一张卡的上限；设置太小，层调度次数增加，又会拖慢速度。
3. 从安装到首次运行：让 airllm 真正跑起来
3.1 环境准备和依赖
安装之前先把基础环境对齐。airllm 依赖 PyTorch、CUDA 和编译工具链，如果你已经装过 PyTorch，那么最稳妥的方式是在创建好的虚拟环境里重新确认版本，避免和系统环境混装。
我当时的操作路径是先建一个干净的虚拟环境，然后安装对应版本的 PyTorch，最后再安装 airllm。不要一上来就直接 pip install airllm 到一个存量环境里，一旦 CUDA 版本和 PyTorch 不匹配，后面报错很难定位。
一个冷知识：airllm 在安装过程中会编译一些 C++ 扩展，所以系统里需要提前装好 GCC 和 make。Windows 上则需要对应版本的 Visual Studio Build Tools。如果安装过程卡在编译阶段，大多数情况下不是 airllm 本身的问题，而是编译工具链不完整。
3.2 模型名映射与模型文件准备
airllm 加载模型的方式和常见的 Hugging Face Transformers 很像，核心逻辑也是根据模型仓库标识或本地路径来寻找模型权重。但它对模型文件的格式有自己的要求，并不是随便放一个目录就能直接跑。
第一次使用，我错误地以为直接把 Hugging Face 格式的权重目录传进去就行。结果加载时报错，提示找不到指定格式的模型文件。后来才明白，airllm 需要通过项目提供的转换脚本，把原始权重转换成它内部使用的 4bit 分块格式。这个转换过程有点类似 GGUF 的原理，但格式是它自己的。
实际操作步骤是：先下载原始模型权重到本地，然后执行转换脚本生成对应格式的文件，转换完成后才轮到模型加载。这一步本身不需要 GPU 算力，CPU 跑就行，70B 模型的转换大概需要几十分钟，一次性完成，之后可以反复使用。
3.3 Python 推理主流程：加载、生成、输出
环境准备好、模型文件转换完成后，推理链路反而很简洁。以下是基于我的使用经验整理出的一个简化示例：
from transformers import AutoTokenizer from airllm import AutoModelForCausalLM MODEL_PATH = "/path/to/your/converted/model/directory" tokenizer = AutoTokenizer.from_pretrained(MODEL_PATH) model = AutoModelForCausalLM.from_pretrained( MODEL_PATH, max_length=4096, deploy_quantized=True ) prompt = "写一段关于本地大模型推理的简短介绍。" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") outputs = model.generate( inputs.input_ids, max_new_tokens=128, do_sample=False, eos_token_id=tokenizer.eos_token_id ) print(tokenizer.decode(outputs[0], skip_special_tokens=True))需要特别提醒两点：第一，deploy_quantized=True是最关键的参数，它告诉 airllm 使用 4bit 量化文件和分页调度模式。如果漏掉这个参数，模型会尝试以原始物理精度加载，一个小显存机器可能直接在加载阶段就崩溃。第二，max_length要提前规划，它决定了 KV Cache 在显存中的预留空间，设置得比实际需求大太多会浪费显存，设置太小则无法处理长提示词。
3.4 关于量化方案的选择
airllm 默认的量化方式是 4bit 分组量化，分组大小通常为 128 个参数。这个方案在体积和精度之间取了一个相对实用的平衡点。4bit 意味着每个参数只保留 16 个离散取值，信息损失肯定存在，但用于文本生成这种容错较高的任务，实际体验比想象中好。
如果你追求更高的生成质量，也可以尝试 8bit 模式，但代价是物理内存占用接近翻倍。我一开始以为 8bit 一定比 4bit 好，实测之后发现，在较长文本生成任务里两者的差异远不如推理速度差异明显。如果你物理内存不是特别充裕，优先选择 4bit 更合理。
还有一个容易忽略的点：模型转换完成后，原始权重文件可以留着，但推理时并不需要重复转换。你可以把转换好的模型目录当作一次性产物缓存，后续加载速度会快很多。
4. 项目自带推理工具箱的使用心得
4.1 参数模型与端口部署
airllm 不只是一个 Python 库，它还附带一个推理工具箱，可以直接拿来做交互式会话或者启动一个本地服务接口。我第一次用这个工具时，最直观的感受是：它把一个“学术实验风格”的项目，变得像一个可以日常使用的产品。
这个工具箱有两种典型入口。一种是终端交互模式，启动后会读取你的提示词并立即返回生成结果，适合快速验证模型是否装对、量化是否生效。另一种是部署模式，启动后会打开一个本地端口，外部程序通过 HTTP 请求发送提示词并获得返回结果。我实际测试时指定了端口参数，启动后日志会显示监听地址和端口号，然后就能用简单的 HTTP 客户端来调用，整个过程很顺滑。
部署模式真正有价值的地方在于：你可以把模型推理封装成一个独立的后台服务，前面的业务代码只管发请求，不需要每次都加载模型。加载 70B 级模型是一件很重的事，几十秒钟甚至更久，如果做成“每次调用都加载”，那整个流程就废了。
4.2 实测输出速率与硬件监测
我的环境下，7B 级别模型 4bit 量化后，单次生成一个 token 大约需要 200 到 300 毫秒，也就是每秒 3 到 5 个 token。70B 模型则慢得多，单 token 延迟可能达到 1 到 2 秒，每秒 0.5 到 1 个 token。这个速度在聊天场景下偏慢，但在离线批量分析任务里完全可以接受。
这里需要解释一个容易误解的数字：大语言模型的“推理速度”不是一条直线。首 token 延迟很大程度取决于提示词长度和首轮设备加载时间，后边的 token 生成速度则受权重搬运频率和 GPU 算力共同影响。airllm 模式下的主要开销是每一层都要从内存搬到显存，这一搬一动就是几十毫秒到几百毫秒不等，所以层数越多的模型越慢。
如果你在测试时发现速度比预期还慢，先看一眼系统内存和显存的实时占用，不要急着怀疑代码。通常问题出在内存带宽被其他程序抢占，或者某一块 GPU 进入了低功耗状态。
4.3 首 Token 延迟与后续吞吐的取舍
在 interactive 场景里，首 token 延迟比平均速度更影响体验。airllm 默认会在加载初始层时耗费一些时间，这会让首 token 延迟偏高。如果你只是做批处理，不用在意这个。
我后来想到一个缓解办法：把 prompt 尽可能控制在较短的长度内，或者预填充阶段先不急着要求输出，让模型先完成那部分一次性计算，其实能有效降低首 token 等待时间。这个思路同样适用于其他大模型推理框架，算是通用经验。
5. 不同模型同一行代码，但改的远不止模型名
5.1 稀疏模型（MoE）的调度差异
airllm 的“按层调度”机制对于常规稠密模型非常有效，但遇到专家混合模型，情况就复杂了。这类模型的每一层内部包含多个专家子网络，推理时只会激活少数专家。
从理论上说，稀疏模型只需要加载被激活的专家权重，能进一步节省传输量。但从我的测试看，airllm 在稀疏模型上依然需要按完整层来调度。也就是说，即使实际计算只用其中两个专家，你也得先把这一整层包含所有专家的权重搬运到显存里。显存和带宽压力并没有因为“稀疏”而下降。
这不是缺陷，而是调度粒度的取舍。按专家调度需要更细的控制逻辑，也会增加调度频率。当前按层调度虽然粗，但在实现稳定性和通用性上更有优势。
5.2 更长的上下文窗口带来的内存增长
很多人忽略 KV Cache 对物理内存的吞噬。KV Cache 的大小和序列长度的平方呈正比关系，尤其长文本生成时，它会占据大量显存和系统内存。airllm 虽然把权重搬到了系统内存，但 KV Cache 往往还是要存在于显存或高速缓冲区中。
实际使用中，将上下文从 2048 扩展到 4096，KV Cache 占用显著上升。如果你在跑长文档摘要任务，建议提前确认模型能承受的最大生成长度，不要想当然地调高 max_length。一旦系统内存耗尽，进程会被系统杀掉，且没有任何恢复余地。
5.3 多 GPU 与异构硬件的组合策略
airllm 对多 GPU 的支持，并不是简单的“把模型分到两张卡”，而是每张卡承担一部分层内张量计算。比如单层内的矩阵乘法被切到两张卡上并行计算，计算完成后结果再合并。这要求两张卡的显存都满足“工作区”需求，而不只是总显存够。
异构硬件需要注意速度匹配。两张卡型号不一致，比如一张老卡和一张新卡混用，整体速度会被慢卡拖累。如果你有条件让两张卡型号一致，最好保证一致；如果实在不行，至少要确认它们的总线带宽和算力差距不会太大，否则多卡并行可能比单卡还慢。
6. 性能瓶颈和调参：显存、内存、线程数与 batch 之间的掰手腕
6.1 影响生成速度的主要因素排序
我把一次完整推理过程中影响速度的因素排了个序，从大到小依次是：权重搬运造成的 PCIe 传输开销、CPU 内存本身的带宽、单层内的矩阵计算量、模型层数、GPU 算力、CPU 线程数。
这个排序可能和一些人的直觉不一样。很多人觉得 GPU 算力决定速度，但在 airllm 这种“显存工作区”模式下，GPU 算力往往不是第一瓶颈，因为权重搬运和内存访问已经占掉了大量时间。这意味着你换一张更强的 GPU，但总线带宽不变，提升可能很有限；反过来，如果你把模型从 70B 换到 13B，每层传输量下降，速度提升会很明显。
如果你的目标是提升吞吐，最有效的方案是换用更低的量化位数，或者选择层数更少、参数量更小的模型，而不是盲目堆硬件。
6.2 batch 调度与长文本生成的现实收益
airllm 支持 batch 生成，也就是一次给模型多个提示词，让模型一次生成多条输出。这个模式让我意外地发现它能真正摊薄权重搬运成本。
如果单次只生成一个序列，每一层需要搬运一次，搬运成本是固定的。但如果同一个 batch 里有 4 个序列，模型的每一层仍然是搬运一次，却能同时为 4 个序列计算，相当于每次搬运的时间被四个请求分摊了。这也是为什么我说：“吞吐优先还是延迟优先，airllm 明显偏向吞吐。”
不过 batch 不是越大越好。batch 增大会拉高显存里的激活值和 KV Cache 占用，一旦超过工作区上限，反而会触发额外的调度开销和显存溢出。我建议始终从一个较小的 batch 开始，逐步上调，同时用nvidia-smi盯着显存使用曲线。
6.3 显存预留多少给 KV Cache 才合适
谈到 KV Cache，实际操作中有一个“多少合适”的问题。如果设置得太小，模型会直接把超出部分截断，影响输出质量；如果设置得太大，空占显存，留给当前层工作区的空间就少了。
空气和水不一样，这是一个需要反复试探的量。我的做法是先跑一条长文本测试，观察显存占用峰值，然后在此基础上留出 10% 到 20% 的余量作为 KV Cache 上限。对于 8GB 显存，KV Cache 通常不宜超过 1GB 到 1.5GB，剩下的要保证当前层权重和激活值能放下。
有一个经验值得记下：max_length这个参数既控制 KV Cache，又控制模型能够处理的最大长度。它不是越大越好，而是要和你的“实际任务最大长度”相匹配。盲目调大，只会白白增加缓存容量，拉长预填充时间。
7. 它明显不擅长的事：什么时候别用 airllm 这类方案
7.1 高频低延迟在线服务的局限
如果你打算做在线聊天机器人，需要每秒钟响应多次请求，airllm 这个方向就不太合适。因为它的核心取舍是“用时间换容量”：允许更慢的推理，来换取单张低显存显卡可以运行超大模型。
在线服务最怕高延迟和吞吐不稳。airllm 的调度过程受内存带宽和总线负载影响较大，并发一高，响应时间的波动会很剧烈，这是在线服务无法接受的。我之前尝试过用它部署一个内部问答机器人，单个请求体验尚可，但并发上来之后，延迟明显飙升，最后放弃了。
如果你有很强的实时性需求，正确的做法是换小模型，然后充分量化，让模型能够完整驻留显存，而不是把层搬来搬去。
7.2 与原生 FP16 推理的质量差异和量化损失
4bit 量化带来的模型质量损失在短回答上不容易察觉，但在复杂推理、多步逻辑、专业术语密集的任务上，和原生 FP16 的差距会明显放大。我在一次测试中让它模拟推理一道数学题，4bit 模型的推理步骤偶尔会跳步，而同样的模型在更大显存机器上用 FP16 运行则稳定得多。
如果你忍受不了这种质量波动，那么 airllm 的定位就不适合你。它更适合任务本身对模型精度要求不极端、重数量轻质量的批量处理场景。如果你只是想要一个能跑在本地、还能像正常助手一样对话的模型，建议选择更小体积的模型并用标准推理框架，而不是硬上 70B 的 4bit 分页调度。
7.3 一个合理的适用边界与我的最终建议
总结一下我测试下来的感受：airllm 最舒服的场景是“小显存显卡 + 较大物理内存 + 离线批量任务”。比如给一摞长篇文档做摘要，跑一批标准的文本分类，或者离线生成一批候选回答再做筛选。在这些场景下，它能在硬件条件受限时，把 8GB 显存机器的模型能力上限拉高到 70B 级，这是非常实用的能力。
但我不会用它做实时聊天服务，也不会用它处理对精度极其敏感的任务。它在所有场景下的共同弱点都是慢，这是物理规律决定的，不是任何代码优化能绕过的事。我再强调一下内存：如果你物理内存小于 48GB，建议把目标模型控制在 34B 以下；只有物理内存足够，才谈得上跑 70B 级模型。
最后分享一个小技巧：跑一次完整推理之前，先用一条最短的 prompt 做一次“预热”，让模型完成层调度和缓存分配。预热之后再跑正式批量，首条输出的延迟会明显下降。它算不上 airllm 专门提供的功能，但确实是我实际跑下来的有效经验。
我在整套流程里最想强调的一点是：不要在显存这件事上钻牛角尖。大模型能不能在本地跑，显存只是其中一个因素，更关键的是物理内存容量、总线带宽和任务本身对延迟的容忍度。airllm 用一种“把模型当仓库货物、按层取用”的思路，给消费级硬件提供了一个还算优雅的答案。如果你愿意接受它的速度，它的确能在不花大钱的前提下，让你触碰到更大的模型边界。
