概念位置

模型命名中的 active parameter 線索：

模型在不同維度的影響：

事實查核註：active parameter 跟模型能力的關係是社群常見回報、不是嚴格定理；具體模型在 coding / reasoning / 對話等任務的表現依訓練資料、RLHF、prompt 風格變化、需以 SWE-bench 等公開 benchmark 跟自己工作流校準。

設計責任

理解 active parameter 後可以解釋兩個現象：為什麼 30B MoE 跟 30B Dense 在同硬體下生字速度差很多（前者每 token 只走 3B active）、為什麼 MoE 模型能力對應的「等價 Dense 大小」不是簡單線性（社群常見回報接近總參數的 60% ~ 80% 等價 Dense 能力、但 case-by-case）。

選 MoE 模型時、active parameter 是速度判讀軸、總參數是記憶體判讀軸、能力判讀靠自己工作流的 benchmark；不要直接拿「30B」跟 Dense 30B 作能力對等。

概念位置

MoE 在 transformer 架構中的位置：

1transformer block：
2  ├── attention 層（所有 token 共用）
3  ├── layer norm
4  └── FFN 層
5        ├── Dense 架構：所有 token 走同一組 FFN
6        └── MoE 架構：FFN 拆成多個 expert、router 挑選 top-k 個啟用

主流 MoE 模型的設計選擇（依模型而異）：

• expert 數量：通常 8 ~ 256 個
• 每 token 啟用 expert 數：通常 1 ~ 2 個（top-k routing）
• shared expert：部分模型保留少數所有 token 共用的 expert
• total / active parameter 比：常見 5x ~ 10x（如 Qwen3-30B-A3B：30B total / 3B active）

事實查核註：MoE 架構的具體實作（router 演算法、load balancing loss、expert 並行策略等）依模型快速演進、引用前以該模型的技術報告或 paper 為準。

代表性 MoE 模型（依公開資訊）：Mixtral 8x7B、DeepSeek V3、Qwen3-30B-A3B、Llama 4 Scout 等。

設計責任

理解 MoE 後可以解釋三個現象：為什麼 MoE 模型的「30B 總參數」跟「3B active parameter」是兩個獨立指標（前者影響記憶體需求、後者影響速度）、為什麼 MoE 適合 CPU 卸載（不活躍的 expert 可以留在系統 RAM）、為什麼 MoE 在多 GPU 場景的並行策略跟 Dense 模型不同（expert 可以分到不同卡）。

選 MoE 模型 vs Dense 模型、需考慮：MoE 對 RAM 容量要求較高（要放所有 expert 權重）、對 GPU 算力要求較低（每 token 走 active parameter）；Dense 對 VRAM 容量要求較低（可全載中型模型）、對 GPU 算力要求較高。詳見 5.1 MoE 模型與 CPU 卸載策略 跟 5.5 PC 場景的模型選型優先順序。

概念位置

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 長度的權衡。

讀完本模組後、你應該能對自己這台 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 生態的相對位置。