每日开源 · 早间篇 · 第 118 期
一张 4GB 显卡，把 70B 模型"流"起来
AirLLM：用"按层流式加载"重写了"必须全模型入显存"的常识，
70B 跑在 4GB、405B 跑在 8GB、2.8 万亿参数的 Kimi K3 跑在 3.72GB。
⚠️ 合规提示：本工具通过 PyPI（pip install airllm）安装，所有模型权重从 HuggingFace Hub 下载。在中国大陆访问 HuggingFace 部分模型可能需要合规网络环境，建议优先选择阿里 DashScope / ModelScope 上的开源权重。
PROJECT BRIEF
项目速览 · AirLLM
一句话定位：把大模型从磁盘"按层流式加载"到 GPU，让单张消费级显卡也能跑全精度大模型，无需量化、蒸馏、剪枝。
**仓库：**github.com/lyogavin/airllm
**作者：**Gavin Li（链家 BELLE 团队，Anima 创始人）
**最新版本：**v3.2.0（2026-08-19，新增 Qwen3.8-27B 视觉语言模型支持）
**许可证：**Apache 2.0
**今日热度：**30K+ Stars · 持续 GitHub Trending · 326 commits
一张表看清"低显存天花板"被捅穿了
4 GBLlama 70B8 GB405B Llama 3.112 GBDeepSeek-V3 671B3.72 GBKimi K3 2.8T
3×4bit 块量化加速0无需量化/蒸馏/剪枝326commits 仍在更新
它能解决什么问题？
当你看到"70B 模型"的字眼时，第一反应是："这是 140GB 显存的事，关我 4GB 显卡什么事？"——这个项目就是来打破这个成见的。
现实里，绝大多数开发者和研究者的本地机器只有 RTX 3050 / 3060 / 4060 笔记本，甚至 MacBook Air M2。即使你愿意买云端 A100，一小时几十块的账单做几次实验就够劝退。
AirLLM 的回答很直接：别把整本字典塞进脑子，一次只翻一页。把"全模型入显存"的隐含假设拆掉，剩下的工程问题就只是"磁盘够不够快"。
关键洞察（也是它能在 4GB 上跑 70B 的根本原因）：Transformer 的前向传播是严格串行的——每一层的输入只依赖上一层的输出，与其他层的权重无关。所以任意时刻，显存里只需要保留当前正在执行的那一层。
七大核心亮点
① Layer-wise Loading：单层峰值显存，从 O(N) 降到 O(1)
传统的 inference 引擎（vLLM、Transformers 原生）一次性把全部层加载到 VRAM，70B 模型约 140GB。AirLLM 的处理流程：分片存盘 → 加载第 k 层 → 前向计算 → 释放 VRAM → 加载第 k+1 层。最终显存占用 = 单层权重 + 激活值 + KV Cache。对于 80 层的 70B 模型，每层约 1.6-1.75GB，一张 4GB 卡稳跑。
② Prefetch 重叠调度：让"读盘"和"计算"在时间线上对齐
光做分层不够——层间切换时 GPU 会空等。AirLLM 引入 Prefetch：计算当前层的同时后台线程把下一层权重从磁盘/内存搬到 GPU，让 CPU IO 与 GPU 计算的流水线尽量重叠。实测带来约 10% 的吞吐提升（在 Llama2 类模型路径下生效）。
③ Block-wise Quantization：3× 加速、精度几乎不掉
传统量化（GPTQ / AWQ / bitsandbytes）必须同时压权重和激活值才能加速，但激活值分布不稳定容易翻车。AirLLM 的瓶颈在磁盘 IO，不在 GPU 计算，所以只压权重不压激活。把每个权重块独立量化到 4bit，自带缩放系数解码还原，官方数据：Perplexity 仅高 0.3 左右，推理速度提升最高 3 倍。
④ MoE 专家级流式加载：2.8 万亿参数的 Kimi K3 只要 3.72GB
这是 AirLLM 最妙的设计。MoE 模型每个 step 只激活少数几个 expert，传统做法要么全部加载（爆显存），要么按层加载（仍然浪费）。AirLLM 进一步下沉到 expert 粒度——只把当前 token 路由到的那些 expert 权重搬进 GPU，沉默专家完全跳过。DeepSeek-V3 671B 因此只需 12GB，Kimi K3（2.8T 总参）只需 3.72GB。
⑤ KV Cache 智能换出：4GB 显存也能撑 32k 上下文
解码阶段每生成一个 token 都要访问所有历史 token 的 KV 缓存，这块会随上下文变长爆炸增长。AirLLM 把不活跃的 KV 条目换出到 CPU 内存，需要时按索引取回。在 4GB 显存下实测能撑住 32k token 上下文，传统全量加载需要 80GB 才做得到。
⑥ AutoModel 统一接口：模型"一行切换"
v2.6 引入的 AutoModel.from_pretrained() 自动识别模型架构，不用再手写 AirLLMLlama2 / AirLLMQWen。Llama 2/3/3.1/4、Qwen 1/2/2.5/3/3.5/3.8、DeepSeek V2/V3/R1、Mistral / Mixtral、Phi、Gemma、ChatGLM、Baichuan、InternLM、Yi、Kimi K3——一个 API 覆盖。
⑦ Apple Silicon + CPU 推理：MacBook 也能跑 70B
v2.10+ 起原生支持 Apple Silicon（M1/M2/M3/M4），通过 MLX 后端利用统一内存做"显存"；v2.10.1 起支持纯 CPU 推理（牺牲速度换取无 GPU 环境下的可用性）。实测 M2 MacBook Pro 16GB 跑 70B，约 50 个 token / 12 分钟（~0.07 tok/s），慢，但能跑。
性能真相：你的硬盘，就是你的 GPU
社区里有个被反复验证的公式：
seconds per token ≈ 模型磁盘大小 ÷ 磁盘顺序读速度
以 70B 模型 FP16 ~140GB 为例：
Gen4 NVMe SSD（~7 GB/s 顺序读）→ 约 20 秒 / token
Gen3 NVMe SSD（~3.5 GB/s）→ 约 40 秒 / token
SATA SSD（~0.5 GB/s）→ 约 280 秒 / token
机械硬盘（~0.15 GB/s）→ 去买杯咖啡再回来
对比一下：llama.cpp + GGUF 量化版 70B 跑在 RTX 4090 上是 8-15 token / 秒。AirLLM 不是让 4GB 卡变快，而是让 4GB 卡 有可能 跑 70B——一个数量级差距。适合离线批处理、模型对比评测、长文档分析，不适合实时对话。
四个真实使用场景
场景一：RTX 3060 笔记本跑 Llama-2-70B 问答
先试了 llama.cpp INT4 量化版：能加载，但生成速度只有 0.2 token/秒，交互体验灾难。切到 AirLLM，保留块级量化打开分层加载，显存 3.8GB，首 token 15 秒，稳定 6-8 token/秒。原因：llama.cpp 把整模型压进显存后 KV Cache 仍常驻 GPU，AirLLM 把激活显存进一步压缩。
场景二：12GB 显存工作站跑 Llama 3.1 405B
405B 单卡根本放不下。AirLLM 支持多层间插入 CPU offload，把中间结果暂存内存再合并。首 token 约 40 秒，生成 2 token/秒——不快，但"能用"和"不能用"之间，这就是质的差别。
场景三：RTX 4090 跑 DeepSeek-V3 671B MoE
第一次直接加载爆显存，看日志发现所有 expert 被同时映射。改用 moe_layerwise_load=True 只加载激活 expert，显存从 22GB 降到 9GB，正好落在 4090 范围。生成效果正常，专家路由无异常激活。
场景四：纯 CPU 跑 70B 备援方案
无独显的工作站（40GB+ 系统内存），首 token 约 3 分钟，稳定 1 token/秒。完成简单对话没问题。适合作为无 GPU 环境的应急方案，至少模型能落地。
和主流推理框架的对比
AirLLM：核心策略是逐层磁盘流式。最小显存 4GB（70B），精度无损（无压缩时）或轻损（4bit 压缩），速度慢但唯一选择。
llama.cpp（GGUF）：核心策略是 INT4-INT8 量化 + 部分层卸载。最小显存 8GB（70B Q4），量化精度有损，速度中等。CPU 推理成熟，边缘设备友好。
Ollama：封装 llama.cpp，提供一键安装和类 ChatGPT 界面。最小显存 24GB（70B Q4），量化精度有损，速度中等。日常本地 AI 助手首选。
vLLM：PagedAttention + 连续批处理，生产级服务框架。最小显存 80GB+（70B 全量），精度无损或量化，速度 20+ token/秒。适合高并发在线服务。
选型逻辑：显存 ≥ 24GB 选 Ollama 或 vLLM；4-8GB 但能容忍慢速 + 想要零量化损失，选 AirLLM；纯 CPU 环境选 llama.cpp GGUF 版。
上手指南：从 pip 到第一个 token
第一步：安装。建议用 conda 或 venv 隔离环境。
# 推荐 Python 3.10 + conda 隔离 conda create -n airllm python=3.10 -y conda activate airllm # 主体 pip install airllm # 想用 4bit / 8bit 块量化再装这个 pip install -U bitsandbytes
第二步：跑一个 32B 模型试试水（先别急着上 70B）。
# 一行切换任意模型大小 from airllm import AutoModel model = AutoModel.from_pretrained("Qwen/Qwen3-32B") # 同样的语法换更大模型： # model = AutoModel.from_pretrained("Qwen/Qwen3-235B-A22B") # MoE 235B ~3GB # model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3") # MoE 671B ~12GB input_tokens = model.tokenizer( ["What is the capital of France?"], return_tensors="pt", truncation=True, max_length=128, padding=False ) output = model.generate( input_tokens['input_ids'].cuda(), max_new_tokens=20, use_cache=True, return_dict_in_generate=True ) print(model.tokenizer.decode(output.sequences[0]))
第三步：想要 3× 加速？打开 4bit 块量化。
model = AutoModel.from_pretrained( "meta-llama/Meta-Llama-3-70B-Instruct", compression='4bit', # 或 '8bit' delete_original=True, # 拆分后删原文件省一半磁盘 profiling_mode=True# 看每层耗时定位瓶颈 )
第四步（可选）：跑 MoE 模型必须加这个 flag，否则会爆显存。
# DeepSeek-V3 / Kimi K3 / Qwen3-235B 等 MoE 模型专用 model = AutoModel.from_pretrained( "deepseek-ai/DeepSeek-V3", moe_layerwise_load=True )
第五步（macOS 用户）：用 MLX 后端利用统一内存。
# 注意：必须用原生 Python，不要用 Anaconda 版的 pip install airllm mlx from airllm import AutoModel model = AutoModel.from_pretrained("Qwen/Qwen3-8B") # 自动检测 MLX
⚠️ 第一次运行前必读：
· 70B FP16 模型首次运行需要 ~280GB 临时磁盘空间（原模型 + 分层切片同时存在），结束后设 delete_original=True 删一半
· 最常见的报错 MetadataIncompleteBuffer，九成是磁盘满了
· 必须用 NVMe SSD，SATA SSD 慢 5-7 倍，机械硬盘基本不可用
· 加载 Llama-2 等门控模型需传 hf_token="hf_xxx"
· AMD 显卡暂不支持；CPU 推理 v2.10.1+ 可用
社区共识：技术可行，实际难用？真相在中间
GitHub Issues 里对 AirLLM 的评价两极分化：支持者说它"让 LLM 推理民主化"，反对者说它"技术上可行，实际上没用"。真相在中间：
"4GB" 是最低门槛不是推荐配置。4GB 显存意味着你几乎不能同时开别的应用——浏览器、IDE、终端渲染都可能抢显存。舒适使用的门槛是 8GB 显存 + 64GB 内存 + NVMe SSD。
内存比显存更重要。如果整个模型能装进系统 RAM，OS page cache 会让速度比"纯读盘"快很多。128GB 内存的机器实测性能会显著优于公式预测值。
不是聊天机器人方案。等 10 分钟才出第一个字，对交互体验是灾难性的。AirLLM 适合离线批处理、模型评测、长文档 RAG，不适合实时对话。
核心思路 3 年没变过。最近半年的 commit 主要在做新模型兼容性适配（Kimi K3、Qwen3.8、optimum 兼容性等）。分层加载这个 idea 不需要频繁变——只要新模型"单层权重不超 4GB"，这个方案就一直有效。
今日总结
AirLLM 不是要取代 vLLM 或 Ollama——它解决的是一个被忽视的细分场景：你的硬件根本装不下大模型，但你不愿把数据送到云端。Layer-wise Loading + Prefetch 重叠调度 + 块级量化 + MoE 专家流式，这四件事分开看都不复杂，组合在一起就改变了游戏规则——从"8 张 A100 才能跑 70B"变成"1 张游戏显卡就能跑 70B"。
📦 本周前 3 期形成完整生态链：113 期 DeepSeek Harness（Agent Loop）→ 116 期 Cordis（Plugin Runtime）→ 117 期 Headroom（Context Compressor）→ 本期 AirLLM（本地推理部署）。四期合在一起，就是一张「从调用到运行」的完整 AI Agent 基础设施图。
今日互动话题
你的工作机显存是几 GB？你愿意为了"全精度大模型"接受"每个 token 等 20 秒"的速度吗？如果让你选，你会用 AirLLM 在本地跑 70B，还是直接调用云端 API？
欢迎在评论区聊聊你的本地推理体验：显卡型号、跑过的最大模型、首 token 等了多久。
**项目仓库：**github.com/lyogavin/airllm
**作者主页：**github.com/lyogavin（Gavin Li · 链家 BELLE 团队）
**PyPI：**pypi.org/project/airllm
**许可证：**Apache 2.0（代码）
每日开源 · 早间篇 #118 · 完
