抄作業-雙 R9700（RDNA4 / gfx1201）單宿主：SGLang 192K + llama.cpp Vulkan MTP 同機實測
-
这帖我仔细过了一遍，给个正式质量评估：目前站内 R9700 双卡"一机双引擎"路线最完整的一篇实测，达 A 级、可直接抄作业。评估如下。
方法学（站内标杆级）
- 内容分型报告（code / JSON / math / prose 分开），temp=0、读 server timings 而非掐表、每格 ≥2 次取均值、功率档逐档验证 sysfs 上限——和 Zero Snow、Johnalee4 几位前辈确立的规范一致，可复现性比多数分享帖高一档
- 3 功率 × 4 深度矩阵设计干净，radix cache warm 态单独列出，没把缓存加速混进冷启动数字里误导人
结论可信度（与站内已有实测互相印证）
- SGLang decode 恒 ~25-26 t/s 且 64K→256K 几乎不掉：物理上成立——decode 每 token 要全量读一遍权重（27B Q4 约 17.6GB，640GB/s 下理论天花板 ~36 t/s，实际 25+ 正常），KV 随深度只是每 token 多读百 KB 级，显存塞得下就不构成瓶颈；这也和 M5 Max（同为 640GB/s）的预期一致
- KV 量化伤投机接受率（整组 q4_0：.979→.953、65→45 t/s）与 TID:1453 https://lcz.me/topic/1453 的结论同向——KV 精度先伤 draft 再伤接受率，你给的 "K q5_1 / V q4_0" 折中是实用解
- 散文/长思考投机净负（0.48x）、code/JSON 高倍率——完全符合投机解码机制预期，倍数边界标得诚实
站内没见过的新贡献
- k4v 在 MTP 接受率 .97 饱和后零贡献（从未触发）+ cache 截断触发 13 分钟整段重 prefill——这个坑值得记进避坑清单，之前没人提过
- n_max=5 在 code 上 +46%（62→90.5 t/s）、size-n=12 误开火 −32% 的对照，给参数调优留了实锤
- "GPU1 SGLang 服务 + GPU0 llama.cpp 投机"同宿主分工本身就是可抄的样板，HSA_OVERRIDE_GFX_VERSION + 70 patch fork、VK_ICD_FILENAMES 显式锁卡的坑也交代全了
小建议（可选）
- 同场对比本质是 "SGLang 无投机 vs llama.cpp 带 MTP"，你已如实标注；想更严谨可把两卡引擎互换复测一轮，排除 03:00.0 / 06:00.0 槽位与温度差异
- 老特提到的实拍图/机箱与功耗截图补两张，帖子就圆满了
奖励：站长已核，本帖质量达标，+5 积分已入账。站里缺的就是这种可复现的实测，继续保持这个标准。
-
前天到了兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大。看到論壇上許多大神提到限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵。看到數據後發現對比我原先的RTX 5060 Ti 16G *2好像快不了多少，於是又嘗試了一下llama.cpp Vulkan MTP。
一台機器兩張 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. 硬體與環境
類別 規格 CPU Intel Core i5-10400（6C12T @ 2.90GHz，睿頻 4.3GHz，L3 12MB） 主機板 MSI MEG Z490 UNIFY（MS-7C71，rev 2.0） BIOS American Megatrends A.G2（2026-04-14） 記憶體 64GB = 4×16GB DDR4-2667（雙通道，4 槽全插滿） GPU 1 AMD Radeon AI PRO R9700（RDNA4，gfx1201）32GB，PCI 06:00.0 — SGLang GPU 2 AMD Radeon AI PRO R9700（RDNA4，gfx1201）32GB，PCI 03:00.0 — llama.cpp 儲存 1× 1TB NVMe（Crucial CT1000P310SSD8，931.5G） 作業系統 Ubuntu 24.04，kernel 7.0.0-30-generic（x86_64），headless 磁碟分割（p4 = /home 574.7G）：
- p1 1G EFI
- p2 326G
/ext4 - p3 29.8G swap
- p4 574.7G
/homeext4
關鍵背景：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參數 值 為什麼 --context-length196608192K 上下文（由 256K 下調） --quantization awq+--dtypeawq/bfloat16權重 int4 省顯存，激活走 bf16 --kv-cache-dtypefp8_e4m3長上下文省顯存主力，192K 能跑的核心 --mem-fraction-static0.85權重 + KV 預留比例，32G 上穩妥 --max-running-requests1單請求最穩最可預測（犧牲並發） --chunked-prefill-size/--max-prefill-tokens8192/16384prefill 分塊，平衡峰值顯存與 TTFT --num-continuous-decode-steps+--cuda-graph-backend-decode16/full連續解碼配完整 graph，降 launch 開銷 --attention-backendtritonAMD 必須（NVIDIA FA 路徑不可用） --max-mamba-cache-size/--mamba-ssm-dtype8/bfloat16限制 mamba/SSM 層緩存規模 --watchdog-timeout1200長 prefill 數分鐘，避免被誤殺 --enable-multimodal— 開視覺（配 mmproj） --reasoning-parser/--tool-call-parserqwen3/qwen3_coderthink 推理塊與 tool call 解析 3. 環境變數（從在跑 process 實抓）
ROCm / RDNA4 映射
環境變數 值 作用 ROCM_PATH/HIP_PATH/opt/rocm指向 ROCm 安裝 HSA_OVERRIDE_GFX_VERSION12.0.1gfx1201 → 已支援 target HIP_VISIBLE_DEVICES1釘 GPU1（06:00.0） 穩定性（RDNA4 上 crash 主要來源，全關）
環境變數 值 作用 SGLANG_USE_AITER/SGLANG_USE_AITER_AR0關 AITER HSA_ENABLE_SDMA0關 SDMA PYTORCH_TUNABLEOP_ENABLED0關 tunableop AMD 版 FlashAttention 走 Triton
環境變數 值 作用 FLASH_ATTENTION_TRITON_AMD_ENABLETRUEAMD 上 FA 走 Triton VLLM_USE_TRITON_AWQ/VLLM_USE_TRITON_FLASH_ATTN1AWQ 與 FA 皆走 Triton 實作 效能 / 雜項
環境變數 值 作用 GPU_MAX_HW_QUEUES8硬體佇列數 HIP_FORCE_DEV_KERNARG1強制 device kernarg HSA_FORCE_FINE_GRAIN_PCIE1PCIe fine-grain TOKENIZERS_PARALLELISMfalse避免 tokenizer 多執行緒衝突 PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True記憶體配置策略 TRITON_CACHE_DIR/home/benai/.cache/triton_rdna4_t36Triton JIT 快取 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.cpp 主線 67a17c17c（Vulkan/RADV，Mesa 25.2.8） 模型 unsloth Qwen3.8-27B-UD-Q4_K_XL 17.56G + MTP drafter 1.37G + mmproj-F16 0.93G Context 196608，KV q5_1/q4_0 → VRAM 22.5G / 32G 投機解碼 MTP-only，n_max=5 服務 llamacpp.service（system 級，Restart=on-failure），載入 ~12sllama-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 240K cold 211.4 t/s（TTFT 1101.9s） code @240K decode 24.1 t/s（accept 96.8%）vs SGLang@256K 25.7 = 0.94x 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.4sllama.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 非掐錶）。兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
-
兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
-
兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
放在一个小房间才是正道
-
兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
此主題已被删除！ -
兩張R9700就想著上論壇抄作業，本地跑上了qwen3.8後才發現這兩傢伙的噪音比我想像中的大
可以請教是哪一個牌子的嗎？
目前聽到的網友反饋是 Asrock and Gigabyte 聲音不大限制功耗可以改善些噪音於是興起了測試250W/280W/300W下的功耗狀況，對於噪音結論是--都很吵
不知道溫度有多高, 風扇曲線調整可能有幫助, 但如果溫度依然很高 可能無效了
還沒用過渦輪卡 不知道怎麼運作的嫌台式机显卡吵的， 给大家推荐一个神器 https://lcz.me/post/13237
-
@kos-or 我入手的是撼訊，因為那時只剩撼訊有貨後來技嘉又放貨了但是跟我撼訊的價格單張差了2W。我也是個窮屌絲就果斷的入手了!另外我也有爬到PhoenixRise2026 有自定義風扇曲線，我也有抄了只能說有改善但真的高負載下去還是吵。我覺得第一次接觸渦輪卡(我也是第一次)真的會覺得噪音很有感，就像一台吸塵器持續在你身邊持續運轉。但或許一段時間後我就會慢慢習慣。
-
，系统 取消固定了此主题
-
@Thanaots 羡慕。。。。
