讀完本模組後、你應該能對自己這台 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 專門教材。

事實查核註：GPU 工具鏈的支援度依 driver 版本、llama.cpp release 與廠商策略快速演進、本章描述為 2026 年 5 月的社群常見回報、建議引用前查閱對應 backend 的官方文件、llama.cpp release notes 跟自己硬體的實測。

本章目標

1. 知道 NVIDIA CUDA、AMD ROCm、Intel SYCL、跨平台 Vulkan 各自的成熟度。
2. 認識「工具鏈支援度」相對「硬體規格」對本地 LLM 體驗的重要性。
3. 在選卡時、能用「工具鏈 × 規格 × 預算」三軸做判讀。
4. 認識常見的混合場景（雲端 + 本地）。

NVIDIA CUDA：當前生態預設

NVIDIA GPU + CUDA backend 是 2026 年本地 LLM 社群的事實預設。原因不是「規格最好」、而是「工具鏈最成熟」：

1. llama.cpp CUDA backend 開發最久、PR 跟 issue 數量最多：新功能（新量化、flash attention 改進、speculative decoding 等）通常先在 CUDA backend 落地。
2. driver 跟 CUDA toolkit 對齊明確：driver 版本對應 CUDA 版本的表清楚、出問題容易查。
3. 社群實測案例多：Reddit、HuggingFace forum、GitHub issue 上、絕大多數 benchmark 跟調參討論基於 CUDA。
4. 上層工具（Ollama、LM Studio）優先支援：新版本通常先 CUDA、再 Vulkan、再 ROCm。

社群常見回報的 NVIDIA 卡分級（依 VRAM 容量為主、寫 code 場景）：

選卡時的常見軸：

1. VRAM 容量決定模型上限：16GB 起步可跑 30B MoE 卸載、24GB 跑 32B Dense、32GB 跑 70B Dense。
2. VRAM 頻寬決定生字速度上限：同 VRAM 容量下、頻寬接近兩倍的卡（如 5070 Ti 對 5060 Ti）生字速度通常顯著差。
3. CUDA compute capability：影響某些優化能否啟用、新世代卡通常有額外指令支援。
4. driver 長期支援：較新世代卡的 driver 支援週期通常較長、適合長時間用。

AMD ROCm 與 Radeon

AMD GPU 在 llama.cpp 生態的位置：ROCm backend 在演進、Vulkan backend 是跨平台 fallback。

ROCm backend

ROCm（Radeon Open Compute）是 AMD 的 GPU 計算平台、定位類似 CUDA。社群常見回報的當前狀態：

1. Linux 支援度較 Windows 成熟：ROCm 在 Linux 上發展時間較長、Windows 版本相對年輕。
2. 支援 GPU 清單：ROCm 對「官方支援」的 GPU 清單有明確限制、清單外的卡也許能跑、但走 unsupported 路徑。
3. llama.cpp ROCm build 跟 CUDA build 的功能差異：多數核心功能跨 backend 一致、新功能 cherry-pick 速度通常稍慢於 CUDA。
4. 效能對比：同價格段、AMD 卡的 VRAM 容量有時較大；但生字速度依模型跟設定變化、社群回報的 NVIDIA / AMD 對比結果不一致、需自己硬體實測。

Vulkan backend

Vulkan 是跨平台 GPU API、llama.cpp 的 Vulkan backend 適合：

1. AMD GPU on Windows：ROCm Windows 不穩或不支援時的選項。
2. Intel ARC：見下節。
3. 跨平台 fallback：希望同一份 binary 跑在多種 GPU 上。

社群常見回報：Vulkan backend 的 throughput 通常較同硬體的 CUDA / ROCm backend 低、但通用性高。

選 AMD 卡的判讀

Intel ARC

Intel 的獨立 GPU 系列 ARC（A 系列、後續預期 B 系列）在 llama.cpp 生態仍處於相對年輕的階段：

1. 可用 backend：Vulkan（通用）、SYCL / OpenVINO（Intel 特化）。
2. VRAM 容量：ARC A770 16GB 的 VRAM 容量在價格段內競爭力較強。
3. 工具鏈成熟度：社群實測案例較 NVIDIA / AMD 少、預期需要較多自己摸索。
4. driver 演進：Intel ARC driver 在 2026 年仍持續演進、不同版本的 throughput 可能差異較大。

選 Intel ARC 的合理情境：

1. 想試「相對冷門但價格友善」的選項。
2. 已有 Intel 平台、想保持廠商一致。
3. 不介意花時間自己調工具鏈設定。

對「想最快跑起來、最少調參」的使用者、ARC 不是最順的選擇。

工具鏈 × 規格 × 預算的判讀框架

選卡時的三軸框架：

1工具鏈支援度（CUDA > ROCm > Vulkan > SYCL）
2  ×
3硬體規格（VRAM 容量 + VRAM 頻寬 + CUDA core / CU 數量）
4  ×
5預算（含後續電費、機殼散熱、電源升級）

判讀順序：

1. 先確認工具鏈支援度符合自己的折騰意願：怕折騰選 NVIDIA、樂於折騰可考慮 AMD / Intel。
2. 再依預算選 VRAM 容量級別：16GB 起步、24GB 進階、32GB 旗艦。
3. 同容量下選頻寬較高的卡：對生字速度影響直接。
4. 預留升級空間：機殼散熱、電源、PCIe lane 配置會影響後續多卡或換卡的選擇。

雲端 + 本地的混合場景

本地 LLM 不必獨自解決所有任務、雲端 + 本地的混合是社群多數使用者的實際做法：

社群常見的混合做法：本地跑 30B 級 MoE 處理日常補完、跨檔案重構或設計討論切到雲端旗艦。Continue.dev 等工具支援同時設定多個 model、可以快速切換、見 1.3 VS Code + Continue.dev 整合。

給讀者的選卡判讀

整合本章與 5.0 VRAM + RAM 分層預算 的建議：

1. NVIDIA 是當前社群預設：怕折騰、想最大化「跑得起來」概率、選 NVIDIA。
2. VRAM 16GB 是常見起點：16GB VRAM + 64GB RAM 配 30B MoE 卸載、是 2026 年寫 code 場景的常見配置。
3. 頻寬比容量更影響日常體感：同容量下、頻寬接近兩倍的卡（如 5070 Ti 對 5060 Ti）日常生字速度差異明顯。
4. 二手卡也是選項：RTX 3090 24GB 二手市場價格依在地市場變化、CUDA 支援度仍佳、適合預算敏感但想要 24GB VRAM 的使用者。
5. 多卡不是優先升級方向：單人寫 code 場景下、單卡 + 良好設定通常勝過雙卡入門配置。

下一步

本章是模組五的最後一章。下一步可以回到 模組五 _index 看其他章節、或進入 模組四 應用層原理 看 LLM 作為系統元件的設計取捨。