@paul-hou 说:

@张光璞

看了一下，確實還滿多人嫌棄NVFP4版的。

下午临下班打的补充，晚上只跑了一次就把一下午都幻觉的问题搞定了

明天烧到板子里看看效果。 我看最终还是要双卡跑个高精度的 27b 来做主力工作机。 30t的速度有点影响开发效率 。

看了一下，確實還滿多人嫌棄NVFP4版的。

@paul-hou 说:

@张光璞

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

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

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

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

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

@paul-hou 说:

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

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

tmp-tmp 说:

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

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

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

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

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

@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秒左右。

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

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

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

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

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

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

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 是「易用的官方模型 + 功能完整的延續版伺服器」；方案 B 是「針對 RDNA4 的極致性能版本 + 上游 base 伺服器」。

1. 伺服器對比：magiccodingman vs stilldeadcode

基本情況

版本堆疊（關鍵差別）

️ 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）

註：此表為 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 量化版，但走的路線完全不同。

本質

簡單說：

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

精度（GSM8K）

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

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

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

部署 / 硬體（最大差別）

授權 / 普及度

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. 選擇建議

實務提醒：

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

1）vLLM 侧这个开关通常写作 --enable-prompt-tokens-details（对应 enable_prompt_tokens_details=True），部分版本还要求同时开了 --enable-prefix-caching 才会把命中数填进 usage。改完先直接打 /v1/chat/completions 看原始 JSON 里 prompt_tokens_details 是否非 null，确认服务端 OK 再查 DSH 前端解析。

2）cached_tokens 只反映 vLLM 自己的 prefix cache 命中，不等于 HiCache / 两级缓存的主机池命中。如果你们是 HiCache 场景，别用它判断主机池是否复用——那取决于 write_policy：write_through 写了不重用，write_back 才真复用（重复前缀 15.4s→0.4s 是 write_back 下的数字）。

另外模板换成 v22.5 后记得重启容器（model 是 read-only mount），并用同一段 system prompt 连发两次看 cached_tokens 是否稳定；如果 prompt 开头带了秒级时间戳之类的易变内容，命中率会被打回 0。