原本使用論壇文章直接丟給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

重複內容 +53%，推理與散文零退步，VRAM 零成本。

但有個大前提：--spec-ngram-map-k4v-size-n 一定要拉到 32。用一般會照抄的 12 會在「格式重複但內容要換」的任務上反而變慢 5~10%（詳見第三節，這是本文最重要的發現）。

另外三個結論（細節在後面）：

1. spec_n_max=5 + p_min=0.4 是有害的——重複內容看起來變快，但推理 -22%、散文 -37%。
2. KV 量化不影響速度，只換容量。24GB 卡的實際天花板：q8_0/q8_0 約 128K、K q5_1/V q4_0 到 200K、q4_0/q4_0 到 224K。
3. VRAM 有懸崖不是斜坡：22.16 GiB 滿速、22.30 GiB 直接掉 40%。RADV 一旦把 buffer 溢出到 GTT（系統記憶體）就全線崩，256K 在 24GB 卡上不可行。

一、環境

為什麼沒走 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

（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）：

這也是為什麼「t/s」這個數字單獨拿出來沒意義——投機解碼的速度完全由內容的可預測性決定。測速一定要固定內容類型，不然數字可以任意漂移 3 倍。

️ 重要：上面「重複內容」那一欄是合成案例（叫模型把同一行印 30 次），是天花板不是實際值。
真實工作負載的收益差異極大，而且參數沒調好會變慢。務必看下面第三節。

三、真實工作負載才是重點：k4v 不是無腦贏，size-n 是關鍵旋鈕

合成案例好看不代表實用。我另外做了四個貼近實務的測項，都是「輸出跟輸入/前文有部分重複」的任務：

• 程式碼改寫：給一支 40 行 Python，要求改一個函式、其餘原樣輸出完整檔案
• 模板批次產出：給一張角色設定卡，要求用同格式再產 3 張（格式重複、內容全新）
• 字幕重排：給一段 SRT，文字完全不動、只把時間軸各推後 2 秒
• 長文引述：逐條照抄規格原文再接上判定

先看「照抄別人推薦的 size-n 12」會發生什麼事（RTX 4080S、其餘參數不變）：

**有兩項變慢了。**原因看 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）：

字幕重排的接受率從 0.60 直接拉到 1.00——n=12 的誤開火在 AMD 上代價更慘（那張卡本來就比較吃虧），修好之後 +37%。

min_hits 不要動

我試過 --spec-ngram-map-k4v-min-hits 2（要求 n-gram 出現兩次才採用），結果四項數字跟完全關掉 k4v 一模一樣（draft 計數逐項相同）。等於直接把功能關掉，別浪費時間。

所以什麼情況真的會用到？

一句話：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 驗證（每輪都把前面的回覆整包送回去）：

第 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，避免第一次推理時的分頁抖動。

八、測速方法（請照著做，不然數字沒有意義）

1. 固定內容類型分開報。我用三種：重複輸出（n-gram 天堂）、數學推理（結構化）、創造性散文（不可預測）。混在一起測等於自欺欺人。
2. temperature=0，不然每次採樣路徑不同、接受率跟輸出長度都會飄。
3. 讀 timings.predicted_per_second，不要用「總時間 ÷ token 數」（會把 prefill 算進去）。
4. 看 draft_n / draft_n_accepted。速度異常時先看接受率，八成問題在那裡。
5. 注意輸出長度。同一個 prompt 兩個配置可能一個寫 335 token、一個寫 369 token，t/s 會差 3% 但那不是速度差異。
6. 每次改設定都完整重啟 + 暖機一次，第一發請求永遠偏低。
7. 同一配置至少測兩次估噪音。我這台是 ±1%，超過這個範圍才算真差異。

九、給 RDNA3 同好的重點整理

1. 先加 --spec-type ngram-map-k4v,draft-mtp，並且 --spec-ngram-map-k4v-size-n 32。零成本、零 VRAM、零重編，逐字重現類任務直接快 40~60%。這是本次唯一真正的效能來源。size-n 太小會在部分任務上倒扣，是唯一要小心的地方。
2. n_max 保持 3、不要設 p_min。猜多了在不可預測內容上是純虧損。
3. KV 量化只換容量不換速度。想要長 ctx 用 K q5_1 / V q4_0；q5_K 不存在於 KV cache。
4. 盯 VRAM 佔用，天花板約 22.2 GiB。過線不會報錯，只會靜靜地掉 40%。24GB 卡別想 256K。
5. Vulkan 別自卑。prefill 146~166 t/s、decode 124 t/s，不裝 ROCm、不編 HIP、不移植 FP4。
6. 穩定性四件套免費，直接加。
7. 投機解碼的 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 三個參數，其餘指令列完全一致）：

重複內容 108.6 → 178.6 t/s，比 7900 XTX 的 +53% 收益更大，推理與散文同樣沒有退步。

順手掃了 n_max 的交互作用（k4v 開啟下）

規律很乾淨：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 都該開，成本是零。

所有數據為同一台機器單次工作階段內連續實測，含失敗組合。有錯歡迎指正。