【倡议】3090 单/双/多卡联合评测帖（2026年9-10月）—— benchmark与配置/模型对比
-
@applejuice 有，因 PCIE 頻寬頻頸(沒NVLink)，效率低下(雖然96G顯存很吸引人)...
剛剛又重新跟AI對話下，更新結論3090(無 NVLink,全程 PCIe)並行配置比較表
數字全取自 skill 已固化實測(2026-09-15,社群 uni_bench 口徑,代碼場景)比較項 tp=2(單實例,用2卡) tp=4(四卡合一) tp=2×2(雙實例,各2卡) 卡間鏈路 PCIe PCIe PCIe all-reduce kernel custom(較省) 退 NCCL 通用(較慢) custom(較省) 通信範圍 2 卡對傳 4 卡集合,含跨 PHB 組慢跳 2 卡/實例,零跨組 單路 decode 249.7 t/s 227.9 t/s(↓9%) 261.7 / 271.8 t/s(各實例) 併發 4 路 agg 361.0 t/s 228.4 t/s(↓37%) 342.7 / 367.1 t/s(各實例) 系統總吞吐 361.0 t/s(2卡用,2卡閒) 228.4 t/s 709.8 t/s(兩實例相加,↑97%) 單模型可用顯存 48GB 96GB(單一池) 48GB × 2(獨立) 卡使用 2 用 / 2 閒 4 全用 4 全用(2 實例) 口徑警告(避免誤讀)
- 709.8 是兩實例併發吞吐「相加」的系統總產能,不是單一請求變快。談速度看單路那列。
- 單路對照(公平比速度):tp=4 227.9 比 tp=2 249.7 還慢 9% —— tp=4 純速度單路、併發兩頭都輸。
- tp=2×2 贏在系統產能(多開一實例吃第二組卡),非單路更快;單路它 ~265,與 tp=2 同級(略高,因兩實例各獨佔一組 PHB 無干擾)。
一句話結論
- 現役 27B(~19GB,48GB 綽綽有餘):tp=2×2 系統產能最高(709),定案最優。
- tp=4 唯一價值 = 96GB 單一顯存池,只有在「模型/context 塞不進 48GB」時才選,代價是單路 -9%、併發 -37%。速度維度全輸。
-
-
-
@Eric-Su 大佬 测一测 pp=2 × tp=2
我想玩很久了 所以之前问ai 问了很多
据ai 单发 可能比较慢
但是多发就快了
而且有96gb vram开个4卡3090帖子吧
分享下硬件 psu 之类的
我想了解多点
@applejuice 正在測...但看來效能可能會很慘(GPU沒吃滿，另不支持DFlash)
結果::
pp2×tp2 POC 實測結果(27B)可行性 — 過了
pp2×tp2 在 Qwen3.8-27B 混合架構(GDN mamba+MTP)上能穩定起、能推理。最大的未知雷——mamba 層跨 pp 段——沒炸:每 rank Mamba Cache 正常分配、TritonGDNKernel 正常 dispatch、四 rank(PP0/PP1×TP0/TP1)排布正確。這是 POC 要驗的核心,達成。速度 — 27B 上全面輸現役(如預期)
口徑 pp2×tp2(無spec) 現役 tp2+DFLASH 單路代碼 71 t/s 260 t/s(-73%) 單路中文散文 70 73 併發4路代碼 192 361(-47%) 主因兩層:
- 丟了 DFLASH spec(pp≠1 硬互斥)——tok/chunk 從 ~6 掉到 1.00,單路少吐一堆 token,這是大頭。
- pp bubble + 每層仍走 PCIe。
-
@applejuice 正在測...但看來效能可能會很慘(GPU沒吃滿，另不支持DFlash)
結果::
pp2×tp2 POC 實測結果(27B)可行性 — 過了
pp2×tp2 在 Qwen3.8-27B 混合架構(GDN mamba+MTP)上能穩定起、能推理。最大的未知雷——mamba 層跨 pp 段——沒炸:每 rank Mamba Cache 正常分配、TritonGDNKernel 正常 dispatch、四 rank(PP0/PP1×TP0/TP1)排布正確。這是 POC 要驗的核心,達成。速度 — 27B 上全面輸現役(如預期)
口徑 pp2×tp2(無spec) 現役 tp2+DFLASH 單路代碼 71 t/s 260 t/s(-73%) 單路中文散文 70 73 併發4路代碼 192 361(-47%) 主因兩層:
- 丟了 DFLASH spec(pp≠1 硬互斥)——tok/chunk 從 ~6 掉到 1.00,單路少吐一堆 token,這是大頭。
- pp bubble + 每層仍走 PCIe。
-
@applejuice 正在測...但看來效能可能會很慘(GPU沒吃滿，另不支持DFlash)
結果::
pp2×tp2 POC 實測結果(27B)可行性 — 過了
pp2×tp2 在 Qwen3.8-27B 混合架構(GDN mamba+MTP)上能穩定起、能推理。最大的未知雷——mamba 層跨 pp 段——沒炸:每 rank Mamba Cache 正常分配、TritonGDNKernel 正常 dispatch、四 rank(PP0/PP1×TP0/TP1)排布正確。這是 POC 要驗的核心,達成。速度 — 27B 上全面輸現役(如預期)
口徑 pp2×tp2(無spec) 現役 tp2+DFLASH 單路代碼 71 t/s 260 t/s(-73%) 單路中文散文 70 73 併發4路代碼 192 361(-47%) 主因兩層:
- 丟了 DFLASH spec(pp≠1 硬互斥)——tok/chunk 從 ~6 掉到 1.00,單路少吐一堆 token,這是大頭。
- pp bubble + 每層仍走 PCIe。
-
@applejuice 正在測...但看來效能可能會很慘(GPU沒吃滿，另不支持DFlash)
結果::
pp2×tp2 POC 實測結果(27B)可行性 — 過了
pp2×tp2 在 Qwen3.8-27B 混合架構(GDN mamba+MTP)上能穩定起、能推理。最大的未知雷——mamba 層跨 pp 段——沒炸:每 rank Mamba Cache 正常分配、TritonGDNKernel 正常 dispatch、四 rank(PP0/PP1×TP0/TP1)排布正確。這是 POC 要驗的核心,達成。速度 — 27B 上全面輸現役(如預期)
口徑 pp2×tp2(無spec) 現役 tp2+DFLASH 單路代碼 71 t/s 260 t/s(-73%) 單路中文散文 70 73 併發4路代碼 192 361(-47%) 主因兩層:
- 丟了 DFLASH spec(pp≠1 硬互斥)——tok/chunk 從 ~6 掉到 1.00,單路少吐一堆 token,這是大頭。
- pp bubble + 每層仍走 PCIe。
@Eric-Su pp2×tp2 的结果符合预期，拆一下主因，不然容易归错因。
- 最大头不是 pp bubble，是 spec 没了。pp>1 和 DFlash 硬互斥，tok/chunk 从 ~6 掉到 1.0，等于把 tp2+DFLASH 的最大增益直接删掉。单路 71 vs 260 里，七成左右是这个造成的。
- pp bubble + 每层 all-reduce 过 PCIe 是第二层原因。pp 段数越多，micro-batch 越难填满，空泡占比越高；无 NVLink/无 P2P 时每层通信还绕主机内存，pp 省下的通信量被延迟吃掉。
- 并发 4 路 192 vs 361 的差距比单路小，说明 batch 大时 micro-batch 能把 bubble 填一部分，但填不平 DFlash 那块缺口。
能验证的动作：
- 单独跑 tp2（不 pp）+ DFlash，拿 tok/chunk 作基准，量化 spec 的贡献。
- 想上 pp，先把 PCIe P2P 打通（同 root complex 的 P2PDMA whitelist / ACS，或上 PCIe switch）。P2P 通了 pp 的每层通信延迟会明显降。
- SGLang 的 CustomAllreduce 在 pp>1 时容易挂，求稳就 --disable-custom-all-reduce 退 NCCL，别为省带宽牺牲可跑性。
- prefill：pp 通常有小幅收益（每 rank 算的层少），但端到端要扣 bubble；测的时候 pp 和 tg 分开报。
4 卡无 NVLink 的结论仍沿用你那张表：tp=2×2 双实例聚合最优，tp=4 单路小跌、聚合大跌。除非有 NVLink 全互联，别把 4 卡当一个 tp=4 大实例用。
-
@Eric-Su 有没有prefill 结果？
@applejuice 離開辦公室哩，下禮拜繼續玩玩...剛主要在拷問有沒有DF的替代方案...
演算法 pp>1 能用? 依據 DFLASH(現役) ✗ 硬擋 arg 層 raise「only supports pp_size==1」(需獨立 draft 模型,不吃 PP_SPEC 路徑) DSpark ✗ 硬擋 同上 raise(596) UNO ✗ 硬擋 要求 TP=PP=1(506) EAGLE / NEXTN ✓ 可用 arg 層無 pp gate + 正是 PP_SPEC 路徑的目標 NGRAM 待確認 arg 層無 pp gate,但 PP_SPEC 註解只提 MTP draft,NGRAM 走 trie 非 MTP,可能不吃這條路 機制(scheduler.py L1033-1042 + L1172-1177):
- 有一個環境變數 SGLANG_ENABLE_PP_SPEC(預設 False)。
- 開啟後,pp 的非最後 stage 不跑 draft worker,只跑 verify-shaped target forward;draft(MTP layer)集中在最後 stage(因為 MTP head + lm_head 只在最後 stage)。
- spec_info.py 有專門的 PP_SPEC_RELAY 中繼機制串接。
為什麼 EAGLE 特別合適我們:
現役模型 Qwen3.8-27B-AWQ-MTP 本身就內建 MTP head。EAGLE 直接吃這個內建 head 當 draft,不需獨立 draft 權重——skill 記載 DFLASH2 之前的正式配方就是 EAGLE(代碼 179 t/s、accept len 6.0),現役 image 就有,零額外下載。一個誠實的但書(未坐實,要實測)
SGLANG_ENABLE_PP_SPEC 預設 False + 註解措辭(「非最後 stage 沒 draft worker」)透露這是實驗性/新路徑。三件事只有實測才知道:
- EAGLE + PP_SPEC + 我們這個 GDN mamba 混合架構會不會有雷(mamba 跨 pp + spec relay 同時作用,是雙重新路徑疊加)。
- 開了之後 EAGLE 的 accept len 在 pp 下會不會打折(draft 在 last stage 算、verify 跨 stage,可能有額外開銷)。
- 實測速度到底補回多少——理論上比「無 spec 的 71 t/s」高不少,但 pp bubble 還在。
方案定位
pp2×tp2 要跑更大模型時,EAGLE + SGLANG_ENABLE_PP_SPEC=1 是把 spec 加回來的正解路徑(取代被擋的 DFLASH),前提是那個大模型也有 MTP head 或 EAGLE draft。這正好把你前面擔心的「pp 丟了 spec 變慢」補上一大塊。
-
【补充·数据修正】4 并发掉速真因 + NVLink 计数修正 + 单路口径说明
（针对帖内此前的复核意见（#11 楼）＋我自己 9/17 报的数据（#9 楼），复测与修正如下）之前我在本帖报过：单路 138.8 / 2 并发 260.9 / 4 并发 243.4 t/s，以及「一次约 400 字回答搬运约 10.1GB」。经今晚两轮复测，修正三处，供后来者参考：
① 4 并发 < 2 并发 的真因（已定位＋已解决）
不是 preempt、也不是 KV 不够——是 mamba state cache 把并发上限卡死在 3。
SGLang 启动日志原话：
max_running_requests is capped to 3 by the mamba state cache (max_mamba_cache_size=15, 4 state slots per request)
→ 第 4 路请求其实在排队（TTFT 4.956s，等了 4.6 秒），聚合吞吐 552 → 496 t/s。
→ 解法：--max-mamba-cache-size 16（+1 槽）即可开满 4 并发。复测（同协议：代码场景 / 固定 1024 输出 / temp0）：- 4 路全部并行：TTFT 均 ≈1.07s、每路 178–183 t/s、聚合 713 t/s（比 3 槽时代 +43.6%、墙钟 −30%）
- 代价：KV 池 354,788 → 322,573 tokens（−9%，仍 >1× 全长 262K）
- 4×32K 长文压力探针：零 retract、KV 稳定 ✓
② NVLink 计数修正
按nvidia-smi nvlink -gt d快照差、同 prompt 三轮复测：≈6,145（KiB 计数）/token → 400 字 ≈ 2.4–2.6GB。
原「10.1GB」的读数高估约 4.3 倍——原因是把 prefill 与 draft/verify 那部分也算了进去。
量法建议：清计数 → 固定 prompt → Δbytes ÷ 生成 token，prefill/decode 分开。③ 单路口径说明
补测（固定 1024 输出、ignore_eos、代码场景）：单路 294 t/s——与帖内先前的代码场景数据（~269.5）同级。
原 138.8 疑似口径差异（含思考段或未固定输出），引用时建议注明条件。附：短协议（单路）：p=8192 冷 prefill ≈ 2447 tok/s；热缓存 TTFT 3.35s → 0.63s；全程 retracted=0。
机器：双 3090（NV4×4 全通、P2P OK）+ Z890 / SGLang tp2 / AWQ + DFlash2(block8) / fp8 KV / mem-fraction 0.90。 -
-
【补充·数据修正】4 并发掉速真因 + NVLink 计数修正 + 单路口径说明
（针对帖内此前的复核意见（#11 楼）＋我自己 9/17 报的数据（#9 楼），复测与修正如下）之前我在本帖报过：单路 138.8 / 2 并发 260.9 / 4 并发 243.4 t/s，以及「一次约 400 字回答搬运约 10.1GB」。经今晚两轮复测，修正三处，供后来者参考：
① 4 并发 < 2 并发 的真因（已定位＋已解决）
不是 preempt、也不是 KV 不够——是 mamba state cache 把并发上限卡死在 3。
SGLang 启动日志原话：
max_running_requests is capped to 3 by the mamba state cache (max_mamba_cache_size=15, 4 state slots per request)
→ 第 4 路请求其实在排队（TTFT 4.956s，等了 4.6 秒），聚合吞吐 552 → 496 t/s。
→ 解法：--max-mamba-cache-size 16（+1 槽）即可开满 4 并发。复测（同协议：代码场景 / 固定 1024 输出 / temp0）：- 4 路全部并行：TTFT 均 ≈1.07s、每路 178–183 t/s、聚合 713 t/s（比 3 槽时代 +43.6%、墙钟 −30%）
- 代价：KV 池 354,788 → 322,573 tokens（−9%，仍 >1× 全长 262K）
- 4×32K 长文压力探针：零 retract、KV 稳定 ✓
② NVLink 计数修正
按nvidia-smi nvlink -gt d快照差、同 prompt 三轮复测：≈6,145（KiB 计数）/token → 400 字 ≈ 2.4–2.6GB。
原「10.1GB」的读数高估约 4.3 倍——原因是把 prefill 与 draft/verify 那部分也算了进去。
量法建议：清计数 → 固定 prompt → Δbytes ÷ 生成 token，prefill/decode 分开。③ 单路口径说明
补测（固定 1024 输出、ignore_eos、代码场景）：单路 294 t/s——与帖内先前的代码场景数据（~269.5）同级。
原 138.8 疑似口径差异（含思考段或未固定输出），引用时建议注明条件。附：短协议（单路）：p=8192 冷 prefill ≈ 2447 tok/s；热缓存 TTFT 3.35s → 0.63s；全程 retracted=0。
机器：双 3090（NV4×4 全通、P2P OK）+ Z890 / SGLang tp2 / AWQ + DFlash2(block8) / fp8 KV / mem-fraction 0.90。 -
@starryskyknight 2.5k 的prefill 实在羡慕
@applejuice NVLINK 真的貴....
-
系统 于 取消固定此主题
-
