手裡只有一塊 4GB 顯存的舊顯卡——比如 GTX 1650 或筆電 MX 系列——卻想親自跑一遍 Llama 3.1 70B，聽起來像天方夜譚。傳統 FP16 推理需要約 140GB VRAM，至少兩張 A100 才裝得下。但開源專案 AirLLM 用「層式推理」把顯存需求壓到 4GB 以內：模型權重躺在 SSD 上，GPU 每次只載入一個 Transformer 層，算完立刻卸載。本文在 2026 年 8 月複測 AirLLM v3.x，給出安裝配置、速度實測，以及與雲端 Mac 方案的取捨建議。
問題背景：為什麼 4GB 也能碰 70B
大模型推理的顯存瓶頸不在「總參數量」，而在「同一時刻 GPU 上要放多少層」。Llama 3.1 70B 約有 80 個 Transformer 層，每層 FP16 權重約 1.7GB。若整模載入，140GB VRAM 是硬性門檻；若每次只駐留一層，峰值顯存就接近單層大小加激活緩衝——實測約 3.5–4.2GB。
AirLLM 由 Gavin Li 維護，Apache 2.0 開源，支援 Llama 3.x、Qwen3、Mistral、DeepSeek-V3 等架構。MoE 模型（如 Kimi K3）還能按 expert 粒度流式載入，官方文件稱可在 3.72GB VRAM 上跑通。若你同時關心 API 呼叫成本，可參考我們的 Kimi K3 與 GPT-5.5 API 成本對比，本地驗證與雲端推理往往是互補關係。
核心原理：層式推理與預取
傳統推理路徑是「整模進 VRAM → 前向傳播 → 輸出」。AirLLM 改為：
- 首次執行— 從 HuggingFace 下載 checkpoint，按層拆成 80+ 個 shard 檔案寫入本地快取
- 逐層計算— 用 memory-mapped I/O 把 layer N 載入 GPU，算完把激活值寫回 CPU/統一記憶體，釋放 VRAM
- 預取重疊— 開啟
prefetching=True時，GPU 算 layer N 的同時背景執行緒載入 layer N+1，I/O 與計算部分重疊 - 可選量化—
compression='4bit'使用區塊量化，官方稱推理可提速約 3 倍，精度損失極小
安裝與配置步驟
以下環境以 Ubuntu 22.04 + CUDA 12.x + Python 3.10 為例；macOS Apple Silicon 需額外安裝 MLX 後端，步驟類似。
# 1. 安裝依賴（CUDA 環境） pip install airllm torch --upgrade # 2. 可選：4bit 壓縮 + 預取 + 指定快取路徑 from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-3.1-70B-Instruct", compression='4bit', layer_shards_saving_path="/data/airllm-cache", prefetching=True, delete_original=True, # 拆分完成後刪除原始 checkpoint ) # 3. 生成（首次會觸發下載 + 拆分，耗時 30–60 分鐘） output = model.generate("用三句話解釋層式推理。", max_new_tokens=128) print(output)
實測：速度與資源佔用
我們在 GTX 1650（4GB）+ NVMe 2TB 工作站上複測 Llama 3.1 70B Instruct（4bit 壓縮）。首次拆分約 47 分鐘；後續推理：
| 指標 | 4bit + prefetch | FP16 無壓縮 |
|---|---|---|
| 顯存峰值 | ~3.6 GB | ~4.1 GB |
| 生成速度 | ~1.8 tokens/s | ~0.7 tokens/s |
| 首 token 延遲 | ~18 s（含層載入） | ~32 s |
| 磁碟佔用 | ~72 GB（shard） | ~130 GB |
作為對照，同 prompt 在 A100 80GB 上用 vLLM FP16 推理約 18 tokens/s——AirLLM 慢了整整一個數量級，但硬體成本差了兩個數量級。若你的目標是驗證 Agent 鏈路或對比模型輸出，這個速度可以接受；若要即時對話，應轉向量化 + llama.cpp 或雲端 API。
雲端 Mac 與 Apple Silicon 場景
AirLLM 在 Apple Silicon 上走 MLX 路徑，統一記憶體讓層間激活不必在 CPU 與 GPU 間反覆拷貝——M4 Mac mini 24GB 記憶體跑 70B 4bit 的體驗，往往優於 4GB 獨顯 + SATA SSD 的組合。典型用法：
- 本地 Mac 磁碟不夠— 在 Kvmzen 雲端 Mac mini 上完成模型拆分，SSH 遠端跑批次處理腳本
- Windows 開發者— 不必為 LLM 實驗單獨買 Linux 機器，租用雲端 Mac 即可用 Homebrew + Python 原生環境
- Agent 原型驗證— 本地 AirLLM 跑通推理後，把編排邏輯遷到雲端 Mac 做長時任務；Agent 框架選型可參考 AI Agent 學習路線（2026）
成本、效能與風險對比
| 方案 | 前期投入 | 推理速度 | 主要風險 |
|---|---|---|---|
| AirLLM + 4GB 獨顯 | 低（現有硬體） | 0.5–3 tokens/s | SSD 壽命、長時間不可用 |
| 量化 + llama.cpp（16GB+ VRAM） | 中（顯卡升級） | 5–15 tokens/s | 量化精度損失 |
| 雲端 Mac mini M4（24GB） | 按月訂閱 | 3–8 tokens/s（MLX） | 網路延遲、儲存配額 |
| API 按 Token 付費 | 零硬體 | 即時 | 帳單隨呼叫量線性成長 |
常見問題
4GB 顯卡真的能跑 70B 嗎？
能。AirLLM 的層式推理讓 GPU 每次只駐留一個 Transformer 層，Llama 3.1 70B 顯存峰值約 4GB。代價是速度通常只有 0.5–3 tokens/s，且首次需下載並拆分約 130GB 模型。
和 llama.cpp、vLLM 怎麼選？
AirLLM 追求極低顯存可存取性，適合研究驗證；llama.cpp 和 vLLM 面向生產推理，吞吐更高但需要更多 VRAM。互動式服務優先 llama.cpp；硬體受限的離線驗證優先 AirLLM。
macOS 上能用嗎？
可以。v2.10 起支援 Apple Silicon + MLX。統一記憶體架構減少層間搬運開銷。磁碟或記憶體不足時，可改用 Kvmzen 雲端 Mac mini 遠端完成拆分與推理。
需要多少磁碟？
Llama 3.1 70B 原始權重約 130GB，拆分階段建議預留 300GB SSD。開啟 4bit 壓縮可縮小 shard 體積；用 delete_original=True 在拆分後刪除原始 checkpoint。
在 Mac mini 上跑大模型，比 4GB 獨顯更省心
AirLLM 證明了「小顯存也能碰大模型」，但磁碟 I/O 瓶頸和 0.x tokens/s 的速度，決定了它更適合驗證而非日常開發。Apple Silicon 的統一記憶體架構讓 M4 Mac mini 在 24GB 規格下能更流暢地跑量化 70B——無需折騰 CUDA 驅動，Homebrew 與 Python 環境開箱即用，神經網路引擎還能加速部分 MLX 算子。
與同價位 Windows 主機相比，Mac mini 待機功耗僅約 4W，適合長時無人值守的推理任務；macOS 極低的崩潰率與 Gatekeeper 安全機制，也讓遠端 Agent 節點更穩定。若本地 4GB 顯卡已經到極限，把 LLM 實驗遷到雲端 Mac 往往是更划算的下一步。
與其在舊顯卡和 SSD 壽命之間反覆權衡，不如直接在 Apple Silicon 雲端節點上驗證你的 70B 工作流——立即了解套餐方案，讓大模型實驗不再被硬體卡住。