AirLLM 完整教學 2026：4GB 顯卡跑 70B、Kimi K3（2.8T）只用 3.72GB VRAM？分層串流原理、安裝、4-bit 壓縮與真實速度（0.5～2 token/s）的殘酷真相

AirLLM 是一套「用磁碟換 VRAM」的推論框架：它一次只把一層模型載進 GPU，算完就丟掉，所以 70B 模型只要約 4GB 顯示記憶體、671B 的 DeepSeek-V3 約 12GB 就能跑，2026 年連 2.8T 的 Kimi K3 都實測只要 3.72GB。代價是速度——真實世界約 0.5～2 token/s，它是「讓不該跑得動的硬體跑得動」，不是拿來取代 vLLM 的生產級推論。

如果你手上只有一張 RTX 3060 12GB 或一張 4GB 的入門卡，卻想親手跑一次 70B 級別的模型，選項通常只有兩個：一是量化到 4-bit 以上（但 70B 就算 4-bit 也要 35GB 以上），二是放棄。AirLLM 提供第三條路：不改模型精度、不蒸餾、不剪枝，靠把 GPU 當快取、把 SSD 當主記憶體的架構硬是把大模型塞進小卡。

截至 2026 年 10 月，這個由 Gavin Li（lyogavin）維護的專案在 GitHub 已累積 38,213 顆星、3,913 個 fork，授權為 Apache-2.0，PyPI 最新版本為 4.0.0（2026 年 9 月 5 日發布），而且 repo 在 10 月 13 日當天仍有提交——屬於活躍專案。

一句話結論：誰該用 AirLLM，誰不該

原理：把「模型大小」換成「單層大小」

傳統推論的邏輯是「模型多大，VRAM 就要多大」。AirLLM 反過來做：

1. 從磁碟載入第 N 層到 GPU
2. 對這一層做 forward pass
3. 丟掉這一層，釋放 VRAM
4. 載入第 N+1 層，重複上述流程

因為任何時刻 GPU 上只有一層（外加 KV Cache 與中間張量），VRAM 需求取決於單層大小，而不是模型總參數量。這就是 671B 模型能擠進 12GB 卡的關鍵。

兩個工程細節決定了它的實用性：

• prefetching（預取）：載入第 N+1 層時，GPU 同時在算第 N 層，用執行緒把磁碟 I/O 與計算重疊，官方稱約有 10% 加速。
• block-wise 量化壓縮：只壓權重、不壓啟動值（activation），因為瓶頸在磁碟讀取而非算力。開啟後最高可達 3 倍加速，官方說準確率損失「幾乎可忽略」（方法引用自 arXiv 2212.09720）。

一句話：AirLLM 的敵人不是 GPU 算力，是磁碟頻寬。 這也是速度差異那麼大的原因——NVMe SSD 與 SATA SSD 的體驗差距非常明顯。

實測 VRAM 對照表（官方 README 數據）

注意 MoE 模型（Mixtral、Qwen3-235B、Kimi K3）特別吃香：AirLLM 會只載入這個 token 實際路由到的專家層，所以 235B 的 MoE 反而比 70B 的 dense 模型更省 VRAM。Kimi K3 的 3.72GB 是在一張 RTX 6000 Ada 上「端到端量測」的數字。

安裝與第一段可執行程式碼

# 1. 安裝（建議先自行裝好對應 CUDA 版本的 PyTorch）
pip install airllm

# 之後要開壓縮加速才需要
pip install -U bitsandbytes

from airllm import AutoModel

MAX_LENGTH = 128

# 一行就能換模型，只需改 Hugging Face repo id
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3-70B-Instruct", hf_token="HF_TOKEN")

input_text = ["用三句話解釋什麼是分層串流推論。"]
input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,           # 有些 tokenizer 沒有 pad token，關掉最保險
)

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

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

第一次執行會做一件很花時間的事：把模型從 Hugging Face 下載後逐層切分（split）並存到磁碟。70B 模型大約要 30～60 分鐘，而且過程中同時存在原始檔與切分後的檔案，所以磁碟空間要準備模型大小的約兩倍。想省空間可以設定 delete_original=True，切分完成後自動刪掉原始下載檔。

開啟 4-bit / 8-bit 壓縮：最多 3 倍加速

# 4-bit block-wise 量化：磁碟讀取量減少，速度約 3 倍
model = AutoModel.from_pretrained(
    "meta-llama/Meta-Llama-3-70B-Instruct",
    compression="4bit",     # 或 "8bit"
    hf_token="HF_TOKEN",
)

這跟 llama.cpp 的量化不是同一件事：傳統量化要同時壓權重與啟動值才能真正加速，但 AirLLM 的瓶頸在磁碟載入，所以只需要把權重壓小，準確率更容易保住。70B 模型經 4-bit 壓縮後大約是 35GB 的磁碟佔用，載入速度明顯變快。

其他常用參數：

從推論到微調：6GB VRAM 訓練 125B 模型

2026 年 9 月的 v4 版本新增訓練支援，做法同樣是串流：凍結的基礎權重逐層從磁碟載入，只有 LoRA adapter 常駐 GPU。官方數據是 Qwen3.8-Flash-Next（125B）可在 6GB 以下訓練（RTX 3060 Ti），Qwen3.8-27B 在 seq 512 時約 2GB。

資料格式很單純，一行一個 JSON 物件（.jsonl）：

{"text": "第一份訓練文件，可以是幾句話或幾段文字。"}
{"prompt": "What is AirLLM?", "completion": "A library that runs and trains huge models on small VRAM."}

python air_llm/examples/train_qwen38_flash_next_lora.py \
  --data my_data.jsonl \
  --seq-len 512 \
  --epochs 1 \
  --save-adapter qwen38-flash-next-lora.pt

--steps N 可以只跑 N 筆做煙霧測試。要提醒的是：這不是 Hugging Face Trainer 或 bitsandbytes QLoRA 的替代品，Flash-Next 目前還需要裝含 qwen4_exp 的 transformers 開發版。

誠實的效能揭露：它有多慢

這是選用前一定要看清楚的段落。

換算成體感：產生 500 個 token 的回覆，可能要等 5～10 分鐘。Hacker News 上有人把 Kimi K3 的速度誤讀成「292 tokens/s」而興奮了一下，隨即被回覆糾正——這正好說明 AirLLM 的定位：它解決的是「能不能跑」的問題，不是「跑得快不快」的問題。

因此它適合的場景是：離線批次處理、研究驗證、深夜跑一份長文件摘要、教學示範「大模型內部長什麼樣」。不適合的場景是：任何形式的即時對話、多用戶服務、需要吞吐量的生產環境。

常見錯誤與排除

安裝前的硬體與環境檢查清單

AirLLM 對 GPU 的要求很低，但對「其他東西」的要求比一般推論高。開始前先確認這五項：

Mac 使用者也可以跑：只要安裝 mlx 與 torch，Apple Silicon 機種同樣適用同一段程式碼，底層改用 Metal 加速，策略仍是磁碟分層交換。

三個判斷問題，決定你要不要用 AirLLM

1. 你的回覆可以等 5 分鐘以上嗎？ 可以 → AirLLM；不行 → 改用 GGUF 量化或雲端 API。
2. 你要的是「跑得動」還是「跑得順」？ 跑得動 → AirLLM；跑得順 → vLLM／llama.cpp。
3. 你的磁碟是 NVMe 嗎？ 不是 → 先換硬碟，或放棄這條路線。

站內延伸閱讀

• GGUF 量化完整教學 2026：Q4_K_M、Q5_K_M、Q8_0 差在哪？VRAM 怎麼算？——同樣是「小 VRAM 跑大模型」，但走量化路線，速度正常得多
• colibri 教學：用純 C 引擎在本機跑 744B MoE 模型，16GB RAM 也跑得動——另一條極端路線，連 GPU 都不需要
• vLLM：具備 PagedAttention 的高吞吐量 LLM 推論引擎——當你要的是速度與吞吐量，該看的是這個
• Ollama：以類 Docker 簡潔風格在本機執行開源 LLM——日常本機推論最省事的起點

原始來源

• AirLLM GitHub 專案（README 與官方數據）
• AirLLM on PyPI（版本 4.0.0）
• Hacker News 討論：AirLLM 70B inference with single 4GB GPU
• Starlog：Running 70B LLMs on a 4GB GPU — How AirLLM Trades Speed for Accessibility
• arXiv 2212.09720（block-wise 量化方法論文）