礼貌是一种语言。它的规则与实行，主要要从观察，从那些有教养的人们举止上去学习。——洛克

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

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

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

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

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

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

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

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

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

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

Quickstart 很短，但气势很大

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

先安装：

1	pip install airllm

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

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 给了三步：

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

示例：

1
2
3

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：

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 才显得格外有吸引力：它不是靠幻觉制造希望，而是靠具体机制把原本“不敢想”的事情变成“值得亲手试一试”。

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

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