已驗證至 2026.04.13

本地 LLM 選型指南

選擇主機類型與記憶體大小，立即找到最適合你的開源模型

精選模型

主機類型

記憶體級距

⬡ 選擇你的硬體

1主機類型

2記憶體大小

拖動滑桿選擇記憶體容量。

8 GB VRAM

請先選擇主機類型，再拖動滑桿設定記憶體大小。

⬡ 完整規格對照表

模型	架構	參數	最低記憶體	Context	授權	效能分	分層

⬡ 深度解析：記憶體管理原理

🪣VRAM 三桶模型：你的記憶體去了哪裡

VRAM 總佔用 = 模型權重 + KV Cache + 執行期開銷
─────────────────────────────────────────────────────────────
模型權重 ≈ 參數量（B）× 量化位元 ÷ 8 （GB）
KV Cache ≈ 2 × 層數 × KV頭數 × 頭維度 × 上下文長度 × 位元組
執行期 ≈ CUDA context 0.3–0.5 GB + activation 0.2–0.5 GB

以 Qwen 3.5 9B Q4_K_M 為例：權重約 5.8 GB，在 8K ctx 下 KV Cache 約 0.6 GB，執行期 ~0.5 GB，合計 ≈ 7 GB，恰好能在 8GB 顯卡上執行。但若你把 ctx 拉到 32K，KV Cache 膨脹至 2–3 GB，就會溢出導致崩潰。Context 長度是被最多人忽視的 VRAM 殺手。

⚠️MoE 常見誤解：節省的是算力，不是記憶體

錯誤觀念：「MoE 每次只用 3B 參數，所以只需要 3B 的 VRAM。」

正確理解：路由器在決定啟用哪個專家前，必須能存取全部專家的權重。Qwen 3.5 35B-A3B 雖然每次只活化 3B，但所有 35B 的權重都必須載入記憶體（需約 21 GB）。

MoE 的優勢是推論速度（每 token 計算量等同 3B）與知識容量（35B 的知識庫），而非節省記憶體。如果你的 VRAM 夠大，MoE 讓你用 8B 的速度得到 35B 的品質。

🆕 MoE 的救星：llama.cpp --n-cpu-moe

當 VRAM 不足以載入全部專家時，可以把「路由專家 FFN 層」卸載到 CPU RAM，只保留注意力層（Attention）在 GPU。速度約 3–8 tokens/s，比純 CPU 快 3–5 倍，但比全 GPU 慢許多。

# 把部分 MoE 專家層卸載到 CPU（適合 Qwen3.5-35B 在 16GB 顯卡）
llama-server --model qwen3.5-35b-a3b.gguf \
  --n-gpu-layers 99 \  # 注意力層全上 GPU
  --n-cpu-moe 20 \   # 20 個 FFN 專家層卸到 CPU
  -c 8192

📦KV Cache 壓縮：三層策略

策略	效果	代價
GQA 模型設計層	減少 50–75% Qwen 3.5 / Gemma 4 皆有	無（已內建）
KV Q8_0 --cache-type-k q8_0	再減 50% 品質幾乎無損	極小
KV Q4_0 --cache-type-k q4_0	再減 75% 組合可達 12.5%	複雜推理略降不建議 8B 以下
TurboQuant 🆕 2026.03 ICLR	壓縮 6× 3-bit 儲存	正在整合至 llama.cpp 尚未正式釋出

實際範例： Llama 3.1 8B（GQA 4x）+ KV Q8_0，32K context 的 KV Cache 從 16 GB 降至 2 GB，讓 8GB 顯卡也能跑長上下文。

⚡CPU 分流的速度代價

把層卸載到 CPU RAM 會造成嚴重速度損失，原因是 PCIe 頻寬瓶頸（PCIe 4.0 約 64 GB/s，遠低於 GDDR6X 的 1 TB/s）。

情境	速度
全部層在 GPU	40–200+ tokens/s
75% 在 GPU（部分分流）	~8–15 tokens/s
MoE FFN 卸到 CPU（--n-cpu-moe）	~3–8 tokens/s
純 CPU 執行	2–6 tokens/s

RTX 50 系 Blackwell 例外：改良的記憶體子系統讓部分分流的速度懲罰減少 30–40%，RTX 5090 在部分分流場景下明顯優於 4090。

原則：選一個完全裝得進 VRAM 的模型，永遠比強迫塞一個超過 VRAM 的模型更好用。

🍎Apple Silicon 特殊規則

Mac 統一記憶體讓 CPU 與 GPU 共用同一記憶體池，優勢是同預算可購得更大容量（如 Mac Mini M4 Pro 48GB 售價遠低於同等 VRAM 的獨顯工作站）。但同等 GB 數字下，Mac 可用空間比獨顯少（需扣除 35% 系統開銷），以下是關鍵規則：

可用模型記憶體 ≈ 統一記憶體 × 60–70%
─────────────────────────────────────────
16 GB → 約 10–11 GB 可用
24 GB → 約 14–17 GB 可用
48 GB → 約 29–34 GB 可用

其餘 30–40% 由 macOS、KV Cache、推論執行期佔用。超過此限制會觸發磁碟 swap，速度驟降至 <1 tokens/s。

🆕 Ollama 0.19 MLX 後端（2026.03）

Ollama 0.19 加入 MLX 原生後端，在 32GB+ Mac 上 decode 速度提升 約 93%（prefill 1154→1810 tokens/s，decode 58→112 tokens/s）。需 32GB 以上才啟用。

GGUF → Ollama / llama.cpp MLX → mlx-lm / Ollama 0.19+ AWQ/GPTQ → 不支援 Apple Silicon

M5 晶片在 MLX 下 TTFT 比 M4 快 4 倍（具備 Neural Accelerator 矩陣乘法單元）；token 生成速度受記憶體頻寬限制（M4: 120 GB/s → M5: 153 GB/s，快 28%）。

🔴AMD 顯卡：能跑但有坑

AMD RX 6000/7000/9000 系列透過 ROCm 支援本地 LLM，但有幾個重要限制：

項目	狀況
基本推論	可用 Ollama / llama.cpp
速度 vs NVIDIA	略慢同 VRAM 約慢 10–30%
NVFP4 量化	不支援僅 NVIDIA Blackwell
AWQ / GPTQ	部分支援需 ROCm 版本
vLLM	支援 --dtype fp8（ROCm）
模型訓練	不建議用 NVIDIA

推薦工具：Ollama（最簡單）或 llama.cpp hipBLAS 版。遇到 OOM 但 NVIDIA 同款不會的問題，通常是 ROCm 版本過舊，先嘗試 rocm-smi 確認驅動版本。

🔢量化格式速查：如何選

格式	大小比	品質損失	適用場景
Q2_K	18%	高	極限壓縮，不推薦
Q3_K_M	23%	明顯	最小化 VRAM，低精度
Q4_K_M	28%	極小	✓ 大多數用戶首選
Q5_K_M	35%	幾乎無	VRAM 充裕時升級
Q8_0	53%	無	最高品質本地版
F16	100%	基準	微調 / 研究

經驗法則：每 1B 參數在 Q4 下約佔 0.56 GB，Q8 下約 1 GB。模型文件大小加 1–2 GB 就是你需要的 VRAM 下限。

🛠️2026 推論工具選擇建議

Ollama

所有平台入門

一行指令、自動 VRAM 偵測、MLX 後端（Mac 0.19+）

LM Studio

Windows / Mac 圖形介面

視覺化 VRAM 監控、MoE 專家分流設定、Flash Attention

llama.cpp

進階調校、低階控制

--n-cpu-moe、--cache-type-k、最細粒度 VRAM 控制

mlx-lm

Mac 最高性能

MLX 原生，Apple Silicon 最快，支援 LoRA 微調

Ollama 多 GPU 限制：Ollama 不支援模型分割（model parallelism），一個模型只能綁一張 GPU。多 GPU 只能跑不同模型，或同模型多個實例做負載平衡。需要真正多 GPU 模型並行，請改用 llama.cpp 或 vLLM。