AirLLM 深度实战：8GB 显存跑 405B 大模型——分层推理如何拆掉「显存墙」（2026 实战指南）

引子：一道让人绝望的算术题

想象一个很常见的场景：你手上有一张消费级显卡（RTX 4090，24GB 显存），老板丢给你一个需求——「把 Llama-3-405B 部署到本地，数据不能出内网」。

你掏出计算器算了一笔账：405B 参数，FP16 精度下每个参数占 2 字节，光权重就需要 810GB 显存。24GB vs 810GB，差了 34 倍。就算换成 INT4 量化（每参数 0.5 字节），也要 203GB，依然是消费级显卡望尘莫及的数字。

传统思路只有四条路：

1. 量化：把精度从 FP16 压到 INT4，显存需求除以 4，但还是装不下 405B；
2. 蒸馏：拿大模型蒸馏出小模型，能力损失不可控，还得有训练预算；
3. MoE：稀疏激活架构确实省显存，但 405B 不是 MoE，你也没法把稠密模型改成 MoE；
4. 上云：数据安全、合规、长期成本，全都不可控。

看起来 405B 本地部署是个死局。但 2026 年 8 月的 GitHub 周榜上，一个名为 AirLLM 的项目一周新增了 5700+ stars——它给出的答案是：8GB 显存就能跑 405B。

这不是魔法，而是一个被整个推理生态「默认假设」掩盖了多年的工程真相：推理过程中，任何一个时刻，Transformer 里只有一层在计算。既然如此，为什么要把 800GB 权重全部常驻在显存里？

这篇文章从显存墙的成因讲起，拆解 AirLLM 分层推理（Layer-wise Inference）的架构设计，给出完整的 Python 实战代码，最后把「时间换空间」这笔账算明白——什么时候该用它，什么时候该老老实实上 vLLM。

一、背景：显存墙是怎么砌起来的

1.1 模型显存需求的算术

大模型推理的显存需求，基础公式只有一行：

显存需求 ≈ 参数量 × 每参数字节数 + 激活值 + KV Cache

权重是绝对大头。不同精度下，405B 模型的权重体积：

作为对比：RTX 4090 显存 24GB，RTX 5090 显存 32GB，一颗 64 核服务器配满也就 1TB 内存。权重体积和可用显存之间，差了两个数量级。

1.2 为什么传统推理要求「权重全部常驻」

传统 GPU 推理的假设是：整个模型权重一次性加载进显存，之后所有计算都在显存内完成。

这个假设来自自回归生成的两个特性：

1. 串行依赖：生成第 N 个 token，必须完整过一遍所有层（第 0 层输出是第 1 层输入）；
2. 重复计算：生成每个 token 都要重新过所有层，N 个 token 就是 N 次全量前向。

于是「权重常驻显存」成了铁律——反正每步都要用，搬来搬去反而更慢。

1.3 被忽略的真相：时刻性

但把「每个 token 都要过所有层」这句话再读一遍，你会发现一个被默认假设掩盖的细节：

任意一个时刻，只有「正在执行的那一层」的权重在参与计算。

层与层之间是严格的串行流水线：layer 0 算完，把 hidden states 交给 layer 1，layer 0 的权重在那一刻就不再被需要，直到下一个 token 的前向。

这就引出一个激进但逻辑自洽的工程思路：与其让 800GB 权重全部常驻显存，不如让权重「按层流动」——用到哪层，就把哪层搬进显存，算完即走。

这就是分层推理（Layer-wise Inference），也就是内存推理（Memory Inference）的核心。它把「显存装不下模型」这个死局，转化成了「搬运 800GB 权重需要多长时间」这个工程问题——后者显然有解。

二、核心概念：时间换空间

2.1 内存推理的定义

内存推理（Memory Inference）指：权重存放在 CPU 内存甚至磁盘上，GPU 显存只容纳「当前计算层」的权重、激活值和 KV Cache，按需加载、算完释放的推理范式。

它和传统推理的本质区别：

2.2 关键洞察：Transformer 的串行依赖

Transformer 的每一层可以抽象为：

hidden = LayerNorm(Attention(hidden) + hidden)
hidden = LayerNorm(MLP(hidden) + hidden)

层与层之间唯一的联系就是 hidden states 张量。这意味着整个前向过程可以写成：

# 伪代码：分层推理的核心循环
for layer_idx in range(model.num_layers):
    # 1. 把这一层的权重从 CPU 内存搬到 GPU 显存
    layer_weights = load_layer_weights(layer_idx)   # 从内存/磁盘
    layer_weights = layer_weights.to("cuda")

    # 2. 只计算这一层
    hidden_states = apply_layer(hidden_states, layer_weights)

    # 3. 算完立刻释放，腾出显存给下一层
    del layer_weights
    torch.cuda.empty_cache()

每一轮循环，显存峰值 = 单层权重 + 激活值 + KV Cache，和总参数量无关。

2.3 代价：搬运时间

天下没有免费的午餐。省下来的显存，要用「搬运时间」来还。

以 Llama-3-8B 为例算一笔账：

• 8B 参数 ÷ 32 层 ≈ 每层 2.5 亿参数；
• FP16 下每层权重 ≈ 500MB；
• PCIe 4.0 x16 的实际可用带宽约 25~30GB/s；
• 搬运一层 ≈ 500MB ÷ 28GB/s ≈ 18ms。

而消费级显卡上，8B 模型单层前向（主要是矩阵乘法）大约 3~10ms。搬运时间已经超过了计算时间——系统从「计算受限」变成了「IO 受限」。

这就是分层推理的本质代价：用时间换空间。你省下的不是钱，是「显存容量」这个硬约束；你付出的是「带宽等待」这个软成本。而软成本是可以通过工程手段压低的（详见第五节）。

2.4 KV Cache 也要重新定位

除了权重，显存里还有第二大头：KV Cache。它是自回归生成中缓存的 K/V 张量，随序列长度线性增长。

以 Llama-3-8B 为例（GQA 架构，8 个 KV 头，head_dim=128）：

每 token 的 KV Cache = 2(K,V) × 层数 × KV头数 × head_dim × 字节数
                     = 2 × 32 × 8 × 128 × 2 (FP16)
                     = 128 KB / token

• 4K 上下文 ≈ 512MB；
• 32K 上下文 ≈ 4GB；
• 128K 上下文 ≈ 16GB。

在内存推理范式下，KV Cache 通常也放在 CPU 内存，生成时增量同步到 GPU。KV Cache 的体量决定了「最大上下文长度 × 批大小」的上限——这成为内存推理的第二约束（第一约束是权重搬运带宽）。

三、架构分析：AirLLM 的工程设计

3.1 项目定位

AirLLM 是 SafeAILab 开源的推理框架，核心卖点一句话：让 8GB 显存的单卡也能跑 400B+ 量级的大模型。它不追求吞吐（那是 vLLM 的活），追求的是「显存下限」。

2026 年 8 月，AirLLM 冲上 GitHub 周榜前列（周增 5700+ stars），和这一波「个人开发者本地跑大模型」的需求爆发直接相关——推理引擎卷完了 GPU 吞吐，终于有人回头解决「显存不够」这个更普遍的问题。

3.2 三层存储架构

AirLLM 把模型权重分布在三个层级：

磁盘 (safetensors 文件)
   │  mmap 按需读页
   ▼
CPU 内存 (权重仓库, 可容纳全部参数)
   │  分层搬运
   ▼
GPU 显存 (只放当前层 + 激活 + KV)

• 磁盘层：模型以 safetensors 格式存储，通过内存映射（mmap）打开，不一次性读入；
• 内存层：CPU 内存作为权重仓库，容量目标 = 全量权重 + KV Cache；
• 显存层：只容纳「当前计算层」。

3.3 safetensors + mmap：零拷贝的按需加载

safetensors 是 HuggingFace 主导的权重格式，相比 pickle 有两个关键优势：

1. 安全：不执行任意代码，只做张量序列化；
2. 可随机访问：文件头部有张量偏移表，可以只读取某个张量，而不必加载整个文件。

配合操作系统的 mmap，AirLLM 打开权重文件时并不真正读盘，只有访问某个张量的内存页时才触发缺页中断、从磁盘读入。这让「按层加载」的粒度从「文件级」细化到了「页级」——加载哪层，磁盘就只读哪层的字节。

3.4 单层计算流水线

AirLLM 对每一层的处理是一个四阶段流水线：

Load → Transfer → Compute → Release

1. Load：从 CPU 内存（或 mmap 触发磁盘读）取得该层权重；
2. Transfer：通过 PCIe 拷贝到显存（cudaMemcpyAsync 异步拷贝）；
3. Compute：执行 attention + MLP 前向；
4. Release：删除显存中的权重副本，释放显存。

工程上还有两个关键优化：

• 双缓冲预取：计算第 i 层时，后台线程已经在搬运第 i+1 层，把串行的「搬运-计算」变成流水线重叠；
• 异步释放：torch.cuda.empty_cache() 只在显存碎片化严重时调用，避免频繁触发 CUDA 缓存回收的开销。

3.5 与主流推理方案的定位差异

vLLM 解决的是「显存够用之后，怎么榨干 GPU」；AirLLM 解决的是「显存不够时，怎么把模型跑起来」。两者是互补关系，不是竞争关系——事实上，AirLLM 社区正在探索把分层调度接到 vLLM 的 Continuous Batching 里，让「低显存」和「高吞吐」兼得。

四、代码实战

4.1 环境准备

# 安装（Python 3.9+）
pip install airllm

# 硬件建议
# - NVIDIA GPU：任意型号，哪怕 4GB 显存（GTX 1650 也能跑 7B）
# - 内存：权重体积 × 1.2 + KV Cache 预算
# - 存储：强烈建议 NVMe SSD（后面会解释为什么）

AirLLM 底层依赖 PyTorch 和 HuggingFace Transformers，API 风格与 transformers 高度一致——这是它上手门槛低的关键设计。

4.2 最小推理示例

from airllm import AutoModel

# 加载模型：权重默认流式映射，不会一次性占满内存
model = AutoModel.from_pretrained("AirLLM/Llama-3-8B-Instruct")

# 构造输入
input_text = [
    "What is the capital of France?",
]
input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    padding=True,
    truncation=True,
).to("cuda")

# 生成
generation_output = model.generate(
    input_tokens.input_ids,
    max_new_tokens=64,
    do_sample=True,
    top_k=50,
    top_p=0.95,
    temperature=0.7,
)

# 解码输出
output = model.tokenizer.decode(generation_output[0], skip_special_tokens=True)
print(output)

注意几个细节：

• model.tokenizer 直接挂在模型对象上，省去单独加载 tokenizer 的步骤；
• tokenizer 输出用 .to("cuda") 搬到显存——输入序列很短，占用可忽略；
• generate 的参数与 transformers 完全一致，迁移成本为零。

4.3 大批量模型：8GB 显存跑 405B

AirLLM 的卖点在这里体现：

from airllm import AutoModel

# 8GB 显存 + 200GB+ 内存 + NVMe，就能跑 Llama-3-405B（INT4 量化版）
# 首次加载会按需读取权重，冷启动需要几分钟到十几分钟（取决于存储带宽）
model = AutoModel.from_pretrained(
    "AirLLM/Llama-3-405B-Instruct",   # 以实际发布的模型 ID 为准
)

prompt = "Explain quantum entanglement in simple terms."
inputs = model.tokenizer(prompt, return_tensors="pt").to("cuda")

output = model.generate(
    inputs.input_ids,
    max_new_tokens=128,
    do_sample=False,          # 贪心解码，结果可复现
)

print(model.tokenizer.decode(output[0], skip_special_tokens=True))

运行过程中用 nvidia-smi 观察，会看到显存占用始终只有几个 GB——峰值出现在单层权重 + 激活 + KV Cache 的叠加，而不是整个模型。

4.4 流式输出

在线场景必须尽快吐出第一个 token，流式输出是标配。如果你的 AirLLM 版本支持 transformers 的 streamer，直接传参：

from transformers import TextStreamer

streamer = TextStreamer(model.tokenizer, skip_prompt=True, skip_special_tokens=True)

model.generate(
    inputs.input_ids,
    max_new_tokens=256,
    streamer=streamer,   # token 边生成边打印
)

如果版本不支持 streamer 透传，用分块生成实现等价的流式效果：

def stream_generate(model, input_ids, total_tokens=256, chunk=32):
    """按块调用 generate，实现伪流式输出。"""
    generated = input_ids
    while generated.shape[1] - input_ids.shape[1] < total_tokens:
        # 每次只生成 chunk 个新 token
        out = model.generate(
            generated,
            max_new_tokens=min(chunk, total_tokens - (generated.shape[1] - input_ids.shape[1])),
            do_sample=False,
        )
        new_tokens = out[:, generated.shape[1]:]
        yield model.tokenizer.decode(new_tokens[0], skip_special_tokens=True)
        generated = out

分块生成的额外代价是每块都会重新 prefill 已有上下文，块越大开销越小——实际使用建议 chunk 取 32~64。

4.5 批量推理

批量处理多个请求时，注意两点：padding 策略和 KV Cache 内存预算。

prompts = [
    "Summarize the plot of Inception.",
    "Write a Python function for binary search.",
    "What is the difference between TCP and UDP?",
]

inputs = model.tokenizer(
    prompts,
    return_tensors="pt",
    padding=True,      # 同一 batch 内对齐长度
    truncation=True,
    max_length=1024,
).to("cuda")

outputs = model.generate(
    inputs.input_ids,
    attention_mask=inputs.attention_mask,   # padding 时必须传 mask
    max_new_tokens=128,
)

for i, out in enumerate(outputs):
    print(f"--- 请求 {i+1} ---")
    print(model.tokenizer.decode(out, skip_special_tokens=True))

内存推理模式下，batch 的代价是 KV Cache 成倍增长：

KV Cache 预算 = 每 token 128KB × 序列长度 × batch 大小

所以批量推理前，先按上面的公式估算内存，别让 KV Cache 撑爆物理内存。

4.6 显存与内存监控

跑大模型时，监控「显存」和「内存」两套指标：

import torch
import psutil

def print_memory_status(tag=""):
    # 显存
    if torch.cuda.is_available():
        allocated = torch.cuda.memory_allocated() / 1024**3
        reserved = torch.cuda.memory_reserved() / 1024**3
        print(f"[{tag}] GPU 显存: allocated={allocated:.2f}GB, reserved={reserved:.2f}GB")

    # 物理内存（含 page cache，page cache 可被回收，不一定是真占用）
    vm = psutil.virtual_memory()
    print(f"[{tag}] 内存: used={vm.used/1024**3:.1f}GB, available={vm.available/1024**3:.1f}GB, "
          f"cached={vm.cached/1024**3:.1f}GB")

print_memory_status("模型加载前")
# ... 推理代码 ...
print_memory_status("推理后")

一个常见误区：free -h 里看到的 cache 占用很高，就以为内存不够。mmap 加载的权重会进入 page cache，这部分内存可被操作系统随时回收，不是真正的内存压力。真正要盯的是 available 和 swap 使用量。

4.7 常见坑位清单

1. OOM 报错要分清是显存还是内存：分层推理下显存 OOM 很少见（除非 KV Cache 爆了），更多是物理内存不足；
2. 冷启动极慢：第一次加载要把权重从磁盘读进 page cache，几百 GB 的模型可能要等很久，之后重启会快很多；
3. tokenizer 版本不匹配：换模型时务必用模型配套的 tokenizer；
4. batch 内序列长度差异过大：padding 浪费大量 KV Cache，尽量把等长请求分到同一 batch；
5. 磁盘空间：模型文件 + 临时交换空间，留足 2 倍权重体积的余量。

五、性能优化：把「时间换空间」的账算明白

5.1 存储设备是生命线

分层推理的性能上限由「权重从慢速存储到 GPU 的带宽」决定。存储设备的顺序读带宽直接决定冷启动速度：

这是冷启动（首次加载）的差异。运行期的层间搬运走的是「内存 → 显存」路径（PCIe），与磁盘无关——所以热启动后，磁盘速度只影响首次加载和换页。

结论：跑 100B+ 模型，NVMe 是硬性要求；只有 7B 级别的小模型，SATA SSD 才勉强够用。

5.2 量化：搬运量直接减半

量化对分层推理的收益比传统推理更直接：权重精度降一半，搬运量就减一半，IO 受限下的推理速度几乎翻倍。

• FP16 → INT8：搬运量 × 1/2；
• FP16 → INT4：搬运量 × 1/4。

405B 模型 INT4 后每层权重约 1.6GB，PCIe 4.0 下搬运一层约 57ms——虽然还是慢，但已经进入「可等待」的区间。量化 + 分层推理，是低显存跑超大模型的黄金组合。

5.3 预取与流水线重叠

把「搬运」和「计算」重叠起来，是隐藏 IO 延迟最有效的手段：

无预取：  [搬运 L0] [计算 L0] [搬运 L1] [计算 L1] ...
有预取：  [搬运 L0]
          [计算 L0] [搬运 L1]
                    [计算 L1] [搬运 L2]
                              ...

理想情况下，计算时间 ≥ 搬运时间时，预取可以完全隐藏搬运开销（搬运在后台进行）。工程上通过双缓冲实现：一块显存缓冲区正在被计算，另一块正在接收下一层权重。

5.4 批大小与序列长度的权衡

内存推理下，每增加一个 token 的 KV Cache 都是真实的内存开销。调参策略：

• 批大小：优先保证单请求延迟，batch 不超过「内存预算 ÷ (序列长度 × 128KB/token)」；
• 序列长度：能截断就截断，4K 和 128K 上下文的 KV Cache 差 32 倍；
• 生成长度：max_new_tokens 设小一点，长文本分段生成。

5.5 实测参考（估算）

不同硬件差异极大，以下数字是 PCIe 4.0 + RTX 4090 + NVMe 环境下的量级参考，用于理解比例关系：

解读：8B 级别模型，分层推理的速度已经接近可用；70B 级别适合离线批量任务；400B 级别，请把它当作「异步任务执行器」而不是「对话服务」——这也是 AirLLM 最诚实的定位。

5.6 生产级建议（15 条）

1. 存储用 NVMe，顺序读带宽是分层推理的第一生产力；
2. 权重尽量 INT4/INT8，搬运量减半起步；
3. 模型放本地，禁止每次启动从 HuggingFace 下载几百 GB；
4. 离线部署时设 HF_HUB_OFFLINE=1，避免网络探测拖慢启动；
5. 冷启动预热：部署后先跑一次空推理，把权重读进 page cache；
6. 内存预算 = 权重体积 + KV Cache + 系统余量（至少 20%）；
7. 监控 swap：一旦开始换页，性能断崖式下跌；
8. 推理期间关闭 GPU 上其他进程，别让显存被分走；
9. 小 batch、短序列，KV Cache 是内存推理的第二约束；
10. 用流式/分块生成尽早返回首 token，别让调用方干等；
11. 长任务（400B 模型）放后台队列，配超时与重试；
12. 同一台机器不要并行跑多个大模型实例，内存争抢会互相拖垮；
13. 定期清理 page cache 碎片（echo 3 > /proc/sys/vm/drop_caches 需谨慎，只在高水位时用）；
14. 先拿 7B 模型验证整套流程，再上大模型，排障成本差一个数量级；
15. 记录每次推理的 torch.cuda.memory_allocated 峰值，建立显存画像，指导后续调参。

六、总结与展望

6.1 什么时候该用 AirLLM

• 显存不足：手头只有消费级显卡，却要跑大模型；
• 离线任务：批量总结、文档处理、代码生成，不要求实时响应；
• 数据敏感：不能上云，必须本地推理；
• 开发调试：本地验证 prompt 效果，再决定是否上生产。

6.2 什么时候别用

• 高并发在线服务：这是 vLLM/TGI 的主场，别拿分层推理硬扛 QPS；
• 延迟敏感：首 token 延迟和每 token 速度都远不如 GPU 常驻方案；
• 显存够用：24GB 显存跑得下 13B，没必要引入 IO 瓶颈。

6.3 分层推理的未来

AirLLM 代表的「内存推理」方向，正在和几个硬件趋势合流：

1. AI SSD / 计算存储：把模型权重放进 SSD 上的专用加速器，存储直接参与计算，搬运瓶颈从 PCIe 下沉到存储内部；
2. CXL 内存池：通过 CXL 协议把多台机器的内存池化，单机「内存仓库」的容量上限被打破，405B 全精度权重常驻内存成为可能；
3. 异构调度标准化：分层加载、专家路由、CPU offload 正在从各家框架的私有实现，走向统一的调度抽象——未来可能一个 device_map 参数就自动决定权重放在 GPU/内存/磁盘的哪一层。

结语

显存墙不是物理规律，而是「权重必须常驻显存」这个工程假设的副产品。AirLLM 用分层推理把这个假设拆掉之后，一道看起来无解的算术题变成了一个可优化的带宽问题——8GB 显存跑 405B 不再是段子，而是一套可以落地、可以调优、可以上生产的工程方案。

算力会越来越便宜，但「在有限的硬件上跑更大的模型」这个需求永远不会消失。分层推理给出的启示是：当你觉得某个资源约束不可逾越时，先回头检查一下，那个约束是不是建立在一个早已过时的默认假设上。 对推理而言，权重常驻是假设；对人生而言，这大概也算一种通用算法。