70B 大模型塞进 4GB 显存——AirLLM 这个层加载思路很有意思

简介: AirLLM 是一款创新的轻量级大模型推理框架,无需量化/剪枝,仅凭4GB显存即可运行70B甚至2.8T参数模型。其核心是“按层动态加载+预取优化”,将显存压力从全模型降至单层,兼顾可行性与精度,让消费级GPU轻松跑起超大模型。

前段时间帮朋友搭建一个本地 LLM 推理服务,他手里只有一块 RTX 3060 12GB。想跑 70B 模型,常规思路是量化到 4bit,但量化后的效果损失在复杂任务里还是能感觉到。

然后我看到了 AirLLM。Python 写的,Apache-2.0 协议,GitHub 27k+ Star。它的卖点是:70B 模型能在单张 4GB 显存 GPU 上跑,不需要量化、蒸馏或剪枝。

我仔细看了它的实现方式,发现核心思路不是压缩模型,而是改变加载策略。今天聊聊这个技术路线。


一、传统思路 vs AirLLM 思路

传统思路

大模型推理时,通常把整个模型权重一次性加载进显存。一个 70B 模型 FP16 需要约 140GB 显存,消费级 GPU 根本放不下。所以大家只能走量化、蒸馏、剪枝路线,用精度换空间。

AirLLM 思路

AirLLM 不问"怎么让模型变小",而是问"能不能一次只加载一层?"

它把模型按层切分成多个 shard 文件,推理时只在 GPU 上保留当前计算的那一层,算完就释放,再加载下一层。这样显存占用取决于单层大小,而不是整个模型大小。

image.png

结果很夸张:

模型 参数量 所需显存
Qwen3 / Mistral / Phi 8B 8B ~1-2 GB
Qwen3-30B / Mixtral 30-47B ~1-3 GB
Qwen3-235B 235B ~3 GB
Llama 3 70B 70B ~4 GB
Llama 3.1 405B 405B ~8 GB
DeepSeek-V3 671B ~12 GB
Kimi K3 2.8T <4 GB

Kimi K3 这个 2.8T 参数的 MoE 模型能在 4GB 以下跑,是因为它每次只加载实际激活的 expert,而不是整个层。


二、核心机制:层分片 + 动态加载

AirLLM 的工作流程可以拆成三步:

image.png

1. 模型分片

首次加载模型时,AirLLM 会把 HuggingFace 下载的模型按层切分成多个独立文件,存在本地。这个预处理只需要做一次,之后复用。

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

2. 按需加载

推理过程中,AirLLM 按顺序加载每一层到 GPU,完成该层计算后释放,再加载下一层。任意时刻 GPU 上只有当前层。

3. 预取优化

为了避免"加载一层 → 计算一层 → 等加载"的流水线空转,AirLLM 做了 prefetching:在计算当前层的同时,提前把下一层从磁盘读到内存。这样 I/O 和计算可以重叠,README 里说能带来约 10% 的速度提升。


三、代码长什么样

实际使用非常简洁,和 transformers 的接口很像:

from airllm import AutoModel

MAX_LENGTH = 128
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

input_text = ['What is the capital of United States?']
input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False
)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True
)

output = model.tokenizer.decode(generation_output.sequences[0])
print(output)

大的模型也是同一行代码:

# 235B MoE,约 3GB 显存
model = AutoModel.from_pretrained("Qwen/Qwen3-235B-A22B")

# 671B,约 12GB 显存
model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")

AutoModel 会自动检测模型类型,不需要手动指定 Llama、Qwen、DeepSeek 这些类。


四、可选的压缩加速

如果觉得层加载还是慢,AirLLM 支持块级权重量化:

model = AutoModel.from_pretrained(
    "garage-bAInd/Platypus2-70B-instruct",
    compression='4bit'  # 或 '8bit'
)

注意这里的量化和传统量化不太一样:

  • 传统量化:权重和激活都量化,容易掉精度
  • AirLLM 的压缩:主要解决磁盘 I/O 瓶颈,只量化权重,精度损失很小

官方说开启 4bit 压缩后推理速度能提升约 3 倍。


五、支持哪些模型

AirLLM 基本覆盖主流开源模型:

  • Llama 2 / 3 / 3.1 / 3.3 / 4
  • Qwen 1 / 2 / 2.5 / 3(含 MoE、FP8)
  • DeepSeek V2 / V3 / R1
  • Mistral / Mixtral
  • Phi / Gemma / ChatGLM / Baichuan / InternLM / Yi

新模型发布的当天通常就能用,因为架构大多是已知变体。


六、实际部署要注意什么

磁盘空间

层分片需要先把完整模型下载到本地,所以磁盘空间要够。首次加载时会做分片预处理,过程也比较吃磁盘。如果磁盘不够,可以设 delete_original=True,分片完成后删掉原始 HuggingFace 模型,省一半空间。

速度 trade-off

AirLLM 把显存瓶颈转移成了磁盘 I/O 瓶颈。模型虽然能跑起来,但速度肯定不如把模型全放显存里快。它适合"能跑起来"的场景,不适合"追求极致吞吐"的场景。

首次加载较慢

第一次用某个模型时,AirLLM 会逐层拆分和保存,耗时较长。之后再次加载就快多了。

macOS 也支持

Apple Silicon 用户可以通过 MLX 后端运行,不过要额外装 mlx 和 torch。


七、适合什么场景

很适合:

  • 消费级 GPU 本地部署大模型
  • 笔记本上做 70B+ 模型实验
  • 学术研究,不想买 A100/H100
  • 原型验证阶段,先让模型跑起来再说

不太适合:

  • 生产环境高并发服务
  • 对延迟敏感的应用
  • 没有足够磁盘空间的机器
  • 追求极致推理速度的场景

结语

AirLLM 给我最大的启发是:有时候问题不在模型本身,而在加载方式。 与其千方百计把模型压缩变小,不如让它按层流动起来。

这个思路虽然牺牲了一定的推理速度,但把"大模型上消费级 GPU"这件事从"不可能"变成了"一行代码"。对于个人开发者、小团队和学生来说,这种技术路线非常实用。

如果你有一块 4GB 或 8GB 的显卡,又一直想试试 70B 甚至更大的模型,AirLLM 值得装一个看看。

目录
相关文章
|
22天前
|
机器学习/深度学习 人工智能 API
Qwen3.8-Max 开源了:该不该从 Claude 切过去?
阿里正式发布2.4万亿参数旗舰Qwen3.8-Max,支持100万上下文与原生多模态,激活95B参数,推理成本仅6美元/百万token。下周将开源Max系列权重——史上首次,兼具强编码、长程智能体与办公自动化能力,但标准编程基准仍略逊Fable 5。(239字)
|
22天前
|
人工智能 Rust JavaScript
让 AI Agent 少读 89% 的文件——我试了 CodeGraph 这个代码知识图谱
CodeGraph是开源代码知识图谱工具,为AI编程Agent预建项目结构地图,避免反复grep/读文件。支持20+语言,Rust内核,本地化存储,显著降低token消耗(-69%)与工具调用(-89%),大幅提升大项目理解效率。
193 0
|
22天前
|
人工智能 数据可视化 安全
把 Claude Cowork 换成开源版——OpenWork 让团队 AI 配置不再各配各的
OpenWork是开源AI工作流中枢,以MCP协议统一管理团队的Skill、API连接与模型服务,支持Codex/Claude/Cursor等多客户端共享能力,提供Den控制台实现权限管控、插件分发与私有化部署,让AI工具配置成为可复用、可审计的团队资产。(239字)
134 1
|
22天前
|
监控 Shell API
Qoder CLI /loop 大升级:Agent 自调节奏,盯盘场景交给它就行了
Loop Engineering 新增动态唤醒机制:`/loop` 不再依赖固定间隔,Agent 可自主决定检查频率、触发时机与终止条件。支持 Monitor 事件秒级响应、三模式自动路由、TUI 管理面板及持久化任务,让盯盘、告警监控等弹性场景真正实现“交出判断权”。
218 0
|
1月前
|
人工智能 弹性计算 API
【AI 尝鲜实验室】上新 | New API:一个入口打通全网大模型的统一网关
New API 是 QuantumNous 开源的大模型网关与 AI 资产管理系统(AGPL-3.0,GitHub 42k+ Stars),聚合 OpenAI、Claude、Qwen 等主流模型,提供统一 OpenAI 兼容接口、渠道分组、自动重试、额度管理及在线充值。本实验通过阿里云计算巢一键部署,几分钟即可搭建专属网关,支持团队令牌分发与国产模型无缝接入编程工具。
620 3
|
19天前
|
人工智能 IDE API
最新版OpenCode AI编程工具全解:核心功能、多模型兼容与实战应用指南
在AI技术深度赋能软件开发的当下,开源AI编程工具凭借灵活定制、模型无关、隐私安全等优势,成为开发者提升编码效率、简化开发流程的核心选择。OpenCode作为一款由Anomaly团队打造、采用MIT协议开源的AI编程代理工具,历经多轮迭代,最新版本已实现从基础代码补全到全流程智能开发、多模型无缝切换、三端协同运行的全面升级。它打破了传统AI编程工具“绑定单一模型”的限制,支持接入75+主流AI模型,同时提供终端、桌面、IDE三端统一体验,内置LSP语言服务器协议、多会话并行、智能任务规划等重磅功能,适配从个人轻量开发到团队规模化协作的全场景需求。本文将全面拆解最新版OpenCode的核心功能、
221 1
|
22天前
|
分布式计算 BI OLAP
Microsoft Fabric 在阿里云上对标什么?AnalyticDB MySQL 湖仓一体统一分析方案
Microsoft Fabric 作为一体化数据分析平台,在阿里云上,推荐以 AnalyticDB MySQL 湖仓版为统一分析平台内核,配合 DataWorks、Quick BI 组成的组合方案对标——AnalyticDB 湖仓版本身就是"统一分析平台"架构,用内置 Serverless Spark 承接数据工程、XIHE 向量化引擎承接交互分析、DMS Notebook/Airflow/MLflow 承接开发调度与 ML、开放表格式(Delta/Hudi/Iceberg on OSS)承接统一存储。
95 1
|
22天前
|
分布式计算 关系型数据库 MySQL
Databricks 数据洞察 DDI 已停服,如何迁移到 AnalyticDB MySQL 湖仓版
阿里云"Databricks 数据洞察(DDI)"已停止服务,当前官方推荐的承接方向是迁移到阿里云 AnalyticDB MySQL 湖仓版(Lakehouse Edition)——它以统一分析平台架构,用内置 Serverless Spark、DMS Notebook/Airflow/MLflow、开放表格式(Delta/Hudi/Iceberg)承接原 DDI 的湖仓分析与 Spark 加工场景,与 Databricks Spark + Deltalake 生态兼容度可达 90%+【数据示意】,且免运维、闲置成本归零、按 ACU 计费。如果你还在用 DDI 或搜到 DDI 相关旧内容,本文
92 1
|
2月前
|
数据采集 边缘计算 安全
边缘计算与云端协同:老旧注塑机如何通过VBOX实现全量数据上云?
本文介绍智象九维VBOX注塑机边缘网关,首创非侵入式旁路部署技术,无需停机破线,安全监听RS-485/CAN等总线;内置2000+协议解析引擎,支持海天、弘讯等多品牌老旧设备;结合云边协同架构,实现高频数据滤波、特征提取、断点续传,并无缝对接阿里云IoT平台与TSDB,构建高可靠工业数据底座。(239字)
471 8
|
21天前
|
编解码 Linux 数据安全/隐私保护
Linux系统之qrencode工具的安装与基本使用
qrencode是一款开源命令行二维码生成工具,支持文本、URL、vCard、Wi-Fi等数据编码,可输出PNG/SVG/EPS等多种格式,具备多级纠错、尺寸/边距/分辨率调节功能,广泛应用于产品溯源、会议签到、文档分享及网络连接等场景。
111 0