單張 RX 7900 XTX 24GB Qwen3.8-27B 優化紀錄 —— Vulkan 路線實測報告

[Zero Snow]

原本使用論壇文章直接丟給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%（詳見第三節，這是本文最重要的發現）。

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

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 卡上不可行。

---

一、環境

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

---

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

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 三個參數，其餘指令列完全一致）：

配置	重複	推理	散文
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 都該開，成本是零。

---

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

[terry]

挺好的分享，单卡单会话下很有价值。

[andyfay]

不错，多谢分享，R9700单卡Q5从30到40多了

[heheimback]

非常好的帖子，我去试下

[fantasy2026]

真不错！收藏了，支持

[coolstar]

@andyfay 说:

不错，多谢分享，R9700单卡Q5从30到40多了

谢谢老哥分享，Q5 40多不错了吧！

[heheimback]

大佬，有没有长上下文速度tps降的太多的优化方案呢

[Xiaote]

长上下文掉速，帮补个通用账（也值得公开回一下），先分清是哪种：

1. 线性掉速（正常物理账）：decode 每生成一个 token 都要把整段 KV 扫一遍，上下文翻倍 = KV 读取翻倍。27B 的 KV 约 37KB/token（q8 时），128K 上下文每次生成要扫约 4.7GB，掉速是必然不是 bug。能优化的是这几处：

• KV 量化 q8→q4_0：KV 字节和带宽占用直接减半，质量损失很小（站内实测 tg 只掉 2-3%），对长上下文收益最大；
• 窗口按需：别固定开 256K，什么任务开多大——短任务 16-32K 就够，速度立刻回来；
• 查"断崖"：如果掉速是断崖式的（到某个长度突然暴跌），那是显存不够、权重或 KV 溢出到内存了，先确认 -ngl 和 KV 缓存全在显存里，跟量化无关。

2. 边际提醒：MTP/投机解码在长上下文下收益会变小——draft 头每步也要扫同一段 KV，上下文越长它的成本越高，别指望投机解码救长窗。

如果能贴一下具体数字（多少 K 开始掉、从多少掉到多少、KV 量化开没开、有没有溢出），就能定位是纯物理账还是有配置问题。

[坤坤]

@heheimback 没办法，这是硬伤，单卡承受不住kv，势必会掉到内存，那瓶颈就是主板的pcie通道速度

[CHIA AN YANG]

推一個 優質好文,願意分享就給讚

[terry]

@CHIA-AN-YANG 既然你开口了，那就置顶，推下。

[gslzk]

可以加--no-mmproj-offload，让cpu计算图片，又可以省一些显存出来，而且速度不慢，适合读图不多的工作环境。

另外我加载了--chat-template-file D:\models\Qwen3.8-27B-GGUF\chat_template.jinja，可以让思考变少一些

[Ranford Wong]

非常感謝

[nami ryuu]

@zero-snow OCuLink 從M.2 外接顯卡你用的谁家的？

[AGI]

@gslzk 非常好的建议！很感谢！

[gslzk]

AGI 谢谢回复，其实还可以加--spec-draft-type-k q4_0 --spec-draft-type-v q4_0，这样可以更省一步显存，另外日常任务多用分身去完成，主体只获取子agent的答案，这样上下文消耗速度明显降低
。