AirLLM 讓 70B 模型跑在 4GB 顯卡上　無需量化、蒸餾或剪枝就能榨乾 VRAM

編按：本文綜合整理自 AirLLM GitHub Repo、HuggingFace 官方部落格、Hacker News 討論串（49154228）與 Medium 技術解析（rohit-shirke），並加入 Siami 編輯部觀點與分析。

一套名叫 AirLLM 的開源函式庫最近在 Hacker News 衝上 94 分，36 則留言，作者 Gavin Li（lyogavin）宣稱：不需要量化、蒸餾、剪枝等任何會犧牲模型品質的手段，就能把 70B 等級的大語言模型塞進單張 4GB VRAM 的顯卡。同一份程式碼也已經能跑 Llama 3.1 405B（8GB）、DeepSeek-V3 671B（約 12GB），甚至連目前已知最大的開源模型 Kimi K3（2.8 兆參數） 都能壓在 4GB 以內。

核心原理：逐層推論 + 預取

傳統 LLM 推論時，模型權重一次全部塞進 VRAM。以 70B 模型為例，僅 FP16 權重就要約 130GB，因此通常需要兩張 A100 80GB 同時上場。AirLLM 反其道而行，把模型一層一層從磁碟載入 GPU、做完運算、再立刻釋放掉 VRAM，再載入下一層。

對 Transformer 架構來說，每一層其實是「前一層輸出 → 這一層計算 → 下一層輸入」的線性關係。推論時同一時間只需要一層在 GPU 上，剩下的 79 層可以躺在磁碟裡。每一層的 VRAM 用量大約只有 1/80 的模型大小，也就是 70B 模型在 4GB 顯卡上剛好跑得動。

整個策略可拆成三個關鍵機制：

Layer-wise Inference（分層推論）：把「整模型進 VRAM」改成「一次一層進 VRAM」。70B 切成 80 層後，VRAM 需求 ≈ 1.6GB，剩下的就是 KV cache。
Prefetching（預取）：在 GPU 算當層的同時，從磁碟預先把下一層讀進主記憶體，把磁碟 I/O 跟 GPU 計算重疊。官方宣稱可帶來約 10% 速度提升。
稀疏 MoE 串流（per-expert streaming）：對 DeepSeek-V3、Kimi K3 這類 MoE（Mixture of Experts）模型，每個 token 真正用到的專家只是全部專家的一小部分，所以一次只需要把那幾個專家載入 VRAM。Kimi K3 雖然總參數高達 2.8 兆，VRAM 卻只需 3.72GB。

v3.0 開始加入的 FP8 權重 + block-wise 量化 可以額外帶來最高約 3 倍速度提升，根據官方說法「幾乎不會影響模型品質」，因為瓶頸在磁碟讀取而非運算，所以只需壓縮權重、不必動到 activation。

各模型 VRAM 對照表

AirLLM 官方 README 列出的硬體需求如下，這也是 HN 討論串上最常被引用來對照的部分：

模型	參數量	所需 VRAM
Qwen3 / Mistral / Phi（約 8B）	8B	約 1–2 GB
Qwen3-30B / Mixtral（MoE）	30–47B	約 1–3 GB
Qwen3-235B（MoE）	235B	約 3 GB
Llama 3.x 70B（FP16）	70B	約 4 GB
Llama 3.1 405B	405B	約 8 GB
DeepSeek-V3	671B	約 12 GB
Kimi K3（MoE）	2.8T	< 4 GB

程式碼只要一行：model = AutoModel.from_pretrained("lyogavin/...")，不需要任何特殊設定。HF Hub 上的模型 ID 直接餵進去就能用。

Kimi K3 的支援是 2026 年 7 月才剛加入的更新（v3.1.0），用 RTX 6000 Ada（48GB VRAM）端到端量測，3.72GB VRAM 即可。為了相容 Kimi K3 還有幾個額外要求：必須安裝 compressed-tensors 與 flash-attn（K3 的 model code 強制要求 flash attention）、需要 CUDA 12 版的 torch（CUDA 13 還沒有 prebuilt wheel）、以及 transformers 4.56.x（5.x 載入不了 K3 的 remote code）。

真實代價：速度

「每個 token 要 292 秒。」——這是 HN 留言區被推最多的數字。

討論串上討論最熱烈的點不是「能不能跑」，而是「跑多慢」。HN 留言區最高分的回應直接引用 v3.1.0 release：Kimi K3 在 RTX 6000 Ada（48GB VRAM）上每個 token 要 292 秒。這代表即使 VRAM 降到位，吞吐量（throughput）也會被磁碟頻寬與層切換成本壓在地上磨。

另一位 HN 用戶 hatthew 質疑的核心也是這一點：

跟直接用 unsloth 量化權重 + llama.cpp 加 -cmoe / -mmap 比起來，速度跟品質到底差在哪？

這也是為什麼另一則留言 ilaksh 開玩笑總結的真實使用情境：「也許你有一台稍微過時的 Mac 或 PC，就是想用一週的時間生出幾封還算像樣的垃圾郵件，這種 latency 完全可以接受。」

也就是說：AirLLM 不是 llama.cpp 的競爭者，而是它的補充。前者用「時間換空間」、後者用「精度換空間」。對於個人開發者、邊緣裝置、批次離線任務，AirLLM 有不可取代的位置；對於需要低延遲對話的應用，純量化版本仍是唯一選項。

為什麼這件事重要

雲端 GPU 的供需失衡（Hacker News 上有人直接稱之為 rampocalypse）已經把 80GB 等級的 H100 / A100 價格推到中小團隊難以負擔的區間。OpenAI、Google、Anthropic 都在搶同一批產能，獨立開發者、學術研究者、新創團隊面臨的不是「要不要用雲端」，而是「搶不搶得到」雲端。

AirLLM 把 VRAM 需求從 130GB 壓到 4GB，等於把「需要一張 80GB H100」變成「只要 4GB 顯卡就能跑」。這背後的意義不是單純省錢，而是把 LLM 推論的硬體門檻打回 2018 年那種「普通遊戲顯卡就能玩」的水位。任何一台 2019 年後的 MacBook、任何一張 RTX 3060 筆電，現在都能本地跑 70B 模型。

從開源社群的角度看，AirLLM 的 GitHub Star 數、Kimi K3 與 DeepSeek-V3 的第一時間整合，顯示這個專案不是「一次性展示」，而是真的有被認真維護。但 HN 留言區的質疑同樣值得重視：分層推論不是魔法，磁碟 I/O 與 KV cache 仍然會卡住吞吐量。這條「用時間換空間」的路徑是否能量產，仍有待觀察。

數據解讀與質疑

AirLLM 官方資料有幾個值得單獨拿出來檢視的數字：

「無損推論」：官方強調「不需要 quantization、distillation、pruning」就能省 VRAM。嚴格說沒錯——原始權重完全沒被修改。但實際上 prefetching、block-wise 量化、KV cache 切換、MoE 專家選擇等最佳化都在背景跑，硬體資源使用模式跟「完全原貌推論」已經不同。對大多數人而言，輸出品質幾乎等價；對少數研究可重現性敏感的場景，要自己評估。
「幾乎不影響品質」 的 4bit / 8bit 壓縮：速度提升 3 倍、誤差「可忽略」。但 AirLLM 沒有放出完整的 perplexity / benchmark 對照表，僅引用一篇 block-wise quantization 的 paper。對需要嚴格品質保證的應用（醫療、法律、財經），建議自行跑 eval。
292 秒/token 的 Kimi K3 數字：這是 HN 用戶從 release notes 引用，AirLLM 官方也沒否認。對照 GPT-4 等級雲端模型通常 50–200 token/秒，差距大約是 10⁴ 到 10⁵ 倍。對話型應用完全不可用；批次離線、可中斷的 workload 才適合。
磁碟空間：把模型完整下載到磁碟是必要步驟。70B 模型約 130GB；405B 約 800GB；K3 約 5–6TB。README 明確說「請確保 HF 快取目錄有足夠磁碟空間」。雲端空間費用也該算進 TCO。
維護疑慮：HN 留言區 roger_ 的擔憂並非沒有道理——「vibe coded projects」在 AI 開源圈確實氾濫。但 AirLLM 從 2023 年 11 月發布到 2026 年 8 月，跨三個年頭仍持續更新（2026/06 v3.0、2026/07 v3.1），GitHub 上也有 issue / PR 往來，至少目前還算「活的」。

Siami 觀點：AirLLM 的意義不在「讓 70B 模型變快」，而在「讓 LLM 推論的硬體底線下移到 4GB」。這對開源生態、邊緣 AI、個人開發者都是實質的進展；但對「想要對話級延遲」的場景，純量化推論（llama.cpp、vLLM、TensorRT-LLM）仍是不可取代的選項。兩者不是競爭、而是互補。

安裝與入門

pip install airllm

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
# 想更大也行，VRAM 自動處理：
# model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")  # 671B, ~12GB
# model = AutoModel.from_pretrained("lyogavin/...")             # Kimi K3, <4GB

input_tokens = model.tokenizer(
    ["台灣的首都位於哪裡？"],
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,
)
output = model.generate(
    input_tokens["input_ids"].cuda(),
    max_new_tokens=128,
    use_cache=True,
    return_dict_in_generate=True,
)
print(model.tokenizer.decode(output.sequences[0]))

首次執行時，AirLLM 會先把模型分層存到 HF cache 目錄（layer_shards_saving_path 可改路徑）。若要啟用額外加速，可加 compression="4bit" 或 compression="8bit"，但需要 bitsandbytes 套件。Apple Silicon 只要另外安裝 mlx 即可使用，作者提供專用 notebook。