概念位置

各家 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 廠商差異。

讀完本章後、你應該能在自己的 PC 上：選對 llama.cpp build、用 llama-server 跑 OpenAI 相容 API、用 llama-bench 校準 throughput、知道多卡跟非 NVIDIA GPU 的入門設定方向。

本章目標

1. 知道怎麼取得對應自己 GPU 的 llama.cpp build（pre-built release vs 自編譯）。
2. 看懂 PC 場景常用旗標的分組與互相關係。
3. 用 llama-server 啟動 OpenAI 相容 server、接到 VS Code Continue.dev。
4. 用 llama-bench 校準 prefill 跟 generation throughput。
5. 認識多卡 tensor split 的入門設定。
6. 知道 ROCm（AMD）跟 Vulkan backend 的相對成熟度。

取得 llama.cpp build

llama.cpp 在 PC 上的取得方式有三條：

路徑一：官方 pre-built release（社群常見起點）

ggml-org/llama.cpp 的 GitHub release 提供 Windows / Linux 的 pre-built binary、含 CUDA 12.x、ROCm、Vulkan、CPU-only 等多種 backend。下載對應自己 GPU + driver 版本的 build、解壓即用。模型權重檔通常為 GGUF 格式。

選 build 時的判讀：

事實查核註：各 backend 的成熟度跟支援度依 llama.cpp 版本快速演進、上表為 2026 年 5 月常見回報的相對情況、建議引用時以 llama.cpp release notes 跟對應 backend 的官方文件為準。

路徑二：自編譯（需要特定功能或最新 commit）

從原始碼編譯適合下面情境：

1. 想用 release 還沒包進去的新功能（如剛 merge 的 PR）。
2. 想針對特定 CUDA compute capability 編譯、減少 binary 大小或開特定優化。
3. 自己 patch 過 llama.cpp。

CUDA build 的常見編譯指令（以 Linux 為例、Windows 請參考官方文件）：

1git clone https://github.com/ggml-org/llama.cpp.git
2cd llama.cpp
3cmake -B build -DGGML_CUDA=ON
4cmake --build build --config Release -j

編譯選項依版本變化、以 CMakeLists.txt 跟 build 文件 為準。

路徑三：透過上層工具（Ollama / LM Studio）

如果你不需要直接面對 llama.cpp 旗標、用 Ollama 或 LM Studio 通常更省事。它們把 llama.cpp 包裝在背後、提供更高層的設定介面。Mac / Windows 都適用、見 5.4 LM Studio 在 Windows。

直接面對 llama.cpp 的價值：完整控制旗標、看 log 直接 debug、用 llama-bench 做精確校準。

核心旗標地圖

PC 場景常用的旗標可以分成五組：

1. GPU 層分配

2. KV cache 與 context

3. 平行與 batch

4. 模型與量化

5. server 設定

完整旗標清單見 llama-server --help 跟 tools/server/README.md；版本更新後旗標可能新增、改名或棄用、以實際版本為準。

完整啟動範例

下面三個範例對應三種常見硬體配置、皆為起點配置、需依實測調整。

範例一：16GB VRAM + 64GB RAM、跑 30B MoE 寫 code

 1./llama-server \
 2  -m ~/models/Qwen3-30B-A3B-Q4_K_M.gguf \
 3  --alias qwen3-30b-a3b \
 4  -ngl 99 \
 5  --n-cpu-moe 30 \
 6  --cache-type-k q8_0 \
 7  --cache-type-v q4_0 \
 8  -fa \
 9  -c 32768 \
10  --parallel 1 \
11  --host 127.0.0.1 \
12  --port 8080

對應的 Continue.dev 設定：

 1{
 2  "models": [
 3    {
 4      "title": "Local llama.cpp",
 5      "provider": "openai",
 6      "model": "qwen3-30b-a3b",
 7      "apiBase": "http://localhost:8080/v1",
 8      "apiKey": "not-needed"
 9    }
10  ]
11}

範例二：24GB VRAM + 64GB RAM、跑 32B Dense

1./llama-server \
2  -m ~/models/Qwen3-32B-Q4_K_M.gguf \
3  -ngl 99 \
4  --cache-type-k q8_0 \
5  --cache-type-v q8_0 \
6  -fa \
7  -c 65536 \
8  --parallel 1 \
9  --port 8080

Dense 32B Q4_K_M 體積落在 16 ~ 20 GB 級、24GB VRAM 可全載；KV cache 保留較保守的 Q8 / Q8、context 開到 64K。

範例三：8GB VRAM + 32GB RAM、跑 7B 級 Dense

1./llama-server \
2  -m ~/models/Qwen3-7B-Q4_K_M.gguf \
3  -ngl 99 \
4  --cache-type-k q8_0 \
5  --cache-type-v q8_0 \
6  -fa \
7  -c 16384 \
8  --port 8080

7B Q4_K_M 體積約 4 ~ 5 GB、8GB VRAM 可全載 + 適中 KV cache。

用 llama-bench 校準

llama-bench 是 llama.cpp 附帶的 benchmark 工具、用來測量特定模型 + 旗標組合的 prefill 跟 generation throughput。

基本用法：

1./llama-bench \
2  -m ~/models/Qwen3-30B-A3B-Q4_K_M.gguf \
3  -ngl 99 \
4  --n-cpu-moe 30 \
5  --cache-type-k q8_0 \
6  --cache-type-v q4_0 \
7  -p 512 \
8  -n 128

-p：prefill 測試的 prompt 長度；-n：generation 測試的 token 數。

輸出會列出 prefill t/s 跟 generation t/s。建議：

1. 記錄基準：用「平衡起點」旗標跑一次、記下 prefill 跟 generation t/s。
2. 逐項調整：每次只動一個旗標（如 --n-cpu-moe 從 30 改 25、再改 35）、看 t/s 怎麼變。
3. 校準目標：找到「VRAM 用量、context 上限、t/s」三者組合符合工作流需求的設定。

llama-bench 的結果是「fixed prompt / 固定生成長度」、跟「實際工作流的混合長度」有差距；建議再用實際工作流的代表性任務做最終驗證。

事實查核註：llama-bench 的輸出格式跟旗標名稱依 llama.cpp 版本變動、以實際 llama-bench --help 為準。

多卡 tensor split 入門

如果你有兩張或以上的 GPU、llama.cpp 支援把模型權重分散到多卡：

1./llama-server \
2  -m ~/models/Llama-4-Scout.gguf \
3  -ngl 99 \
4  --split-mode layer \
5  -ts 0.5,0.5 \
6  --port 8080

• --split-mode layer：以層為單位切分、最常用
• --split-mode row：以張量的 row 切分、用於 tensor parallel
• -ts 0.5,0.5：兩張卡各分一半權重；若兩卡 VRAM 不同、可調比例（如 -ts 0.4,0.6）

多卡的實際吞吐縮放比依下面因素變化：

1. 主機板 PCIe lane 配置：消費級主機板常見「一條 x16 + 一條 x4」、第二張卡的 PCIe 頻寬可能受限。
2. GPU 之間是否有 NVLink：消費級 RTX 系列普遍不支援 NVLink、卡間通訊走 PCIe、相對資料中心級配置慢。
3. split-mode 選擇：row 模式需要更高的卡間頻寬、layer 模式對 PCIe 頻寬要求較低。

社群常見回報：多卡縮放比通常低於線性、layer 模式對長 prompt 的 prefill 提升較明顯、generation 提升相對小。具體效益依工作流跟卡間頻寬、需用 llama-bench 校準。

對單人寫 code 場景、多卡的邊際效益通常不如「先升級單卡」或「先優化單卡配置」。

ROCm 與 Vulkan backend 的相對成熟度

llama.cpp 對非 CUDA backend 的支援度依社群回報有以下相對位置：

事實查核註：各 backend 的成熟度跟性能對比是社群常見回報、不是經本文系統實測。建議引用前查閱 llama.cpp 的 PR 列表、對應 backend 的官方文件、跟自己硬體的實際 benchmark。

選 backend 的判讀：

1. NVIDIA GPU：用 CUDA build、不需考慮其他。
2. AMD GPU on Linux：優先試 ROCm build；不穩或不支援的卡型則退回 Vulkan。
3. AMD GPU on Windows：ROCm on Windows 在演進、Vulkan 通常較穩。具體選擇以 llama.cpp release notes 跟自己硬體實測為準。
4. Intel ARC：Vulkan 或 SYCL backend；社群實測案例較少、預期需要較多自己摸索。

跟 Ollama / LM Studio 並存

llama.cpp server、Ollama、LM Studio 可以同時跑、用不同 port：

Continue.dev 可以同時接：

 1{
 2  "models": [
 3    {
 4      "title": "Ollama default",
 5      "provider": "ollama",
 6      "model": "qwen3-30b-a3b",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "llama.cpp custom",
11      "provider": "openai",
12      "model": "qwen3-30b-a3b",
13      "apiBase": "http://localhost:8080/v1",
14      "apiKey": "not-needed"
15    }
16  ]
17}

實務上、多數情況只需要一個推論伺服器；同時跑多個的場景是「比較同一模型在不同 backend / 旗標下的差異」、屬於調參階段、不是常態。

下一章

下一章：5.4 LM Studio 在 Windows、給「不想直接面對 CLI」的讀者另一條路。

事實查核註：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 作為系統元件的設計取捨。