一台機器兩張 32GB R9700（ROCm 7.2 + Mesa 25.2.8，280W cap）。GPU1 跑 SGLang（Qwen3.8-27B AWQ int4，192K），GPU0 原本空閒，09-03 起加跑 llama.cpp Vulkan（同模型 GGUF + MTP 投機解碼）。所有數字皆本機實測，方法與原始數據見文末。

一句話：llama.cpp MTP 在 code / JSON / 工具呼叫這類可預測內容上，192K 深度 decode 約 1.5 倍、短上下文 2.4–3.4 倍於 SGLang；但散文、長思考反而較慢（投機解碼對不可預測內容是淨負）。

先謝過幾位前輩的實測鋪路：

@Brian 前輩《双 R9700 部署 — GPU1 跑 SGLang 256K 大模型，GPU0 跑 ComfyUI MiniMax H3 视频》(lcz.me/topic/1416) — 本機 SGLang 部署配置即參照此文，依實況改 192K、GPU0 不跑 ComfyUI
@PhoenixRise2026 前輩《R9700 32GB 跑 Qwen3.8-27B：llama.cpp Vulkan + MTP 实测与踩坑记录》(lcz.me/topic/1218)
@Zero Snow 前輩《單張 RX 7900 XTX 24GB Qwen3.8-27B 優化紀錄 —— Vulkan 路線實測報告》(lcz.me/topic/1398)
@Johnalee4 前輩《分享自己的经验 7900 XTX Vulkan 主线 llama.cpp DSpark / DFlash/MTP 投机解码实测》(lcz.me/topic/1050)

1. 硬體與環境

磁碟分割（p4 = /home 574.7G）：

• p1 1G EFI
• p2 326G / ext4
• p3 29.8G swap
• p4 574.7G /home ext4

關鍵背景：gfx1201（RDNA4）不在 ROCm 官方支援列表，SGLang 能跑靠 HSA_OVERRIDE_GFX_VERSION=12.0.1 + patch fork；32G 單卡塞 192K 靠 AWQ int4 權重 + fp8 KV cache。CPU 只負責排程（~1.8 核）與 tokenizer，不構成瓶頸。

2. SGLang 啟動（GPU1，port 23334）

python -m sglang.launch_server \
  --model-path /home/benai/AI/models/Qwen3.8-27B-AWQ \
  --enable-multimodal --quantization awq \
  --served-model-name qwen3.8-27b \
  --dtype bfloat16 --kv-cache-dtype fp8_e4m3 \
  --context-length 196608 --mem-fraction-static 0.85 \
  --max-running-requests 1 \
  --num-continuous-decode-steps 16 \
  --chunked-prefill-size 8192 --max-prefill-tokens 16384 \
  --cuda-graph-backend-decode full --attention-backend triton \
  --max-mamba-cache-size 8 --mamba-ssm-dtype bfloat16 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
  --trust-remote-code --watchdog-timeout 1200 \
  --host 0.0.0.0 --port 23334

3. 環境變數（從在跑 process 實抓）

ROCm / RDNA4 映射

穩定性（RDNA4 上 crash 主要來源，全關）

AMD 版 FlashAttention 走 Triton

效能 / 雜項

SGLang 為 v0.5.18 + 70 個 RDNA4 patches（editable install 進 conda env sglang-triton36-v0518）。服務：sglang.service（system 級，Restart=on-failure，重啟後約 55 秒通過健康檢查）+ gpu-power-cap.service（開機把兩卡 power cap 寫回 280W——sysfs 重開機會還原 300W 預設）。

4. SGLang 實測（250 / 280 / 300W 三檔功率）

方法：同 prompt 連續三輪，每輪前後驗證 sysfs 上限；token 數 tokenizer 實測校準（15K prompt = 14,664 tok，50K = 48,784）。

項目                250W      280W      300W
Decode (512 tok)    26.0      26.4      26.7     t/s
Prefill 15K 冷      1450      1539      1567     t/s (10.1/9.5/9.3s)
Prefill 50K 冷      1008      1040      1052     t/s (48.4/46.9/46.4s)
Warm 15K (radix)    2885      3028      —        t/s (5.1/4.8s)
Decode 實耗         249/253   274/313   299/307  W (均/峰)

功率差距（相對 300W）：280W 約 −1.1~−1.8%，250W 約 −2.6~−7.7%。R9700 decode 受 VRAM 頻寬限制而非功率，280W 是平衡點。

上下文掃描矩陣（冷啟動 prefill + 128 tok decode）：

== 250W ==
Context  Prefill   TTFT      Decode
64K      774 t/s   84.7s     25.4 t/s
128K     461 t/s   284.5s    25.3 t/s
192K     328 t/s   599.6s    25.3 t/s
256K     255 t/s   1027.1s   25.3 t/s

== 280W ==
Context  Prefill   TTFT      Decode
64K      785 t/s   83.5s     25.8 t/s
128K     468 t/s   280.2s    25.7 t/s
192K     334 t/s   588.4s    25.7 t/s
256K     259 t/s   1010.2s   25.7 t/s

== 300W ==
Context  Prefill   TTFT      Decode
64K      797 t/s   82.2s     25.9 t/s
128K     472 t/s   278.0s    25.9 t/s
192K     336 t/s   585.6s    25.9 t/s
256K     262 t/s   1001.3s   25.9 t/s

矩陣結論：

• 上下文是主角，功率是配角：64K→256K prefill 掉 3.0×；功率 250→300W 全程只差 2–3%
• Decode 幾乎不受深度影響：同功率下 64K→256K 只差 0.1–0.2 t/s
• Prefill 衰減：深度每翻倍約 −40%，長文冷啟動就是要等；radix cache 重複前綴（15K 冷 1,539 → warm 3,028 t/s）可避開

5. llama.cpp 部署（GPU0，port 23335）

llama-server -m Qwen3.8-27B-UD-Q4_K_XL.gguf -md MTP/mtp-Qwen3.8-27B-Q4_0.gguf \
  --mmproj mmproj-F16.gguf -c 196608 -ctk q5_1 -ctv q4_0 \
  -fa on -ngl 999 --no-mmap -np 1 --jinja \
  --spec-type draft-mtp --spec-draft-n-max 5 \
  -b 512 -ub 256 -t 12 --cache-ram 16384 \
  -dev Vulkan0 --host 0.0.0.0 --port 23335

雙卡必顯式指定：VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json + -dev Vulkan0（Vulkan0 = 03:00.0 那張，別假設順序）。同深度後續請求走 prompt cache，補 prefill delta 後 TTFT 可低至 0.5s。

6. llama.cpp 實測 vs SGLang（皆 280W cap）

方法：temp=0、prefill ≥2000 tok、decode ≥512（math 900）、每格 ≥2 次取均值、暖機後測、讀 server timings（predicted_per_second + draft_n_accepted/draft_n 算接受率）、內容型別分開報。

decode 主對比（llama.cpp = MTP n4；SGLang 取同深度實測值 25.8@64K / 25.7@192K / 26.4 short）：

場景             llama.cpp t/s  MTP 接受率  SGLang t/s  倍數
code 改寫 @61K    64.9           97.9%       25.8        2.52x
code 改寫 @190K   40.0           96.8%       25.7        1.56x
JSON 批次 @61K    40.5           71.6%       25.8        1.57x
JSON 批次 @190K   26.1           87.3%       25.7        1.02x
math 思考 @61K    37.0           71.9%       25.8        1.43x
math 思考 @190K   22.8           71.1%       25.7        0.89x
prose 散文 @61K   19.4           24.9%       25.8        0.75x
prose 散文 @190K  12.4           27.5%       25.7        0.48x

• math / JSON @190K 取自 k4v+MTP 組（與 MTP-only 實測逐項相同）。短 ctx（n_max=5）code 可到 90.5 t/s = 3.43x。

深度衰減（MTP n4，61K→190K 約 ×0.62）：

內容        @61K    @190K   衰減
code 改寫   64.9    40.0    62%
math 思考   37.0    22.8    62%
prose 散文  19.4    12.4    64%

256K 臂（ctx 262144）：單卡可載（240K fill 後 VRAM 23.9G / 32G，無 GTT spill）——24GB 的 7900XTX 做不到：

Prefill 對照（cold，含 JIT 暖機）：

引擎        深度    t/s     TTFT
llama.cpp   61K     441     123s
llama.cpp   190K    246     744s
SGLang 280W 64K     785     83.5s
SGLang 280W 192K    334     588.4s

llama.cpp RADV prefill 較慢（約 0.55–0.73x），長文冷啟動是 SGLang 強項；但 prompt cache 讓同深度後續請求只補 delta（實測 TTFT 0.5–4.6s）。Mesa 26.1.7 另有 prefill +15% 潛力，未測。

7. 參數專項（code 任務）

臂                      t/s    接受率   結論
n_max=3 (short)         62.2   96.7%    基準
n_max=5 (short)         90.5   97.0%    +46% → code 密集用 n5
size-n=32 @61K (=MTP)   64.9   97.9%    k4v 從未觸發
size-n=12 @61K          44.5   95.3%    n-gram 誤開火 -32%（陷阱確認）
KV q4_0 @61K            44.8   95.3%    KV 量化傷接受率 -31%
KV q5_1/q4_0 @61K       64.9   97.9%    推薦

三個跟論壇結論不同的地方（本機實測）：

• ngram-map-k4v 零貢獻：MTP 接受率已 .97–.98 飽和，k4v 的 draft 計數與 MTP-only 完全相同（從未觸發）。且 k4v 的 n-gram map 在 cache 截斷時會觸發約 13 分鐘整段重 prefill（MTP-only 只需數秒）→ 直接關
• KV 量化會掉速：q4_0 KV 讓 code 接受率 .979→.953、速度 65→45 t/s——KV 精度傷注意力 → 草稿接受率掉 → 投機速度崩。省 VRAM 用 K q5_1 / V q4_0，別整組 q4_0
• size-n=12 是陷阱：與 @Zero Snow 前輩結論一致；本機 s32 等於沒開（見第一點）

8. 品質探針

• 死循環 watch：√2 無理性證明（thinking on，900 tok）無循環，重複 12-gram 僅 2 次（AWQ 為 4 次）
• AWQ 並排：同預算 GGUF 輸出 2249 chars vs AWQ 1435 chars——token 效率更好、無品質退化（UD-Q4_K_XL，沒遇到 Q4_K_M 的思考死循環問題）
• 視覺辨識：合成圖（紅圓 / 藍方 / 綠字 HERMES-42 + 標籤）全數正確，連「右緣文字被裁切」都如實回報

9. 優劣歸納（純比較）

• llama.cpp 優：可預測內容 decode 快 1.5–3.4x（投機本質）；短 ctx 極快；256K 單卡可行；主線無 fork 維護；KV 型別彈性大
• SGLang 優：prefill 冷啟動快 1.5–1.8x；散文 / 思考不扣分（decode 恆 ~26）；reasoning / tool-call parser 完整
• llama.cpp 劣：低可預測內容投機淨負（散文 @192K 僅 12.4）；prefill 慢（RADV 25.2.8）
• SGLang 劣：無投機解碼（decode 天花板 ~26，內容再可預測也上不去）；fork + 70 patches 維護重（DFlash2 需 rebase 上游）

10. 踩坑補充

SGLang / ROCm 側

• stock SGLang 跑不了 RDNA4 → patch fork + HSA_OVERRIDE_GFX_VERSION=12.0.1 缺一不可
• --attention-backend triton 要顯式指定（預設 FA 路徑在 AMD 不可用）
• --kv-cache-dtype fp8_e4m3 是長上下文省顯存主力
• AITER / SDMA / tunableop 在 RDNA4 上是 crash 來源，全關
• --watchdog-timeout 調大（長 prefill 會被預設值誤殺）
• 功率上限是 sysfs，重開機失效 → 靠 gpu-power-cap.service 重設
• 雙卡務必 HIP_VISIBLE_DEVICES 物理隔離

llama.cpp 側

• k4v n-gram map 是雙面刃：接受率飽和時零貢獻 + cache 截斷 13 分鐘重 prefill → 關
• cache 行為：同深度換任務型別只補 delta（快）；換深度 = 整段重 prefill（190K 約 12 分鐘）→ bench 按深度分組跑
• 主線已含 DSpark/DFlash/MTP（PR #25173 / #22105）——SGLang fork 卡住的 DFlash2 可轉此處
• --no-mmap 已棄用（改 --load-mode），現行仍可用僅 warning
• hf download 多檔要分開多次 --include，否則後面檔名被當 positional

方法學：SGLang 側為本機 09-02 三檔功率 × 四深度 matrix（原始 JSON 與在跑 sglang.service 一致）；llama.cpp 側為 09-03 同機 GPU0 實測。所有 t/s 皆 decode 穩態（非峰值），TTFT 為完整 prefill 首 token 時間。原始數據在本機 AI/bench/llamacpp-m4/results.json。方法學參考 @Zero Snow 前輩 篇 §8 與 @Johnalee4 前輩 篇（內容型別分開報、temp=0、讀 timings 非掐錶）。