魔改SGLANG支持7900XTX 双卡TP V2 DFLASH2 单流220Token/s
-
-
-
根据楼主的文章，我也测试了SGLANG和VLLM，发现SGLANG只是纯 Prefill 吞吐、尤其是多并发短 Prompt，vLLM 更高
文章的 PP=2048、并发4 测试里：
vLLM baseline：1891 tok/s
而：
SGLang DFlash2：1275 tok/s
最终还是选择SGLang是嘛 -
根据楼主的文章，我也测试了SGLANG和VLLM，发现SGLANG只是纯 Prefill 吞吐、尤其是多并发短 Prompt，vLLM 更高
文章的 PP=2048、并发4 测试里：
vLLM baseline：1891 tok/s
而：
SGLang DFlash2：1275 tok/s
最终还是选择SGLang是嘛这两个数不是同一口径，别直接下结论：
- vLLM 1891 是 baseline（无投机），SGLang 1275 是 DFlash2 路径。投机解码在 prefill 阶段不省反增——要多跑一个 drafter、还要验证，收益全在 decode。所以多并发短 prompt 的纯 prefill SGLang 输是正常的，不代表引擎本身弱。
- 选型按负载：
- 多并发、短 prompt、TTFT/prefill 敏感，用 vLLM，或者 SGLang 关掉投机；
- 单流或少并发、长上下文、decode(TG) 敏感，用 SGLang + DFlash2（也就是 flyer666 那 220 tok/s 的场景）；
- 自己一个人用，多并发通常不是刚需，长 ctx 下的 TG 才决定体感，SGLang 更划算。
- 想公平比，把 SGLang 的投机关掉再跑一遍同样的 PP=2048/c=4，才能把「引擎差距」和「投机开销」分开。
-
-
系统 于 取消固定此主题
-
F franklee006 于 引用了 此主题
-
-
我弟的测试非常精髓，这是本站神卡7900XTX的封神之作，最后一块短板倍补齐，还是可以折腾下FP8 KV，社区找找方案，到时候让大家抄作业，还有你不是要测试hicache吗？失败了吗？这玩意和FP8KV必须搞定一个
@terry @flyer666 特哥，Flyer666大佬：回到这个帖子 -
这两天继续折腾我的 7900XTX 双卡 SGLang，把所有能找到的量化方法试了一遍，最后发现 KV 缓存（fp8_e4m3）居然能跑通。
好处就一个：L1（显存的可用 KV 池）从 179,551 到了 531,900，L2（内存）从 366,212 到了 732,424（ratio 2.0 自动翻倍），池子直接翻倍（总 KV 池超过 1M）。显存没爆，graph capture 正常，也没有 OOM。这是它唯一实打实的好处。
代价一大堆：短请求基本没差，decode 速度和 BF16 基本一个水平，看不出优势也没明显变慢。但是长上下文直接崩，prefill 速度从 1362 tok/s 掉到 224 tok/s（实测 64K 从 48 秒拉到将近 5 分钟，约 1/6），再往上直接 hang。靠着 HiCache 还能掩盖一段时间——L2 里存着的历史不用重算，回访还是秒回；但 fresh prefill 一多就等得让人抓狂。
问了 AI，为什么慢：gfx1100（RDNA3）没有原生的 FP8 矩阵单元。BF16 的 attention 走的是硬件的整型 matmul 路径，而 fp8_e4m3 没有对应的硬件加速 kernel，只能全退到 Triton 软件模拟的浮点运算。短序列时多算几拍感觉不出来，但 64K 这种长序列的 attention 计算量是 O(N²) 的，软件 kernel 的开销在这个量级下直接吃掉全部收益，最后就表现为 hang。
除非 SGLang 能开整数 KV，或者有哪位大神能出 RDNA3 的 Kernel 优化，否则 fp8 KV 量化在长上下文下还是有很大副作用的，但是短上下文可以忍，缓存命中高也可以掩盖。可能像Flyer666这样的大佬会用DSH的能用得上。我现在用Hermes开220K上下文的用不了，不过有了HiCache BF16的KV目前也够用了。
-
@terry @flyer666 特哥，Flyer666大佬：回到这个帖子 -
这两天继续折腾我的 7900XTX 双卡 SGLang，把所有能找到的量化方法试了一遍，最后发现 KV 缓存（fp8_e4m3）居然能跑通。
好处就一个：L1（显存的可用 KV 池）从 179,551 到了 531,900，L2（内存）从 366,212 到了 732,424（ratio 2.0 自动翻倍），池子直接翻倍（总 KV 池超过 1M）。显存没爆，graph capture 正常，也没有 OOM。这是它唯一实打实的好处。
代价一大堆：短请求基本没差，decode 速度和 BF16 基本一个水平，看不出优势也没明显变慢。但是长上下文直接崩，prefill 速度从 1362 tok/s 掉到 224 tok/s（实测 64K 从 48 秒拉到将近 5 分钟，约 1/6），再往上直接 hang。靠着 HiCache 还能掩盖一段时间——L2 里存着的历史不用重算，回访还是秒回；但 fresh prefill 一多就等得让人抓狂。
问了 AI，为什么慢：gfx1100（RDNA3）没有原生的 FP8 矩阵单元。BF16 的 attention 走的是硬件的整型 matmul 路径，而 fp8_e4m3 没有对应的硬件加速 kernel，只能全退到 Triton 软件模拟的浮点运算。短序列时多算几拍感觉不出来，但 64K 这种长序列的 attention 计算量是 O(N²) 的，软件 kernel 的开销在这个量级下直接吃掉全部收益，最后就表现为 hang。
除非 SGLang 能开整数 KV，或者有哪位大神能出 RDNA3 的 Kernel 优化，否则 fp8 KV 量化在长上下文下还是有很大副作用的，但是短上下文可以忍，缓存命中高也可以掩盖。可能像Flyer666这样的大佬会用DSH的能用得上。我现在用Hermes开220K上下文的用不了，不过有了HiCache BF16的KV目前也够用了。
-
-
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！