讀完本章後、你可以對自己這台 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 的判讀。

讀完本模組後、你應該能對自己這台 PC 直接回答：能跑哪些模型、要不要卸載 MoE 專家層到 RAM、KV cache 該量化到哪一級、context 能開多大、併發數能拉到多少。

為什麼 PC 路線值得獨立模組

Mac 統一記憶體的判讀模型把「能載入多大模型」這個問題收斂到一塊預算。PC 場景被獨立 VRAM 拆成兩個記憶體區域、判讀軸增加：

1. VRAM：高頻寬區。常見消費級 NVIDIA 卡的廠商標稱頻寬大致落在數百 GB/s 到 1 TB/s 級的區間（例如 RTX 5060 Ti 16GB 標稱約 448 GB/s、RTX 5070 Ti 標稱約 896 GB/s、以廠商規格表為準）、生字速度上限主要受 VRAM 頻寬影響。
2. 系統 RAM：高容量區。DDR5 6000 雙通道的標稱頻寬約 96 GB/s（依主機板與時序變化）、相對 VRAM 慢約一個量級、但 64GB / 128GB 在 PC 平台的擴充成本相對低、適合放容量需求大但存取頻率較低的權重。
3. PCIe：兩個區域之間的連線。PCIe 5.0 x16 廠商標稱單向約 64 GB/s（PCIe 4.0 x16 約一半）；實際傳輸吞吐受驅動、檔案系統與工作流影響。

這三層差異產生兩個 Mac 場景上較少出現的工程選項：

1. MoE 模型 + 專家層 CPU 卸載：MoE 模型每個 token 只啟用少數專家、把不活躍的專家權重放在系統 RAM、用到再走 PCIe 拉回 GPU。讓 16GB VRAM 卡能載入 30B / 70B 等級的 MoE 模型。
2. KV cache 量化開大 context：把 K cache 量化到 Q8、V cache 量化到 Q4、KV cache 體積大幅壓縮、騰出的 VRAM 可用於開大 context window 或提高併發數。

這兩個選項在 Mac 統一記憶體場景下較少使用（VRAM 跟 RAM 共用、不需在兩個區域之間搬資料）、在 PC 場景則是常用的調參工具。

章節列表

跟模組一的對應關係

最短路徑：16GB VRAM + 64GB RAM 跑 Qwen3 30B MoE

事實查核註：本模組引用的硬體規格、模型體積、社群實測數量級、廠商工具鏈成熟度、皆以 2026 年 5 月的公開資訊與社群常見回報為基準。GPU 規格、driver 版本、llama.cpp release、模型釋出與量化版本快速演進、引用前請以 llama.cpp release notes、各廠商官方規格表、各模型 Hugging Face model card 為準、並用 llama-bench 或實際工作流校準。

如果你有類似 RTX 5060 Ti 16GB / 5070 Ti 16GB + 64GB DDR5 的配置、想用一小時搞定 PC 本地 LLM 寫 code、下面是最短路徑：

 1# 1. 裝 llama.cpp 的 CUDA build（Windows / Linux 各有預編好的 release）
 2# 從 ggml-org/llama.cpp GitHub release 抓 CUDA 12.x 版
 3
 4# 2. 抓一個 MoE 模型（如 Qwen3-30B-A3B 的 GGUF Q4_K_M 版本）
 5# 從 Hugging Face 下載到 ~/models/
 6
 7# 3. 啟動 server、把 30 層 MoE 專家層卸載到 CPU
 8./llama-server \
 9  -m ~/models/Qwen3-30B-A3B-Q4_K_M.gguf \
10  -ngl 99 \
11  --n-cpu-moe 30 \
12  --cache-type-k q8_0 \
13  --cache-type-v q4_0 \
14  -c 32768 \
15  --port 8080
16
17# 4. 在 VS Code 裝 Continue 擴充套件、config 指向 http://localhost:8080

關鍵參數的意義先濃縮成一句、詳細推導留給 5.3 llama.cpp 在 PC 上：

• -ngl 99：把所有可放的層丟到 GPU。
• --n-cpu-moe 30：把 30 層的 MoE 專家權重留在系統 RAM、不上 VRAM。實際層數視模型結構與 VRAM 餘量微調。
• --cache-type-k q8_0 / --cache-type-v q4_0：KV cache 量化、騰出 VRAM 開大 context。
• -c 32768：context window。配上 KV cache 量化、單卡 16GB 通常能開到 128K ~ 256K（看模型）。

為什麼這個順序

本模組章節順序的設計脈絡：

1. 先 5.0 VRAM + RAM 分層預算：建立 PC 硬體判讀模型、是後面所有章節的前提。
2. 再 5.1 MoE 卸載：MoE + CPU 卸載是 PC 場景相對 Mac 的核心優勢、先把這個工程選項說清楚。
3. 接 5.2 KV cache 量化：跟 5.1 一起決定 VRAM 怎麼切、是 PC 場景的第二個獨有選項。
4. 再 5.3 llama.cpp 在 PC 上：把前三章的理論落地到實際參數。
5. 再 5.4 LM Studio 在 Windows：給「不想直接面對 CLI」的讀者另一條路、補上 GUI 內對應 5.1 / 5.2 設定的位置。
6. 然後 5.5 模型選型：所有工程選項都建立後、回答「具體裝哪個模型」。
7. 最後 5.6 GPU 廠商差異：選好模型跟參數後、再處理 NVIDIA / AMD / Intel 的工具鏈差異。

不在本模組內的主題

本模組不討論：

1. 多卡 NVLink、tensor parallelism：消費級 PC 場景通常單卡、多卡分散式推論屬於資料中心級教材。
2. 資料中心級 GPU（H100 / H200 / B200）部署：本模組聚焦消費級 PC、不涵蓋 vLLM / TGI / Triton 等資料中心 inference server。
3. Linux 系統管理 / CUDA 驅動安裝細節：假設讀者已會基本系統管理；具體驅動安裝步驟交給 NVIDIA / AMD 官方文件。
4. 訓練 / fine-tuning：跟「跑現成模型」是不同工程問題、見 模組三 與其推薦課程。
5. 產圖模型：Diffusion 跟 Transformer 是不同架構、見 ComfyUI / Stable Diffusion 專門教材。