llama.cpp 是 PC 場景跑本地 LLM 的主流 推論伺服器、也是 Ollama、LM Studio 的底層 backend。在 PC 上直接使用 llama.cpp 的場景跟 Mac 不同：PC 需要選對 GPU compute backend（CUDA / ROCm / Vulkan）、處理 driver 版本對齊、調 MoE 卸載 與 KV cache 量化旗標、產出的是 OpenAI 相容 API。本章把這些 PC 場景特有的設定串成一條完整的調參工作流。

讀完本章後、你應該能在自己的 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」的讀者另一條路。