原本使用論壇文章直接丟給AI
最後他給我跑出來的 Qwen3.8-27B 跑起來 25~60 t/s 上下幅度很大
複雜任務常常掉到 3x t/s
後來在b站看到 链接文本
把裡面的資訊整理一下貼給AI 優化，發現平均速度明顯提升
最低常常維持在40~50 tok/s
AI 跟我說重複的內容可以跑到 120 TOK/S 我是不太相信, 我自己跑平常的任務
大概是 40~60 TOK/S
另外我目前是使用 OCuLink 從M.2 外接顯卡的，看起來這塊影響不大
詳細記述我也不太懂, 反正優化不錯就丟上來給大家參考
-----AI 整理報告
單張 RX 7900 XTX 24GB 把 Qwen3.8-27B 推到 124 t/s —— Vulkan 路線實測報告
起因：看到一篇「7900XTX 用 ROCm HIP + FP4 把 Qwen3.8-27B 推到 97.8 t/s、256K 上下文」的技術報告，想照著優化自己的機器。
結果：用 Vulkan 就打到 124 t/s，而且是在完全不重編、不換權重、不裝 ROCm 的情況下，關鍵只有一個參數。
底下每個數字都是同一台機器實測，含失敗的組合與踩到的坑，方便大家直接抄或避雷。
TL;DR
加一個參數：--spec-type ngram-map-k4v,draft-mtp
| 配置 | 重複內容 | 推理內容 | 創造性散文 | VRAM |
|---|---|---|---|---|
| 原本（只有 MTP 自投機） | 80.8 t/s | 66.4 t/s | 40.9 t/s | 22.02 GiB |
| 加上 ngram-map-k4v | 124.0 t/s | 67.1 t/s | 41.9 t/s | 21.96 GiB |
| 參考文章的 HIP+FP4 極限方案 | 97.8 t/s | 68.7 t/s | 29~33 t/s | 24.2 GiB |
重複內容 +53%，推理與散文零退步，VRAM 零成本。
但有個大前提：--spec-ngram-map-k4v-size-n 一定要拉到 32。用一般會照抄的 12 會在「格式重複但內容要換」的任務上反而變慢 5~10%（詳見第三節，這是本文最重要的發現）。
另外三個結論（細節在後面）：
spec_n_max=5+p_min=0.4是有害的——重複內容看起來變快，但推理 -22%、散文 -37%。- KV 量化不影響速度，只換容量。24GB 卡的實際天花板：
q8_0/q8_0約 128K、K q5_1/V q4_0到 200K、q4_0/q4_0到 224K。 - VRAM 有懸崖不是斜坡：22.16 GiB 滿速、22.30 GiB 直接掉 40%。RADV 一旦把 buffer 溢出到 GTT（系統記憶體）就全線崩，256K 在 24GB 卡上不可行。
一、環境
| 項目 | 內容 |
|---|---|
| GPU | AMD Radeon RX 7900 XTX（Navi 31 / gfx1100），sysfs 回報 VRAM 23.98 GiB |
| 後端 | Vulkan（RADV） —— 不是 ROCm/HIP |
| OS / RAM | Ubuntu 24.04 / 31 GB |
| 推理引擎 | llama.cpp 帶投機解碼分支（llama-server 0.3.0-dev，ggml 0.22.0），build-vulkan |
| 模型 | Qwen3.8-27B unsloth Q4_K_M（15.93 GiB）+ mmproj-BF16（0.87 GiB，視覺） |
為什麼沒走 HIP
原文把 HIP 當效能基座（prefill 105 t/s）。但我這台 Vulkan 的 prefill 實測 146~166 t/s，本來就比它快，加上機器裡 ROCm 7.2.4 的 dpkg 記錄雖然在、/opt/rocm-7.2.4 的檔案卻已經被清掉（hipcc、rocminfo 都不存在），要重裝是好幾 GB。投機解碼的收益跟後端無關，所以整條 HIP + ROCm-FP4 移植路線我直接跳過——那部分還需要自己逐算子移植 STX 4-bit 格式，並且沒有現成的 FP4 權重檔。
結論：如果你是 RDNA3 想跑大模型，Vulkan 已經夠好，先別為了「AMD 就該用 ROCm」去折騰。
模型結構（決定 KV 開銷的關鍵）
Qwen3.8-27B（qwen35 架構）是混合注意力：
qwen35.block_count = 65 # 其中 blk.64 是內建 MTP 頭
qwen35.full_attention_interval = 4 # → 64 層裡只有 16 層是全注意力
qwen35.attention.key_length = 256
qwen35.attention.value_length = 256
qwen35.attention.head_count_kv = 4
qwen35.nextn_predict_layers = 1 # 內建 MTP，不需要外掛 draft 模型
只有 16 層全注意力會隨上下文長度吃 KV，其餘 48 層是 DeltaNet 線性注意力（狀態固定大小）。所以：
每 token 的 K（或 V）元素數 = 16 層 × 4 kv heads × 256 = 16384
| KV 型別 | bits/elem | 每 token 每側 | 每 token K+V | 64K ctx |
|---|---|---|---|---|
| f16 | 16 | 32 KiB | 64 KiB | 4.0 GiB |
| q8_0 | 8.5 | 17 KiB | 34 KiB | 2.13 GiB |
| q5_1 | 6.0 | 12 KiB | 24 KiB | 1.50 GiB |
| q5_0 | 5.5 | 11 KiB | 22 KiB | 1.38 GiB |
| q4_0 | 4.5 | 9 KiB | 18 KiB | 1.13 GiB |
（f16 每 64K 剛好 4 GiB，跟原文的觀測吻合。這張表可以直接拿來算你要開多少 ctx。）
二、核心優化：把 n-gram 映射疊在 MTP 上
llama.cpp 的投機解碼分支支援多種投機器同時啟用，--spec-type 吃逗號清單：
--spec-type none,draft-simple,draft-eagle3,draft-mtp,draft-dflash,draft-dspark,
ngram-simple,ngram-map-k,ngram-map-k4v,ngram-mod,ngram-cache
原本只開 draft-mtp（模型內建 MTP 頭自投機）。改成 ngram-map-k4v,draft-mtp 之後：
--spec-type ngram-map-k4v,draft-mtp \
--spec-draft-n-max 3 \
--spec-ngram-map-k4v-size-n 12 \
--spec-ngram-map-k4v-size-m 48 \
--spec-ngram-map-k4v-min-hits 1
原理：ngram-map-k4v 從已生成的上下文做 n-gram 查表，命中就一次吐出最多 48 個 draft token（size-m 48）。這在有重複結構的內容上幾乎零成本地暴力加速；沒命中就退回 MTP，所以不會拖慢其他內容。MTP 是「每步猜 3 個」，n-gram 是「命中就猜一大段」，兩者互補。
看接受率就很清楚（來自 timings.draft_n_accepted / draft_n）：
| 內容類型 | 接受率 | 解讀 |
|---|---|---|
| 重複內容 | 463/463 = 1.00 | n-gram 全中，等於免費 |
| 推理內容 | 356/462 = 0.77 | MTP 為主 |
| 創造性散文 | 171/489 = 0.35 | 本質不可預測，投機幫不上 |
這也是為什麼「t/s」這個數字單獨拿出來沒意義——投機解碼的速度完全由內容的可預測性決定。測速一定要固定內容類型，不然數字可以任意漂移 3 倍。
️ 重要：上面「重複內容」那一欄是合成案例（叫模型把同一行印 30 次），是天花板不是實際值。
真實工作負載的收益差異極大，而且參數沒調好會變慢。務必看下面第三節。
三、真實工作負載才是重點：k4v 不是無腦贏，size-n 是關鍵旋鈕
合成案例好看不代表實用。我另外做了四個貼近實務的測項，都是「輸出跟輸入/前文有部分重複」的任務：
- 程式碼改寫：給一支 40 行 Python，要求改一個函式、其餘原樣輸出完整檔案
- 模板批次產出：給一張角色設定卡，要求用同格式再產 3 張（格式重複、內容全新）
- 字幕重排：給一段 SRT，文字完全不動、只把時間軸各推後 2 秒
- 長文引述：逐條照抄規格原文再接上判定
先看「照抄別人推薦的 size-n 12」會發生什麼事（RTX 4080S、其餘參數不變）：
| 情境 | 關 k4v | k4v n=12 | 差異 | 接受率變化 |
|---|---|---|---|---|
| 程式碼改寫 | 104.1 | 166.4 | +60% | 0.93 → 0.72 |
| 長文引述 | 99.8 | 98.4 | -1.4% | 0.89 → 0.82 |
| 模板批次產出 | 72.0 | 68.4 | -5% | 0.57 → 0.39 |
| 字幕重排 | 106.1 | 95.8 | -10% | 0.96 → 0.51 |
**有兩項變慢了。**原因看 draft 計數就很清楚——字幕重排在 n=12 時 draft 了 992 個 token 只接受 510，而不開 k4v 是 draft 536 接受 514。n-gram 一直開火、一直猜錯，白做了 450 個 token 的計算。
為什麼字幕會猜錯？因為那個任務要「文字照抄、時間軸改掉」。n-gram 看到前文就把舊的時間戳一起預測出來，每到時間軸就撞牆。格式重複但內容要換的任務，n-gram 是負資產。
掃 --spec-ngram-map-k4v-size-n（查表 n-gram 長度）
size-n 決定「要比對多長的前文才算命中」。拉長 = 更嚴格 = 少開火但更準。完整掃描（RTX 4080S）：
| size-n | 程式碼改寫 | 模板批次 | 字幕重排 | 長文引述 | 合成重複 |
|---|---|---|---|---|---|
| 關閉 | 104.1 | 72.0 | 106.1 | 99.8 | 108.6 |
| 12 | 166.4 | 68.4  |
95.8 |
98.4 | 178.6 |
| 24 | 169.1 | 70.2 | 100.9 |
98.0 | — |
| 32（建議） | 157.0 | 71.1 | 105.4 | 99.1 | 237.0 |
| 40 | 136.0 | 71.9 | 104.8 | 99.2 | 236.9 |
size-n 32 是甜蜜點：程式碼改寫還有 +51%、合成重複衝到 237 t/s（+118%），而所有負面項全部收斂到 ±1.3% 的噪音內。n=24 的程式碼分數最高但字幕還是掉 5%；n=40 開始連程式碼都保不住。
在 7900 XTX 上交叉驗證（同樣有效）
同一個發現搬到 AMD 卡（Vulkan、K q5_1/V q4_0、200K ctx，只改 size-n）：
| 情境 | k4v n=12 | k4v n=32 | 差異 |
|---|---|---|---|
| 程式碼改寫 | 79.3 | 109.1 | +38% |
| 字幕重排 | 58.8 | 80.6 | +37%（接受率 0.60 → 1.00） |
| 模板批次產出 | 51.6 | 51.8 | — |
| 長文引述 | 78.4 | 78.8 | — |
字幕重排的接受率從 0.60 直接拉到 1.00——n=12 的誤開火在 AMD 上代價更慘（那張卡本來就比較吃虧），修好之後 +37%。
min_hits 不要動
我試過 --spec-ngram-map-k4v-min-hits 2（要求 n-gram 出現兩次才採用），結果四項數字跟完全關掉 k4v 一模一樣（draft 計數逐項相同）。等於直接把功能關掉，別浪費時間。
所以什麼情況真的會用到？
| 你的任務長這樣 | k4v 收益 |
|---|---|
| 要模型把一整份檔案/文章原樣吐回來，只改幾行（程式碼重構、翻譯校對、逐條批註） | +40~60%，最有價值 |
| 大量重複的結構化輸出（JSON/YAML/SRT/表格批次） | 中等，前提是 size-n 要夠大 |
| 逐條照抄原文再加判定（規格檢查、RAG 引述、法條比對） | 小幅或持平 |
| 格式固定但內容全新（套模板產新資料） | 持平（n=12 會變慢） |
| 純創作、思考鏈、對話 | 無感（不會變慢） |
一句話：k4v 賺的是「逐字重現」，不是「格式相似」。 只要你的工作流裡有「把長內容原樣搬過去、只動一小塊」，這招就非常值得；如果全是從零創作，就當它不存在（也不會扣分）。
四、全部實測結果（合成案例，含失敗組合）
測法：同一組固定 prompt、temperature=0、max_tokens=512、stream=false，讀 llama-server 回傳的 timings.predicted_per_second（不是自己掐秒錶）。每次改設定都完整重啟服務、跑一次暖機再測。
| # | 配置 | 重複 | 推理 | 散文 | VRAM | 判定 |
|---|---|---|---|---|---|---|
| 0 | 基準：MTP n3、q8_0 KV、128K | 80.8 | 66.4 | 40.9 | 22.02 | 起點 |
| 1 | k4v+MTP、n_max=5 / p_min=0.4、q8_0、128K | 95.2 | 51.6 | 26.2 | 22.02 | 有害 |
| 2 | k4v+MTP、n_max=3 不設 p_min、q8_0、128K | 123.9 | 66.9 | 41.8 | 21.96 |  |
| 3 | 同上但 KV 換 q4_0、128K | 124.5 | 68.4 | 40.4 | 19.96 | 省 2GB |
| 4 | q4_0、160K | 123.9 | 68.2 | 40.2 | 20.68 | |
| 5 | q4_0、192K | 124.1 | 68.1 | 40.3 | 21.40 | |
| 6 | q4_0、224K | 123.9 | 68.1 | 40.1 | 22.12 | 純 q4_0 上限 |
| 7 | K q5_1 / V q4_0、200K | 124.1 | 68.1 | 40.9 | 22.16 | 最佳折衷 |
| 8 | K q5_1 / V q4_0、224K | 76.8 | 40.5 | 23.2 | 22.30 | 爆 |
| 9 | q4_0、256K | 76.9 | 40.9 | 23.3 | 22.37 | 爆 |
噪音水準：同一個配置重跑，重複內容 124.7 → 123.6（-0.9%）。所以 1% 以內的差別都不要當真。
坑 1：n_max=5 + p_min=0.4 是陷阱
原文推薦 n5/p0.4。實測（#1 vs #2）：重複內容 95.2，看起來不錯；但推理掉 22%、散文掉 37%。原因是 draft 猜長了、接受率上不去（散文只有 0.39），每步都在做白工。
原文自己的數據也有同樣特徵（散文只有 29~33 t/s）。維持 n_max=3、不要設 p_min，重複內容反而衝到 123.9——比它們的 97.8 還快 27%。
坑 2：VRAM 是懸崖，不是斜坡
看 #5→#6→#8→#9 的 VRAM 與速度：
21.40 GiB (192K) → 滿速
22.12 GiB (224K) → 滿速
22.16 GiB (200K, q5_1) → 滿速 ← 上限就在這附近
22.30 GiB (224K, q5_1) → 掉 40%
22.37 GiB (256K) → 掉 40%
**天花板在 22.16 ~ 22.30 GiB 之間，只有約 140 MB 的餘裕。**超過之後 RADV 會把 buffer 靜靜地放到 GTT（走 PCIe 的系統記憶體），不會報錯、不會 OOM，就是全線掉 40%，非常容易誤判成「256K 本來就比較慢」。
我特別驗證過不是分層掉到 CPU：#6(224K) 與 #3(128K) 的 VRAM 差 2.16 GiB，剛好等於多出來的 q4_0 KV（229376-131072 tokens × 18 KiB = 2.13 GiB），所有層都還在 GPU 上。
所以 24GB 卡跑 27B Q4_K_M + 視覺投影，256K 是不可行的（原文能到是因為開了 SAM 拿到 25.75 GiB 的預算，而且用更小的 FP4 權重）。
坑 3：q5_K 不能當 KV cache
原文寫「引入 q5_k / q4_0 組合」——這個參數傳不進去：
$ llama-server --cache-type-k q5_K
error while handling argument "--cache-type-k": Unsupported cache type: q5_K
allowed values: f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1
KV cache 只吃「legacy 量化」。K-quant（q5_K/q4_K…）用 256 元素超級區塊＋階層子縮放，flash-attention 的 KV 讀寫核心沒有實作那種存取樣式。
想要 5-bit KV 就用 q5_1（6 bits/elem，比 q5_0 多一個 zero-point，精度較好）。而且 K 比 V 敏感，可以不對稱配置：
--cache-type-k q5_1 --cache-type-v q4_0 # → 200K 滿速，VRAM 22.16 GiB
這是我最後採用的長上下文方案：比純 q4_0 的 224K 只少 11% 容量，換到 K 精度 +33%。
坑 4：KV 量化不會讓你變快，別指望它
#2(q8_0) vs #3(q4_0) 在同樣 128K 下：123.9/66.9/41.8 vs 124.5/68.4/40.4——差異在噪音內。KV 量化省的是 VRAM，買到的是 ctx，不是速度。（順便：#3 的散文看起來慢 3%，實際是因為模型那次多寫了 14 個 token 才停，屬於輸出長度差異，不是吞吐量差異。這種假訊號在 benchmark 裡很常見。）
沒踩到的坑：注意力旋轉
原文說開 KV 量化會在 hadamard 旋轉路徑觸發 GGML_ASSERT(buffer) abort，必須 export LLAMA_ATTN_ROT_DISABLE=1。
我 q8_0 / q5_1 / q4_0 三種 KV 量化全部在旋轉開啟的狀態下正常運行，沒有崩。旋轉本身是提升量化 KV 精度的，能不關就別關。如果你真的撞到那個 assert 再開這個環境變數。
五、「越聊越慢」的穩定性套件
原文提到多輪對話後解碼一路下滑，因為 kv_unified 預設共享 KV，混合架構跨請求保不住狀態，每輪都要全量重算 prefill。修法是四件套：
--no-kv-unified --parallel 1 --ctx-checkpoints 2 --cache-ram 4096
實測：這組完全不影響速度（#8 加了三件套 vs #9 沒加，數字一模一樣），所以就算你沒遇到問題也可以直接加上。
4 輪對話的增量 prefill 驗證（每輪都把前面的回覆整包送回去）：
| 輪次 | 重新 prefill 的 token 數 | prefill 耗時 | decode |
|---|---|---|---|
| 1 | 24 | 0.32s | 38.69 t/s |
| 2 | 190 | 1.08s | 41.11 t/s |
| 3 | 164 | 1.08s | 42.17 t/s |
| 4 | 158 | 1.08s | 42.55 t/s |
第 2 輪只重算 190 token（= 新增的助手回覆 + 新問題），不是整段對話，而且 decode 速度沒有衰減反而微升。沒有雪崩。
六、DFlash2 sidecar：想用要重編
原文最終方案用 --spec-type ngram-map-k4v,draft-dflash 搭 DFlash2 側掛 drafter。我下了 z-lab/Qwen3.8-27B-DFlash2（Q4_K_M 只有 1.06 GB），載入直接失敗：
llama_model_load: error loading model: done_getting_tensors:
wrong number of tensors; expected 81, got 58
差的 23 個張量正好是 blk.*.attn_conv_base、blk.*.attn_conv_proj、blk.*.ffn_conv_base、blk.*.ffn_conv_proj（4×5=20）＋ selector_hidden / selector_predecessor / selector_successor（3）。也就是舊的 dflash 實作不認識 DFlash2 的 conv + selector 結構，要用得換帶 DFlash2 支援的原始碼重編。
不過：我沒重編也已經比它們的 97.8 快了，所以這步的邊際效益要自己評估。（有人編起來測到請回報，我很想知道 k4v + dflash 對散文有沒有幫助——那是目前唯一還是弱項的內容類型。）
七、最終配置（可直接抄）
方案 A：極速（KV 精度優先，128K）
./build-vulkan/bin/llama-server \
-m models/Qwen3.8-27B-unsloth-Q4_K_M.gguf \
--mmproj models/mmproj-Qwen3.8-27B-BF16.gguf \
-c 131072 -fa on -np 1 -t 16 -tb 6 -ub 256 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--device Vulkan0 --fit on --no-mmap \
--no-kv-unified --ctx-checkpoints 2 --cache-ram 4096 \
--spec-type ngram-map-k4v,draft-mtp \
--spec-draft-n-max 3 --spec-draft-threads 4 --spec-draft-threads-batch 4 \
--spec-ngram-map-k4v-size-n 32 \
--spec-ngram-map-k4v-size-m 48 \
--spec-ngram-map-k4v-min-hits 1 \
--host 0.0.0.0 --port 9120 --alias qwen38-max --jinja
→ 124.0 / 67.1 / 41.9 t/s，VRAM 21.96 GiB
方案 B：長上下文（200K）
把上面兩行 KV 改掉即可：
-c 204800 \
--cache-type-k q5_1 --cache-type-v q4_0 \
→ 124.1 / 68.1 / 40.9 t/s，VRAM 22.16 GiB
兩者速度完全相同，差別只有「K 精度 8.5 bit / 128K」對「6 bit / 200K」。
幾個參數的說明
--device Vulkan0：雙顯卡機器一定要指定，不然會被分到別張卡去。--fit on：讓引擎自適應分配、避免硬性 OOM。但要注意它可能安靜地把層搬到 CPU，看 VRAM 佔用比看 log 快。-ub 256：實測比預設好，prefill 沒有變慢。-t 16 -tb 6：CPU 執行緒；投機的 draft 執行緒另外用--spec-draft-threads 4。--no-mmap：權重直接載進 VRAM，避免第一次推理時的分頁抖動。
八、測速方法（請照著做，不然數字沒有意義）
- 固定內容類型分開報。我用三種：重複輸出（n-gram 天堂）、數學推理（結構化）、創造性散文（不可預測）。混在一起測等於自欺欺人。
temperature=0，不然每次採樣路徑不同、接受率跟輸出長度都會飄。- 讀
timings.predicted_per_second，不要用「總時間 ÷ token 數」（會把 prefill 算進去）。 - 看
draft_n/draft_n_accepted。速度異常時先看接受率，八成問題在那裡。 - 注意輸出長度。同一個 prompt 兩個配置可能一個寫 335 token、一個寫 369 token，t/s 會差 3% 但那不是速度差異。
- 每次改設定都完整重啟 + 暖機一次，第一發請求永遠偏低。
- 同一配置至少測兩次估噪音。我這台是 ±1%，超過這個範圍才算真差異。
九、給 RDNA3 同好的重點整理
- 先加
--spec-type ngram-map-k4v,draft-mtp，並且--spec-ngram-map-k4v-size-n 32。零成本、零 VRAM、零重編，逐字重現類任務直接快 40~60%。這是本次唯一真正的效能來源。size-n太小會在部分任務上倒扣，是唯一要小心的地方。 n_max保持 3、不要設p_min。猜多了在不可預測內容上是純虧損。- KV 量化只換容量不換速度。想要長 ctx 用
K q5_1 / V q4_0；q5_K不存在於 KV cache。 - 盯 VRAM 佔用，天花板約 22.2 GiB。過線不會報錯，只會靜靜地掉 40%。24GB 卡別想 256K。
- Vulkan 別自卑。prefill 146~166 t/s、decode 124 t/s，不裝 ROCm、不編 HIP、不移植 FP4。
- 穩定性四件套免費，直接加。
- 投機解碼的 t/s 是內容的函數，看到別人報單一數字先問「什麼內容」。
附錄：同一招在 NVIDIA 上一樣有效（+64%）
有人會問這是不是 AMD/Vulkan 特有的。不是——這是引擎層的投機解碼，跟後端無關。我在同一台機器的另一張卡上用完全相同的方法驗證：
環境：RTX 4080 SUPER（32GB 魔改版）、CUDA build、Qwen3.8-27B Q5_K_M、q4_0 KV、192K ctx、thinking 開啟（effort low / budget 1024）、外掛官方 mtp-Qwen3.8-27B-Q4_0 drafter。
單一變數對照（除了 --spec-type 與 k4v 三個參數，其餘指令列完全一致）：
| 配置 | 重複 | 推理 | 散文 |
|---|---|---|---|
draft-mtp（原本） |
108.6 | 88.0 | 62.7 |
ngram-map-k4v,draft-mtp |
178.6 | 89.5 | 63.2 |
| 增幅 | +64.5% | +1.7% | +0.8% |
重複內容 108.6 → 178.6 t/s，比 7900 XTX 的 +53% 收益更大，推理與散文同樣沒有退步。
順手掃了 n_max 的交互作用（k4v 開啟下）
--spec-draft-n-max |
重複 | 推理 | 散文 |
|---|---|---|---|
| 3 | 180.5 | 82.5 | 64.4 |
| 4（採用） | 178.6 | 89.5 | 63.2 |
| 5 | 183.5 | 91.1 | 59.4 |
規律很乾淨：n_max 越大，可預測內容越快、不可預測內容越慢（散文接受率從 0.57 掉到 0.39）。重複內容那欄三者都在 ±3% 噪音內，所以真正的取捨是「推理 vs 散文」。我選 4 當平衡點；如果你的用途偏程式碼/結構化輸出可以拉到 5，偏創作就用 3。
這也回頭解釋了本文坑 1：原文的 n5/p0.4 之所以災難，主因不是 n_max=5，而是再疊上 p_min=0.4 把低機率的 draft 也硬塞進去。
所以這招 NVIDIA / AMD 都該開，成本是零。
所有數據為同一台機器單次工作階段內連續實測，含失敗組合。有錯歡迎指正。