大语言模型的参数规模持续膨胀，70B 参数的模型仅权重文件就达到 130GB 以上，传统推理方法需要两张 100GB 显存的 A100 GPU 才能完成加载。这一硬件门槛将绝大多数研究者和开发者阻挡在大型模型应用的大门之外。AirLLM 通过层式推理的创新架构，实现了在单张 4GB 显存 GPU 上运行 70B 模型的突破性能力，甚至能够在 8GB 显存上运行 405B 的 Llama3.1。本文将从工程实现角度深入剖析其核心技术机制，提供可落地的部署参数配置。
层式推理的核心设计理念
传统的大模型推理采用整体加载模式，需要将全部模型权重一次性加载到 GPU 显存中。对于 70B 参数的模型，按照 FP16 精度计算，仅权重就需要 140GB 显存空间，远超消费级显卡的承载能力。此外，推理过程中的注意力机制计算需要将完整输入序列驻留显存，其内存占用与输入长度呈平方关系增长，进一步加剧了显存压力。
AirLLM 采用的层式推理本质上是一种分治策略，将原本的模型整体分解为可独立加载和执行的层单元。其工作流程可以概括为四个关键步骤：首先加载单个层或少数层的权重到 GPU 显存；然后执行该层的计算操作并保存必要的输出结果；随后将已完成计算的层权重卸载以释放显存空间；最后移动到下一层并重复上述过程。这种设计使得任意时刻 GPU 显存中只需要保留当前层的权重和少量中间激活值，从而将峰值显存需求从模型整体规模降低到单层规模量级。
具体而言，一个 70B 规模的 Transformer 模型通常包含 80 层左右的解码器层。如果采用混合精度存储，每层权重大约需要 1.7GB 到 2GB 的显存空间，完全在 4GB 显存的承载范围之内。AirLLM 进一步通过 prefetching 机制实现计算与加载的流水线重叠，在前一层计算的同时预取下一层权重，这一优化带来了约 10% 的端到端性能提升。
块级量化压缩与推理加速
虽然层式推理已经能够将显存需求降低到可接受范围，但模型首次加载时的磁盘 IO 仍然是性能瓶颈。70B 模型的完整权重需要从磁盘读取 130GB 以上的数据，这一过程在机械硬盘上可能需要数十分钟。AirLLM 引入了基于块级量化的模型压缩技术，能够在几乎不损失模型精度的前提下实现推理速度的三倍提升。
与传统的全量化方法不同，AirLLM 的压缩策略仅针对模型权重进行量化，而非同时量化权重和激活值。这种设计选择基于对推理瓶颈的精准分析：在层式推理架构下，磁盘读取带宽而非计算算力成为主要瓶颈，因此只需减小模型文件的存储体积即可获得显著的性能收益。块级量化的核心思想是将权重矩阵划分为固定大小的块（通常为 64 或 128 个元素），对每个块独立计算缩放因子并进行整数映射，从而在保持权重量化精度的同时避免异常值对整体量化效果的负面影响。
启用压缩功能的配置参数如下：安装 bitsandbytes 库后，在模型初始化时指定 compression='4bit' 或 compression='8bit' 参数即可激活块级量化。4bit 压缩能够将模型体积压缩至原始大小的约四分之一，8bit 压缩则提供约两倍的压缩比。根据项目提供的评估数据，4bit 压缩下的精度损失在大多数基准测试中可以忽略不计，对于实际应用场景的影响微乎其微。
值得注意的是，AirLLM 的压缩机制与传统的模型量化存在本质区别。传统量化为了追求推理速度，通常需要同时量化权重和激活值，这会导致激活值中的异常值严重影响量化效果，需要复杂的校准流程。AirLLM 的设计目标是在不牺牲模型精度的前提下优化加载性能，因此选择仅对权重进行量化，避免了激活值量化带来的精度风险。
模型分片与磁盘空间管理
层式推理的实现需要在磁盘上预先完成模型的分片处理。AirLLM 在首次运行时会自动将原始模型权重分解为按层组织的分片文件，这一过程需要消耗显著的磁盘空间和计算时间。原始的 Hugging Face 格式模型通常采用 safetensors 格式存储，单个 70B 模型的体积约为 130GB。分片后的模型虽然总体积不变，但会以独立的层文件形式组织，便于后续的按需加载。
对于磁盘空间有限的用户，AirLLM 提供了 delete_original 配置选项。设置为 True 时，系统会在完成分片转换后自动删除原始模型文件，仅保留转换后的层式结构，从而将磁盘占用从约 260GB（原始文件加分片文件）降低到约 130GB。这一选项在首次运行时需要谨慎使用，因为原始模型的删除将无法通过简单的缓存清理恢复。
分片文件的默认保存路径为 Hugging Face 缓存目录下的模型快照路径，用户也可以通过 layer_shards_saving_path 参数指定自定义的保存位置。建议选择具有充足读写带宽的 SSD 存储位置，以最大化分片加载的性能表现。
多模型架构支持与跨平台部署
AirLLM 的层式推理框架设计为模型架构无关，通过抽象统一的分层加载接口来支持不同结构的 Transformer 模型。截至目前，项目已经实现了对主流开源模型家族的完整支持，包括 Llama 系列（支持 Llama3 70B 以及 Llama3.1 405B）、Qwen 系列（支持 Qwen2.5 等最新版本）、Mistral 与 Mixtral 系列、ChatGLM 系列（ChatGLM3、ChatGLM2）、Baichuan 系列（Baichuan2）以及 InternLM 系列。
对于不同架构的模型，AirLLM 提供了统一的 AutoModel 接口，能够自动检测模型类型并选择对应的处理模块。开发者无需关心底层的架构差异，只需传入 Hugging Face 的仓库 ID 或本地路径即可完成模型加载。这种设计极大简化了跨模型迁移的工程成本，使得开发者能够在不同模型之间快速切换以比较效果。
在平台支持方面，AirLLM 覆盖了 Linux 和 macOS Apple Silicon 两大运行环境。在 Linux 环境下，系统支持 NVIDIA GPU 的 CUDA 加速推理，同时也支持纯 CPU 推理模式。macOS 平台的支持依赖于 MLX 框架和 Apple Silicon 芯片的 Unified Memory 架构，得益于统一内存设计，M 系列芯片能够共享 CPU 和 GPU 的内存池，使得在内存充足的情况下运行 70B 模型成为可能。
工程实践中的关键配置参数
在生产环境中部署 AirLLM 时，以下配置参数对性能表现具有显著影响。prefetching 参数控制是否启用预取机制来重叠计算与加载过程，该选项在大多数场景下应保持开启状态，能够带来稳定的 10% 性能提升。profiling_mode 参数用于输出各层的执行时间统计，对于定位性能瓶颈和优化资源配置具有参考价值。
对于需要访问 gated 模型（如 meta-llama/Llama-2 系列）的场景，需要通过 hf_token 参数提供 Hugging Face 的访问令牌。建议将令牌存储在环境变量中而非硬编码在代码里，以增强安全性。在处理不包含 padding token 的模型 tokenizer 时，应显式设置 padding=False 以避免运行时错误。
显存管理方面，建议根据目标 GPU 的实际显存容量选择合适的批量大小。单批次推理在 4GB 显存上运行 70B 模型时，需要将输入序列长度控制在合理范围内以避免激活值爆显存。对于 8GB 显存的配置，可以适当增加 MAX_LENGTH 参数以支持更长的上下文输入。
性能特征与适用场景分析
AirLLM 的层式推理架构在带来显存优势的同时，也引入了特定场景下的性能权衡。由于每层计算完成后需要等待下一层权重的加载，磁盘 IO 带宽成为端到端推理延迟的关键瓶颈。在使用机械硬盘或网络存储时，首 token 生成的延迟可能达到分钟级别，而在 SSD 存储上这一时间可以缩短到十秒以内。对于需要低延迟响应的交互式应用场景，建议将模型分片文件存储在本地 NVMe SSD 上。
吞吐量层面的分析表明，AirLLM 特别适合长文本生成和多次迭代推理的场景。在这些场景下，首 token 的初始化成本可以被后续的大量计算分摊，从而获得较高的端到端效率。对于短文本补全等高频低延迟需求的场景，可能需要权衡是否采用预热加载或缓存机制来优化体验。
量化压缩选项的启用需要在推理速度和模型精度之间做出选择。根据基准测试数据，4bit 压缩在带来三倍推理加速的同时，模型在大多数语言理解任务上的准确率下降通常控制在 0.5% 以内，对于实际应用的影响可以忽略。对于对精度要求极高的场景，可以选择关闭压缩选项以获得原始精度。
总结与展望
AirLLM 通过层式推理和块级量化两项核心技术创新，成功打破了消费级硬件运行超大规模语言模型的技术壁垒。其工程实现既保持了与 Hugging Face Transformers 生态的兼容性，又提供了灵活的压缩配置选项，使得研究者能够在有限资源下探索大模型的应用边界。随着模型架构的持续演进和硬件平台的多元化发展，层式推理的范式为边缘计算和端侧部署场景提供了可行的技术路径。
资料来源：AirLLM GitHub 仓库（https://github.com/lyogavin/airllm）