【2026 最新】本機 LLM 顯存怎麼選？8／16／24GB 模型、MoE、Context 決策樹

同樣寫著「30B」，為什麼有人用 24GB 顯存跑得順，有人 16GB 顯存加 64GB RAM 還像翻書一樣慢？問題通常不是你不會裝，而是把本機 LLM 顯存只算成模型參數量，漏了量化後的實際檔案、KV Cache、Context、workspace、視覺投影器與 CPU offload。

這篇不再重教 Ollama、llama.cpp、MLX 怎麼安裝；那是LLM 推論引擎教學的範圍。這裡只做一件事：給你一套能重算的容量方法，從 8／16／24GB、聊天／coding／Agent 三種工作負載，反推出值得下載的模型與 Context 起點。

這是寫給第一次挑本機模型的讀者，不必先懂量化或推論引擎。文中的 K 代表 1,024 個 tokens；模型下載檔沿用 repo 常見的十進位 GB，記憶體算例則標成二進位 GiB，避免把兩種單位混成同一個數字。

本機 LLM 顯存先說結論：容量先行，模型第二

• 能不能載入：看「權重 + KV Cache + runtime／系統餘量」，不是只看 8B、30B 或 A3B。
• 值不值得跑：再看速度與真實任務成功率。載入成功不等於 coding Agent 好用。
• MoE：容量先看總權重；active parameters 主要描述每個 token 啟用的部分計算。
• Context：模型卡寫 128K、256K 或 1M，不代表你的硬體能用同樣長度；prompt 與輸出共用窗口。
• 8／16／24GB 的保守起點：第一輪把實際量化權重檔上限抓在約 5–6／9–12／14–18GB，再用啟動紀錄校正；檔案更小只會留下更多空間。這是初篩規則，不是硬體保證。

整篇的錨點只有一條：

峰值記憶體 ≈ 權重 + KV Cache + compute／workspace + 系統餘量 + 額外模型。

視覺模型還要留 mmproj；draft model、adapter 與平行請求也會增加用量。

第一步：參數量只告訴你權重下限

最常見的心算是「參數 × 每參數位元 ÷ 8」。例如 30B 如果真的平均恰為 4-bit，權重約 15GB。它適合快速淘汰明顯裝不下的候選，卻不能當最終顯存需求。

原因是 Q4_K_M、IQ、GPTQ、AWQ、MLX 等標籤並不等價；GGUF 本身也是容器，不等於固定量化。縮放因子、混合 tensor 編碼、embedding 與 metadata 都會讓實際檔案偏離心算。llama.cpp 的官方量化範例中，Llama 3.1 8B 的 Q4_K_M 約為 4.58GiB、4.8944 bits per weight，已經證明「Q4」不是每個參數恰好四個 bit。

因此下載前第一個可用數字是你真的要抓哪些檔案、加總幾 bytes。多模態 repo 常把文字模型與 mmproj 分開；只看主 GGUF，之後開圖像功能就會突然多出一塊。

第二步：Dense 與 MoE 要讀不同的數字

Dense 稠密模型像一間所有部門都會處理每張訂單的公司；MoE 則有路由器，每個 token 只叫少數專家上工。這會降低單步計算量，卻不會把其他專家的檔案憑空刪掉。Hugging Face 的MoE 技術說明也明確把「所有 experts 的記憶體」與「每 token 的計算量」分開。

以 Qwen3.6-35B-A3B 為例，官方模型卡列的是 35B total、3B activated；官方 BF16 checkpoint 約 71.9GB，FP8 版本也約 37.5GB。它不是「3B 模型」。llama.cpp 的 expert offload 可以把專家權重移到 CPU，但只是改放置位置，不會把總 bytes 改成 3B。

第三步：Context 為什麼會吃光剩餘顯存？

模型生成下一個 token 時，會保留過去 token 的 Key／Value；這就是 KV Cache。對標準 full-attention Transformer，單一 sequence 可用下式估：

KV bytes ≈ 2 × layers × context tokens × KV heads
           × head dimension × bytes per element

假設 32 層、8 個 KV heads、head dimension 128、K/V 用 fp16、一次一條 sequence，8K／32K／128K Context 的 KV 約為 1／4／16GiB。這只是方便理解線性成長的標準範例；GQA、MQA、MLA、滑動或混合注意力、KV 量化與 backend allocator 都會改結果。Hugging Face 的Cache 說明也指出 KV 會隨 sequence length 成長。

另一個常漏的是並行量：兩條同時存在的對話，普通 KV 預算約變兩份；Agent 的工具輸出、檔案內容與錯誤紀錄，也都會進入 Context。這正是為什麼聊天能跑，換成AI Agent Harness長迴圈就 OOM。

8／16／24GB 本機 LLM 顯存怎麼分？

先不要問「最多幾 B」，先問你的工作負載。下圖把量化權重當成第一輪篩選，再把 Agent、視覺與多使用者往上一級估。這些區間是 AlphaLab 的保守起點；通過後仍要以固定 backend 的啟動紀錄驗收。

同一張卡，聊天、coding、Agent 是三種預算

聊天最容易控制：一條對話、固定 system prompt、沒有大量工具回傳。8GB 先用 4K～8K，通常比硬開 32K 更能保留較好的量化與輸出空間。長期知識不要全塞在聊天紀錄，可用摘要或檢索把相關段落送進來。

Coding不是 Context 越長越聰明。先提供 repo tree、錯誤訊息與真正相關的檔案，往往比一次貼完整 repository 有效；編譯產物、重複 log、lockfile 都應排除。若模型要改多個檔案，還要為 diff、測試結果與下一輪修正保留輸出空間。

Agent最容易膨脹：每次工具呼叫的參數、結果、錯誤與反思都會回到下一輪，平行分支還可能各自保留 KV。與其把 Context 上限拉到模型卡標稱值，不如先設工具輸出截斷、歷史摘要、最大迴圈與停止條件；這也是Context Engineering真正解決的問題。容量估算時，把 Agent 往上一級硬體或往下一級模型抓，通常比 OOM 後再補救省時間。

8GB：小模型 + 短 Context，目標是穩定

第一輪把文字權重檔上限抓在約 5–6GB。第一方可驗證例子中，Ministral 3 3B 的 Q4_K_M 主檔約 2.15GB；Gemma 4 E4B 的 QAT Q4_0 主檔約 5.15GB，視覺 mmproj 另約 0.99GB。前者留下較多 KV 空間，後者若連視覺一起開，在 8GB 就要縮短 Context。適合單輪聊天、摘要、單檔補全與短 patch；把整個 repo、測試輸出和長歷史一次塞入，通常先撞到容量而不是智力。

16GB：12B～14B Q4 的甜蜜點，大 MoE 是緊繃案

第一輪把權重檔上限抓在約 9–12GB。Gemma 4 12B 的官方 QAT Q4_0 主檔約 6.98GB；Ministral 3 14B Q4_K_M 主檔約 8.24GB，兩者都比硬塞 15GB 檔案更能保留 Context。OpenAI 的 gpt-oss-20b 是 MoE，官方 MXFP4 checkpoint 約 12.82GiB，官方把 16GB memory 列為最低門檻；所以 16GB 是「可測的緊繃下限」，不是放任長 Context 的舒適設定。

24GB：30B 級 Q4 開始實用，但別同時拉滿模型與 Context

第一輪把權重檔上限抓在約 14–18GB。Gemma 4 26B-A4B 的官方 QAT Q4_0 主檔約 14.44GB，視覺投影器另約 1.19GB；31B dense 主檔約 17.65GB，連投影器約 18.85GB，留給 KV 的空間明顯不同。另一個 coding／Agent 例子是Muse Glimmer 30B 本機教學裡的約 17GB 文字 GGUF。24GB 的價值不是「一定要塞最大」，而是可以在模型品質、Context 與 Agent 餘量之間做選擇。

截至 2026-08-13，模型名稱只當起點

如果你想要第一個候選，而不是永遠不會過期的冠軍榜，可從以下定位開始：

• 8GB 聊天／JSON：Ministral 3 3B 或 8B 的第一方 Q4_K_M；Gemma 4 E4B Q4_0 適合願意壓 Context 的使用者。
• 16GB 通用：Gemma 4 12B、Ministral 3 14B 的第一方 Q4；Agent／reasoning 可從 gpt-oss-20b 的短 Context 開始測。
• 24GB 通用：Gemma 4 26B-A4B 比 31B dense 留下更多餘量；若重視 coding，可評估官方稱能在單張 RTX 4090 運行的 Devstral Small 2 24B，但其官方 Mac 建議是 32GB RAM，不能直接外推到 24GB Mac。
• Qwen coding 路線：Qwen3.6-27B 等型號有明確 coding／Agent 定位；截至 2026-08-13，本文在 Qwen3.6-27B 官方 model repo 可直接核對的是 BF16 checkpoint。若採社群量化，必須多核對檔案、converter、chat template 與 backend。

「支援 tool calling」也只是模型能輸出工具格式，不代表你的 client、parser 與Agent loop自動相容。要比較 coding 模型，請固定 prompt、量化、Context、backend 與真實任務；不要用一個 benchmark 名次代替端到端驗收。

Apple unified memory 與 CPU offload 怎麼算？

Apple Silicon 的 unified memory 是 CPU 與 GPU 直接存取同一個記憶體池，不是「RAM 加 VRAM」，也不是同容量獨立顯存。OS、瀏覽器、IDE、wired memory 與模型會共用它。MLX 的官方說明解釋了這個共享機制；實機要同時看 Activity Monitor 的 Memory Pressure／Swap Used，或用 mlx.core.device_info() 查看建議 working set。

離散 GPU 的 CPU offload 則是把部分權重放到 system RAM。16GB VRAM + 64GB RAM 確實可能載入更大的模型，但每次推理仍受 PCIe／互連、CPU、RAM 頻寬和 backend 影響。它解決的是「塞不塞得下」，不是免費把 16GB 變成 64GB GPU。若互動速度是目標，寧可先選小一級模型、全 GPU 跑，再比較任務完成時間。

下載前 90 秒：一張本機 LLM 決策樹

1. 不下載，先查精確檔案

Hugging Face CLI 的 --dry-run 會列出檔名與大小。把 revision 換成模型 repo 的 commit SHA，避免同名檔案之後被替換：

MODEL_REPO='OWNER/REPO'
MODEL_REVISION='COMMIT_SHA'

hf download "$MODEL_REPO" \
  --include '*.gguf' \
  --revision "$MODEL_REVISION" \
  --dry-run

這個流程來自 Hugging Face 的官方下載文件。若 repo 是分片，必須加總你實際會載入的 shards；若要看圖，再把 mmproj 算進去。

2. 讀該型號的 config，不讀家族口號

• 是 Base 還是 Instruct／IT？聊天與工具使用通常要選後者。
• Dense 還是 MoE？若是 MoE，記 total、active、experts 與每 token 啟用數。
• num_hidden_layers、num_key_value_heads、head_dim 是多少？這些決定 KV 心算。
• Context 是原生、RoPE 延伸，還是 backend 能設定的上限？不要把三者混成品質保證。
• license、chat template、tool parser 與多模態投影器是否齊全？

3. 用短 Context 做一次端到端 smoke test

先用 4K 或 8K 啟動，觀察 log 裡的 model weights、KV、compute buffer、GPU layers 與 CPU/GPU split；穩定後再加到 16K、32K。llama.cpp 現行 CLI 可用 -ngl 控制 GPU layers，--fit 也會嘗試在記憶體限制內調整；Ollama 則可用 ollama ps 看 PROCESSOR 與實際 CONTEXT。

特別注意：截至 2026-08-13，Ollama 的 Context 專頁與 FAQ 對預設值仍有不同描述，所以不要背一個通用數字；直接看你本機 ollama ps 的 CONTEXT。這比照抄網路設定可靠。

七個常見坑：能啟動，不等於能工作

1. 把 active 當容量：35B-A3B 仍先看 35B 的實際權重。
2. 把 Q4 當固定四位元：量化 recipe 與架構會改整體 bpw。
3. 把最大 Context 當可用 Context：先扣輸出，再算 KV 與長距離品質。
4. 只算主模型：視覺 mmproj、adapter、draft model 都可能加碼。
5. 把標稱容量全交給模型：桌面、瀏覽器與 runtime 也要空間。
6. 只問 tokens/s：coding／Agent 還要量任務完成率、重試與工具格式。
7. 格式對就以為 backend 支援：架構、tokenizer、RoPE、chat template 與 tool parser 都要實際跑一輪。

本機 LLM 顯存 FAQ

8GB 顯存還值得跑本機 LLM 嗎？

值得，但要把成功定義成小模型、短 Context、單一任務。聊天、摘要、分類、JSON 與短補全都有實用空間；長 Agent loop 要主動裁掉工具輸出和歷史。

16GB VRAM + 64GB RAM 能跑 30B 嗎？

可能載入，但速度不能從容量推出。先查 exact quant，將一部分 layers offload 到 RAM，再用你的 PCIe、CPU 與 backend 測 prefill、decode 和完整任務時間。

24GB 能把 35B-A3B MoE 當 3B 跑嗎？

不能用 A3B 直接判斷。3B active 描述單步啟用量；能否載入要看 35B 總權重的實際量化檔、Context 與 backend 是否支援 expert offload。

Q4 一定比 Q8 快嗎？

不一定。Q4 通常較小，但解量化 kernel、硬體、batch、offload 與記憶體頻寬都會影響速度；同名量化也要固定 backend 版本再比。

模型標 256K，就應該直接設 256K 嗎？

不要。從 4K／8K smoke test 開始，逐級拉長並量 peak memory 與任務品質。Context 是 prompt + output 的共同預算，不是只給輸入。

24GB Apple unified memory 等於 24GB GPU 嗎？

不等於。它是 CPU、GPU、OS 與應用程式共享的一池記憶體；優點是可減少 CPU／GPU 間的顯式資料搬移，代價是模型沒有 24GB 專用額度。

跑本機 LLM，CPU 重要嗎？

全 GPU 時影響較小，offload 時會變重要。CPU 算力、RAM 頻寬與互連一起決定被 offload layers 的速度，不能只看 GPU 型號。

Ollama、llama.cpp、MLX 要選哪個？

先依平台與格式選，再用本文容量式驗收。想快速上手可看推論引擎比較；Apple 原生量化可優先研究 MLX，GGUF 與細緻 offload 可研究 llama.cpp。

給新手的五個重點

1. 先決定工作負載與 Context，再選模型。
2. 權重以實際檔案／shards 總和為準，參數位元公式只做初篩。
3. MoE 載入看總權重，active parameters 看每 token 啟用計算。
4. 8／16／24GB 先用 5–6／9–12／14–18GB 權重預算，再留 KV 與 runtime 空間。
5. 下載前 dry-run，下載後短 Context smoke test；最後才是長任務。

若你要把這套方法做成自己的 coding／Agent 工作流，可以到AlphaLab 課程練習 Context 控制、工具驗收與停止規則，也可在AI 專區追蹤新模型與 backend 更新。