本章用「優先順序」而不是「對比表羅列」呈現，因為實際使用上 95% 的讀者只需要從前兩三個選一個；後面的選擇是給特定情境用的補充。先給結論再給推導，讀者可以快速看到結論、有空再回頭看為什麼。

本章目標

讀完本章後，你應該能：

1. 對自己的 Mac 規格，立刻知道該裝哪個模型。
2. 理解每個模型的能力強項與適用情境。
3. 看到新模型發表時，知道怎麼放進這個優先順序。
4. 看到「最強本地模型」這類排名時、用具體任務脈絡判讀。

優先順序總覽

對 32GB+ Mac 的讀者、建議的選型順序：

1. Gemma 4 31B MTP（首選）— 速度最快、coding 任務 MTP 加速 2 ~ 3 倍
2. Qwen3-Coder 30B（次選）— coding 專科、SWE-bench 表現最強的本地模型
3. Qwen3 14B（通用備案）— 較小較快、記憶體吃緊或要跑 long context 時切回來
4. gpt-oss 20B（OpenAI 開源）— 風格較像 GPT、想嘗試 OpenAI 風味時用

對 24GB Mac、跳過 31B、從 14B 起步。對 16GB Mac、可用模型限於 7B 或 Gemma 4 E4B、能力明顯下降、建議混用雲端。

1. Gemma 4 31B MTP：日常主力首選

Gemma 4 31B MTP 在「速度 × 能力 × 工具支援」三軸取得寫 code 場景的最佳平衡、是首選的原因。Gemma 4 31B 在 SWE-bench、HumanEval（OpenAI 提供的 164 題 Python 函式補完 benchmark）等 coding benchmark 上接近 Qwen3-Coder 30B、但因為 Google 釋出官方 MTP drafter、Ollama v0.23.1 一鍵整合、實際使用體感速度比 Qwen3-Coder 30B 快 2 ~ 3 倍（同硬體、同任務）。

Ollama tag：gemma4:31b-coding-mtp-bf16

記憶體需求：~18GB（含 drafter），32GB Mac 順暢、24GB Mac 吃緊。

能力範圍：

• 簡單 function 補完、改寫、加 type：強
• 寫 unit test、寫 docstring：強
• 解釋程式碼、提建議：中強
• 跨檔案重構：中等（仍輸雲端旗艦）
• 跟你討論架構設計：中等（會給合理方向但深度有限）
• 多步驟 agent 規劃：弱（雲端旗艦領先明顯）

為什麼選它而不是 Qwen3-Coder 30B：MTP 加速在寫 code 場景太明顯。Qwen3-Coder 在 benchmark 上略強，但實際工作流的「等模型回應」時間差會抵消那點 benchmark 差距。除非你的任務剛好命中 Qwen3-Coder 強過 Gemma 4 的部分（後面會說），Gemma 4 是更穩的預設。

2. Qwen3-Coder 30B：coding 專科

Qwen3-Coder 30B 是「benchmark 最強、速度次之」的本地 coding 模型、做為 benchmark 敏感工作流的次選。Qwen3-Coder 在 SWE-bench Verified（OpenAI 篩過的高品質子集、500 題）上達 77.2 分（2026 年 4 月 Alibaba 釋出時的公開數據）、是本地模型中 coding 表現最強的。對「複雜程式碼任務、不在乎速度差一倍」的使用者、這是更好的選擇。

Ollama tag：qwen3-coder:30b

記憶體需求：~18 ~ 20GB，32GB Mac 順暢。

Qwen3-Coder 30B 強項（JSON 結構穩定 / SQL Rust Go / 200+ 行 code / 演算法題）：

• 需要嚴格遵循 prompt 結構（例如要求輸出 JSON）— Qwen3-Coder 較穩定
• 需要寫 SQL、Rust、Go 等較少見語言 — 訓練資料較多
• 需要產出較長 code（200+ 行）— 比較不容易在中段失控
• 需要解 leetcode 風格演算法題（注重題目模式 + 標準解）— benchmark 強項

為什麼不是首選：MTP 加速目前限於 Gemma 4 官方 drafter、Qwen3-Coder 還沒有對應的官方 drafter（2026 年 5 月）。生字速度明顯慢於 Gemma 4 31B MTP、體感等候時間長。

3. Qwen3 14B：通用備案

Qwen3 14B 是 32GB Mac 想留記憶體餘裕（多 model 並存、長 KV cache、其他重 app）時的合理「降一級」選擇。能力較弱但記憶體佔用減半。

Ollama tag：qwen3:14b

記憶體需求：~10GB，24GB Mac 順暢、32GB Mac 留更多空間給 IDE 與系統。

能力範圍：

• 簡單 function 補完、加 type：尚可
• 解釋程式碼：尚可
• 寫 unit test：有時會錯
• 跨檔案重構：明顯弱於 31B 等級
• 複雜推理：明顯弱

主要使用情境：

1. 24GB Mac 的預設選擇。
2. 32GB Mac 但想留記憶體給其他重 app（如同時跑 Docker、跑大型測試）。
3. Tab autocomplete 的小模型（搭配主對話 31B 模型）。
4. 長 context 場景（KV cache 佔用較少）。

4. gpt-oss 20B：OpenAI 開源版

gpt-oss 20B 是 OpenAI 在 2025 年釋出的開源模型、風格較接近 GPT 系列、定位是「習慣 GPT 語感的使用者」的補充選項。如果你已經很習慣 GPT 的回答方式、這個模型的「語感」會比 Gemma 或 Qwen 親切。

Ollama tag：gpt-oss:20b

記憶體需求：~12GB，24GB Mac 起點可跑。

能力範圍：

• coding 表現中等，輸 Gemma 4 31B、Qwen3-Coder 30B。
• 一般對話、解釋、寫作風格較 polished。
• Tool use 支援較好（OpenAI 自家生態的優勢）。

主要使用情境：

1. 你已習慣 GPT 風格、不想換語感。
2. 寫 code + 一般對話混用（一般對話 gpt-oss 較自然）。
3. 24GB Mac 的進階選擇（比 Qwen3 14B 大、能力強，比 Gemma 4 31B 小、塞得進）。

16GB Mac 的選擇

16GB Mac 是現實上的最小可用配置。能跑的選擇：

實話：16GB Mac 跑這些模型只能做「簡單補完、解釋短段程式碼」、比較複雜的任務還是要切雲端。如果你想以本地 LLM 為主力寫 code、16GB 不在本指南推薦範圍；建議混用雲端、或評估升級到 24GB+ Mac。

48GB+ Mac 的選擇

48GB 以上記憶體可以跑更大模型，但邊際效益要考慮。可用選擇：

48GB Mac 的主要收益不是「跑得到更大模型」，而是「同時跑兩個 model」或「長 context 不卡」。例如同時跑 31B 主對話 + 4B autocomplete + 留空間給 IDE。

判斷新模型是否值得換的步驟

本地模型發布速度很快、每 2 ~ 3 個月會有新候選。判斷要不要換的步驟：

1. 看 SWE-bench Verified 分數：新模型在 SWE-bench Verified 上比現用模型高 5 分以上、值得試。
2. 看模型大小與記憶體預算：新模型大小落在 Mac 預算內、再進入下一步評估。
3. 看 speculative decoding 支援：有 drafter 的新模型在體感速度上常勝過稍強但沒加速的模型。
4. 用自己的 5 ~ 10 個日常任務當私人 benchmark：公開 benchmark 是參考、自己跑一遍才能拿到能用在自己場景的數字。
5. 看 Ollama / LM Studio 的 release notes：新模型要被伺服器支援、Ollama registry 已收錄的模型用起來最直接。

合理的更換節奏是一年 2 ~ 3 次主力模型。每換一次要重新適應它的語感、prompt 風格、體感速度、切換成本不算低；穩定下來再換、收益比追新發布每個都試大。

量化等級的選擇

對所有模型，量化等級的選擇大致一致：

量化等級的延伸判讀：

• Q8 / bf16 的回退條件：模型載入時 swap 到 SSD（生字速度掉一個量級）就要往下降一級。
• Q5_K_M 的回退條件：載入後 KV cache 跟 IDE 一起擠到記憶體上限、改 Q4_K_M。
• Q4_K_M 的回退條件：跑 coding 任務通過率明顯下降（基準 vs Q5 / Q8 下降 10% 以上）就換較小模型的 Q5、不再下降到 Q3。
• Q3 的觸發訊號：hallucination 上升、編造 API、長 context 累積誤差。寫 code 場景的具體判讀：Q3 31B 在 coding 任務上常輸給 Q5 14B、選 model size 時先看任務通過率、再用量化調記憶體、不是反過來。

適合寫 code 以外場景的模型

以下五類模型各自有專屬定位、跟「寫 code 主力」是不同的工作流；放在寫 code 主力位置會踩到能力錯位。每類各自有不同的判讀條件、用同一個欄位塞會遺失各自的失敗模式。

Llama 3.x base 等 base model

Base model 是純粹做下一個 token 預測訓練、沒做 instruction-tuning 的原始模型。直接拿來對話會跟著 prompt 隨機接龍、不會「回答你的問題」。適合下游 fine-tuning 跟研究；寫 code 場景改選同 family 的 instruction-tuned 版本（例如 llama3.3:70b-instruct 而不是 llama3.3:70b）。

純對話模型（Vicuna、ChatGLM 早期等）

純對話模型是 2023 年早期對話研究的成果、訓練資料偏自然對話、coding 表現遠輸後來的專科模型。早期教學示範或對話技術 baseline 仍會用到；現階段 coding 任務直接選 Qwen3-Coder 或 Gemma 4、不在這條路線上糾結。

多模態模型（Llava、Gemma 4 多模態版等）

多模態模型訓練資料含圖片 + 文字、能做圖片理解、UI 描述、OCR、圖文對應、適合「給 LLM 看截圖」這類工作流。寫 code 場景如果不需要看圖、改選同等級的純文字模型較省記憶體（多模態的 vision tower 佔額外 GB 級記憶體、純文字 coding 用不到）。

中文特化模型

中文特化模型在純中文寫作、客服場景表現好、但 coding 仍以英文 prompt + 英文 code comment 為主流。寫 code 用通用模型 + 英文 prompt 通常表現較穩、中文特化模型反而在英文程式碼相關任務上劣勢。除非工作流真的有大量中文 docstring / 註解需求、否則用通用模型。

「最新最強」測試模型

社群每週都有新模型釋出、號稱「跑分爆表」。日常主力建議等社群驗證 1 ~ 2 個月再採用、避免出「benchmark 強但 prompt 適應性差」「prompt 模板未進入主流工具預設」的事故。嘗鮮跟跑分是另一條工作流、用 LM Studio 探索性測試後再決定是否切主力。

模型不只 chat、還有 embedding

Continue.dev 的 codebase 索引功能要用 embedding model，這跟 chat model 是兩種不同的模型。常用 embedding：

1ollama pull nomic-embed-text

nomic-embed-text 約 274MB，記憶體佔用低，是 Continue.dev codebase 索引的好搭檔。其他選項：

Embedding 模型的選擇對 codebase 搜尋品質有影響，但邊際效益遠小於 chat model。先用預設 nomic-embed-text，有需求再換。

何時不適用本章優先順序

本章選型假設「Apple Silicon Mac + 寫 code 為主 + 個人使用」。以下情境的選型邏輯不同、需要另外的判讀路徑：

給讀者的最快決策路徑

決策表把記憶體預算跟用途摺成一張快查、依情境定位、不需要重讀整章：

決策表的兩個閱讀方式：先按「你的情境」找對應 model、再注意「觸發回退條件」決定何時切換到下一行。回退條件常被忽略、導致讀者在條件變化時還抱著原本的選擇。

下一章

下一章：1.5 期望管理，把本地 LLM 放在「免費的初階 pair programmer」這個正確位置，避免錯誤期待造成的挫折。

事實查核註：本章引用的模型名稱、能力等級、量化版本以 2026 年 5 月的社群可用資源為基準。模型發布速度快、3 ~ 6 個月後可能有新候選、本章建議用具體版本日期跟對應的官方 model card / 技術報告校準。

本章目標

1. 認識 PC 場景特有的「全載 Dense vs 卸載 MoE」選型軸。
2. 知道不同 VRAM 容量對應的候選模型清單。
3. 區分「coding 專用模型」跟「通用模型」對寫 code 任務的差異。
4. 知道量化版本的取捨（Q4_K_M / Q5_K_M / Q6_K 的選擇）。
5. 認識選型決策的觀察期跟換模型的時機。

PC 場景特有的選型軸

Mac 統一記憶體場景下、選型主要看「能不能塞進記憶體」。PC 場景多了 MoE 卸載這個變數、變成三軸選型：

1選型三軸：
2├── VRAM 是否能全載      → 決定是否需要卸載
3├── MoE vs Dense          → 決定卸載的代價大小
4└── coding vs 通用        → 決定能力對寫 code 任務的契合度

兩條典型路線（同樣 16GB VRAM）：

社群多數寫 code 場景的回報傾向「卸載 30B MoE 對任務成敗的幫助大於速度損失」、但工作流以高頻短補完為主的使用者、有時偏好全載 14B Dense 的速度。實際取捨需用自己的工作流任務校準。

16GB VRAM + 64GB RAM 的候選清單

這是 2026 年 5 月 PC 場景最常被討論的配置、對應幾個主要候選：

候選一：Qwen3-30B-A3B（MoE、卸載）

模型定位：MoE 架構、總參數約 30B、active parameter 約 3B、coding / 通用混合訓練。

啟動旗標起點（GGUF Q4_K_M、需配合 5.1）：

1llama-server -m Qwen3-30B-A3B-Q4_K_M.gguf \
2  -ngl 99 --n-cpu-moe 30 \
3  --cache-type-k q8_0 --cache-type-v q4_0 -fa \
4  -c 32768

主要使用情境：

1. 跨檔案重構、需要理解較多上下文的任務。
2. 長 context 場景（RAG、大型 codebase 索引）。
3. 中文 + 英文混合的 prompt。

候選二：Qwen3 14B（Dense、全載）

模型定位：Dense 架構、14B 參數、通用 + coding 混合訓練。

啟動旗標起點：

1llama-server -m Qwen3-14B-Q4_K_M.gguf \
2  -ngl 99 \
3  --cache-type-k q8_0 --cache-type-v q8_0 -fa \
4  -c 32768

主要使用情境：

1. 工作流以高頻短補完為主、對生字即時體感要求高。
2. 想保持較穩的 latency、避開 MoE 卸載的調參。
3. 系統 RAM 只有 32GB、卸載空間有限。

候選三：Qwen3-Coder 30B / CodeLlama 13B 等 coding 專用模型

模型定位：在通用訓練後、用 code corpus 做了額外的 instruction tuning 或 continued pre-training。

社群常見回報：

• 在「補完 / 行內編輯」這種純 code-completion 任務上、coding 專用模型通常表現較好。
• 在「需要解釋程式碼 / 設計討論」混合任務上、通用模型有時更自然。

選擇邏輯：若你的工作流以純補完為主、coding 專用模型是合理優先；若以 chat-based 設計討論為主、通用模型也許更合適。

量化版本的取捨

GGUF 量化版本對同一模型的選擇：

選擇邏輯：先用 Q4_K_M 起步、若品質符合需求且 VRAM 有餘量、可試 Q5 / Q6；若 VRAM 不足、優先考慮「換小一級的模型 + Q5/Q6」而非「同模型 + Q3」、因為品質衰減在小模型上較易感知。

24GB VRAM 的候選清單

24GB VRAM（如 RTX 4090、RTX 3090）能跑全載 32B Dense 或重度卸載 70B MoE：

選擇邏輯：24GB 是「Dense 32B 級」跟「MoE 70B 級」的分水嶺；多數寫 code 場景在 Dense 32B 級已能勝任、再往 70B 級的邊際效益依任務變化。

32GB VRAM 的候選清單

32GB VRAM（如 RTX 5090）能跑 70B Dense Q4 全載：

32GB VRAM 場景下、選型回到「能力 vs 生字速度」的傳統取捨、MoE 卸載這個變數的影響相對減弱。

8GB / 12GB VRAM 的候選清單

VRAM 較小的場景、候選清單較短：

8GB 場景下、本地 LLM 的「跑得起來但能力有限」需先設好期望、見 1.5 期望管理（跨平台共用）。

coding 專用 vs 通用模型

選型的另一條軸是「coding 專用模型 vs 通用模型」：

選擇邏輯：純補完場景優先 coding 專用；chat-based 工作流通用模型也許更合適；多數使用者可以用兩個（一個 coding 專用 + 一個通用）、依任務切換。

選型決策步驟

實際選模型時、可以照下面的步驟：

1. 盤點硬體：VRAM 容量、系統 RAM 容量、CPU 性能。
2. 盤點工作流：補完為主 vs 跨檔案任務為主、短 prompt 為主 vs 長 prompt 為主、純 code vs 設計討論混合。
3. 依 VRAM 級別查上面候選清單：選 1 ~ 2 個起點模型。
4. 用 Q4_K_M 量化版本起步：跑一週實測、用代表性任務記錄品質、速度、VRAM 用量。
5. 依瓶頸調整：
   • 品質不夠 → 試更大模型 / 更高量化等級 / 不同訓練取向
   • 速度不夠 → 試較小 Dense 全載 / 減少卸載
   • VRAM 不夠 → 加量化（Q5 → Q4）、加 MoE 卸載、量化 KV cache
6. 建立可重複的校準腳本：把代表性任務寫成 prompt 集、新模型來時跑一次回歸測試。

觀察期與換模型時機

社群常見的換模型節奏：

1. 新模型發布：本地 LLM 模型平均每 2 ~ 3 個月有新候選。
2. 觀察期：新模型剛發布時、量化版本可能不全、社群實測案例較少；建議等 2 ~ 4 週、看是否有 Q4_K_M / Q5_K_M 等常用量化、社群回報是否穩定。
3. 回歸測試：用自己的校準腳本跑一次、比較跟現有主力模型的品質、速度、VRAM。
4. 切換：明顯優於現有主力 + 校準腳本通過 + 旗標設定穩定 → 才切換。

過早跳到新模型的常見代價：量化版本不穩、社群 issue 還在湧現、自己的旗標設定要從頭調。

下一章

下一章：5.6 GPU 廠商差異、處理 NVIDIA / AMD / Intel 在 llama.cpp 生態的相對位置。