R9700 單/雙卡有抄magiccodingman/vllm-radiance 作業的同學看一下

[paul hou]

已安裝magiccodingman/vllm-radiance + amd/Qwen3.8-27B-Quark-AWQ-MXFP4的，
也可以試試正主stilldeadcode/vllm-radiance + Launch80/Qwen3.8-27B-PARO-MXFP4 作者自己優化的模型。
我目前是兩個都用，都還在測試中，單卡的速度上是差不多的。
以下是讓AI分析一下二個組合的特點。

vllm-radiance 部署方案對比

對比兩套「推理伺服器 + 量化模型」組合，針對 AMD Radeon AI PRO R9700 (gfx1201 / RDNA4)。

• 方案 A：magiccodingman/vllm-radiance + amd/Qwen3.8-27B-Quark-AWQ-MXFP4
• 方案 B：stilldeadcode/vllm-radiance + Launch80/Qwen3.8-27B-PARO-MXFP4

---

0. 總覽

面向	方案 A（magiccodingman + Quark-AWQ）	方案 B（stilldeadcode + PARO）
伺服器 repo	magiccodingman/vllm-radiance（GitHub fork，延續版）	stilldeadcode/vllm-radiance（Codeberg 原作，上游 base）
模型量化	Quark AWQ，MXFP4 權重 + 動態 MXFP4 激活	ParoQuant 旋轉 + OCP MXFP4 權重
推理路徑	原生 Quark MXFP4 W4A8（fp8 激活）	W4A8 fp8-WMMA 路徑 + 旋轉前綴
硬體綁定	R9700 / gfx1201（dual R9700 TP2 為主）	R9700 / gfx1201（2× R9700 TP2）
部署門檻	中（Docker image，需設定 W4A8 環境變數）	高（需裝 patched vLLM 插件 + 編譯 kernel）
授權	伺服器：open；模型：All rights reserved	伺服器：open；模型：Apache-2.0
適合對象	要跑官方 Quark 模型、要完整功能與文檔	要極致 prefill/decode 性能、接受非標準部署

一句話：方案 A 是「易用的官方模型 + 功能完整的延續版伺服器」；方案 B 是「針對 RDNA4 的極致性能版本 + 上游 base 伺服器」。

---

1. 伺服器對比：magiccodingman vs stilldeadcode

基本情況

	stilldeadcode（上游）	magiccodingman（fork / 延續）
平台	Codeberg	GitHub
提交數	17 commits	132 commits
Stars / Forks	14 / 5	48 / 4
最近活動	約 3 週前	2 天前（更活躍）
Docker Hub pulls	10K+	有發布 image
定位	核心 Radiance runtime + 手寫 gfx1201 kernels	上游 + 大量 ported 優化與 qualification

版本堆疊（關鍵差別）

元件	stilldeadcode image	magiccodingman image
vLLM	0.27.1	0.28.0（pinned 到具體 commit）
PyTorch	2.11.0	2.12 branch（pinned commit）
Triton	3.6.0	3.7.1（pinned commit）
AITER	0.1.17	0.1.20
libr4d	—（早期）	0.5.0（pinned commit）
ROCm userspace	7.14	7.14

️ magiccodingman 明確警告：PyTorch / Triton / vLLM 不能單獨升級——它們是一個 compiler stack，之前版本錯配曾導致 TP hang。

stilldeadcode 的優勢

• 更簡單、維護面小：patch 數量約 30 個（vs magiccodingman 70+）。
• 最新 commit 加入 Nrank allreduce，支援 TP4 / TP8 配置（magiccodingman 主要 qualification 是 dual R9700 TP2）。
• 作為上游 base，是 magiccodingman 的基礎；若 fork 停更，上游仍是最小可用版本。

magiccodingman 的優勢

• 功能遠超上游：
  • 原生 Quark MXFP4 W4A8（含 fused split-K、subnormal scale-fold kernels）
  • DFlash2 推測解碼（W4 draft linears、int2 verify head）
  • XGrammar 結構化輸出 + 推測解碼 backport（修 tool-call grammar 與 draft batch 不同步）
  • Qwen 嵌套 object tool-call 修復
  • KV cache group size 優化（+20.7% KV 容量、並發 2.82x → 3.41x）
  • rank-sharded KV offload、FP8 KV calibration sidecar、TunableOp 調優 lab
  • 完整 BetterBench 資格化數據 + 大量 qualification 報告（含負結果）
• 文檔與可重現性最好：每個 image 從 pinned commit 构建，附完整 qualification 報告。
• 性能數據更完整（見下表）。

性能數據（magiccodingman，歷史基線 0.9.3 / libr4d 0.5.0，雙 R9700）

模式	加權單流 TPS	c1	c2	c4	c8
Non-spec	43.6	43.2	83.1	145.7	241.3
Fast MTP K4	102.3	97.8	173.1	284.5	372.1
Fast DFlash K5	136.2	123.0	216.4	343.0	435.7
Fast DFlash K7	145.4	132.4	234.6	343.3	416.9

註：此表為 0.9.3/libr4d 0.5.0 基線的歷史數據，非目前 RX4-dark image 的 K7 上限。

風險

• magiccodingman 自我標註 experimental：
  • 主要 qualification 環境 = 2× R9700 TP2、FP8 或 Quark MXFP4 權重、強制 FP8 KV。
  • 其他模型 / 量化 / 卡數 / 硬體未經驗證。
  • speculative 模式 opt-in（跨模式輸出等價 gate 未通過）。
• stilldeadcode image 版本較舊（vLLM 0.27.1），且沒有 MXFP4 W4A8 原生路徑。

---

2. 模型對比：Quark-AWQ-MXFP4 vs PARO-MXFP4

兩者都是 Qwen3.8-27B 的 MXFP4 量化版，但走的路線完全不同。

本質

	amd/Quark-AWQ-MXFP4	Launch80/PARO-MXFP4
權重	MXFP4（OCP microscaling FP4，group 32，E8M0 共享 scale）	OCP MXFP4（e2m1，e8m0 共享 scale，4.25 bit/weight）
激活	MXFP4，動態（per-block，runtime 計算）	fp8（W4A8，per-token fp8 量化）
演算法	AWQ（activation-aware weight quantization）	ParoQuant 旋轉（Givens 旋轉 + channel_scales）+ stage-2 微調
校準	128 樣本 / seq 512 / pileval（Quark 預設）	256 樣本 × 2 epochs（權重 + per-block 指數偏置）
視覺塔	未量化（bf16），只量化 LM decoder	lm_head 與 embeddings 為 bf16
量化工具	AMD Quark（官方）	自製 patched vLLM 插件

簡單說：

• Quark-AWQ = 傳統校準式量化，簡單標準，AMD 官方發布。
• PARO = 在 MXFP4 之上加 ParoQuant 旋轉 + 微調，更「講究」，精度更高但綁定特定部署。

精度（GSM8K）

	amd/Quark-AWQ	Launch80/PARO
測試條件	5-shot，thinking（temp 1.0, top_p 0.95）	500 題，greedy，served path
成績	95.0% / 95.3%（recovery 101.8%）	97.4–97.6%
非 thinking	89.9%（recovery 99.2%）	—

️ 測法不同（5-shot vs 500q greedy），不能直接比，只能當參考。數字上 PARO 略高。

速度（2× R9700，TP2，fp8 KV）

	amd/Quark-AWQ	Launch80/PARO
prefill 2k/8k/16k/32k/64k (t/s)	—（無數據）	4770 / 4827 / 4649 / 4495 / 4273
綜合 decode (t/s)	186	203
decode step @ctx 25 (ms)	28.6	24.53
decode step @8k / 32k (ms)	—	25.89 / 26.80

PARO 的 MXFP4 grid 去掉了 int4 GEMM 內迴圈的 per-group FMA，prefill 提速約 25%；decode 流量與 int4 g128 相同（都是 4.25 bit/weight）。

部署 / 硬體（最大差別）

	amd/Quark-AWQ	Launch80/PARO
載入方式	標準 vllm serve --trust-remote-code	不能用 stock vLLM/transformers，需 patched radiance-vllm-mxfp4 插件
可攜性	跨 AMD ROCm 可攜，官方發布	綁死 RDNA4（gfx1201 / R9700）；換硬體要重寫 rotation prologue 和 GEMM
維護性	官方 AMD，維護性好	社群自製，門檻高

授權 / 普及度

	amd/Quark-AWQ	Launch80/PARO
授權	All rights reserved（限制性）	Apache-2.0（寬鬆）
上月下載	22,860	287
發布方	AMD 官方	社群（基於 z-lab ParoQuant + AMD MXFP4 packing 慣例）

---

3. 兩套組合的整體評估

方案 A：magiccodingman/vllm-radiance + amd/Quark-AWQ-MXFP4

組合邏輯：官方 Quark 模型 + 功能完整的延續版伺服器。magiccodingman 明確支援 Quark MXFP4 W4A8（README 有完整環境變數範例）。

優點

• 部署最簡單：docker compose up + 設定 W4A8 環境變數即可跑官方 Quark 模型。
• 伺服器功能最完整：DFlash2、XGrammar、KV 優化、benchmark lab、完整文檔。
• 模型是 AMD 官方發布，下載量高（22,860），生態好。
• 跨 AMD ROCm 可攜性較好。

缺點

• 模型授權是 All rights reserved（限制性）。
• 伺服器自我標註 experimental，qualification 綁定 R9700。
• 速度（尤其 prefill）不如 PARO 組合。
• speculative 模式 opt-in，跨模式等價 gate 未通過。

方案 B：stilldeadcode/vllm-radiance + Launch80/PARO-MXFP4

組合邏輯：上游 base 伺服器 + 極致性能模型。

️ 注意：PARO 模型本身需要 radiance-vllm-mxfp4 插件（ggz14 的 repo），而 stilldeadcode 的 image 沒有 MXFP4 W4A8 原生路徑。因此「stilldeadcode + PARO」這個組合在實務上需要額外整合（把 PARO 的 patched 路徑接進 stilldeadcode base），不是開箱即用。若要開箱即用的 PARO 路徑，magiccodingman 的 image 反而更合適（它 ported 了 ggz14 的 MXFP4 W4A8 工作）。

優點

• PARO 模型精度更高（GSM8K 97.4–97.6%）、速度更快（prefill +25%、decode 203 vs 186 t/s）。
• 授權寬鬆（Apache-2.0）。
• stilldeadcode 支援 TP4/TP8（Nrank allreduce）。
• 上游 base 簡單、維護面小。

缺點

• 部署門檻最高：PARO 不能用 stock vLLM，需裝 patched 插件 + 編譯 kernel。
• 綁死 RDNA4（gfx1201 / R9700）。
• 模型下載量極低（287），生態小。
• 組合的開箱即用性差（需手動整合 PARO 路徑）。

---

4. 選擇建議

需求	推薦
要「跑得起來、省事、官方模型、完整功能」	方案 A（magiccodingman + Quark-AWQ）
雙 R9700 + 要跑 Quark MXFP4 模型 / DFlash2 / speculative	方案 A
要極致 prefill/decode 性能、接受非標準部署、綁 R9700	方案 B（PARO 模型）
要 TP4/TP8 多卡	方案 B 的 stilldeadcode base（或自行整合）
一般單卡/雙卡 FP8 部署	兩個都能用，方案 A 的 0.28 base + KV 優化通常更值得

實務提醒：

1. 兩套組合的 qualification 都綁定 R9700 / gfx1201；換卡需自行驗證。
2. PARO 模型的開箱即用路徑其實在 magiccodingman image（它 ported 了 ggz14 的 MXFP4 W4A8），而非 stilldeadcode。若要「stilldeadcode base + PARO」需手動整合。
3. magiccodingman 的 speculative 模式（DFlash2）目前是 opt-in，跨模式輸出等價 gate 未通過，生產環境建議先用 non-spec 或 MTP。

---

附錄：關鍵來源

• 伺服器：
  • stilldeadcode/vllm-radiance — https://codeberg.org/StillDeadcode/vllm-radiance
  • magiccodingman/vllm-radiance — https://github.com/magiccodingman/vllm-radiance
  • Docker Hub：stilldeadcode/vllm-radiance、magiccodingman/vllm-radiance
• 模型：
  • amd/Qwen3.8-27B-Quark-AWQ-MXFP4 — https://huggingface.co/amd/Qwen3.8-27B-Quark-AWQ-MXFP4
  • Launch80/Qwen3.8-27B-PARO-MXFP4 — https://huggingface.co/Launch80/Qwen3.8-27B-PARO-MXFP4
  • 上游 ParoQuant：z-lab/Qwen3.8-27B-PARO、論文 arXiv:2511.10645

[terry]

你双卡VLLM跑Agent如何？数字太复杂了，简单说下体感，和在线API对比有明显慢吗？还是长链任务后差不多？

[paul hou]

@terry
我只有單卡喔，目前論壇中的雙卡數據就是十分接近*2。
以PREFILL的感覺來說，線上DSV4F或LUNA之類的FLASH模型大約快了3倍，雙卡算起來還是比不上但很接近了。
DECODE來說，差不了多少，線上都是時快時慢的，雙卡應該跟飛的一樣。

這是今天是EFR32BG22 MCU的工作，設定GPIO，設定BEACON的格式，讀取MCU內部電壓，設定各種狀況的廣播方式和IO動作，省電設定，一個會話9輪做好，上下文262144 壓縮了2次，一次壓縮的時間是55秒，只有IO中斷有問題重新修改了一次就完成任務。
目前用起來確實是Launch80/Qwen3.8-27B-PARO-MXFP4在較長的上下文沒這麼笨，之前用AMD的模型大多要修改個3-5次才能完工。

關於緩存命中，vllm的數值是平均值，llama.cpp常常在99%，算起來不該這麼高，猜測是當次載入的命中率。

[paul hou]

https://www.reddit.com/r/ROCm/comments/1wix8sq/amd_radeon_1xr9700_153_toks_decode_prefill_3619/?solution=5046190dd2b0af065046190dd2b0af06&js_challenge=1&jsc_token=7afd7253fec22262ff1c52b1703fe9eccbc0da34dda07321e707e977a9f17200&jsc_orig_r=&share_id=swyH6oVedGYDwH6c5bAoX&utm_content=2&utm_medium=android_app&utm_name=androidcss&utm_source=share&utm_term=18

正主版本又有更新了，這次主要針對單R9700進行效能升級，DECODE看起來是效能上漲了80%，晚上裝來試試看。

[paul hou]

新的FORK方案
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main

昨天晚上有小試了一下，https://github.com/GGZ14/vllm-mxfp4 版本
簡單的MCU OTA APP，讓DSH分析程式和檢查BUG。
之前版本TOKEN的平均值大概在55-60TOKEN左右，新版提升到88TOKEN。
過程中大多維持在10X TOKEN，最後的分析說明很長一大堆，就降到了88 TOKEN。

DSH的新會話按下送出到開始思考的第一行出現，目測大概比前一版快了1秒左右。

[张光璞]

@paul-hou 说:

新的FORK方案
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main

昨天晚上有小試了一下，https://github.com/GGZ14/vllm-mxfp4 版本
簡單的MCU OTA APP，讓DSH分析程式和檢查BUG。
之前版本TOKEN的平均值大概在55-60TOKEN左右，新版提升到88TOKEN。
過程中大多維持在10X TOKEN，最後的分析說明很長一大堆，就降到了88 TOKEN。

DSH的新會話按下送出到開始思考的第一行出現，目測大概比前一版快了1秒左右。

民间最终也是走了梁圣的路线，不断的调优一次次探索和突破硬件极限边界

[Magic629]

@paul-hou 持续运行任务，半小时后的token输出速度每秒有多少？谢谢。

[Magic629]

@paul-hou 持续运行任务，半小时后的token输出速度每秒有多少？谢谢。

[paul hou]

@Magic629

最近二天裝的新版本還沒試
之前的版本大概跑一個工作大概輸入30M的TOKEN，平均的DECODE會落在55~60之間。

新版本目前測試是快了20多%。

我所謂的舊版=> https://github.com/GGZ14/vllm-mxfp4
新版=> https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main

一個是原始發佈，一個是FORK，新舊是我安裝的順序而言。

[Magic629]

@paul-hou 好的，谢谢。

[paul hou]

@Magic629
版本是
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
模型：unsloth/Qwen3.8-27B-NVFP4
DHS上 /plan + 執行
整體是29分鐘多

[Magic629]

@paul-hou 谢谢，我的token输出在40，我看了下，不带视觉看图功能吗？本来想试试的，但是我需要视觉功能啊。

[paul hou]

如果是nvfp4的方案，有視覺的上下文160k應該會有，mxfp4的話可以到200k這個我有在用。

[tmp tmp]

此主題已被删除！

[tmp tmp]

tmp-tmp 说:

@paul-hou 刚刚看了某东，技嘉16500,讯景14000,盈通13000了。完全风了。
这下，你说的正主要负主责，你要负次责。

[Magic629]

怪我太菜，折腾一晚上以上方案就一个成功的，但是效果还是不理想。
就这个成了：https://github.com/Eliovp-BV/paiton-vllm-plugin/blob/main/models/Qwen3.8-MXFP4-DFlash2/README.md
感觉跟社区版的没啥区别，最主要稳定性不行。也可能是我操作失误

[张光璞]

@paul-hou 说:

@Magic629
版本是
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
模型：unsloth/Qwen3.8-27B-NVFP4
DHS上 /plan + 執行
整體是29分鐘多

我发现这个版本会有幻觉。昨天处理一个长任务 ，就一直循环住了。

[paul hou]

@tmp-tmp
這鍋我不背，這鍋錘哥的

@张光璞
我覺得他太難的任務+XHIGH會瘋狂的鬼打牆，有查他內建Chat-Templates，非原廠，應該有小改，但看來是不太行。
我換froggeric/Qwen-Fixed-Chat-Templates來試試。

剛發現這方案又有小更新，目前看來GGZ14的要保留好，其他的就試試。

[paul hou]

@张光璞

改成froggeric/Qwen-Fixed-Chat-Templates有救。
思考強度設成MEDIUM或LOW就好。

[张光璞]

@paul-hou 说:

@张光璞

改成froggeric/Qwen-Fixed-Chat-Templates有救。
思考強度設成MEDIUM或LOW就好。

我有空了试试，今天帮我开发一个雷达的程序 ，已经降智到半弱智阶段了