项目地址：/lyogavin/airllm

大语言模型发展到今天，常常会给人一种微妙的距离感。模型越来越大，参数越来越夸张，名字里动不动就是几十 B、几百 B，仿佛每一次新能力的出现，都在悄悄抬高硬件门槛。很多人刚燃起一点“我也想本地跑跑看”的兴趣，转头一看显存要求，热情立刻被现实按回桌面。

`AirLLM` 的出现，几乎就是冲着这种落差去的。

它在仓库 description 里的自我介绍非常干脆：**单张 4GB GPU 跑 70B 推理**。README 开头则把这件事说得更完整：它可以**大幅降低推理内存占用**，让 70B 大模型在单张 4GB GPU 卡上运行，而且**不需要量化、蒸馏或剪枝**。更进一步，README 甚至提到，你还可以在约 8GB 显存上运行 **405B Llama 3.1**。

这类说法会让人第一反应是：这怎么做到的？

而这恰恰也是 AirLLM 最吸引人的地方。它不像在喊一句“更快更强”的空口号，而是在试图重新定义一个问题：**大模型到底为什么一定要先把整座山都搬进显存里？**

## 它想解决的，是“大模型和普通硬件之间的尴尬关系”

AirLLM 给人的第一印象，不是它支持了多少模型，而是它在对抗一种默认前提：超大模型只能属于高配机器。

README 一开始就把这种不对称挑明了。很多大模型能力很强，但要想真正跑起来，往往需要相当可观的硬件条件。AirLLM 的目标很明确——不是通过删减模型、压扁模型、阉割模型来换可运行性，而是在推理内存使用上想办法，把超大模型从高门槛设备上“搬下来”。

这种姿态会让整个项目显得很有冲击力。因为它说的不只是“优化”，而是“让那些原本看起来不现实的模型，开始对普通硬件变得可触碰”。

## Quickstart 很短，但气势很大

AirLLM 的快速开始部分非常直接。

先安装：

```bash
pip install airllm
```

然后推理代码示例几乎是一上来就把它的核心野心摊开了：

```python
from airllm import AutoModel

MAX_LENGTH = 128
# just pass a hugging face repo id — works with almost any popular model:
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

# go bigger with the exact same one line:
#model = AutoModel.from_pretrained("Qwen/Qwen3-235B-A22B")     # 235B, runs in ~3GB
#model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")  # 671B, runs in ~12GB

# or use a model's local path...
#model = AutoModel.from_pretrained("/home/ubuntu/.cache/huggingface/hub/models--Qwen--Qwen3-32B/snapshots/...")

input_text = [
        'What is the capital of United States?',
        #'I like',
    ]

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)
```

这段示例最妙的地方，是它没有把“支持超大模型”写成单独一套复杂流程，而是刻意强调：**同样一行 `AutoModel.from_pretrained(...)`，从 32B 到 235B，再到 671B，写法都一样。**

这种一致性非常有说服力。它让超大模型看起来不再像一个特殊实验，而像一个你只是把模型 ID 换大一点的日常动作。

## AirLLM 的核心思路：它只让一层一层上显卡

README 在 “Tiny GPU, huge models” 里把核心机制讲得很清楚：

**AirLLM 在任意时刻只会把一层放到 GPU 上。**

这句话几乎就是整个项目的灵魂。它意味着显存需求不再取决于模型总大小，而主要取决于**单层大小**。也正因为如此，它才会让一个参数量巨大到夸张的模型，仍然能在很小的显存上被推理。

README 甚至直接给出了一张很有冲击力的表：

- 约 8B 的 Qwen3 / Mistral / Phi：约 1–2 GB
- 30–47B 的 Qwen3-30B / Mixtral：约 1–3 GB
- Qwen3-235B：约 3 GB
- Llama 3.x 70B：约 4 GB
- Llama 3.1 405B：约 8 GB
- DeepSeek-V3 671B：约 12 GB

读到这里时，会很容易生出一种强烈的反差感：模型体量和显存需求之间，那种常识里的线性关系，被它硬生生撬开了一道口子。

## 它不是只想省显存，还想继续提速

如果说“低显存跑超大模型”已经够抓眼球，那么 README 后面关于 **Model Compression** 的部分则显得更进一步。

AirLLM 提到，他们加入了基于 **block-wise quantization-based model compression** 的模型压缩能力，可以把推理速度继续提升，最高可达 **3x**，同时 README 说准确率损失几乎可以忽略。

如何启用这项能力，README 给了三步：

1. 安装 `bitsandbytes`
2. 确保 AirLLM 版本高于 2.0.0
3. 初始化模型时传入 `compression='4bit'` 或 `compression='8bit'`

示例：

```python
model = AutoModel.from_pretrained("garage-bAInd/Platypus2-70B-instruct",
                     compression='4bit' # specify '8bit' for 8-bit block-wise quantization 
                    )
```

这部分特别有意思，因为 README 还专门解释了：**模型压缩和量化不是一回事。**

它的说法是，传统量化往往需要同时量化权重和激活，才能真正显著加速，这样会更难兼顾准确率，也更容易受到输入异常值影响。而 AirLLM 所面对的瓶颈主要在**磁盘加载**，因此只需要把模型加载尺寸压小，也就是只量化权重部分，就能缓解瓶颈。

这是一种非常“工程问题工程解”的思路。它没有试图一口气把所有环节都改写，而是先认清真正卡住系统的是哪一段，再精准下手。

## 它提供的配置项，几乎都围绕“现实世界会遇到什么问题”展开

README 的 Configurations 列出了初始化模型时支持的几个主要参数：

- `compression`
- `profiling_mode`
- `layer_shards_saving_path`
- `hf_token`
- `prefetching`
- `delete_original`

这些选项看起来不多，但都很有针对性。

### `layer_shards_saving_path`

这个参数允许你指定分层拆分后模型的保存路径。因为 README 明确说了，推理过程中，原始模型会先被拆分并按层保存，所以磁盘空间和存储位置是一个真实存在的问题。

### `hf_token`

如果你加载的是 gated model，就可以通过这个参数提供 Hugging Face token。

### `prefetching`

README 说，预取机制会把模型加载和计算重叠起来，而且默认开启。它还提到，在早期更新中，这项能力曾带来约 10% 的速度提升。

### `delete_original`

如果磁盘空间紧张，可以删除原始下载模型，只保留转换后的版本，以节省大约一半磁盘占用。

这一整套参数组合非常能说明 AirLLM 的设计气质：它不是在造一个“只适合演示”的概念原型，而是在围绕实际使用中的存储、下载、令牌、速度和磁盘限制一点点做取舍。

## README 里还有一句很重要的提醒：磁盘空间要够

AirLLM 在 Quickstart 后专门写了一条注释：

**推理时，原始模型会先被逐层拆解并保存。请确保 Hugging Face 缓存目录中有足够磁盘空间。**

这类提醒很关键。因为一个项目越是试图让超大模型在小显存上跑起来，就越容易把压力转移到别的地方，而 AirLLM 并没有回避这一点。它很坦率地告诉你：显存是省下来了，但模型分层拆解本身是很吃磁盘的。

这份坦率反而让整个方案显得更可信。它没有神奇地“什么都省”，而是在不同资源之间做了明确重分配。

## Mac 也在支持范围内

README 里单独有一节 MacOS，写法非常轻巧：**安装 airllm 后，基本可以像 Linux 一样运行。**

同时，它也列出几个前提：

- 需要安装 `mlx` 和 `torch`
- 可能需要安装原生 Python
- 只支持 Apple silicon

这种表述有一种“已经替你走过坑”的感觉。它没有把 Mac 支持写得过于铺张，但边界条件点得很明确。再结合更新记录里提到的“Support MacOS running 70B large language models”，可以看出这条线并不是附带尝试，而是被认真推进过的能力。

## 它支持的模型，不是少数几个例子，而是几乎“全明星阵容”

README 的 Supported Models 写得相当豪爽：**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

这种支持范围，和它前面一直强调的 `AutoModel.from_pretrained(...)` 非常一致：它并不想让你记一堆专门类名或不同模型族的专用入口，而是尽量把“模型之间的差异”吸收进统一接口里。

## 更新记录本身，也像一条不断扩张边界的时间线

README 的 Updates 一节非常长，而且相当抓人眼球。里面写到：

- 支持 Kimi K3（2.8T），并给出单卡 3.72GB VRAM 的端到端测量
- v3.0 支持 FP8 模型，并提到 DeepSeek-V3 671B、Qwen3-235B 等模型的运行显存
- 支持 CPU inference
- 支持 non sharded models
- 支持 Llama 3.1 405B
- 支持 8bit/4bit quantization speed up
- 原生支持 Llama3
- 支持 MacOS 跑 70B
- 支持 AirLLMMixtral
- 加入 AutoModel
- 增加 prefetching
- 增加 ChatGLM、QWen、Baichuan、Mistral、InternLM 支持
- 支持 safetensors
- 加入压缩能力
- 初始版本发布

如果把这串更新连起来看，会发现 AirLLM 的路线非常清楚：它一直在把“大模型可运行性”的边界往外推。

不是一次性解决全部问题，而是不断拓展模型支持范围、降低硬件门槛、增加平台兼容、补上推理路径、优化速度和接口统一性。

## FAQ 很接地气，因为它谈的都是“真会撞上的问题”

README 的 FAQ 也很实在。

比如：

### `MetadataIncompleteBuffer`

它解释说，这通常是**磁盘空间不足**。因为拆分模型的过程非常吃磁盘。

### `ValueError: max() arg is an empty sequence`

这通常意味着你用错了模型类，比如用 Llama2 类去加载 QWen 或 ChatGLM。README 的建议是使用 `AutoModel`。

### gated model 的 401 错误

这说明模型需要 Hugging Face token，需要通过 `hf_token` 提供。

### tokenizer 没有 padding token

可以直接关闭 padding：

```python
input_tokens = model.tokenizer(input_text,
    return_tensors="pt", 
    return_attention_mask=False, 
    truncation=True, 
    max_length=MAX_LENGTH, 
    padding=False  #<-----------   turn off padding 
)
```

这类 FAQ 读起来会有一种“作者真的见过大家卡在哪里”的感觉。它们不是很宏大，但都是真正影响第一次跑通的地方。

## 它还有一些示例笔记本，覆盖了不同模型族

README 提供了 example notebook，并且在正文里放了一些其他模型的示例代码，包括：

- ChatGLM
- QWen
- Baichuan
- InternLM
- Mistral

这些示例的结构大体一致，继续强化了那个核心印象：不管模型族怎么换，使用方式都尽量收敛到一套统一的推理模式里。

## 从仓库元信息看，它的身份也很鲜明

根据仓库元信息，`airllm`：

- 仓库 description 是 “AirLLM 70B inference with single 4GB GPU”
- 使用 Apache 2.0 许可证
- 公开仓库
- 主题包括 `llm`、`lora`、`qlora`、`open-models`、`generative-ai` 等

这些信息和 README 所展现出的方向高度一致：这是一个明显围绕大模型运行、适配和低门槛推理而展开的开源项目。

## 仓库里还有其他 README，但主线依然很清楚

仓库中还包含 `anima_100k/README.md` 和 `rlhf/README.md`。它们分别讨论了 Anima 的 100K 长上下文能力，以及基于 QLoRA + DPO 的低成本 RLHF 训练实现。

这些内容虽然不是主 README 的核心路径，但它们会让整个仓库呈现出一种更大的技术兴趣版图：不仅关注“模型怎么跑”，也关注“模型怎么训练”“怎么拉长上下文”“怎么更便宜地做 DPO 对齐”。这让 `airllm` 看起来不只是一个孤立的小工具，而像是作者围绕大模型可用性不断展开的一系列探索中的关键一环。

## AirLLM 最迷人的地方，是它把“跑不动”变成了“也许可以试试”

很多项目的魅力来自新功能，AirLLM 的魅力则来自它对门槛的重新改写。

它并没有承诺“所有人都能无痛地在任何机器上跑任何模型”，也没有假装资源约束不存在。相反，它非常明确地告诉你：

- 我们是在省显存
- 代价之一是分层拆模和磁盘占用
- 可以进一步用压缩提速
- 可以传 token 处理 gated model
- 可以在 Mac 上跑，但要满足 Apple silicon 和相关依赖
- 还能通过统一的 `AutoModel` 接口去覆盖大量模型家族

这是一种很有工程感的诚实。也正因为如此，AirLLM 才显得格外有吸引力：它不是靠幻觉制造希望，而是靠具体机制把原本“不敢想”的事情变成“值得亲手试一试”。

如果把它拟人化，它像一个特别懂资源紧张是什么感受的人。它不会劝你先去换一张更大的卡，也不会先嫌弃你的设备不够“专业”。它会先低头看看手里现有的资源，然后告诉你：别急，也许我们可以换一种搬运方式，把这个大家伙一点一点运进去。

而对很多想靠近大模型、却总被硬件门槛挡在门外的人来说，这种姿态，本身就已经很动人了。

大语言模型发展到今天，常常会给人一种微妙的距离感。模型越来越大，参数越来越夸张，名字里动不动就是几十 B、几百 B，仿佛每一次新能力的出现，都在悄悄抬高硬件门槛。很多人刚燃起一点 “我也想本地跑跑看” 的兴趣，转头一看显存要求，热情立刻被现实按回桌面。

当大模型不再嫌你的显卡小：AirLLM 想把超大模型塞进普通人的机器里

技术副总监/联合创始人

人工智能

AirLLM突破大模型硬件限制，让70B参数模型在4GB显存GPU上运行，无需量化或剪枝。采用分层加载技术，仅需单层显存即可推理，支持Llama3、Qwen等主流模型。提供4bit/8bit压缩选项提升3倍速度，兼容MacOS系统，统一AutoModel接口简化操作。解决大模型与普通硬件的兼容问题，让超大模型触手可及。

代码解释

DeepSeek

Python

Linux

MacOS

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当大模型不再嫌你的显卡小：AirLLM 想把超大模型塞进普通人的机器里-腾讯云开发者社区-腾讯云

当大模型不再嫌你的显卡小：AirLLM 想把超大模型塞进普通人的机器里

当大模型不再嫌你的显卡小：AirLLM 想把超大模型塞进普通人的机器里

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐