終於完成。也稍微了解你的波折。
拿到專案之後，我發給hermes使用千問27b的模型，繼續未完成的部署，然後就跑去睡了一覺，早上起來想說睡一覺，應該部署好吧。結果確實是部署成功了，但是因為模型生成的階段會生成亂碼，所以還持續的不斷在除錯，無止境的除錯，最後我忍不住把它關了，整個大約跑了將近12小時除錯100多個版本，還無法解決生成亂碼的問題。
我將strata的專案升級到0.1.44.1版本，使用Q4KXL模型，繼續除錯部署。大約花了5小時。終於除錯完成可以正常生成。接下來下指令，打開投機解碼，啟動hicache 。結果如下：
進度回報
投機解碼 — 已啟用並驗證
- DFLASH + DFlash2 draft（5 層 BF16）
- 踩到一個新坑並解決：draft 預設繼承 target 的 r4d_mxfp4 量化 → draft 權重載入鏈同樣錯亂 → warmup 直接 GPU 硬體異常（HSA 0x1016）崩潰。解法：--speculative-draft-model-quantization unquant（repo 生產配方是 AWQ target 所以沒踩到，我們是 MXFP4 target 才會觸發）
- 實測：accept len 2.4~4.3、decode 37~64 tok/s（無投機時 26.5 → 增益 ~1.4-2.4×）
- 正確性：17×23=391
HiCache — 確定無法啟用（ROCm 缺 kernel）
三層根因，全部實測：
- kernel io-backend：需要 sgl_kernel.get_device_accessible_ptr（HIP 的 host 指標 ≠ device 指標，CUDA UVA 不需要）— 映像內 sgl-kernel 沒編這個符號，重編需 AOT ROCm 工具鏈
- 我用 ctypes hipHostGetDevicePointer 補上後，init 通過（host pool 8.91GB 分配成功、hicache_attached=True）→ 執行期仍 HSA 崩潰：transfer_kv_direct 的 pinned-memory DMA 路徑在 RDNA4 上壞（SGLANG_RDNA4_DISABLE_STORE_CACHE=1 就是上游已知 store-cache bug 的標記）
- direct io-backend 也一樣崩
結論：HiCache 在此 RDNA4 堆疊不可用，已從 compose 註解移除。 這是引擎/驅動層限制，非配置問題。
️ 代價：KV pool 縮水（投機解碼的 trade-off）
無投機
• KV pool: 301,936 tokens
DFLASH + BF16 draft
• KV pool: 79,008 tokens（draft 權重 1.48GB + 雙份 KV pool 擠壓）
邊界測試已按 79K 重新排程掃描點（40K/60K/70K/76K/79K/82K/90K），跑完後接 100K+ 多輪長鏈測試 — 但先講清楚：若你要 100K+ 生產上下文，投機解碼和長上下文在單卡上互斥，到時用數據決定取捨。
結論：目前r9700。
- 使用vllm-radiance 推理引擎跑qwen 3.8-27b, 速度與穩定度都不錯，上下文邊界能有180k，跑長鏈任務，沒有衰退問題。
- Paiton 9月底 200k 版本，上下文召回率，穩定只能到128k，再大的上下文就容易不穩定，簡單的意思來說，就是超過128k的上下文,邏輯比較會跑偏，長鏈任務感覺有衰減，不知是否是錯覺，感覺沒有vllm-radiance穩定順暢。
- Paiton 10月初版本，還沒測試，聽說可以併發，速度還不錯，但是要降智3%。現在都在想辦法提升智力，正在測試Strata，之後有興趣再來測試。
4.sglan 能開hicache 之後再來折騰。