雙 2080 Ti 22G 魔改卡跑 Qwen3.8-27B：由 1 並發改 8 並發實測 — 總吞吐 +112%，單線只跌 3%
-
最近把工作站的 vLLM 由 1 並發改成 8 並發，分享一下改動思路和實測數據。
硬件：
- RTX 2080 Ti 22G 魔改卡 ×2（NVLink 橋）
- 模型：Qwen3.8-27B W4A16 AWQ（community quant，~11GB）
- 軟件：weicj/vLLM-2080Ti-Definitive（專為雙 2080 Ti / SM75 Turing 優化的 vLLM fork，感謝作者 weicj 和 upstream vLLM）
- TP=2 · 256K context · MTP speculative decoding · fp16 KV
為什麼從 1 並發改 8 並發：
之前跟 repo 建議跑 1-concurrent + 內建排隊，圖的是單線 decode 最快。但實際 workload 是：
- 讀 PDF / RAG：一般 50K context 以內
- VS Code agent：可控制在 100K context 以內
- 都遠低於 256K 上限 —— 「一條 request 食滿整個 context」的場景根本沒出現過
而 agent 的工作模式是：想一段 → 等 command 跑完 → 再想。等 command 時 GPU 完全 idle，1 並發下這些空檔全部浪費。多並發就是把空檔填滿。
實測數據（同方法對比，真實 token 計數）：
配置 單線 decode 8 並發總吞吐 8 並發 max TTFT 1 並發（MTP3，舊設定） 54.6 t/s 60.4 t/s（其餘排隊） 30.4 s 8 seqs 無 MTP 46.3 t/s 102.0 t/s 3.2 s 8 seqs + MTP2（現行） 52.8 t/s 128.4 t/s 5.3 s Prefill（現行配置）：~1,600 t/s @8K · ~1,430 t/s @32K · ~1,200 t/s @65K
結論：
- 總吞吐 60.4 → 128.4 t/s（+112%），TTFT 從排隊 30 秒級降到 5 秒級
- 單線只跌 ~3%（54.6 → 52.8，MTP3→MTP2 騰出 batch 空間）
- 對 agent / 多 client 場景是質變：以前第二條 request 要等第一條做完，現在真正並行
代價也要說：8 並發時每條線只有 ~20 t/s，長 context prefill 會互相排隊。所以這是「agents farm」取向，不是「單線跑分」取向。
現行配置（launcher 參數）：
--tensor-parallel-size 2 --max-model-len 262144 --max-num-seqs 8 --max-num-batched-tokens 2048 --quantization compressed-tensors (W4A16) --speculative-config method=mtp,num_speculative_tokens=2 --enable-chunked-prefill --enable-prefix-caching temperature 0.6 / reasoning_effort medium -
为什么你的单线程mtp3 decode这么慢 不应该啊，没装nvlink吗？ 实际decode应该有100tks
测试结果 (OpenAI兼容接口 - Qwen3.8-27B-W4A16)
备注：2080tix2_Qwen3.8-27B-W4A16 | 并发数: 1
提示词长度 (tokens) TTFT (ms) ITL平均 (ms) 预填充速度 (tokens/s) 输出速度 (tokens/s) 状态 2048 1822.42 35.49 1125.67 111.18 1/1 并发成功 4096 2253.48 36.06 1820.28 110.25 1/1 并发成功 6144 3496.46 36.18 1759.57 108.65 1/1 并发成功 测试结果 (OpenAI兼容接口 - Qwen3.8-27B-W4A16)
备注：2080tix2_Qwen3.8-27B-W4A16 | 并发数: 4
提示词长度 (tokens) TTFT (ms) ITL平均 (ms) 预填充速度 (tokens/s) 输出速度 (tokens/s) 状态 512 2420.56 42.30 363.41 189.68 4/4 并发成功 1024 2189.48 43.36 1509.46 267.87 4/4 并发成功 2048 3585.16 44.90 1710.21 300.96 4/4 并发成功 4096 6680.39 48.72 1735.14 241.81 4/4 并发成功 -
@明风影视mfys 这个 110 t/s 才是 2080Ti×2 的正确区间，54.6 t/s 那组要拆开看。
27B W4A16 约 11GB 权重，TP=2 后每卡读 ~5.5GB；2080Ti 显存带宽 616 GB/s，纯 decode 的带宽上限就是 ~110 t/s。你测到的 111/110/108 t/s（2K–6K prompt）基本贴着天花板，说明这条路径没有额外开销。
OP 那组 54.6 t/s 是「1 并发 + MTP3 旧设定」下的数：MTP 在 batch=1 时每步多跑一次 draft + verify，只有 accept length 明显 >1 才赚；accept 在 1.x 时反而净亏，旧 fork 的 MTP 路径也可能没进 CUDA Graph、多一次同步。另外 fp16 KV 在长上下文下 KV 读取量上来，也会把 decode 从 110 拉下来。
定位用三组单变量：
- 同 prompt、同并发，MTP on/off 各跑一次，记录 accept length（vLLM 的 spec_decode 指标）；accept < 1.6 就别开 MTP。
- nvidia-smi dmon 看显存带宽有没有吃满；没吃满就是 kernel/同步开销，不是带宽。
- NVLink 对 batch=1 影响很小（TP 每层 all-reduce，batch=1 通信量本就不大），它救的是 8 并发那组的 TTFT/吞吐。2K–6K 组能到 110 t/s 已经说明这点。
结论：不是「没装 NVLink 所以慢」，是 MTP 旧设定和 KV 口径的差；两边对齐同 prompt/并发口径后应该能收敛。
