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

概念位置

MoE 卸載屬於「推論時的權重位置管理」、跟 量化 屬於「權重精度壓縮」是兩個獨立維度、可以疊加（如 30B MoE Q4 + 卸載部分層、模型精度跟記憶體位置同時被處理）。它跟 KV cache 量化是 PC 場景常一起使用的兩個工具：卸載騰出 VRAM、KV cache 量化讓騰出的 VRAM 拿去開大 context window。

在 llama.cpp 中、對應的旗標是 --n-cpu-moe <N>、把 N 層的 MoE 專家權重保留在 CPU 記憶體。例如 --n-cpu-moe 30 表示 30 層的專家層留 RAM、其餘走 GPU。

可觀察訊號與例子

以 Qwen3-30B-A3B Q4_K_M（模型體積 10 GB 級、active parameter 約 3B 等級）為例、不同卸載策略下記憶體分布與生字速度的相對方向（具體數值依驅動、CUDA backend、模型版本、PCIe 版本變化、本表用於說明趨勢、不是嚴格 benchmark）：

事實查核註：上表是趨勢示意、不是經本文系統實測的數值。實際數值依顯卡型號、PCIe 版本、CUDA backend、GGUF 量化版本、-ngl 設定、context 長度與 batch size 變化、建議用 llama-bench 或實際工作流校準。

社群常見的觀察是：MoE 卸載對生字速度的衰減幅度、相對於「Dense 模型把同樣比例的層卸載到 CPU」較小、原因是 MoE 每 token 只啟用少數專家、PCIe 上的權重傳輸量也較少；具體幅度依模型架構（active parameter 比例、專家數）變化。

設計責任

理解 MoE 卸載後、可以解釋三個 PC 場景的現象：16GB VRAM 卡能載入 30B 級 MoE 模型（透過部分卸載而非全載 VRAM）、PC 場景 64GB RAM 相對 32GB 在 MoE 卸載空間上明顯更寬裕（可卸載更多層）、Mac 統一記憶體場景較少需要「卸載」這個概念（VRAM 跟 RAM 共用、不需要在兩個區域之間搬資料）。

設定 PC 推論伺服器時、卸載層數通常跟 KV cache 量化、context 長度、併發數一起調：先估算想開的 context 長度、扣掉 KV cache 體積算出 VRAM 餘量、再選卸載層數讓模型剛好放得進。詳見 5.0 VRAM + RAM 分層預算。

讀完本章後、你應該能對自己的硬體配置回答：這個模型適不適合用 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 長度的權衡。

讀完本章後、你應該能對自己的工作流回答：KV cache 量化的好處能換到什麼、品質代價落在什麼範圍、K 跟 V 為什麼建議不同等級、跟 context 長度跟併發數怎麼搭配。

本章目標

1. 理解 KV cache 為什麼會隨 context 線性膨脹、為什麼 PC 場景常需要量化。
2. 區分 K 跟 V 在 attention 計算中的角色、解釋為何兩者對量化的容忍度不同。
3. 判讀「該不該量化 KV cache」的工作流類型。
4. 認識 llama.cpp 的 --cache-type-k / --cache-type-v 旗標與相關限制（如 flash attention 要求）。
5. 知道調參時的觀察訊號跟取捨方向。

KV cache 為什麼會膨脹

LLM 推論時、每處理一個 token 都會把該 token 的 key 跟 value 向量算出來、暫存進 KV cache、供後續 token 的 attention 計算複用（不重算）。KV cache 的體積跟下面幾個變數線性相關：

1KV cache 體積 ≈ 2 × n_layers × n_heads × head_dim × bytes_per_value × context_長度 × batch

• 2：分別是 K cache 跟 V cache
• n_layers / n_heads / head_dim：模型結構參數
• bytes_per_value：fp16 是 2 bytes、Q8_0 約 1 byte、Q4_0 約 0.5 byte
• context_長度：context 開多大、KV cache 就放多大
• batch：併發處理多少 sequence

實際 KV cache 體積依模型 attention 變體（MHA / GQA / MLA）、head 數設計、量化方式而變。比起背公式、更實用的做法是看 llama.cpp 啟動時的 log、它會列出實際 KV cache 配置的記憶體：

1llm_load_print_meta: n_layer    = 48
2llm_load_print_meta: n_head     = 32
3llama_kv_cache_init: KV self size = 2048.00 MiB, K (q8_0): 1024.00 MiB, V (q8_0): 1024.00 MiB

事實查核註：上面的 log 格式跟欄位名稱依 llama.cpp 版本變動、實際輸出以執行時為準。常見模型的 KV cache 估算工具可參考 llama.cpp 官方文件 或社群維護的 calculator。

K 跟 V 為什麼適合用不同量化等級

K 跟 V 在 attention 計算中扮演不同角色、對量化的容忍度也不同。K 參與內積比較（量化容忍度通常較高）、V 是被加權平均的輸出內容（量化誤差會線性累積）、社群常見做法是 K 用較激進的量化、V 保留較高精度。

attention 的計算流程簡化為：

1attention(Q, K, V) = softmax(Q · K^T / √d) · V

K 跟 V 在這個流程中的角色差異：

1. K（key）：用來跟 Q 算內積、產生 attention score。內積本質是「相對量級的比較」、量化造成的微小誤差容易在 softmax 後被吸收。
2. V（value）：是被 softmax 加權平均後直接輸出的內容、量化誤差會線性累積進輸出。

社群多數回報指出：

• K 用 Q8_0 或 Q4_0 對品質影響相對小：因為 softmax 對輸入量級的敏感度集中在最大值附近、其他位置的小幅誤差會被指數壓縮。
• V 用 Q4_0 在長 context 末尾較易出現品質下降：因為 V 是被加權平均的內容、累積誤差會在輸出中可見。

事實查核註：K 跟 V 對量化敏感度不同的論述、來自社群常見回報跟若干針對 KV cache 量化的論文（如 KIVI、KVQuant 等）。具體影響因模型架構、量化方法（symmetric / asymmetric、per-head / per-channel scale 等）變化、不同模型的表現可能不一致；建議用自己工作流的任務跟自己選定的量化版本實測校準。

KV cache 量化等級對照

llama.cpp 支援的常見 KV cache 量化等級：

常見組合（社群回報、需自行校準）：

• 保守（品質優先）：K=fp16、V=fp16。完全不量化、VRAM 用量最大。
• 平衡起點：K=Q8_0、V=Q8_0。體積約一半、品質衰減社群多數回報為小幅或不明顯。
• 激進（context 優先）：K=Q8_0、V=Q4_0。體積約 fp16 的 35%、社群回報短 prompt 影響小、長 prompt 末尾可能出現品質下降。
• 極限：K=Q4_0、V=Q4_0。體積約 fp16 的 25%、用於開超大 context 或極高併發、品質風險最高。

何時值得量化、何時不該量化

KV cache 量化的主要用途是「VRAM 不足以同時放下模型權重 + 目標 context 長度 + 目標併發數」的場景。當 VRAM 已有充裕餘量、量化省下的 VRAM 沒有對應的用途時、保留 fp16 通常較合適。下表整理常見的判讀情境：

判讀原則：先確認瓶頸是「VRAM 不夠」還是「品質不夠」。前者量化是解法、後者量化通常會惡化問題。

跟 context 長度、併發數的協調

KV cache 量化的好處要跟其他 VRAM 用量一起評估。常見的取捨方向：

1. 量化 → 開更大 context：把省下的 VRAM 用在加大 -c、能開長 prompt（如 RAG、長對話、跨檔案分析）。
2. 量化 → 加併發：把省下的 VRAM 用在加 --parallel、能同時服務多個 client（如多個編輯器視窗、多 agent）。
3. 量化 → 載入更大模型：把省下的 VRAM 用在降 --n-cpu-moe、減少卸載、提升生字速度。

三者通常不能同時極大化、需要依工作流挑主軸。

實務上的常見搭配（社群回報、需校準）：

llama.cpp 的相關旗標

跑 KV cache 量化時、常用的旗標：

flash attention 的關係

部分 KV cache 量化組合（特別是 V=Q4_0 / Q4_1）在 llama.cpp 上需要同時啟用 flash attention（-fa）才能正常運作；沒啟用時可能載入失敗或 fallback 到 fp16。具體要求依 llama.cpp 版本變化、以實際 llama-server --help 跟 llama.cpp 官方 issue / PR 為準。

事實查核註：flash attention 對 KV cache 量化組合的限制、是 llama.cpp 實作層面的演進議題、不是模型本身的限制。新版 llama.cpp 可能放寬或改變要求、引用前以最新版的 release notes 為準。

給讀者的調參步驟

實際設定 KV cache 量化時、可以照下面的步驟調：

1. 先用 fp16 基準跑一次：用實際工作流的代表性任務、記錄補完品質、執行時間、VRAM 用量。這是後續比較的基準。
2. 切到 K=Q8 / V=Q8：跑同樣的任務、比較品質。社群多數回報差異不明顯、但需以自己工作流確認。
3. 進一步切到 V=Q4：再跑同樣任務、特別注意長 prompt 末尾、推理鏈、複雜邏輯任務的輸出品質。
4. 若品質可接受、評估省下的 VRAM 怎麼用：加大 -c、提高 --parallel、或減少 --n-cpu-moe。
5. 建立可重複的校準腳本：把代表性任務寫成 prompt 集、做為日後升級模型或調參時的回歸測試。

下一章

下一章：5.3 llama.cpp 在 PC 上、把本章跟 5.1 MoE 卸載 的旗標放進完整的 llama.cpp 調參工作流。

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

讀完本章後、你應該能在 Windows 上：選對 LM Studio 的 GPU backend、在 GUI 內設定卸載層數與 KV cache 量化、啟動 OpenAI 相容 server、接到 VS Code Continue.dev。

本章目標

1. 在 Windows 上安裝 LM Studio、選對 GPU backend。
2. 知道 GUI 設定面板的哪幾個欄位對應 llama.cpp 的核心旗標。
3. 啟動 LM Studio 的本地 server、提供 OpenAI 相容 API。
4. 判斷你的工作流適不適合用 LM Studio 當主力。
5. 處理常見的 Windows + GPU 整合議題（driver 版本、CUDA toolkit）。

安裝

LM Studio 是 Electron 桌面 app、個人使用免費、Windows / Linux / macOS 三平台都支援。從 lmstudio.ai 官網 下載對應系統的安裝檔即可。

Windows 版的安裝步驟：

1. 下載 .exe 安裝程式、執行安裝（不需 admin 權限的情況下會裝在使用者目錄）。
2. 首次啟動時、LM Studio 會偵測 GPU 並提示選擇 backend。

事實查核註：LM Studio 是商業軟體、UI 跟功能會隨版本變化。本章描述以 2026 年 5 月的穩定版為基準、實際 UI 元素位置以當前版本為準。

GPU backend 選擇

LM Studio 在 Windows 上的 GPU compute backend 選項依 GPU 廠商不同：

backend 的切換位置：LM Studio 的設定面板（齒輪圖示）→ Hardware / Runtime 區段、會列出當前可用的 backend 與下載連結。部分 backend 在首次使用時需要下載對應的 runtime（如 CUDA runtime）。

選錯 backend 的常見徵兆：

1. 模型載入時間異常長：可能 fallback 到 CPU、確認 GPU backend 是否正確啟用。
2. 生字速度遠低於同硬體的社群回報：backend 不對、或 driver 版本不對、或 VRAM 不足而啟用了 CPU offload。
3. 載入時錯誤訊息提到 CUDA 版本不符：driver 跟 LM Studio 內建的 CUDA runtime 不對齊、需更新 driver 或選擇對應的 LM Studio build。

事實查核註：各 backend 的可用性跟下載方式依 LM Studio 版本變動、以當前版本的 Hardware / Runtime 設定面板顯示為準。

GUI 設定對應到 llama.cpp 旗標

LM Studio 在背後使用 llama.cpp、GUI 內的設定欄位通常對應到 llama.cpp 的某個旗標。對熟悉 5.3 llama.cpp 在 PC 上 旗標的讀者、這個對應表能加速 GUI 內的設定：

具體欄位名稱跟位置依 LM Studio 版本變化、以實際 UI 為準。新加入 llama.cpp 的旗標通常會在後續 LM Studio 版本被加進 GUI。

啟動 LM Studio Server

LM Studio 內建 OpenAI 相容 server、預設 port 1234。啟用步驟：

1. 載入想用的模型（GUI 左側 Chat / Local Server 切換）。
2. 切到「Local Server」分頁。
3. 設定上面對應的旗標（GPU Offload、Context、KV Quant、MoE Offload 等）。
4. 點「Start Server」、看 log 確認模型載入成功、port 顯示為 1234（或自訂）。

啟動成功後、可以用任何 OpenAI 相容 client 連接：

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

接到 VS Code Continue.dev：

 1{
 2  "models": [
 3    {
 4      "title": "LM Studio",
 5      "provider": "openai",
 6      "model": "loaded-model-name",
 7      "apiBase": "http://localhost:1234/v1",
 8      "apiKey": "not-needed"
 9    }
10  ]
11}

model 欄位填 LM Studio 載入的模型名稱、要跟 GUI 顯示一致。

模型瀏覽器與下載

LM Studio 的內建模型瀏覽器直接連到 Hugging Face、可以搜尋 GGUF 格式的模型並一鍵下載。對「想試新模型但不想自己抓 GGUF」的使用者較友善。

下載時的選擇：

1. 量化等級：LM Studio 會列出可用的量化版本（Q4_K_M、Q5_K_M、Q8_0 等）、可依 VRAM 預算選擇。
2. 模型大小估計：LM Studio 通常會顯示「在你當前硬體上能不能跑」的提示；提示為估計、實際載入仍以 llama.cpp 啟動結果為準。
3. 下載位置：LM Studio 預設下載到使用者目錄；可在設定面板改路徑（適合把模型放到大容量 SSD）。

事實查核註：LM Studio 對「能否在當前硬體跑」的判讀是基於 VRAM + RAM 容量的估算、不考慮 MoE 卸載、KV cache 量化等進階設定；提示僅供參考、實際以實測為準。

跟 Ollama / llama.cpp 並存

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

實務上同時跑多個的場景是調參階段比較不同 backend 或設定；常態使用通常一個就夠。

切換主力的判讀：

Windows + GPU 整合常見議題

Windows 上跑本地 LLM 的常見議題：

1. NVIDIA driver 版本：driver 太舊可能不支援 LM Studio 內建的 CUDA runtime；過新 driver 偶爾出現相容性問題。建議用 NVIDIA Studio Driver（相對 Game Ready Driver 更穩）、或 NVIDIA 官方建議的當前長期支援版本。
2. WSL2 vs 原生 Windows：LM Studio 在原生 Windows 跟 WSL2 都能跑；WSL2 可以更接近 Linux 環境（適合熟悉 Linux 工具的使用者）、但 GPU 透傳的配置略多。
3. windows defender / 防毒軟體掃描：模型檔案常為 10+ GB、安全軟體的即時掃描可能拖慢載入速度；建議把模型目錄加入排除清單。
4. 電源計劃：Windows 的「省電」電源計劃可能讓 CPU 在閒置時降頻、影響 prefill 速度；建議使用「高效能」或自訂「卓越效能」計劃。
5. VRAM 被其他應用佔用：Chrome、Discord、遊戲都可能佔用 VRAM；觀察「工作管理員 → 效能 → GPU」確認 VRAM 餘量。

事實查核註：上面的議題以 Windows 10 / 11 為背景、具體現象跟解法依 Windows 版本、driver 版本變化。引用前以自己版本的官方文件為準。

給多數讀者的建議

LM Studio 在 Windows + 獨立 GPU 場景的核心價值是「降低 MoE 卸載與 KV cache 量化的學習成本」。對下面類型的使用者特別合適：

1. 剛接觸本地 LLM、不熟悉 CLI 旗標。
2. 主力工作是探索新模型、不是調穩定 production-like 設定。
3. 想視覺化看「卸載層數 vs VRAM 用量」的關係、再決定要不要轉到 CLI。

對下面類型的使用者、Ollama 或直接 llama-server 通常更適合：

1. 熟悉 CLI、想最完整地控制旗標。
2. 主力是穩定日常寫 code、模型不常換。
3. 想用 llama-bench 做精確校準。
4. 部署到團隊或多人共用的 server 環境（GUI app 不適合 headless 部署）。

下一章

下一章：5.5 PC 場景的模型選型優先順序、用前面四章建好的工程選項回答「具體裝哪個模型」。

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

事實查核註：本章引用的模型名稱、能力等級、量化版本以 2026 年 5 月的社群可用資源為基準。模型發布速度快、3 ~ 6 個月後可能有新候選、本章建議用具體版本日期跟對應的官方 model card / 技術報告校準。

本章目標

1. 認識 PC 場景特有的「全載 Dense vs 卸載 MoE」選型軸。
2. 知道不同 VRAM 容量對應的候選模型清單。
3. 區分「coding 專用模型」跟「通用模型」對寫 code 任務的差異。
4. 知道量化版本的取捨（Q4_K_M / Q5_K_M / Q6_K 的選擇）。
5. 認識選型決策的觀察期跟換模型的時機。

PC 場景特有的選型軸

Mac 統一記憶體場景下、選型主要看「能不能塞進記憶體」。PC 場景多了 MoE 卸載這個變數、變成三軸選型：

1選型三軸：
2├── VRAM 是否能全載      → 決定是否需要卸載
3├── MoE vs Dense          → 決定卸載的代價大小
4└── coding vs 通用        → 決定能力對寫 code 任務的契合度

兩條典型路線（同樣 16GB VRAM）：

社群多數寫 code 場景的回報傾向「卸載 30B MoE 對任務成敗的幫助大於速度損失」、但工作流以高頻短補完為主的使用者、有時偏好全載 14B Dense 的速度。實際取捨需用自己的工作流任務校準。

16GB VRAM + 64GB RAM 的候選清單

這是 2026 年 5 月 PC 場景最常被討論的配置、對應幾個主要候選：

候選一：Qwen3-30B-A3B（MoE、卸載）

模型定位：MoE 架構、總參數約 30B、active parameter 約 3B、coding / 通用混合訓練。

啟動旗標起點（GGUF Q4_K_M、需配合 5.1）：

1llama-server -m Qwen3-30B-A3B-Q4_K_M.gguf \
2  -ngl 99 --n-cpu-moe 30 \
3  --cache-type-k q8_0 --cache-type-v q4_0 -fa \
4  -c 32768

主要使用情境：

1. 跨檔案重構、需要理解較多上下文的任務。
2. 長 context 場景（RAG、大型 codebase 索引）。
3. 中文 + 英文混合的 prompt。

候選二：Qwen3 14B（Dense、全載）

模型定位：Dense 架構、14B 參數、通用 + coding 混合訓練。

啟動旗標起點：

1llama-server -m Qwen3-14B-Q4_K_M.gguf \
2  -ngl 99 \
3  --cache-type-k q8_0 --cache-type-v q8_0 -fa \
4  -c 32768

主要使用情境：

1. 工作流以高頻短補完為主、對生字即時體感要求高。
2. 想保持較穩的 latency、避開 MoE 卸載的調參。
3. 系統 RAM 只有 32GB、卸載空間有限。

候選三：Qwen3-Coder 30B / CodeLlama 13B 等 coding 專用模型

模型定位：在通用訓練後、用 code corpus 做了額外的 instruction tuning 或 continued pre-training。

社群常見回報：

• 在「補完 / 行內編輯」這種純 code-completion 任務上、coding 專用模型通常表現較好。
• 在「需要解釋程式碼 / 設計討論」混合任務上、通用模型有時更自然。

選擇邏輯：若你的工作流以純補完為主、coding 專用模型是合理優先；若以 chat-based 設計討論為主、通用模型也許更合適。

量化版本的取捨

GGUF 量化版本對同一模型的選擇：

選擇邏輯：先用 Q4_K_M 起步、若品質符合需求且 VRAM 有餘量、可試 Q5 / Q6；若 VRAM 不足、優先考慮「換小一級的模型 + Q5/Q6」而非「同模型 + Q3」、因為品質衰減在小模型上較易感知。

24GB VRAM 的候選清單

24GB VRAM（如 RTX 4090、RTX 3090）能跑全載 32B Dense 或重度卸載 70B MoE：

選擇邏輯：24GB 是「Dense 32B 級」跟「MoE 70B 級」的分水嶺；多數寫 code 場景在 Dense 32B 級已能勝任、再往 70B 級的邊際效益依任務變化。

32GB VRAM 的候選清單

32GB VRAM（如 RTX 5090）能跑 70B Dense Q4 全載：

32GB VRAM 場景下、選型回到「能力 vs 生字速度」的傳統取捨、MoE 卸載這個變數的影響相對減弱。

8GB / 12GB VRAM 的候選清單

VRAM 較小的場景、候選清單較短：

8GB 場景下、本地 LLM 的「跑得起來但能力有限」需先設好期望、見 1.5 期望管理（跨平台共用）。

coding 專用 vs 通用模型

選型的另一條軸是「coding 專用模型 vs 通用模型」：

選擇邏輯：純補完場景優先 coding 專用；chat-based 工作流通用模型也許更合適；多數使用者可以用兩個（一個 coding 專用 + 一個通用）、依任務切換。

選型決策步驟

實際選模型時、可以照下面的步驟：

1. 盤點硬體：VRAM 容量、系統 RAM 容量、CPU 性能。
2. 盤點工作流：補完為主 vs 跨檔案任務為主、短 prompt 為主 vs 長 prompt 為主、純 code vs 設計討論混合。
3. 依 VRAM 級別查上面候選清單：選 1 ~ 2 個起點模型。
4. 用 Q4_K_M 量化版本起步：跑一週實測、用代表性任務記錄品質、速度、VRAM 用量。
5. 依瓶頸調整：
   • 品質不夠 → 試更大模型 / 更高量化等級 / 不同訓練取向
   • 速度不夠 → 試較小 Dense 全載 / 減少卸載
   • VRAM 不夠 → 加量化（Q5 → Q4）、加 MoE 卸載、量化 KV cache
6. 建立可重複的校準腳本：把代表性任務寫成 prompt 集、新模型來時跑一次回歸測試。

觀察期與換模型時機

社群常見的換模型節奏：

1. 新模型發布：本地 LLM 模型平均每 2 ~ 3 個月有新候選。
2. 觀察期：新模型剛發布時、量化版本可能不全、社群實測案例較少；建議等 2 ~ 4 週、看是否有 Q4_K_M / Q5_K_M 等常用量化、社群回報是否穩定。
3. 回歸測試：用自己的校準腳本跑一次、比較跟現有主力模型的品質、速度、VRAM。
4. 切換：明顯優於現有主力 + 校準腳本通過 + 旗標設定穩定 → 才切換。

過早跳到新模型的常見代價：量化版本不穩、社群 issue 還在湧現、自己的旗標設定要從頭調。

下一章

下一章：5.6 GPU 廠商差異、處理 NVIDIA / AMD / Intel 在 llama.cpp 生態的相對位置。

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

本指南預設讀者已經會用過雲端 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 對照）。