概念位置

Tensor split 位在 inference server / GPU serving 層，跟 NVLink 或 PCIe 是不同責任：互連決定卡間傳輸成本，tensor split 決定權重怎麼分布。

可觀察訊號與例子

在 llama.cpp 看到 --tensor-split 或 -ts，通常是在手動指定多卡分配比例。兩張 VRAM 不同的卡可以用不同比例，避免小卡先 OOM。

設計責任

只有多 GPU 且需要手動控制分配時才需要它。單卡消費級 PC 通常不用；多卡沒有高速互連時，分割模型可能降低速度，需用實際 benchmark 校準。

讀完本章後、你應該能對自己的硬體配置回答：這個模型適不適合用 MoE 卸載、卸幾層是合理起點、卸到讓 prefill 變慢時該怎麼調、跟 KV cache 量化怎麼搭配。

本章目標

1. 理解 MoE 架構為什麼適合卸載（active parameter 少 ≠ 模型小）。
2. 判讀「該不該用 MoE 卸載」的工作流類型。
3. 知道卸載層數的調參範圍跟兩端的徵兆。
4. 區分卸載對 prefill 跟 generation 的影響差異。
5. 認識 llama.cpp 的 --n-cpu-moe 旗標與相關旗標的協作。

MoE 架構為什麼適合卸載

MoE 模型適合卸載的關鍵是「總參數大、active parameter 小」這個結構特性：每個 token 只啟用少數專家、走 PCIe 的權重量遠小於 Dense 模型卸載同比例層數的傳輸量。卸載因此變成可行的工程選項、而不是「速度大幅下降的退路」。

對比 Dense 模型：Dense 模型每個 token 都會用到所有層的所有權重、任何一層放到 RAM 都會讓每個 token 等 PCIe 拉回來、生字速度衰減較明顯。MoE 在每個 transformer block 內把 FFN（feed-forward network）拆成多個「專家」、router 為每個 token 挑選少數啟用、不啟用的專家權重留在 RAM 不參與計算。

MoE 卸載成立的三個結構要點：

1. 總參數大、active parameter 小：例如 Qwen3-30B-A3B 的 A3B 表示 active parameter 約 3B、總參數約 30B、每個 token 只走 ~10% 的權重。
2. 每 token 走 PCIe 的權重量大幅縮減：不活躍的專家權重留在 RAM、不參與本 token 的計算。具體幅度依模型 active 比例變化、可透過 量化 再進一步壓縮。
3. 共用層（attention、layernorm）放 VRAM：這些是每 token 必經、放 VRAM 確保速度上限不被拉低、跟 KV cache 一起佔用 VRAM 主要區段。

事實查核註：MoE 模型的 active / total parameter 比例依模型而異（Qwen3-30B-A3B、Llama 4 Scout、DeepSeek V3 等各有不同設計）。具體比例見各模型的官方技術報告或 Hugging Face model card。

對照 Dense 模型的卸載（在 llama.cpp 中、Dense 模型可以用 -ngl 控制放 GPU 的層數、剩下走 CPU）：Dense 卸載每 token 都要傳輸卸載層權重、生字速度衰減較明顯；MoE 卸載每 token 只傳輸啟用的專家、衰減較小。社群常見回報指出「MoE 卸載比 Dense 同比例卸載友善」、但具體幅度依模型架構（專家數、active 比例）變化、需用 llama-bench 校準。

何時值得用 MoE 卸載

MoE 卸載的主要用途是「處理 VRAM 容量不足以全載目標模型」的場景。當模型已能全載 VRAM、卸載通常會降低生字速度而沒有對應的收益。下表整理常見的判讀情境：

判讀原則：先確認瓶頸是「模型載不進」還是「速度不夠」。前者卸載是解法、後者卸載通常會惡化問題、應該往別的方向調（選較小模型、升級顯卡、提高量化等級）。

卸載層數的調參範圍

llama.cpp 的 --n-cpu-moe <N> 旗標表示「把 N 層的 MoE 專家權重放 CPU 記憶體」。實際範圍取決於模型結構：

1. 下限：0、表示所有 MoE 專家層都在 VRAM。對 16GB VRAM + 30B MoE 而言通常不可行（VRAM 不足）。
2. 上限：模型的 MoE 層總數、表示所有 MoE 層的專家都在 CPU。對應 VRAM 佔用最低、生字速度也最低。

調參的兩端徵兆：

常見起點：對 16GB VRAM + 64GB RAM 跑 30B 級 MoE 模型、社群常見回報的 --n-cpu-moe 落在 25 ~ 35 區間、具體值依模型 MoE 層數而定。建議從中間值（如 30）起步、再依 OOM / 速度徵兆雙向調整。

卸載對 prefill 跟 generation 的影響不同

prefill 跟 generation 是兩個不同的計算階段、對卸載的反應也不同：

1. prefill（處理 prompt）：一次處理整個 prompt、可用 batch 平行化、屬於 compute-bound 階段。卸載對 prefill 的衰減相對小、因為 batch 大可以攤平 PCIe 傳輸成本。
2. generation（生字）：一個 token 接一個 token、每 token 都要走完整個 forward pass、屬於 memory-bandwidth-bound 階段。卸載對 generation 的衰減較明顯、因為每 token 都要走 PCIe 拉部分權重。

實務影響：

• 長 prompt + 短回答（如「總結這份 codebase」）：prefill 主導總時間、卸載的代價較小。
• 短 prompt + 長回答（如「從 spec 寫一段功能」）：generation 主導、卸載的代價較大、可能適合用較小 Dense 模型全載。
• 互動式補完（每幾秒一次短 prompt 短回答）：prefill 跟 generation 都重要、卸載的整體成本依工作流節奏而定。

事實查核註：prefill 跟 generation 的具體 t/s 差異依模型、量化、batch size、CUDA backend 變化；建議用 llama-bench 或實際工作流任務分別校準。

跟 KV cache 量化的協調

MoE 卸載騰出 VRAM、KV cache 量化讓騰出的 VRAM 拿去開大 context。兩者的關係是「先後」而非「替代」：

1總 VRAM 預算
2├── 模型權重（活躍部分）= 由 --n-cpu-moe 決定
3├── KV cache             = 由 -c (context) × cache-type 決定
4└── 推論中間結果         = 通常固定

調參順序（社群常見做法）：

1. 先決定目標 context 長度：例如 32K、128K、256K。
2. 估算 KV cache 體積：依模型 attention head 配置、context 長度、量化等級。具體值用 llama.cpp 啟動時的 log 確認。
3. 算出 VRAM 餘量：總 VRAM − KV cache − 推論中間結果。
4. 決定 --n-cpu-moe：讓「模型權重活躍部分」放得進 VRAM 餘量。

如果做完上面四步發現 VRAM 仍不夠、就回頭調 KV cache 量化（K=fp16 → Q8 → Q4_0）、或降低 context 長度。

詳細的 KV cache 量化判讀見 5.2 KV cache 量化策略。

llama.cpp 的相關旗標

跑 MoE 卸載時、常一起出現的旗標：

完整旗標清單見 llama.cpp 官方文件；版本更新後參數名稱可能變動、以實際 llama-server --help 為準。

給讀者的判讀步驟

實際設定 MoE 卸載時、可以照下面的步驟調：

1. 確認模型適合 MoE 卸載：模型是 MoE 架構（如 Qwen3-30B-A3B、Llama 4 Scout、DeepSeek V3 系列）、且總參數量明顯超過 VRAM 容量。

2. 抓取 GGUF 量化版本：寫 code 場景的常見起點是 Q4_K_M、品質 / 體積平衡較好。

3. 設定起點旗標：

   1llama-server -m <model.gguf> -ngl 99 --n-cpu-moe 30 \
   2  --cache-type-k q8_0 --cache-type-v q4_0 -c 32768

4. 觀察啟動 log：llama.cpp 會列出「實際載入 VRAM 的層數」「KV cache 體積」「剩餘 VRAM」。

5. 跑 llama-bench 校準：用同樣的旗標跑 prefill / generation benchmark、記錄 t/s。

6. 依瓶頸調整：

   • 想開更大 context → 加大 -c、若 VRAM 不足則加 --n-cpu-moe 或量化 KV cache
   • 想要更快生字 → 減 --n-cpu-moe、確認 VRAM 仍夠
   • VRAM OOM → 加 --n-cpu-moe 或降量化

完成這六步後、再進入 5.3 llama.cpp 在 PC 上 了解更全面的旗標組合。

下一章

下一章：5.2 KV cache 量化策略、深入 K=Q8 / V=Q4 跟 context 長度的權衡。

對寫 code 場景的多數讀者來說、Ollama 已涵蓋 llama.cpp 的直接使用情境。Ollama 已經把它包好、使用者看到的是 model tag 跟 CLI；llama.cpp 自己的編譯、量化、參數設定都被抽象掉。本章的目的是澄清網路上「llama.cpp 才是真本地、Ollama 是壓榨版」這類迷思、並給少數需要直接用 llama.cpp 的場景一條路。

本章目標

讀完本章後，你應該能：

1. 理解 llama.cpp 在三層架構中的位置。
2. 知道 Ollama 與 llama.cpp 的關係（包含 / 上游）。
3. 判斷自己什麼情境下需要直接用 llama.cpp、什麼情境不用。
4. 看懂 GGUF 格式與量化標籤（Q4_K_M、Q5_K_S 等）。
5. 對「llama.cpp 整合 Gemma 4 MTP」這類消息建立判讀反射。

llama.cpp 在哪一層

llama.cpp 同時跨三層架構的兩層：

1. 推論引擎（library、可被其他程式呼叫的程式碼集合）：核心 C++ library、把 GGUF 權重載入、跑 forward pass（神經網路把輸入算到最後一層產出 token 的單次計算）。Ollama、LM Studio、許多其他工具的 backend 就是這個 library。
2. CLI 工具與 server（llama-cli、llama-server）：附帶的命令列工具與 HTTP server、可以直接拿來用、但需要自己編譯與配置。

當你看到「我用 Ollama 跑 Gemma 4」，實際發生的事是：

1你的指令
2  ↓
3Ollama CLI / server（包裝層、模型管理）
4  ↓
5llama.cpp library（推論核心）
6  ↓
7Metal API（Apple Silicon GPU）
8  ↓
9Apple Silicon 硬體

所以「Ollama vs llama.cpp」不是兩個競爭品，是「上層包裝」跟「底層引擎」的關係。

Ollama 跟 llama.cpp 的關係

Ollama 是 llama.cpp 的下游 wrapper、但 fork 跟 upstream 不是即時同步的關係。Ollama 在自己的 repo 裡放一份 vendored（複製進來、跟隨 Ollama 自家發版節奏管理）的 llama.cpp source、加上他們自己的 patches（補丁修改）；新功能進入 Ollama 的順序通常是：

1. llama.cpp 上游加新功能或修 bug
2. Ollama 把該 commit cherry-pick（從另一個 branch 單獨挑出一個 commit 套用）進來
3. Ollama 發新版

但反過來也成立：Ollama 有時搶先在 fork 裡加上游還沒接受的功能，例如 Gemma 4 MTP 在 2026/5/7 的 Ollama v0.23.1 一鍵支援，當時 llama.cpp 上游的 Gemma 4 MTP 整合還是 feature request。

這個關係的啟示：

1. 「llama.cpp vs Ollama 誰先進」視功能而定：具體功能要實際對照 release notes、「上游 / 下游」直覺只是初步參考、未必符合實際版本狀態。
2. 判讀支援度看 release notes：主版本號只是命名、實際功能列表要看具體版本的 changelog。
3. 直接用 llama.cpp 跟靠近上游是兩件事：Ollama 的 patches 有時是「上游還沒接受、但已經實用的功能」。

什麼情境真的需要直接用 llama.cpp

絕大多數寫 code 場景，Ollama 完全夠用。直接用 llama.cpp 的合理情境只有少數：

寫 code 場景的讀者通常不命中以上任何一條。

安裝（如果你真要試）

從原始碼編譯：

1git clone https://github.com/ggerganov/llama.cpp.git
2cd llama.cpp
3make

或用 Homebrew（社群維護，版本可能稍舊）：

1brew install llama.cpp

裝完後常用命令：

1# CLI 對話
2llama-cli -m /path/to/model.gguf -p "Hello"
3
4# HTTP server
5llama-server -m /path/to/model.gguf --port 8080 --host 127.0.0.1

llama-server 啟動後在 localhost:8080 提供 OpenAI 相容 API：

1curl http://localhost:8080/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "any-name",
5    "messages": [{"role": "user", "content": "Hi"}],
6    "stream": false
7  }'

model 欄位 llama-server 忽略，因為它一次只 serve 一個模型（不像 Ollama 可以動態切換）。

--host 127.0.0.1 是 loopback 預設、只接受本機連線。改 0.0.0.0 會把伺服器暴露到整個 LAN、跟 Ollama 改 OLLAMA_HOST 同類別的決定；完整的綁定模式跟誤開放後果見 6.1 推論伺服器的綁定與暴露範圍。

GGUF 格式與量化標籤

量化標籤是看 GGUF 檔名選模型的唯一線索、影響「記憶體 / 品質 / 速度」三軸的取捨。GGUF（GGML Unified Format）是 llama.cpp 定義的模型權重格式、把模型權重、tokenizer、metadata 打包成單一檔案。Ollama 內部存的就是 GGUF。

常見量化標籤：

_K_M、_K_S 的 K 指 K-quants（更先進的量化方法）、M / S 指 mixed-medium / mixed-small（不同層用不同量化）。實務上選 Q4_K_M 或 Q5_K_M 是寫 code 場景的甜蜜點；極端記憶體緊張才往 Q3 走、但通常會發現換較小模型的 Q5 比強塞大模型的 Q3 好。

為何 coding 任務對 Q3 以下特別敏感：寫 code 的回應要在 token 層保持高精度（變數名拼字、API 呼叫格式、括號配對都不容錯）、低 bit 量化會放大 token 分布失真、體感是 hallucination 上升、編造的 API 變多、長 context 累積誤差更明顯。一般對話容忍幾個錯字、code 一個錯字就跑不過。所以同 24GB Mac 上 Q5 14B 通常比 Q3 31B 適合寫 code、雖然參數量名義上少了一半。

Gemma 4 MTP 在 llama.cpp 的狀態（2026/5）

2026 年 5 月時：

• speculative decoding 框架：llama.cpp 已有 --draft-model 參數，整體 speculative decoding 功能 beta 階段。
• Gemma 4 官方 drafter 整合：feature request 開著（GitHub issue 上有討論），但尚未合進主分支。
• Ollama 對應狀態：v0.23.1 已一鍵支援 gemma4:31b-coding-mtp-bf16。

這是少見的「Ollama 領先 llama.cpp 上游」情境，原因是 Ollama 團隊接到 Google 的合作後直接做 patch、不等上游 review 流程。

實務啟示：

1. 想用 Gemma 4 MTP，直接用 Ollama 是最快路徑。
2. 想在 llama.cpp 直接跑 Gemma 4 MTP，要自己編譯帶上 Ollama 的 patches，或等上游合進來。
3. 看到「llama.cpp 已整合 Gemma 4 MTP」的網路文章，先去 llama.cpp 的 PR 列表 確認時間點。

llama.cpp 對 Apple Silicon 的優化

llama.cpp 對 Apple Silicon 有針對性優化：

1. Metal backend：在 macOS 上自動啟用 Metal（Apple 的 GPU 加速 API）、把 GPU 算力吃滿。
2. NEON / AMX：CPU 上用 ARM 向量指令集（NEON 是基本 SIMD、AMX 是 Apple 的矩陣加速器）加速 dequantization（把量化權重還原為計算精度的過程）。
3. Unified Memory aware：不像 NVIDIA GPU 要透過 PCIe（連接 GPU 與系統其他元件的高速匯流排）把資料搬進 VRAM、Apple Silicon 直接共用記憶體、省下這趟搬移。

這些優化都「免費」，不用使用者特別設定。但跟 MLX 比，llama.cpp 用的是 Metal 而不是 MLX framework；兩者效能各有勝負，差距通常 10 ~ 30%，不是「天差地遠」。

陷阱是看到「MLX 比 llama.cpp 快 N 倍」這類說法時，要追問：

1. 哪個模型？
2. 哪個量化？
3. 哪台 Mac？
4. llama.cpp 哪個版本？
5. 量測腳本是什麼？

多數網路 benchmark 沒有完整變數控制，差距常被誇大。對寫 code 場景的使用者，這個差距不值得糾結。

直接用 llama.cpp 跟 Ollama 並存

如果你真的想試 llama.cpp，可以跟 Ollama 並存（port 不同）：

Continue.dev 可以同時連兩個：

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

給多數讀者的建議

直接用 llama.cpp 的學習成本比 Ollama 高、換來的好處對寫 code 場景的使用者通常不命中需求。在「自己量化模型 / 跑特殊冷門模型 / 需要 llama.cpp 最新 commit」三個條件都不命中時、Ollama 是低成本的預設選擇。

把 llama.cpp 當成「Ollama 背後的引擎、值得知道存在、但不必直接面對」。這個定位足夠應付網路上 95% 的相關討論。

何時不適用本章 / 該往哪去

本章的「以 Ollama 為主、llama.cpp 作為底層理解」這個敘事在以下情境會失準、需要另外的路徑：

下一章

下一章：1.3 VS Code + Continue.dev 整合，把伺服器接到日常編輯器，這才是寫 code 的真正起點。

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

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

本指南預設讀者已經會用過雲端 LLM（ChatGPT、Claude）、熟悉終端機操作、想以工程視角理解 LLM。寫 code 場景是主要使用例、但模組二 / 三 / 四 / 六多數章節跨場景通用：想懂 reasoning model / RAG / embedding model 內部、即使不裝本地 LLM 也能讀。硬體前提分兩條路線：Apple Silicon Mac（M1 ~ M4、統一記憶體）走模組一；Windows / Linux + 獨立 GPU（NVIDIA / AMD、獨立 VRAM + 系統 RAM）走模組五。文章不販賣 LLM 焦慮、也不誇大本地能取代雲端的程度；它的責任是給每條讀者旅程的最短可行路徑、並標出每個階段的取捨。

模組零（心智模型）是所有讀者旅程的共同前置。模組一跟模組五是「裝本地 LLM」的兩條硬體路線、依平台選一條；想懂底層走模組二跟模組三（跟硬體無關、含 reasoning model / speculative decoding 等推論細節）；想看 LLM 作為系統元件走模組四（12 章涵蓋 RAG、tool use、agent、應用層協議、workflow、production resource、long context、embedding model、benchmarking、vision、靜態 deployment）；本地工作流跑穩想看安全議題走模組六（個人 dev 視角的供應鏈、伺服器綁定、tool use 權限、prompt injection、跨雲端邊界、production routing）。

教材邊界

學習路線

本指南分成七個模組加一組前置卡片（111 張）。讀者依目的選讀、不需要從頭到尾全讀：

• 想用 Apple Silicon Mac 裝本地 LLM 寫 code：讀模組零 + 模組一（最短路徑）
• 想用 Windows / Linux + 獨立 GPU 裝：讀模組零 + 模組五
• 想懂 LLM 內部原理：模組二（數學） + 模組三（理論、含 reasoning models / speculative decoding）— 跟硬體無關
• 想做 LLM 應用開發（含 RAG / agent / VLM / 靜態 deployment）：模組四（12 章、跨工具世代不變的原理）— 跟硬體無關
• 想懂本地工作流的安全議題：模組一 / 五跑穩後接模組六（個人 dev 視角）
• 想選 RAG 的 storage 方案（pickle / vector DB / hosted SaaS）：直接看 4.22 RAG storage 工程
• 想在靜態網站加 RAG / 智能搜尋：直接看 4.16 靜態 / serverless RAG deployment
• 想在本機 fine-tune 模型：模組三 3.4 訓練流程原理 → 本機 QLoRA hands-on
• 想跟最新進展接軌：讀完模組後進推薦的公開課程跟 paper（模組二 2.4 + 模組三 3.10）

前置知識卡片

用原子化卡片整理 token、自回歸、KV cache、量化、speculative decoding、MTP、MLX、推論伺服器、OpenAI 相容 API、memory bandwidth、統一記憶體、TTFT、prefill、context window、Transformer、Diffusion 等核心概念。章節文章專注情境推導、術語背景交由卡片維持一致。

模組零：基礎知識與心智模型

整理本地 vs 雲端 LLM 的差異、自回歸架構與記憶體頻寬瓶頸、介面 / 伺服器 / 模型三層心智模型、OpenAI 相容 API 為何重要、MLX / MTP / oMLX 三個容易搞混的術語、Apple Silicon Mac 記憶體與模型大小的對應關係、判讀本地 LLM 資訊的五個框架。

模組一：本地 LLM 服務的安裝與應用

整理 Ollama、LM Studio、llama.cpp 三個主流推論伺服器的現況差異與安裝路徑、用 Continue.dev 把本地 LLM 接到 VS Code 的完整步驟、寫 code 場景下模型選型的優先順序、本地模型的期望管理、想進一步玩 coding agent、Web UI、產圖時的延伸方向。

模組二：LLM 的數學基礎

整理 LLM 推論背後的數學工具：線性代數（向量、矩陣、空間）、機率與資訊論（softmax、cross-entropy、KL、perplexity）、微積分與最佳化（gradient、SGD / Adam）、數值精度（fp32 / bf16 / Q4 / Q8 的取捨）。每章末尾接到公開課推薦。

模組三：LLM 的理論基礎

整理 LLM 內部運作機制、共 11 章：神經網路基礎、embedding 空間、attention 機制、Transformer 架構、訓練流程（pre-train → SFT → RLHF / DPO）、sampling 策略、tokenization 算法、跨語言場景原理、Reasoning models（o1 / R1 / QwQ 等 test-time compute paradigm）、Speculative decoding 內部（drafter / MTP / EAGLE）。每章末尾接到公開課推薦（Karpathy、Stanford CS224N / CS25 / CS336、DeepLearning.AI）。

模組四：LLM 應用層原理

整理 LLM 作為系統元件的設計原理、共 12 章：RAG、tool use、agent 架構、應用層協議、workflow 編排模式、Production resource planning、衍生產物管理、Long context engineering、Embedding model 內部、Benchmarking 方法論、Vision in coding workflow（本地 VLM 接 IDE）、靜態 / serverless RAG deployment（沒 backend 場景）。本模組刻意只寫跨工具世代不變的原理、避開 LangChain / LlamaIndex 等具體 framework 教學。

模組五：Windows / Linux + 獨立 GPU

整理消費級 PC（Windows / Linux + NVIDIA / AMD 獨立 GPU）跑本地 LLM 的硬體判讀模型與工程選項：VRAM + RAM 分層預算、MoE 模型的 CPU 卸載策略（--n-cpu-moe）、KV cache 量化（K=Q8 / V=Q4）跟 context 長度的權衡、llama.cpp 在 PC 上的調參空間。本模組跟模組一是平行的硬體路線、共用模組零的心智模型跟卡片。

模組六：本地 LLM 的安全與權限

整理個人 dev 在自己機器上跑本地 LLM 的安全議題：模型供應鏈與信任邊界、推論伺服器的綁定與暴露範圍、tool use 與 MCP server 的權限模型、IDE 場景的 prompt injection、跨雲端 / 本地的資料邊界、跨進 production 的 routing 中樞。framing 是個人 dev 視角、不是 enterprise 資安管理；production / 多租戶 LLM 服務的特殊資安議題見 Backend 模組七 資安與資料保護 的 LLM 相關章節。

模組之間怎麼配合

模組二跟模組三可並讀。閱讀模組三遇到陌生數學詞時跳回模組二補完、再回模組三繼續。模組四在前面模組之上、但讀者熟悉 LLM 應用詞彙也可直接從這裡讀起。模組一跟模組五依硬體選一條主路線、共用模組零的心智模型與 knowledge-cards。模組六在模組一 / 五跑穩後接、處理「跑起來後該注意什麼」。

適合的讀者

用語約定

本指南使用的關鍵術語在第一次出現時都附原文。為避免歧義，下列詞彙在本指南內固定指涉：

1. 本地 LLM：跑在使用者自己機器（Mac 或 PC）上的大型語言模型推論、prompt 留在本機。
2. 推論伺服器（inference server）：負責載入模型權重、處理 prompt、產生 token 的常駐程式、例如 Ollama、LM Studio 內建 server、llama.cpp server。
3. 介面層：使用者實際打字互動的工具、例如 VS Code + Continue.dev、CLI、Web UI。介面層透過 API 跟推論伺服器溝通。
4. 模型（model）：權重檔本身、例如 gemma4:31b、qwen3-coder:30b。模型可以在不同推論伺服器之間共用、前提是格式相容。
5. 量化（quantization）：把模型權重從高精度（如 bf16）壓成低精度（如 Q4）以減少記憶體佔用、代價是少許品質下降。

不在本指南內的主題

本指南不討論：

• Speech / audio LLM：跟核心文字 LLM 是不同方向、本指南不涵蓋。Vision（VLM）原本不放、但因 coding 工作流的 vision use case 進入主流、補上 4.15 Vision in coding workflow；video LLM 仍不放。
• 資料中心訓練的工程細節：data parallelism、ZeRO、tensor parallelism 等屬於專門課程的範圍。
• 向量資料庫的 vendor 比較（Pinecone vs Weaviate vs Chroma 等）：vendor 格局半年一變、不適合寫入教材。RAG 的 storage 工程原理（升級判讀、index 生命週期、dependency 約束）見 4.22 RAG storage 工程。
• Kubernetes / 資料中心級分散式推論：跟個人機器本地 LLM 方向不同、需另尋專門教材。
• 多卡 NVLink、tensor parallelism：消費級 PC 場景通常單卡、本指南不涵蓋多卡分散式推論。

若讀完本指南後想往這些方向走：

1. 想做 RAG 應用：先把 Ollama + Continue.dev 跑穩、再讀 模組四 4.1 RAG 原理 建立設計取捨判讀、或 模組三 3.8 推薦 的 DeepLearning.AI short courses。
2. 想跑 coding agent：先讀 4.4 Agent 架構原理 建立判讀、再看 1.6 延伸方向 了解 aider、Cline 等工具的定位差異。
3. 想跑產圖模型：Diffusion 跟 Transformer 是不同架構、請另尋 ComfyUI / Draw Things / Diffusers 教材。
4. 想自己訓練 / fine-tune：讀完模組三、進入 Karpathy zero-to-hero、Stanford CS336、Hugging Face NLP Course 等推薦資源。

文件版本：v0.7.0 最後更新：2026-05-12 系列狀態：七個模組 + 125 張知識卡片。模組零（9 章）/ 一（10 章 + hands-on、含 QLoRA + judge harness）/ 二（5 章）/ 三（12 章、含 reasoning / speculative / constrained decoding）/ 四（17 章、含 long context / embedding / benchmarking / VLM / 靜態 deployment / coding agent harness / prompt caching / agent memory / tracing / LLM-as-judge）/ 五（7 章）/ 六（7 章、含 OWASP 對照）。