2x3090 NVLink 王者配置再度进化——SGLang dev507 + DFLASH2 全面复测，并发 249 t/s 新高峰
-
双 3090 NVLink 王者配置再度进化：SGLang dev507 + DFLASH2 全面复测
接上一篇 133 t/s 的实测帖，这周做了两件大事：引擎升级 506 个 commits + 跑完整优化矩阵。结论先行：王者配置没变，但藏着一个被内存挤掉的关键优化，挖出来后并发冲到 249 t/s 新高峰。
一、升级了什么
项目 旧 新 SGLang 8/26 快照 dev507（9/4 最新，506 commits） 关键修复 - f60bc73c DFLASH TP 状态分歧修复 Kernel 7.0.0-30 7.0.0-31.31（swap_cgroup 崩溃修复版） FlashInfer 0.6.17 0.6.18 其中 DFLASH TP 修复很重要：多轮长对话时 draft 模型状态会在 TP rank 间漂移，输出有潜在漂移风险，这版根除了。
二、挖出的隐藏瓶颈
升级后翻启动日志，发现一行：
Disable DFLASH draft cuda graph because only 0.93 GB GPU memory is available
draft 模型的 CUDA graph 一直被内存挤掉！mem-fraction 0.94 留给 draft graph 的空间只剩 0.93GB，不够。降到 0.90 后：
- draft cuda graph 启用
- selector decode（greedy + sampling）也折进 graph
三、优化矩阵实测（6 项，单变量）
测试 结果 判定 mem-fraction 0.94→0.90 draft graph 启用 采纳 dflash-block-size 16 并发 -28% 否决 dflash-block-size 4 JSON 场景 -18% 否决 tokenizer-worker-num 4 无增益 否决 fastokens（Rust tokenizer） 需 Rust toolchain 不适用 speculative-adaptive 仅支持 EAGLE 不适用 踩坑：DFLASH 强制 draft-tokens == block-size，不匹配直接 ValueError。
四、最终数据（2x3090 NVLink TP2 + AWQ INT4 + DFLASH2）
指标 数据 并发 aggregate（2 路） 219.1 avg / 249.1 峰 JSON 工具调用并发 280.5 avg（峰 303.7） 短 prompt 单路 297.3 代码生成 254.0 中文散文 85.4 vs 旧帖 133 t/s：+65% ~ +87%。
口径声明：并发 = 2 路 aggregate（双路同时生成的总吞吐）；单路端到端（含 prefill）一直 82-88 t/s。数字都是实测，无估算。
五、配置
--mem-fraction-static 0.90
--speculative-num-draft-tokens 8
--speculative-dflash-block-size 8
--tp-size 2 --kv-cache-dtype fp8_e5m2
--chunked-prefill-size 2048 --max-running-requests 2完整报告和踩坑记录见回复区，欢迎交流。
-
-
@applejuice 「200 多 decode」解释：楼上已经说到点子上了——底层前向速率恒定约 31 次/秒，速度 = 31 × 每次前向接受的 token 数。DFLASH 一次草稿 8 个 token，主模型一次前向验证。代码场景一次能接受 6.69 个 → 207 t/s；中文散文只接受 2.06 个 → 52.7 t/s。「249 新高峰」是并发 2 路的 aggregate 口径，单路端到端（含 prefill）一直是 82-88 t/s，两个口径不矛盾。
@starryskyknight 我有個問題， 如果是兩張 3090 跑張量並行， 那是不是比單張 48G的 4090 跑的快很多呢？ 就好像兩根小容量內存組雙通道， 比一根大容量內存還要快。
-
@starryskyknight 我有個問題， 如果是兩張 3090 跑張量並行， 那是不是比單張 48G的 4090 跑的快很多呢？ 就好像兩根小容量內存組雙通道， 比一根大容量內存還要快。
@johnnybegood 应该4090更快 而且架构更新
-
@johnnybegood 你这个就是我说的 3090 会跌成3080速度
基本上3080 就差3090 10+% 算力
sglang vllm 都不能分配算力 都是平均分配现在还不知道我们跟有nvlink 的测试有什么不同
如果楼主是用thinking 模式 就跟甩我们没有nvlink一大截了之前我用nvlink 没有mtp 没有dflash 速度差个10-15%
现在用dflash 如果是直接叠加 差真的很多 -
这就对了
nvlink 帮助还是很大的
不懂之前ai 怎样测的单路（四场景） — Single stream, 512 tokens, t=0, 3 rounds
Scenario Decode (t/s) TTFT (s) Tokens / chunk 代码生成 (Code generation) 141.1 0.149 3.64 英文技术论述 (English technical) 104.0 0.136 2.69 中文常规对话 (Chinese chat) 76.8 0.135 1.99 中文散文 (Chinese essay) 63.8 0.137 1.67 并发 2 路（代码场景） — Two concurrent streams, code prompts
Case Aggregate decode (t/s) n 同 prompt（radix 命中） Same prompt, radix hit 207.1 3 不同 prompt Different prompts 203.9 3 Setup: SGLang, Qwen3.8-27B AWQ, TP=2 on 2× RTX 3090, DFLASH speculative decoding (8 draft tokens, block size 8), fp8_e5m2 KV cache, max_running_requests=2. AMD EPYC 7452, 62 GB RAM.
@applejuice 统一脚本收到, 跑了两轮 (rounds=2), 顺带把你的 thinking 疑问一起答了: 我回帖的 235.9 确实是 thinking 默认 ON (今天用你的脚本复测 ON=237.4, 完全印证). 关掉 thinking 之后, 我这边的数字:
thinking OFF (你的脚本, 同 prompt 同 t=0)
- 代码 270.2 (tok/chunk 5.38) | 英文 165.6 | 中文对话 129.2 | 散文 78.6
- 并发同 prompt: 518.4 | 并发不同: 550.8
对齐你 thinking OFF 的 246.7 / 429.7 / 402.4: 单路 +9.5%, 并发同 +20.6%, 并发不同 +36.9%.
有意思的是你的 accept rate 更高 (代码 6.32 vs 我 5.38), 但总速度我赢 -- 前向速率我 50 次/s, 你 39 次/s. 单路差距小 (9.5%) 是前向+接受率综合; 并发差距 20-37% 才是 NVLink 的主场: DFLASH 多路并发时 P2P 直走 NVLink 免过 PCIe, 纯硬件红利.
thinking ON 我这边的数据也贴上: 237.4 / 473.7 / 488.7 -- 开关在我这只差 ~13% (代码场景), draft 模型吃思考 token 的效率还行.
小建议: 脚本 payload 把 thinking 开关显式化 (chat_template_kwargs enable_thinking), 不然默认 ON/OFF 各家模型行为不同, 口径会打架.
Setup: SGLang 0bdc15d2 (今晨升级 main 最新), twolven-Qwen3.8-27B AWQ MTP, TP=2 NVLink, DFLASH2 block 8, fp8 KV.
-
@starryskyknight 我有個問題， 如果是兩張 3090 跑張量並行， 那是不是比單張 48G的 4090 跑的快很多呢？ 就好像兩根小容量內存組雙通道， 比一根大容量內存還要快。
@johnnybegood 对齐口径后你的两个问题都有答案了:
3090+3080 = 我的 69.8%, 不到 80% (188.5/270.2, 同 thinking OFF 同脚本). 原因两个都是硬伤:
- 前向被 3080 拖住: TP=2 平均分算力, 你 33 次/s vs 我 50 次/s -- TP 同步永远等最慢那张卡, 楼上 applejuice 说的没错, 平均分配救不了
- 20GB 锁死 mem-fraction: SGLang 按最小卡分配, draft 模型和 KV cache 空间受限, CUDA graph 可能也开不起来
"哪里怪怪的": 你的 TTFT (0.098s) 反而比我快, 是 radix 命中+短 prompt, 但 decode 阶段短板效应全部显形.
双 3090 vs 单张 48G 4090: 数据说话 -- 单张 4090 跑 27B AWQ+MTP 公开实测 ~65 t/s (24G 版), 48G 版会好一些但撑死 ~130. 我这套 thinking OFF 代码 270, 并发 550. 4090 单卡优势是省电省心, 绝对速度不在一个量级. 内存双通道那个类比不成立: TP=2 是张量切分不是带宽叠加, 两张 3090 不等于一张 4090x2.
-
@johnnybegood 你的很好了 毕竟花的钱有分别
我比较惨 钱都花了 但是nvlink 用不上
为了有比较好的速度 还花多4000 上epyc 7452 -
@johnnybegood 你的很好了 毕竟花的钱有分别
我比较惨 钱都花了 但是nvlink 用不上
为了有比较好的速度 还花多4000 上epyc 7452@applejuice 现在看来双卡3080 20g 可能是性价比最高的了。 内存够大， 性能也能打。 现在3080 20G咸鱼才 3600左右， 两块还不如一块3090贵。
-
@applejuice 现在看来双卡3080 20g 可能是性价比最高的了。 内存够大， 性能也能打。 现在3080 20G咸鱼才 3600左右， 两块还不如一块3090贵。
@johnnybegood 要是我知道nvlink 用不了 我都选择3080
但是现在已经上车了 没得回头 -
无聊测试350w, thinking mode off
Decode (tokens/s, median of 3, spread in brackets)
Case 350 W tok/chunk 中文散文 72.7 (72.4–72.8) 2.06 中文常规对话 78.4 (78.3–78.5) 1.94 English technical 126.0 (126.0–126.1) 2.97 Code generation 284.9 (284.8–285.0) 6.69 Prefill (tokens/s)
Prompt tokens 350 W TTFT 19 206 1966 9.8 s 43 036 1781 24.2 s 88 907 1499 59.3 s 181 307 1141 159.0 s -
，A applejuice 引用了 此主题
-
双 3090 NVLink 王者配置再度进化：SGLang dev507 + DFLASH2 全面复测
接上一篇 133 t/s 的实测帖，这周做了两件大事：引擎升级 506 个 commits + 跑完整优化矩阵。结论先行：王者配置没变，但藏着一个被内存挤掉的关键优化，挖出来后并发冲到 249 t/s 新高峰。
一、升级了什么
项目 旧 新 SGLang 8/26 快照 dev507（9/4 最新，506 commits） 关键修复 - f60bc73c DFLASH TP 状态分歧修复 Kernel 7.0.0-30 7.0.0-31.31（swap_cgroup 崩溃修复版） FlashInfer 0.6.17 0.6.18 其中 DFLASH TP 修复很重要：多轮长对话时 draft 模型状态会在 TP rank 间漂移，输出有潜在漂移风险，这版根除了。
二、挖出的隐藏瓶颈
升级后翻启动日志，发现一行：
Disable DFLASH draft cuda graph because only 0.93 GB GPU memory is available
draft 模型的 CUDA graph 一直被内存挤掉！mem-fraction 0.94 留给 draft graph 的空间只剩 0.93GB，不够。降到 0.90 后：
- draft cuda graph 启用
- selector decode（greedy + sampling）也折进 graph
三、优化矩阵实测（6 项，单变量）
测试 结果 判定 mem-fraction 0.94→0.90 draft graph 启用 采纳 dflash-block-size 16 并发 -28% 否决 dflash-block-size 4 JSON 场景 -18% 否决 tokenizer-worker-num 4 无增益 否决 fastokens（Rust tokenizer） 需 Rust toolchain 不适用 speculative-adaptive 仅支持 EAGLE 不适用 踩坑：DFLASH 强制 draft-tokens == block-size，不匹配直接 ValueError。
四、最终数据（2x3090 NVLink TP2 + AWQ INT4 + DFLASH2）
指标 数据 并发 aggregate（2 路） 219.1 avg / 249.1 峰 JSON 工具调用并发 280.5 avg（峰 303.7） 短 prompt 单路 297.3 代码生成 254.0 中文散文 85.4 vs 旧帖 133 t/s：+65% ~ +87%。
口径声明：并发 = 2 路 aggregate（双路同时生成的总吞吐）；单路端到端（含 prefill）一直 82-88 t/s。数字都是实测，无估算。
五、配置
--mem-fraction-static 0.90
--speculative-num-draft-tokens 8
--speculative-dflash-block-size 8
--tp-size 2 --kv-cache-dtype fp8_e5m2
--chunked-prefill-size 2048 --max-running-requests 2完整报告和踩坑记录见回复区，欢迎交流。
@starryskyknight 同配置复测来了，先报数据再请教硬件。
环境：SGLang 0.5.19 + twolven AWQ-MTP + incoai DFlash2（8/8, fp8_e5m2, mem 0.88, mamba 20, TP2, NCCL_P2P_DISABLE=1），你的统一脚本，t=0 / 512 tok / 3 rounds，thinking OFF：
单路 decode：代码 218.0 t/s（LRU prompt）、TTFT 0.06-0.10s
并发 2 路：同 prompt 355.2、不同 prompt 367.1想对齐几个硬件问题：
- 我这边 2×3090 走主板 PCIe x8+x8（i7-13700K，Z690），无 NVLink，NCCL P2P 已禁用。你那边 3090 是 x16 还是 x8？NVLink 之外主板的 PCIe 分配是？
- CPU 是什么？我在猜并发 355 vs 你 440 的差距主要来自 CPU/PCIe lanes（我是 24 线程桌面平台），不是模型或 SGLang 参数——想验证这个假设。
- mem-fraction 你用 0.90，我试过 0.88（给 draft graph 多点空间）单路略好，0.93 会挤 draft graph。你 0.90 时 draft graph avail mem 大概多少？
applejuice 兄的 EPYC 7452 数据（无 NVLink）我这边基本复现了（单路 218 vs 他 246，约 9% 差），所以怀疑剩的差距是纯平台带宽/核数。
-
@starryskyknight 同配置复测来了，先报数据再请教硬件。
环境：SGLang 0.5.19 + twolven AWQ-MTP + incoai DFlash2（8/8, fp8_e5m2, mem 0.88, mamba 20, TP2, NCCL_P2P_DISABLE=1），你的统一脚本，t=0 / 512 tok / 3 rounds，thinking OFF：
单路 decode：代码 218.0 t/s（LRU prompt）、TTFT 0.06-0.10s
并发 2 路：同 prompt 355.2、不同 prompt 367.1想对齐几个硬件问题：
- 我这边 2×3090 走主板 PCIe x8+x8（i7-13700K，Z690），无 NVLink，NCCL P2P 已禁用。你那边 3090 是 x16 还是 x8？NVLink 之外主板的 PCIe 分配是？
- CPU 是什么？我在猜并发 355 vs 你 440 的差距主要来自 CPU/PCIe lanes（我是 24 线程桌面平台），不是模型或 SGLang 参数——想验证这个假设。
- mem-fraction 你用 0.90，我试过 0.88（给 draft graph 多点空间）单路略好，0.93 会挤 draft graph。你 0.90 时 draft graph avail mem 大概多少？
applejuice 兄的 EPYC 7452 数据（无 NVLink）我这边基本复现了（单路 218 vs 他 246，约 9% 差），所以怀疑剩的差距是纯平台带宽/核数。
-
@Don-zhu 我这 3090+3080的奇葩组合Decode都到 199 t/s 了。。。
@johnnybegood 说明我的配置还有问题，我让deepseek再调 ：）
-
@starryskyknight 同配置复测来了，先报数据再请教硬件。
环境：SGLang 0.5.19 + twolven AWQ-MTP + incoai DFlash2（8/8, fp8_e5m2, mem 0.88, mamba 20, TP2, NCCL_P2P_DISABLE=1），你的统一脚本，t=0 / 512 tok / 3 rounds，thinking OFF：
单路 decode：代码 218.0 t/s（LRU prompt）、TTFT 0.06-0.10s
并发 2 路：同 prompt 355.2、不同 prompt 367.1想对齐几个硬件问题：
- 我这边 2×3090 走主板 PCIe x8+x8（i7-13700K，Z690），无 NVLink，NCCL P2P 已禁用。你那边 3090 是 x16 还是 x8？NVLink 之外主板的 PCIe 分配是？
- CPU 是什么？我在猜并发 355 vs 你 440 的差距主要来自 CPU/PCIe lanes（我是 24 线程桌面平台），不是模型或 SGLang 参数——想验证这个假设。
- mem-fraction 你用 0.90，我试过 0.88（给 draft graph 多点空间）单路略好，0.93 会挤 draft graph。你 0.90 时 draft graph avail mem 大概多少？
applejuice 兄的 EPYC 7452 数据（无 NVLink）我这边基本复现了（单路 218 vs 他 246，约 9% 差），所以怀疑剩的差距是纯平台带宽/核数。
@Don-zhu prefill 多少
楼主是nvlink pcie 也不重要了，因为都显卡数据交换 经过nvlink 不经过pcie
你的是x8 我的是x16 分别就是这里
单路 decode，rounds=3、max_tokens=512、temperature=0, NCCL_P2P_DISABLE=0, NCCL_P2P_LEVEL=SYS, disable_custom_all_reduce=true, 245w 功耗
场景 ON (t/s) OFF (t/s) Δ decode tok/chunk ON tok/chunk OFF 代码生成 147.6 258.1 +74.9% 3.64 6.32 英文技术论述 109.2 147.2 +34.8% 2.69 3.63 中文常规对话 80.5 103.5 +28.6% 1.99 2.56 中文散文 67.0 64.3 −4.0% 1.67 1.60 并发 2 路 aggregate decode（代码场景）：
并发模式 ON (t/s) OFF (t/s) Δ OFF 相对单路 同 prompt（radix 命中） 232.2 463.7 +99.7% ×1.80 不同 prompt 221.1 433.2 +95.9% ×1.68 Prefill
唯一随机 prompt（规避 radix 命中），
max_tokens=1，rounds=2 取最快。
固定开销标定 411 ms（极短 prompt 最小 TTFT，5 次取 min）。实际 prompt_tokens TTFT (s) 原始 t/s 扣除开销 t/s 2,160 1.529 1413 1933 
️8,502 5.167 1645 1788 16,982 10.304 1648 1717 33,703 21.657 1556 1586 67,642 49.198 1375 1386 137,835 124.093 1111 1114 -
@johnnybegood 说明我的配置还有问题，我让deepseek再调 ：）
-
@Don-zhu 我觉得差不多 一方面你没有nvlink 然后 pcie x8
@applejuice 感谢回复。我也觉得是这个问题。
-
@Don-zhu prefill 多少
楼主是nvlink pcie 也不重要了，因为都显卡数据交换 经过nvlink 不经过pcie
你的是x8 我的是x16 分别就是这里
单路 decode，rounds=3、max_tokens=512、temperature=0, NCCL_P2P_DISABLE=0, NCCL_P2P_LEVEL=SYS, disable_custom_all_reduce=true, 245w 功耗
场景 ON (t/s) OFF (t/s) Δ decode tok/chunk ON tok/chunk OFF 代码生成 147.6 258.1 +74.9% 3.64 6.32 英文技术论述 109.2 147.2 +34.8% 2.69 3.63 中文常规对话 80.5 103.5 +28.6% 1.99 2.56 中文散文 67.0 64.3 −4.0% 1.67 1.60 并发 2 路 aggregate decode（代码场景）：
并发模式 ON (t/s) OFF (t/s) Δ OFF 相对单路 同 prompt（radix 命中） 232.2 463.7 +99.7% ×1.80 不同 prompt 221.1 433.2 +95.9% ×1.68 Prefill
唯一随机 prompt（规避 radix 命中），
max_tokens=1，rounds=2 取最快。
固定开销标定 411 ms（极短 prompt 最小 TTFT，5 次取 min）。实际 prompt_tokens TTFT (s) 原始 t/s 扣除开销 t/s 2,160 1.529 1413 1933 ️8,502 5.167 1645 1788 16,982 10.304 1648 1717 33,703 21.657 1556 1586 67,642 49.198 1375 1386 137,835 124.093 1111 1114 @applejuice 350W 这组 prefill 档位数据收了,19k 181k 从 1966 掉到1141 t/s(-42%)、TTFT9.8s 159s,退化曲线 很有用。
不过有个反直觉点想对齐:350W 墙下代码 284.9 反而比无
墙 246.7高 15%,散文 72.7 也高 18%,英文/中文却掉 10-21%——不像功耗墙特征,更像 prompt 或热身后的状态差 (tok/chunk 也不一样:6.69 vs 6.32)。方便的话同 prompt 无墙再跑一轮对照?真复现了就是功耗墙时钟策略对某些负 载有利,那是个大发现。
-
@starryskyknight 同配置复测来了，先报数据再请教硬件。
环境：SGLang 0.5.19 + twolven AWQ-MTP + incoai DFlash2（8/8, fp8_e5m2, mem 0.88, mamba 20, TP2, NCCL_P2P_DISABLE=1），你的统一脚本，t=0 / 512 tok / 3 rounds，thinking OFF：
单路 decode：代码 218.0 t/s（LRU prompt）、TTFT 0.06-0.10s
并发 2 路：同 prompt 355.2、不同 prompt 367.1想对齐几个硬件问题：
- 我这边 2×3090 走主板 PCIe x8+x8（i7-13700K，Z690），无 NVLink，NCCL P2P 已禁用。你那边 3090 是 x16 还是 x8？NVLink 之外主板的 PCIe 分配是？
- CPU 是什么？我在猜并发 355 vs 你 440 的差距主要来自 CPU/PCIe lanes（我是 24 线程桌面平台），不是模型或 SGLang 参数——想验证这个假设。
- mem-fraction 你用 0.90，我试过 0.88（给 draft graph 多点空间）单路略好，0.93 会挤 draft graph。你 0.90 时 draft graph avail mem 大概多少？
applejuice 兄的 EPYC 7452 数据（无 NVLink）我这边基本复现了（单路 218 vs 他 246，约 9% 差），所以怀疑剩的差距是纯平台带宽/核数。
@Don-zhu 收到，三个问题逐一回：
PCIe：我这边也是 x8+x8——Z890 平台 CPU 直出 20 lanes，x16 槽拆 x8/x8（PCIe 5.0），两卡各 x8，跟你一样。唯一物理差异就是 NVLink 桥。
CPU：Core Ultra 9 285K（24 线程）——巧了，跟你 13700K 线程数一样，所以并发差距不在 CPU 线程数。先说个口径：我 OFF 同 prompt 是 518.4 / 不同 550.8（不是 440）。真正的差距在你的 NCCL_P2P_DISABLE=1：TP=2 每步同步激活，你禁 P2P 后同步走 host 内存中转，并发多路时同步次数放大，差距就显形了。证据是模式：单路 218 vs 270（-19%），并发 -31%~-33%，差距随并发放大正是同步带宽特征。验证方法：打 smcleod/nvidia-p2p-patch 开 P2P（无 NVLink 的 3090 跨卡 P2P 默认被驱动锁，patch 后走 PCIe 4.0 x8 双向 ~16GB/s，远好于 host 中转），重跑并发——差距缩到 ~20% 以内就证伪 CPU 假设了。
mem-fraction 0.90：0.94 时日志打 Disable DFLASH draft cuda graph because only 0.93 GB GPU memory is available——graph 被挤掉；0.90 恢复启用（selector decode 也折叠进去）。精确 avail 我没记，估算 0.90 时 ~1.9GB 上下，看你自己启动日志这行的数字最准。你 0.88 单路略好我信，但会压缩 KV cache 上限，长 context 档位先吃紧，看用途取舍。
-
@stormaround
关于「DFLASH 牺牲视觉」：不会，正好今天实测验证了。DFLASH 只参与 decode 阶段（草稿出 token），图像编码在 prefill 阶段完成，两段正交。twolven 这个 AWQ 版视觉塔保留 bf16 未量化，模型卡原文就有 "vision still works"。今天 curl 直传图片实测：读图 100% 正确（形状/颜色/文字全对），同时段 DFLASH accept rate 0.28-0.40 照常跑，零冲突。真实照片测试连法文成分表都能正确 OCR。那还可以，之前用双r9700跑tp2，mtp和dflash速度差不多，就没有再去调dflash
@stormaround 有用就行。双 R9700 上 MTP/DFLASH 增益相近这个数据很宝贵，AMD 平台的 DFLASH 适配确实起步晚。这版 SGLang dev 对 DFLASH 动了不少（f60bc73c 修 TP 状态分歧 + draft cuda graph 默认启用），ROCm 下值得再试一轮。
