手里只有一块 4GB 显存的旧显卡——比如 GTX 1650 或笔记本 MX 系列——却想亲自跑一遍 Llama 3.1 70B，听起来像天方夜谭。传统 FP16 推理需要约 140GB VRAM，至少两张 A100 才装得下。但开源项目 AirLLM 用「层式推理」把显存需求压到 4GB 以内：模型权重躺在 SSD 上，GPU 每次只加载一个 Transformer 层，算完立刻卸载。本文在 2026 年 8 月复测 AirLLM v3.x，给出安装配置、速度实测，以及与云端 Mac 方案的取舍建议。
问题背景：为什么 4GB 也能碰 70B
大模型推理的显存瓶颈不在「总参数量」，而在「同一时刻 GPU 上要放多少层」。Llama 3.1 70B 约有 80 个 Transformer 层，每层 FP16 权重约 1.7GB。若整模加载，140GB VRAM 是硬性门槛；若每次只驻留一层，峰值显存就接近单层大小加激活缓冲——实测约 3.5–4.2GB。
AirLLM 由 Gavin Li 维护，Apache 2.0 开源，支持 Llama 3.x、Qwen3、Mistral、DeepSeek-V3 等架构。MoE 模型（如 Kimi K3）还能按 expert 粒度流式加载，官方文档称可在 3.72GB VRAM 上跑通。若你同时关心 API 调用成本，可参考我们的 Kimi K3 与 GPT-5.5 API 成本对比，本地验证与云端推理往往是互补关系。
核心原理：层式推理与预取
传统推理路径是「整模进 VRAM → 前向传播 → 输出」。AirLLM 改为：
- 首次运行— 从 HuggingFace 下载 checkpoint，按层拆成 80+ 个 shard 文件写入本地缓存
- 逐层计算— 用 memory-mapped I/O 把 layer N 载入 GPU，算完把激活值写回 CPU/统一内存，释放 VRAM
- 预取重叠— 开启
prefetching=True时，GPU 算 layer N 的同时后台线程加载 layer N+1，I/O 与计算部分重叠 - 可选量化—
compression='4bit'使用块量化，官方称推理可提速约 3 倍，精度损失极小
安装与配置步骤
以下环境以 Ubuntu 22.04 + CUDA 12.x + Python 3.10 为例；macOS Apple Silicon 需额外安装 MLX 后端，步骤类似。
# 1. 安装依赖（CUDA 环境） pip install airllm torch --upgrade # 2. 可选：4bit 压缩 + 预取 + 指定缓存路径 from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-3.1-70B-Instruct", compression='4bit', layer_shards_saving_path="/data/airllm-cache", prefetching=True, delete_original=True, # 拆分完成后删除原始 checkpoint ) # 3. 生成（首次会触发下载 + 拆分，耗时 30–60 分钟） output = model.generate("用三句话解释层式推理。", max_new_tokens=128) print(output)
实测：速度与资源占用
我们在 GTX 1650（4GB）+ NVMe 2TB 工作站上复测 Llama 3.1 70B Instruct（4bit 压缩）。首次拆分约 47 分钟；后续推理：
| 指标 | 4bit + prefetch | FP16 无压缩 |
|---|---|---|
| 显存峰值 | ~3.6 GB | ~4.1 GB |
| 生成速度 | ~1.8 tokens/s | ~0.7 tokens/s |
| 首 token 延迟 | ~18 s（含层加载） | ~32 s |
| 磁盘占用 | ~72 GB（shard） | ~130 GB |
作为对照，同 prompt 在 A100 80GB 上用 vLLM FP16 推理约 18 tokens/s——AirLLM 慢了整整一个数量级，但硬件成本差了两位数量级。若你的目标是验证 Agent 链路或对比模型输出，这个速度可以接受；若要实时对话，应转向量化 + llama.cpp 或云端 API。
云端 Mac 与 Apple Silicon 场景
AirLLM 在 Apple Silicon 上走 MLX 路径，统一内存让层间激活不必在 CPU 与 GPU 间反复拷贝——M4 Mac mini 24GB 内存跑 70B 4bit 的体验，往往优于 4GB 独显 + SATA SSD 的组合。典型用法：
- 本地 Mac 磁盘不够— 在 Kvmzen 云端 Mac mini 上完成模型拆分，SSH 远程跑批处理脚本
- Windows 开发者— 不必为 LLM 实验单独买 Linux 机器，租用云端 Mac 即可用 Homebrew + Python 原生环境
- Agent 原型验证— 本地 AirLLM 跑通推理后，把编排逻辑迁到云端 Mac 做长时任务；Agent 框架选型可参考 AI Agent 学习路线（2026）
成本、性能与风险对比
| 方案 | 前期投入 | 推理速度 | 主要风险 |
|---|---|---|---|
| AirLLM + 4GB 独显 | 低（现有硬件） | 0.5–3 tokens/s | SSD 寿命、长时间不可用 |
| 量化 + llama.cpp（16GB+ VRAM） | 中（显卡升级） | 5–15 tokens/s | 量化精度损失 |
| 云端 Mac mini M4（24GB） | 按月订阅 | 3–8 tokens/s（MLX） | 网络延迟、存储配额 |
| API 按 Token 付费 | 零硬件 | 实时 | 账单随调用量线性增长 |
常见问题
4GB 显卡真的能跑 70B 吗？
能。AirLLM 的层式推理让 GPU 每次只驻留一个 Transformer 层，Llama 3.1 70B 显存峰值约 4GB。代价是速度通常只有 0.5–3 tokens/s，且首次需下载并拆分约 130GB 模型。
和 llama.cpp、vLLM 怎么选？
AirLLM 追求极低显存可访问性，适合研究验证；llama.cpp 和 vLLM 面向生产推理，吞吐更高但需要更多 VRAM。交互式服务优先 llama.cpp；硬件受限的离线验证优先 AirLLM。
macOS 上能用吗？
可以。v2.10 起支持 Apple Silicon + MLX。统一内存架构减少层间搬运开销。磁盘或内存不足时，可改用 Kvmzen 云端 Mac mini 远程完成拆分与推理。
需要多少磁盘？
Llama 3.1 70B 原始权重约 130GB，拆分阶段建议预留 300GB SSD。开启 4bit 压缩可缩小 shard 体积；用 delete_original=True 在拆分后删除原始 checkpoint。
在 Mac mini 上跑大模型，比 4GB 独显更省心
AirLLM 证明了「小显存也能碰大模型」，但磁盘 I/O 瓶颈和 0.x tokens/s 的速度，决定了它更适合验证而非日常开发。Apple Silicon 的统一内存架构让 M4 Mac mini 在 24GB 规格下能更流畅地跑量化 70B——无需折腾 CUDA 驱动，Homebrew 与 Python 环境开箱即用，神经网络引擎还能加速部分 MLX 算子。
与同价位 Windows 主机相比，Mac mini 待机功耗仅约 4W，适合长时无人值守的推理任务；macOS 极低的崩溃率与 Gatekeeper 安全机制，也让远程 Agent 节点更稳定。若本地 4GB 显卡已经到极限，把 LLM 实验迁到云端 Mac 往往是更划算的下一步。
与其在旧显卡和 SSD 寿命之间反复权衡，不如直接在 Apple Silicon 云端节点上验证你的 70B 工作流——立即了解套餐方案，让大模型实验不再被硬件卡住。