Seedance 2.5 is live — 30-second cinematic video with native audio & real-person references
全部文章
用 AirLLM 在 4GB GPU 上运行 70B 大模型
2026/08/02

用 AirLLM 在 4GB GPU 上运行 70B 大模型

70B 大语言模型真的能在 4GB GPU 上运行吗？学习 AirLLM 如何从磁盘流式加载层、需要何种硬件、如何尝试，以及为何执行缓慢。

可以，70B 大语言模型在使用大约 4GB 显存的情况下可以用 AirLLM 执行，但模型并不存放在 4GB 显卡内部。 AirLLM 将检查点保存在磁盘上，每次加载一个 transformer 层到显存中，计算该层，释放它，然后重复。这种技术用存储 I/O 和延迟交换内存。[1][2]

这个区别就是整个故事。70B 模型仍需要在所使用精度下大约 130GB 的权重存储。4GB 这个数字指的是在特定配置下推理运行中的峰值显存，而不是总机器内存、下载大小或交互性能。

TL;DR

  • AirLLM 使极端卸载成为可能。 它按层将权重分片存在磁盘上，只将活跃层移动到 GPU。
  • 原始结果测试在 16GB Nvidia T4 上的显存低于 4GB。 它并未演示完全从 4GB 物理显卡运行的快速聊天机器人。[1]
  • 磁盘容量和速度仍然重要。 首次运行下载并重新分片检查点，每生成一个 token 都会重复将权重流经计算设备。
  • 短输入长度是技巧的一部分。 原始示例使用 100 个 token 的输入长度；更大的 KV 缓存和运行时缓冲会消耗更多内存。[1]
  • 期待研究或批处理速度，而不是响应式聊天。 AirLLM 作者明确将低端硬件定位于离线工作而非交互应用。[1]
  • 需要输出速度时使用 API。 极端本地卸载对于学习和偶发私有任务很有用；托管推理通常是更简单的生产路径。

"在 4GB GPU 上运行 70B 大模型"实际意味着什么

四种不同的资源被压缩为一个标题。分离它们可以避免大多数不当的硬件决策。

资源AirLLM 改变了什么AirLLM 没改变什么
GPU 显存仅保持大约一层加运行时状态驻留完整检查点不在显存中
系统内存使用延迟加载和元设备避免完整模型物化Python、分词器、缓冲区和操作系统内存仍然存在
磁盘将完整模型存储为面向层的分片下载不会变成 4GB
时间预取可以重叠部分加载和计算存储流量仍然是中心瓶颈

原始 2023 年演示使用基于 Llama 2 的 70B 检查点，有 80 个 transformer 层。单层估计约 1.6GB，其 100-token 示例的 KV 缓存约 30MB。测量过程中 Nvidia T4 上的 GPU 显存保持在 4GB 以下。[1]

AirLLM 当前存储库将相同理念扩展到 Llama 3.x、Qwen、DeepSeek、Mixtral、Phi、Gemma 和其他系列。其当前参考表仍列出全精度 Llama 3.x 70B 运行在大约 4GB 显存。[2] 将其视为项目声明和内存目标，而非每个 4GB 显卡的吞吐量基准。

AirLLM 层级推理如何工作

AirLLM 从磁盘通过 4GB GPU 暂存区流式处理 transformer 层

transformer 按顺序运行其块。第 12 层消耗来自第 11 层的隐藏状态；第 13 层等待第 12 层。AirLLM 利用该顺序实现五部分管道。

  1. 创建空模型外壳。 Hugging Face Accelerate 的元设备初始化架构，而无需为每个参数分配真实存储。[3]
  2. 按层重新分片检查点。 Safetensors 文件重新排列，以便加载一层不需要读取无关的多 GB 分片。
  3. 将一层加载到计算设备。 仅该层和所需的运行时张量占用 GPU。
  4. 计算、释放并继续。 隐藏状态向前移动，同时层权重离开显存。
  5. 对每个生成的 token 重复。 预取重叠一些存储 I/O 与计算，但无法消除重复的数据移动。

FlashAttention 通过平铺的 I/O 感知计算减少注意力使用的临时内存。[4] 它帮助活跃层适配，而层流式处理解决非活跃权重等待位置的独立问题。

仍然需要的硬件和存储

GPU 仅是一个组件。下载 70B 检查点前，验证机器的其余部分。

  • 兼容的计算路径。 标题演示针对 Nvidia CUDA。AirLLM 也记录 Apple 硅和 CPU 路径，但其内存和性能特性不同。[2]
  • 足够的磁盘用于检查点和转换。 项目警告首次运行层分割是磁盘密集型的。其 delete_original 选项在存储紧张时可以在转换后删除原始检查点。
  • 快速本地存储。 NVMe 不会让层流式处理免费，但慢硬盘会使已有 I/O 限制的循环大大恶化。
  • 短初始上下文和输出。 从很小的提示和 20-40 个新 token 开始。更长的上下文增加 KV 缓存，更长的输出重复完整层遍历更多次。
  • 模型访问。 受门控的 Meta 检查点需要 Hugging Face token 和模型许可证的接受。

不要仅仅为了测试环境是否有效就开始 70B 下载。先运行 8B 或更小的支持模型，验证 CUDA 和存储路径，然后扩大规模。

如何用 70B 模型尝试 AirLLM

当前项目快速入门使用 AutoModel，从 Hugging Face 存储库 ID 选择合适实现。[2] 首先安装与 CUDA 驱动程序兼容的 PyTorch 构建，然后安装 AirLLM。

python -m venv .venv
source .venv/bin/activate
pip install airllm

将密钥保存在环境变量中而不是源代码：

export HF_TOKEN="your_hugging_face_token"

然后运行有意小的生成：

import os

from airllm import AutoModel

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"
MAX_LENGTH = 128

model = AutoModel.from_pretrained(
    MODEL_ID,
    hf_token=os.environ["HF_TOKEN"],
    layer_shards_saving_path="/data/airllm-shards",
)

prompt = ["Explain layer-wise inference in three short sentences."]
tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)

result = model.generate(
    tokens["input_ids"].cuda(),
    max_new_tokens=32,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(result.sequences[0]))

这是对存储库快速入门的最小化改编，不是通用环境锁定文件。AirLLM、Transformers、PyTorch、CUDA 和模型的远程代码可能有特定版本约束，所以在生产机器上安装前检查当前存储库问题。

首次运行会发生什么

首次启动不代表后续启动。AirLLM 必须下载模型、检查其架构、将检查点分割成层分片，并将这些分片写入配置路径。中断转换或磁盘不足可能会留下不完整的 safetensors 头；项目的常见问题建议清除不完整缓存并在腾出空间后重新运行。 [2]

单独监控四个信号：

nvidia-smi -l 1          # GPU 内存和利用率
free -h                  # 系统内存
df -h /data              # 可用磁盘空间
iostat -xz 1             # 存储饱和度（如果安装了 sysstat）

低显存数字本身不是成功。记录首 token 时间、每个输出 token 秒数、磁盘读取量，以及是否重复运行重用已完成分片。

为什么 AirLLM 即使能适配也很慢

正常 GPU 推理加载权重一次并为许多 token 和请求重用。极端层卸载反转这个优势。每个新 token 必须通过完整模型堆栈，同时权重成小块从存储移入 GPU。

AirLLM 添加了预取来重叠加载与计算，并提供 4 位或 8 位块级权重压缩来减少磁盘流量。存储库报告压缩可获得高达三倍改进，但实际性能取决于模型、存储、GPU、上下文和软件版本。[2]

这使该方法更适合于：

  • 对无法加载的模型进行一次性评估；
  • 离线文档分类或提取；
  • 低量私有批处理，其中延迟是次要的；
  • 研究内存调度和模型架构。

它对实时聊天、代理循环、高并发或任何延迟目标的 API 是不理想的。

AirLLM 对比量化与 API

方法本地权重典型目标主要权衡
AirLLM 层流式处理是使超大模型执行非常低的吞吐量和重磁盘 I/O
4 位量化是使模型更小更快密集 70B 模型仍需远超 4GB 用于权重
CPU/GPU 卸载是跨 RAM 和显存分割中等超大模型需要大量系统 RAM
托管 API否获得交互或生产推理远程执行、使用成本、提供商信任

当实验是重点时选择 AirLLM。当本地交互性是重点时选择较小的量化模型。当 70B 类模型和可用响应时间都是要求时选择 API。

相同的区别适用于更大的声明。我们的 Kimi K3 在 4GB GPU 分析 解释为什么稀疏专家改变流式处理单元但不消除检查点。作为当前长上下文 API 示例，参见 MiniMax M3 API 指南，或浏览实时 模型目录。

实际决策清单

在 4GB GPU 上尝试 70B LLM 前，回答以下问题：

  1. 目标是证明执行，还是构建响应式产品？
  2. 转换期间磁盘是否能容纳原始模型及其层分片副本？
  3. 检查点架构是否由当前 AirLLM 版本明确支持？
  4. 工作负载是否能容许长首 token 时间和低吞吐量？
  5. 模型许可证是否允许预期用途？
  6. 你是否先用小检查点测试过相同软件堆栈？

如果问题二到四的回答是否定，4GB 标题不是有用的部署计划。

常见问题

70B 大语言模型真的能在 4GB GPU 上运行吗？

是的，通过极端层级流式处理。只有模型的小部分在一次驻留在显存中；完整检查点保持在磁盘上。这与将 70B 模型加载到 4GB 不同。

原始 AirLLM 测试使用了实际 4GB 显卡吗？

2023 年文章说团队在 16GB Nvidia T4 上测试，测得少于 4GB 的 GPU 显存使用。[1] 当前存储库分别列出 Llama 3.x 70B 在大约 4GB 显存。

70B 模型需要多少磁盘空间？

取决于检查点精度和格式。原始演示描述大约 130GB 参数，层转换可能会临时需要原始和转换副本。下载前检查存储库文件并为中断或部分转换留出空间。

AirLLM 对聊天机器人足够快吗？

在低端硬件上通常不是。原始作者警告 T4 设置缓慢，更适合离线工作。[1]

AirLLM 在 4GB 中训练 70B 模型吗？

否。训练必须为反向传播保留或重计算激活和梯度。AirLLM 的层级技术涉及推理，不是完整训练。[1]

4 位 70B 模型对 4GB 显存足够小吗？

否。七十亿参数在 4 位仅需要 35GB 理论值用于原始权重，在量化元数据和运行时内存前。量化帮助，但不能关闭这个差距。

关于 70B 推理在 4GB 显存上的诚实结论

AirLLM 将硬显存限制转变为调度问题。这是真实的技术结果：70B LLM 可以在 4GB 显存下执行，当运行时从更大存储流式处理层分片时。代价是重复 I/O、缓慢生成、大型检查点和脆弱软件堆栈。

用它来研究极端推理或完成低量离线任务。对于交互应用，使用较小本地模型或通过 reAPI 快速入门 调用托管模型。有用的教训不是 70B 成为了 4GB 模型。而是显存不再必须同时容纳每个权重。

参考文献

  1. Gavin Li. Unbelievable! Run 70B LLM Inference on a Single 4GB GPU with This New Technique. November 30, 2023. huggingface.co/blog/lyogavin/airllm
  2. AirLLM. AirLLM repository, current quickstart, supported models, configuration, and FAQ. Retrieved August 2, 2026. github.com/lyogavin/airllm
  3. Hugging Face Accelerate. Big Model Inference and the meta device. huggingface.co/docs/accelerate/usage_guides/big_modeling
  4. Dao et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022. arxiv.org/abs/2205.14135
全部文章

更多文章