【直播】二次开发R9700单卡用SGLang跑Qwen3.8-27B成功! TTFT0.9s/PP2000/TG100tps(代码)!体验丝滑
-
-
@Charly-Cheng
感谢捧场,看我的签名档吧,已经发布了,希望你可以顺利复现。 -
@Charly-Cheng
感谢捧场,看我的签名档吧,已经发布了,希望你可以顺利复现。@fcme 终于等到了! 所以现在楼主会选SGLANG还是paiton当主力?
-
@fcme 终于等到了! 所以现在楼主会选SGLANG还是paiton当主力?
-
@alan.lgv60
Paiton, 因为我用了一段我的那个方案,那个响应确实是快,但是跑起长一点的任务来讲,还是整体上要慢一些。等有人做出像paiton的这么牛逼的kernal以后再移植过去的话,就可以全面超越原版Paiton并秒杀毛坯SGlang了。@fcme 那我要等抄作业!
但老实说,现时的 Paiton 已经很好了。 -
@fcme 那我要等抄作业!
但老实说,现时的 Paiton 已经很好了。 -
@alan.lgv60
对,我现在是R9700跑27B,5070ti配合大内存跑flash next 也能到2100/80左右,其实个人使用也够了。
后续换工作了使用强度高了就搞双卡R9700,顶到8000/215就爽歪歪了。 -
https://lcz.me/projects/local/amd-r9700-sglang-maxx
放这个,论坛给你做了个专页,
-
@Charly-Cheng
感谢捧场,看我的签名档吧,已经发布了,希望你可以顺利复现。終於完成。也稍微了解你的波折。
拿到專案之後,我發給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 tokensDFLASH + 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 之後再來折騰。
-
終於完成。也稍微了解你的波折。
拿到專案之後,我發給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 tokensDFLASH + 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 之後再來折騰。