讀完本章後、你可以對自己這台 PC 直接回答：能跑哪些模型、要不要做 MoE 卸載、KV cache 該量化到哪一級、context 能開多大、系統 RAM 容量該不該升級。

本章目標

讀完本章後、你應該能：

1. 看 PC 規格（VRAM + RAM）立刻知道能跑哪一級的模型、需不需要卸載。
2. 理解為什麼 16GB VRAM + 64GB RAM 跑 30B MoE 比跑 14B Dense 全載 VRAM 划算。
3. 判讀 KV cache 量化跟 context 長度的權衡。
4. 判斷自己這台 PC 適不適合跑本地 LLM、瓶頸在 VRAM 還是 RAM。

PC 記憶體預算的基本算式

PC 跑本地 LLM 的預算拆成兩塊、各有自己的容量上限：

1VRAM = 顯卡記憶體（GDDR6/7）= 高頻寬區
2  └── 通常需放：當前活躍模型層 + KV cache + 推論中間結果
3
4系統 RAM = 主機板上的 DDR4/5 = 高容量區
5  └── 可以放：MoE 不活躍專家層（透過 --n-cpu-moe）、暫存權重、context cache
6  └── 通常需保留：作業系統 + 應用程式 + GPU driver pinned memory
7
8PCIe = 兩塊預算之間的橋
9  └── 5.0 x16 廠商標稱單向約 64 GB/s、模型載入時較常成為瓶頸、推論時通常較少

兩塊預算各自的估算原則（具體數值依硬體世代、廠商規格與驅動版本而變化、本章引用的數字以廠商規格表為主、實際吞吐受系統配置影響）：

1. VRAM 容量：決定能放多少模型層。Dense 模型若要生字快、所有層都該在 VRAM；MoE 模型可以只放「共用層 + 部分專家」、其餘走 RAM。
2. VRAM 頻寬：影響生字速度上限。常見消費級 NVIDIA 卡的廠商標稱頻寬（向廠商規格表查驗）大致落在數百 GB/s 到約 1 TB/s 級的區間（如 RTX 5060 Ti 16GB 標稱約 448 GB/s、RTX 5070 Ti 約 896 GB/s）；生字 t/s 約等於「VRAM 頻寬 ÷ 模型每 token 讀取的 bytes」、但實際吞吐還受 CUDA backend、量化方式與 batch size 影響。
3. 系統 RAM 容量：影響 MoE 卸載與多模型併存的彈性。對 16GB VRAM 卡而言、64GB DDR5 通常足以支撐重度 MoE 卸載、128GB 對多模型併存或長 context cache 更從容、32GB 則會限縮可卸載的層數。
4. 系統 RAM 頻寬：影響卸載到 CPU 的層走多快。DDR5 6000 雙通道的標稱頻寬約 96 GB/s（依主機板、CMK 模組與時序變動）、相對 VRAM 慢約一個量級、所以卸載層數要跟可接受的生字速度損失一起調。
5. PCIe 頻寬：模型載入時通常是瓶頸、單人推論時較少成為主要瓶頸（除非每 token 都需要把大量卸載權重拉回 VRAM）。

PC 配置與可運作模型對照

下表整理 2026 年 5 月常見消費級 NVIDIA GPU 加上不同 RAM 容量、可運作模型的數量級對照。體感標籤是社群常見回報的相對描述、實際因 llama.cpp / Ollama 版本、CUDA backend、模型量化版本、--n-cpu-moe 設定與工作流類型而變動、需自行實測校準。

讀這張表要注意四件事：

1. 「全載 VRAM」跟「卸載」是兩種選型。全載生字較快但模型較小、卸載生字較慢但能跑較大模型；MoE 結構讓兩者的速度差距小於 Dense 模型。
2. 量化等級可以調整。16GB VRAM 跑 30B MoE Q4 比跑 30B MoE Q5 留下更多 VRAM 餘量、給 KV cache 跟併發數使用。
3. RAM 容量影響選型。32GB RAM 配 16GB VRAM 時、可卸載層數有限、能跑的最大 MoE 規模受限；64GB RAM 配 16GB VRAM 通常足以支撐 30B 級 MoE 的重度卸載。
4. 多卡升級建議在單卡跑穩後評估。雙 GPU 在 llama.cpp 上要設定 tensor split、實際速度提升依模型與配置變化；消費級主機板的 PCIe lane 分配（常見一條 x16 + 一條 x4）也會影響多卡效益。建議先把單卡跑熟、再依瓶頸決定是否多卡。

為什麼 16GB VRAM + 64GB RAM 常被列為寫 code 場景的合理起點

這個配置（RTX 5060 Ti 16GB / RTX 5070 Ti 16GB + 64GB DDR5）在 2026 年 5 月的 PC 本地 LLM 社群裡、常被作為「寫 code 用途」的價格效能比合理起點。對應的判讀軸有四條：

1. 30B 級 MoE 模型在多數寫 code 任務已能勝任。Qwen3-30B-A3B 等 MoE 模型在公開 coding benchmark 上的回報（如 Qwen 官方技術報告、社群 SWE-bench 跑分）顯示表現接近大型 Dense 模型；具體分數依任務類型、prompt 設計與評測版本變動、需參考各模型官方文件或 SWE-bench 卡片。模型總參數與 active parameter 是兩個獨立軸、影響記憶體需求跟生字速度上限。
2. MoE 卸載讓 16GB VRAM 能載入 30B 級模型。把約 30 層 MoE 專家權重留在 RAM、其餘放 VRAM、Qwen3-30B-A3B Q4 量化下整套模型總記憶體約落在 18 ~ 22GB 區間、其中常見約 12 ~ 14GB 在 VRAM（實際依模型結構與 --n-cpu-moe 設定變化）。
3. KV cache 量化能在剩餘 VRAM 開大 context。模型權重放好後、剩餘 VRAM 配上 K=Q8 / V=Q4 的 KV cache 量化、社群常見回報能開到 128K ~ 256K 級 context（依模型 attention 配置變化）、寫 code 場景的長 prompt 較少需要截斷。
4. 零件可分次採購、後續可升級。相對 Apple Silicon 整機綁定配置、PC 零件（GPU、RAM、CPU、儲存）可分次採購與升級；具體零件價格依在地市場、世代與促銷波動、本文不引用具體幣值。

下表是社群討論中常被提及的兩張同代 16GB 卡的相對對照、用意是「同樣 16GB VRAM 但頻寬不同對 throughput 的影響」、不是嚴格 benchmark：

兩張卡的差異主要在 VRAM 頻寬（廠商標稱接近 2 倍）、不在 VRAM 容量。對「同樣的模型能否載入」沒影響、對「生字多快」影響較大。實際 throughput 因驅動版本、模型量化方式、--n-cpu-moe 設定與 prompt 長度而變動、需自行用 llama-bench 或實際工作流校準。

事實查核註：表中 prefill / 生成的具體數字是社群討論中常見回報的相對數量級、不是經本文系統實測的 benchmark。VRAM 頻寬以 NVIDIA 廠商規格表為主、實作上會被 GDDR 模組廠商、PCIe 版本、CUDA backend 版本影響。引用前請以最新官方規格表跟 llama.cpp 官方 benchmark 為準。

社群常見回報的三個觀察點（同樣需以自身配置實測校準）：

1. --n-cpu-moe 數值往上加（如從 20 加到 30）、單張卡的 VRAM 佔用降低、可開的 context 上限拉大、但生成速度也會下降；具體下降幅度依模型 active parameter 比例變化。
2. KV cache 量化（K=Q8 / V=Q4）相對 fp16 KV cache 體積大幅壓縮、能換取更大 context 上限；寫 code 場景的補完品質影響社群多數回報為小幅或不明顯、但會視 prompt 長度與任務類型而異。
3. 系統 RAM 從 32GB 升到 64GB 後、可卸載的 MoE 層數上限明顯提高、能跑的最大模型規模也跟著拉開；具體層數依模型結構而定。

對應的 PC 配置面向（2026 年 5 月、不引用具體幣值）：

• 價格優先：RTX 5060 Ti 16GB + 64GB DDR5 + 中階 CPU（如 AMD 9900X / Intel 14700K）+ 1TB NVMe。
• 生字速度優先：RTX 5070 Ti 16GB + 64GB DDR5 + 中階 CPU。VRAM 容量跟 5060 Ti 相同、頻寬規格接近兩倍。
• 跑得了 70B 級：RTX 4090 24GB / RTX 5090 32GB + 64GB ~ 128GB DDR5。

若你正準備組新機主要為了跑本地 LLM 寫 code、16GB VRAM + 64GB RAM 是社群常見的合理起點；具體選哪張卡、視預算上限與對生字速度的要求而定。

MoE 卸載 vs 全載 Dense 的選型差異

PC 場景有 Mac 沒有的選型變數：同樣 16GB VRAM、要跑「全載 14B Dense」還是「卸載 30B MoE」？

兩條路線的差異：

判讀原則：寫 code 場景下、模型能力對任務成敗的影響通常比生字速度更顯著；30B 模型能完成的跨檔案任務、生字較慢仍可能勝過 14B 較快但解不出來的情況。若工作流以高頻短補完為主、對生字即時體感要求高、14B Dense 全載仍是合理選擇。實際取捨建議用一週實測校準。

KV cache 量化與 context 的權衡

VRAM 預算扣掉模型權重後、剩下的空間主要給 KV cache。KV cache 跟 context 長度大致成正比、長 context 場景的 VRAM 限制跟 Mac 統一記憶體場景類似、但 PC 多了「量化 KV cache」這個工程選項。

下表為 KV cache 體積的數量級估算（依模型 attention head 數、hidden size、量化策略變化、實際值需用工具測量、本表用於說明量化前後的比例變化）：

KV cache 量化在寫 code 場景的體感判讀有三條社群常見回報的原則（具體影響因模型、量化版本與工作流而變、需自行實測校準）：

1. K（key）對量化容忍度通常較高：key 用來計算 attention score、本質是相對量級的比較。社群多數回報指出 K=Q8 相對 fp16 在補完品質上差異不明顯、可作為較安全的起手量化等級。
2. V（value）對量化敏感度集中在長 context 末尾：value 是被加權平均的內容、量化誤差會累積進輸出。短 prompt（< 32K）下 V=Q4 跟 fp16 的差異多為小幅；長 prompt（128K+）的對話末尾、社群回報偶爾觀察到「對前文細節記憶較模糊」的情形、但對跨檔案 code 補完任務影響社群多數回報為小。
3. 品質影響在 coding 跟自由創作場景不同：寫 code 的輸出空間受語法 / 型別 / 編譯限制、KV cache 量化的小幅誤差較容易被約束過濾；自由創作（小說、詩、長對話）對 V 量化較敏感、社群回報品質差異較明顯。

實務上、K=Q8 / V=Q4 是 PC 場景開大 context 的常見組合；若觀察到長 prompt 末尾的回答品質下降、可考慮把 V 升回 Q8 或 fp16（代價是 VRAM 佔用上升、context 上限會縮短）。

具體調參邏輯詳見 5.2 KV cache 量化策略。

系統 RAM 容量在 PC 場景的角色

Mac 統一記憶體只有一個容量數字、PC 多了「VRAM」跟「系統 RAM」兩個獨立數字。PC 場景的預算分配若全部投入 VRAM、可能忽略系統 RAM 對 MoE 卸載策略的支撐角色。

系統 RAM 在本地 LLM 場景的主要用途（具體佔用量依工作流變化）：

1. 作業系統 + 開發工具：Windows / Linux + VS Code + 瀏覽器、常見佔用約 8 ~ 16GB。
2. GPU driver pinned memory：NVIDIA driver 為了 PCIe DMA 會固定一塊系統 RAM、依驅動版本與配置常見約 1 ~ 2GB。
3. MoE 卸載的專家權重：跑 30B MoE 卸載多數專家層、所需 RAM 落在 10 GB 級以上；跑 70B MoE 重度卸載通常需要數十 GB 級。具體數字依模型結構與 --n-cpu-moe 設定變化。
4. 多模型併存：同時跑 coding model + embedding model + 翻譯模型、每個各佔數 GB 級。
5. page cache / 系統暫存：Linux 會把剩餘 RAM 用於 page cache、模型 reload 時可加速。

對 16GB VRAM 配置而言、64GB RAM 通常足以支撐重度 MoE 卸載、是社群常見的起點容量。32GB RAM 配 16GB VRAM 在重度 MoE 卸載場景容易吃緊、可卸載層數會受限；視工作流類型、32GB 也可能足夠跑全載 Dense 模型。

PCIe 頻寬的角色

PCIe 在「載入模型」階段較常成為瓶頸、單人推論時通常不是、但 MoE 卸載會讓 PCIe 在推論時也參與資料流：

1. 模型載入時：PCIe 5.0 x16 廠商標稱單向約 64 GB/s（PCIe 4.0 x16 約一半）、實際走完磁碟 → RAM → VRAM 整條路徑的吞吐通常較規格低、模型載入時間視 NVMe 讀取速度、檔案系統與量化格式變動。常見差異在啟動秒數、推論階段一般感受不到。
2. MoE 卸載推論時：每 token 啟用的專家層權重需透過 PCIe 從 RAM 拉到 VRAM。以 Qwen3-30B-A3B 為例、每 token 啟用約 3B active parameter；若部分專家層在 RAM、每 token 需透過 PCIe 拉部分權重。單人推論場景下、相對 PCIe 5.0 x16 的可用頻寬佔比通常較小、社群多數回報不是主要瓶頸；併發數高或卸載比例極大時會逐漸顯現。
3. 多卡推論：多卡 tensor parallel 會密集走 PCIe / NVLink。消費級 GPU 普遍不支援 NVLink、訊息走 PCIe；多卡的吞吐縮放比社群回報相對單卡 + MoE 卸載的線性度差、需依工作流評估。

實務上、單卡 + MoE 卸載場景下 PCIe 較少成為主要瓶頸；多卡或極端卸載比例下、PCIe lane 分配（如主機板的 x16 + x4 配置）會明顯影響可達吞吐。

給讀者的決策表

看完上面的對照後、可以照下表做決策：

釐清需求類型：個人使用 vs 服務多人

初次接觸本地 LLM 時、常見的疑問是「是不是要 H100 / H200 等資料中心級配置才能跑」。實際上資料中心級配置的設計目標是大規模並發推論服務（同時對許多 client 出 token）、跟單人寫 code 的需求側重不同。釐清需求類型後、硬體選擇會清楚很多。

三條判讀軸：

1. 能載入的模型大小主要受 VRAM 容量影響、跟 GPU 算力等級沒有單一對應關係。16GB VRAM 配 MoE 卸載可載入 30B 級 MoE 模型；資料中心級 GPU 容量更大、能載入更大的 Dense 模型、但對個人寫 code 場景的能力提升不一定線性。
2. 生字速度上限主要由 VRAM 頻寬影響。消費級高階卡（如 RTX 5070 Ti、4090、5090）的頻寬已足以支撐單人寫 code 場景的補完即時體感、實際差異依模型量化、context 長度與 backend 變化。
3. 大量並發推論才需要資料中心級配置。單人開 VS Code 跟 LLM 對話、通常不會用到資料中心的並發優勢。

對應的決策路徑：先確認需求是「個人寫 code」還是「服務多人」、再選 16GB VRAM + 64GB RAM 級的起點配置、實測一週觀察模型能力是否符合任務需求、再依痛點選擇升級方向（VRAM 容量、頻寬、或多卡）。

升級到能跑 70B 級之前、建議先確認痛點是「模型能力不夠」還是「生字速度不夠」。本地 30B MoE 在多數寫 code 任務上已能勝任、社群多數使用者回報不是每個工作流都需要 70B 級模型；具體判斷需用自己的任務實測。

下一章

下一章：5.1 MoE 模型與 CPU 卸載策略、深入 --n-cpu-moe 的判讀。

概念位置

各家 GPU 對應的常見 backend（2026 年 5 月狀態、依社群實踐變化）：

選 backend 的判讀依硬體跟平台：NVIDIA GPU 用 CUDA、AMD on Linux 優先 ROCm、AMD on Windows 多用 Vulkan、Intel ARC 用 Vulkan 或 SYCL、Apple Silicon 用 Metal。

事實查核註：上表的「llama.cpp 生態成熟度」是社群常見回報、不是經本卡系統實測的 benchmark；各 backend 的支援度跟 throughput 依推論軟體版本快速演進、引用前以對應 backend 的官方文件跟 llama.cpp release notes 為準。

設計責任

理解 GPU compute backend 後可以解釋三個現象：為什麼下載 llama.cpp release 要選 CUDA / ROCm / Vulkan 版本（每個 build 對應一種 backend）、為什麼同樣硬體 throughput 差很多（backend 不對或 fallback 到 CPU）、為什麼非 NVIDIA GPU 跑 LLM 經驗較少（CUDA 生態太成熟、其他 backend 仍在演進）。

選 PC GPU 跑本地 LLM 時、backend 成熟度是「工具鏈支援度」軸、跟硬體規格軸獨立、選卡時兩軸都要考慮。詳見 5.6 GPU 廠商差異。

概念位置

NVLink 在多卡推論場景的角色：

1. tensor parallel：把一個 transformer 層的 weight 切到多張卡、每 token 計算時需要卡間同步、卡間頻寬影響直接。
2. pipeline parallel：把不同層分到不同卡、卡間需要傳 activation、頻寬要求中等。
3. 資料分發：把不同 request 分到不同卡（data parallel）、卡間流量低、PCIe 也夠。

頻寬對照（廠商標稱、依世代變化）：

NVLink 比 PCIe 高一個量級、是資料中心多卡推論的關鍵；消費級 RTX 場景多卡通常只能走 PCIe、縮放效益相對受限。

事實查核註：NVLink 各世代的頻寬數字依 NVIDIA 官方規格、不同 GPU 跟世代有差異；NVLink 在哪些消費級 / 工作站 / 資料中心 GPU 可用、依時段跟廠商策略變化、引用前以 NVIDIA 官方產品頁 跟對應 GPU 的 datasheet 為準。

設計責任

理解 NVLink 後可以解釋兩個現象：為什麼資料中心多卡 LLM 推論能線性 scale（NVLink 頻寬足以做 tensor parallel）、為什麼消費級雙卡 RTX 推論縮放比通常低於線性（沒 NVLink、走 PCIe x4 / x8、卡間頻寬限制）。

選消費級 GPU 跑本地 LLM 時、NVLink 不是常見選項；多卡升級的判讀應該基於「能否容忍縮放比低於線性」、而不是預期 NVLink 等級的卡間頻寬。詳見 5.6 GPU 廠商差異。

概念位置

PCIe 在本地 LLM 推論的兩個階段角色不同：

1. 模型載入階段：模型權重從 SSD → 系統 RAM → 走 PCIe → VRAM。PCIe 是常見瓶頸、影響「啟動時間」、不影響推論。
2. 推論階段：
   • 全載 VRAM 場景：權重已在 VRAM、推論時 PCIe 流量很少。
   • MoE 卸載場景：每 token 從系統 RAM 拉專家權重經 PCIe、PCIe 頻寬成為次要瓶頸。

PCIe 版本跟頻寬（廠商標稱、單向）：

實際傳輸吞吐受驅動、檔案系統、量化格式影響、通常低於規格上限。

事實查核註：PCIe 各版本的標稱頻寬數字以 PCI-SIG 官方規格為主、實際可達吞吐依硬體配置變化、引用前以對應版本的官方規格文件為準。

消費級主機板的 PCIe lane 分配常見「一條 x16 + 一條 x4」、加第二張 GPU 時、第二張的有效頻寬可能只有 x4、影響多卡縮放效益。詳見 5.3 llama.cpp 在 PC 上 的多卡 tensor split 段落。

設計責任

理解 PCIe 後可以解釋三個現象：為什麼模型載入要等幾秒到十幾秒（PCIe 是橋）、為什麼單卡 + MoE 卸載通常不卡 PCIe（每 token 拉的權重量小於 PCIe 頻寬）、為什麼雙卡縮放比沒有直接翻倍（PCIe lane 跟主機板配置）。

選 PC 配置時、PCIe 版本影響模型載入體感、但對單人推論的生字速度通常影響小。多卡升級前要看主機板的 PCIe lane 分配。

概念位置

VRAM 同時影響「能載入什麼」跟「跑多快」兩個維度：

1. 容量（GB）：決定能放多少模型權重 + KV cache + 推論中間結果。容量不夠則跑不起來、需透過 MoE CPU 卸載 把部分權重放系統 RAM。
2. 頻寬（GB/s）：影響每 token 生成速度上限、見 memory bandwidth 卡片。

常見消費級 GPU 的 VRAM 規格（廠商標稱、依世代與型號變化）：

VRAM 容量是選 GPU 跑本地 LLM 的第一決策軸、頻寬是第二決策軸。同容量下、頻寬接近 2 倍的卡（如 5070 Ti 對 5060 Ti）生字速度差異明顯。

事實查核註：上表是 2026 年 5 月主流消費級 NVIDIA GPU 規格的數量級對照、實際 VRAM 容量、頻寬、GDDR 版本依特定型號、廠商 / SKU、製造時間變化、引用前以 NVIDIA 官方規格頁 為準。

設計責任

理解 VRAM 後可以解釋三個現象：為什麼同樣 16GB 容量、不同卡的生字速度差很多（頻寬不同）；為什麼 MoE 模型在 16GB VRAM 上跑得了 30B 級模型（透過卸載）；為什麼 PCIe 頻寬在 PC 場景影響 MoE 卸載的速度（系統 RAM 跟 VRAM 之間的橋）。

選 PC 規劃本地 LLM 時、VRAM 容量決定能跑的模型上限、VRAM 頻寬決定生字速度上限、系統 RAM 容量決定 MoE 卸載空間。詳見 5.0 VRAM + RAM 分層預算。

Apple Silicon Mac 跑本地 LLM 的核心限制是記憶體大小、而非 CPU 或 GPU 算力。記憶體決定能載入多大的模型；模型載得進、推論才有得跑（生字速度則由 memory bandwidth 決定、見 0.1）。本章把「24GB 能跑 70B」這類含糊說法、換成可操作的記憶體預算判讀。

讀完本章後，你可以對自己這台 Mac 直接回答：能跑哪些模型、要用什麼量化、要留多少給系統、風扇會不會狂轉、什麼時候該升級。

本章目標

讀完本章後，你應該能：

1. 看 Mac 規格立刻知道能跑哪一級的模型。
2. 理解量化等級跟模型大小的乘積為何決定可行性。
3. 為「給系統留多少記憶體」這件事設一個合理上界。
4. 判斷自己這台 Mac 適不適合跑本地 LLM。

記憶體預算的基本算式

跑本地 LLM 的記憶體預算大致拆成三塊：

1總記憶體 = 系統與其他 app（保留）+ 模型權重 + KV cache + 推論中間結果

各塊的估算原則：

1. 系統與其他 app：至少留 8GB 給 macOS、VS Code、瀏覽器與其他工作流程。重度多工建議留 10 ~ 12GB。
2. 模型權重：用「參數規模 × 每權重 bits / 8」算出 bytes。其中「Q4」代表每個權重佔 4 bits。例如 31B 模型 Q4 量化 = 31 × 4 / 8 = 15.5 GB、加上 metadata 與 overhead 約 16 ~ 18GB。
3. KV cache：跟 context 長度成正比。短 context（< 2K tokens）約 0.5 ~ 1GB、長 context（10K+ tokens）可能超過 5GB。
4. 推論中間結果：通常 1 ~ 2GB。

實際留給模型的可用記憶體 = 總記憶體 − 系統保留（8GB）− KV cache（2 ~ 5GB）− 推論 overhead（2GB）。

Mac 記憶體與可運作模型對照

下表是 2026 年 5 月、Apple Silicon Mac 在 Q4 量化下的可運作模型對照。預設 Q4 是因為它是 31B 等級寫 code 場景的甜蜜點、下節「為什麼 32GB 是寫 code 場景的甜蜜點」會展開原因。所有體感標籤都假設「主要用途是寫 code」、純文字對話的甜蜜點會往較小模型偏。

讀這張表要注意四件事：

1. 體感是 coding 場景。純對話、寫文章、解釋程式的記憶體門檻較低。
2. 量化等級可以調整。32GB 跑 31B Q4 順暢、跑 31B Q5 也行（吃 21GB 左右）；跑 70B Q3 會崩潰，因為 70B Q3 約 26GB，加上 KV cache 跟系統，超過 32GB。
3. fanless 機種要打折。MacBook Air 系列因為散熱被動，跑大型模型 5 分鐘後會降頻，實際生字速度比有風扇的同代機器低 30 ~ 50%。
4. 記憶體不是 SSD。Apple Silicon 的「統一記憶體」是 RAM、不是 SSD swap。雖然 macOS 會 swap、但 swap 後生字速度會慢一個量級以上、實質喪失互動可用性。

MoE 與 dense 模型在記憶體預算上的差異

Mixture of Experts（MoE） 模型跟 dense 模型的記憶體 / 速度判讀方式不同、Gemma 4 26B A4B 這類 MoE 模型在上表「24GB Mac」一格出現時、容易讓人誤以為跟 14B dense 同等的記憶體需求。實際差異：

判讀重點：MoE 的記憶體需求看「總參數」、但速度看「啟用參數」。同記憶體預算下 MoE 通常跑得比 dense 快、但能力強度比較需配合具體 benchmark 判讀、名義參數僅作初步篩選。PC 獨立 GPU 上的 MoE 部署策略（CPU 卸載專家層）見 MoE CPU 卸載卡片。

為什麼 32GB 是寫 code 場景的甜蜜點

32GB Mac 跑 Gemma 4 31B（Q4 + MTP）是 2026 年 5 月寫 code 場景最佳的價格效能比，原因是三個趨勢的交會：

1. 31B 模型剛好能力夠用。Gemma 4 31B / Qwen3-Coder 30B 在 SWE-bench 等 coding benchmark 上的表現大幅超越 14B 模型，接近 GPT-4 mini 等級。14B 等級的模型在跨檔案任務上仍經常失誤。
2. Q4 量化在 31B 上的品質衰減仍可接受。Q4 在 7B 模型上品質衰減明顯，但 31B 模型有「參數冗餘」，Q4 反而是甜蜜點。
3. 32GB 剛好夠 18GB 模型 + 8GB 系統 + 6GB 其他。再小（24GB）跑 31B Q4 會吃緊；再大（48GB）邊際效益降低，除非要跑 70B。

對應的 Mac 機型（2026 年 5 月可購）：

• MacBook Pro 14 / 16 with M4 Pro / Max，32GB 配置。
• Mac mini M4 Pro，32GB 配置（最便宜的進入點）。
• Mac Studio M4 Max，32GB 起跳。

如果你正準備買新 Mac 主要為了跑本地 LLM 寫 code、32GB 在 [預算敏感、單機、Gemma 4 31B 為主] 通常是最划算的起點。16GB 在 [>14B 模型 / 多工] 會被擠到 swap、48GB+ 在純寫 code 場景超過甜蜜點、但對 [長 context coding agent / 70B 模型] 仍有實際價值。

16GB Mac 的可行策略

16GB Mac 是現實上的最小可用配置。能跑的最大實用模型是 Gemma 4 E4B（Google 的 8B 級實驗版本）或 Qwen3 7B。體感上：

1. 同時開 VS Code + Chrome + Slack 跟跑模型會擠到 swap、整台 Mac 變慢；建議跑模型時關掉其他重度 app。
2. 模型品質明顯弱於 31B 等級。簡單 function 補完還行、跨檔案重構交給雲端旗艦更划算。
3. 適合「偶爾用本地、主要還是雲端」的混用策略。

如果你的 Mac 是 16GB，先用 Gemma 4 E4B 試試看，評估自己工作流是否真的需要本地 LLM。多數情況下答案是「雲端 API 月費比換 Mac 便宜」。

KV cache 與長 context 的記憶體陷阱

模型權重佔的記憶體是固定的，但 KV cache 隨 context 長度線性增加。長 context 場景的記憶體陷阱常被忽略。

接近真實的估算（Gemma 4 31B、Q4 量化）：

陷阱是把 context 長度設到模型支援的上限（如 32K、128K）卻沒算 KV cache 成本。32GB Mac 跑 31B 模型，實際可用 context 大約只有 8 ~ 16K tokens；超過就會 swap，速度崩潰。

解法：

1. 短 prompt 場景（compact code completion）：完全沒問題，多數設定都在 2K 以下。
2. 中等 context（4 ~ 16K）：32GB Mac 仍可運作，但要留意 KV cache 吃多少。
3. 長 context（16K+）：考慮 oMLX 的 paged SSD KV cache（把 KV cache 部分頁面換出到 SSD、換取較長 context、代價是 TTFT 與生字速度略增）。詳見 0.4 MLX / MTP / oMLX。

風扇、發熱與降頻

Apple Silicon Mac 跑本地 LLM 會持續滿載 CPU / GPU。實際體感：

對「全天候用本地 LLM」的工作流，桌機型（Mac mini、Studio）比筆電好。筆電上跑長時間推論還要考慮電池與發熱對手部舒適度的影響。

按情境選機型決策表

決策表把前面三個變數（手上預算 / 想跑的 model size / 主要用途）摺成一張快查、依情境定位、不需要重新讀整章。詳細的模型選型考慮見 1.4 模型選型優先順序。

陷阱是把 96GB+ 配置當成「未來證明」。模型架構演進可能讓現在的記憶體預算明年就不重要（例如 1-bit 量化、新的稀疏架構）。買超大記憶體前先確認有具體現有需求支撐；「以後可能跑得到 100B+ 模型」這類期待風險很高。

下一章

下一章：0.6 判讀本地 LLM 資訊的五個框架、把心智模型轉成判讀資訊的反射。