R9700 單/雙卡有抄magiccodingman/vllm-radiance 作業的同學看一下
-
建議要讓HERMES幫你裝上
froggeric/Qwen-Fixed-Chat-Templates說明包含修復DSH中KV緩存命中顯示的BUG
一、froggeric/Qwen-Fixed-Chat-Templates v22.5 更新
1.1 修改目標
將 Qwen 3.8 官方 chat template 換成 froggeric 的 v22.5 修復版，解決官方模板的以下已知缺陷：
- 預設 reasoning effort 硬編譯
xhigh，token 預算大量花在 reasoning 上 - 非 reasoning 快速模式（
enable_thinking=false）會直接 crash - 歷史 reasoning 提取不完整，會在真實 thought 前多加入空白「思考」區塊
- Tool argument 的 JSON 字串化格式會導致解析 crash
- 客戶端 reasoning effort 名稱別名（high/max/minimal 等）不被識別
1.2 修改檔案明細
檔案 位置 修改內容 chat_template.jinja/mnt/NVME/qwen38-27b-R9700/models/Qwen3.8-27B-MXFP4-mtpfp8/官方模板 → v22.5（ template_version = "qwen3.8-froggeric-v22.5"）tokenizer_config.json同上 chat_template欄位同步更新為 v22.5 模板字串備份檔案（修改前自動產出）：
chat_template.jinja.bak-officialtokenizer_config.json.bak-official
1.3 v22.5 相比官方模板的主要修復
項目 官方 Qwen 3.8 模板 froggeric v22.5 預設 reasoning baseline 硬編譯 xhigh預設 medium（零注入），保留 KV cache 一致性非 reasoning 快速模式 Qwen3.8-2.4T-A95B模板遇enable_thinking=false直接 crash完整支援，via kwargs 或 <\|think_off\|>歷史 reasoning 提取 丟棄 in-content 提取，在真實 thought 前加空白「思考」區塊 跨 OpenAI / Anthropic / in-content 統一提取，不重複 tag Tool argument wire format 標準 OpenAI client 的 JSON 字串化 arguments 會 crash 統一 XML 預設，安全渲染 stringified JSON 客戶端 reasoning alias 拒絕非標準名稱 自動映射： high/max/ultracode/extreme→xhigh，minimal→low，none/off→disabled內聯 steering tag 不支援 <\|think_low/medium/xhigh/ultracode/off\|>，strip 後保留至下個 tag前置 system/developer 訊息 多條視為獨立 turn 合併為單一 system turn 1.4 啟動腳本同步修改
檔案：
~/vllm-start-8080-v116，第 86 行附近- "--default-chat-template-kwargs={\"reasoning_effort\":\"xhigh\"}" + "--default-chat-template-kwargs={\"reasoning_effort\":\"low\"}"原因：v22.5 預設
medium即可；xhigh會繼續強制注入 xhigh reasoning instruction，與 v22.5 的 zero-injection 設計衝突。改為low讓 v22.5 的 short thinking 指引正確生效。1.5 生效條件
vLLM model 是 read-only mount，啟動時讀入 → 換完 template 後需重啟容器才生效：
./vllm-start-8080-v116 start
二、vLLM 緩存命中顯示修復
2.1 問題描述
DSH 介面讀
usage.prompt_tokens_details.cached_tokens顯示 prefix cache 命中數，但 v116（vLLM 0.28.0）的 API 回傳："prompt_tokens_details": null導致 DSH 一直顯示 0，即使 prefix cache 實際有命中（vLLM log 顯示 hit rate 45.3% → 61.2%，證明 cache 本身運作正常）。
2.2 根因分析
vLLM 的
enable_prompt_tokens_details預設值是False。v116 啟動腳本沒有傳入該旗標，所以 API 端不會把 cached token 數填進 usage 欄位。0.9.3 upstream 的
serve-mxfp4.sh有兩支旗標，v116 漏掉：--enable-prompt-tokens-details # 把 num_cached_tokens 填進 usage.prompt_tokens_details --enable-force-include-usage # 強制每次回應都帶 usage 欄位兩支旗標在 1.0.16 映像（vLLM 0.28.0）中均已支援，預設值皆為
False，需顯式傳入才啟用。2.3 修改內容
檔案：
~/vllm-start-8080-v116，SERVE_ARGS陣列（base / vision / conc2 三個變體共用，加在變體分支之前）--enable-auto-tool-choice --tool-call-parser=qwen3_coder --reasoning-parser=qwen3 --generation-config=auto + # DSH 讀 usage.prompt_tokens_details.cached_tokens 顯示緩存命中; 0.9.3 upstream + # 靠這兩支旗標讓 vLLM 把 cached token 數填進 usage (否則回 null, DSH 一直 0) + --enable-prompt-tokens-details + --enable-force-include-usage "--default-chat-template-kwargs={\"reasoning_effort\":\"low\"}"2.4 驗證方式
dryrun 驗證（已執行，兩支旗標均出現在最終 docker 指令）：
./vllm-start-8080-v116 dryrun | tr ' ' '\n' | grep -E "enable-prompt-tokens-details|enable-force-include-usage" # 預期輸出: # --enable-prompt-tokens-details # --enable-force-include-usage模型速度測試報告：Prefill / Decode Throughput
模型與環境
- 模型：
qwen3.8-27b-mxfp4 - 推理引擎：vLLM
- 端點：
http://192.168.1.241:8080/v1（OpenAI 相容 API） - 並行度：batch = 1（單序列測量）
- max_model_len：262,144
量測方法
- 使用 SSE 串流逐 chunk 記時。
- Prefill 速度 =
prompt_tokens / TTFT（TTFT = 第一個 token chunk 的時間點）。 - Decode 速度 =
completion_tokens / (total_time − TTFT)。 - Prefill 使用隨機文本，避免 vLLM prefix-cache 命中，量測「冷啟動」速率。
- 溫度
temperature = 0。
Prefill 結果（input tokens/s，冷啟動、無快取）
目標 實際 prompt tokens TTFT (s) Prefill 速度 (tok/s) 2,048 3,685 1.464 2,516 4,096 7,294 3.111 2,345 8,192 14,504 6.361 2,280 16,384 28,907 13.646 2,118 32,768 57,805 31.138 1,856 65,536 115,663 78.598 1,472 備註：因隨機單詞 token 化較密，實際 prompt tokens 比目標大；此處以實際 token 數計算。
觀察：短上下文約 2.5K tok/s，隨 context 變長因 attention / KV 二次成本遞減至 ~1.47K tok/s（115K tokens），符合預期。本次整體比上次快約 5–8%。
Decode 結果（輸出 tokens/s，穩態）
任務 total tokens content tokens 生成時間 (s) 吞吐 (tok/s) 中位間隔 (ms/token，間隔 content) 列 1..800 3,127 387 24.033 130.1 61.3 重複句子 ×200 4,096（觸頂） 507 31.631 129.5 61.7 觀察：穩態 ~130 tok/s（約 7.7 ms/token，全部 token 基準）。
- 預設 reasoning effort 硬編譯
-
-
-
补两个容易踩的点，免得照改完还是显示 0：
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。
-
已安裝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 優化通常更值得 實務提醒：
- 兩套組合的 qualification 都綁定 R9700 / gfx1201；換卡需自行驗證。
- PARO 模型的開箱即用路徑其實在 magiccodingman image（它 ported 了 ggz14 的 MXFP4 W4A8），而非 stilldeadcode。若要「stilldeadcode base + PARO」需手動整合。
- 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
- 方案 A：
-
-
@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%，算起來不該這麼高，猜測是當次載入的命中率。
-
正主版本又有更新了，這次主要針對單R9700進行效能升級，DECODE看起來是效能上漲了80%，晚上裝來試試看。
-
新的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秒左右。
-
新的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秒左右。
新的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秒左右。
民间最终也是走了梁圣的路线，不断的调优一次次探索和突破硬件极限边界
-
新的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秒左右。
-
新的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秒左右。
-
最近二天裝的新版本還沒試
之前的版本大概跑一個工作大概輸入30M的TOKEN，平均的DECODE會落在55~60之間。新版本目前測試是快了20多%。
我所謂的舊版=> https://github.com/GGZ14/vllm-mxfp4
新版=> https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main一個是原始發佈，一個是FORK，新舊是我安裝的順序而言。
-
最近二天裝的新版本還沒試
之前的版本大概跑一個工作大概輸入30M的TOKEN，平均的DECODE會落在55~60之間。新版本目前測試是快了20多%。
我所謂的舊版=> https://github.com/GGZ14/vllm-mxfp4
新版=> https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main一個是原始發佈，一個是FORK，新舊是我安裝的順序而言。
-
-
@Magic629
版本是
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main
模型：unsloth/Qwen3.8-27B-NVFP4
DHS上 /plan + 執行
整體是29分鐘多
-
-
正主版本又有更新了，這次主要針對單R9700進行效能升級，DECODE看起來是效能上漲了80%，晚上裝來試試看。
-
-
