并发加到 16 吞吐反而没涨：找到收益天花板与实用拐点
把并发从 1 一路加到 16，吞吐涨到并发 8 就停住了，16 甚至略降（148.95 → 148.22 tok/s），但单请求等待从 13.13 秒涨到 20.24 秒。结论：并发 4 是实用拐点，8 是收益天花板，16 是纯亏。加并发的真实含义不是「让系统变快」，而是把一个人的等待摊到所有人头上。
推理优化并发张量并行SGLang容量规划这条适用于
- 多机跑实例（张量并行切分）
- 关注的是吞吐拐点，不是单请求延迟
版本指纹
4 台机器跑单实例（张量并行）；拐点值为本机可接受等待度的判断
具体做法
# 4× DGX Spark 单实例（DeepSeek-V4.1-Flash / SGLang），max_tokens=256, temperature=0, 同 prompt
# 同时发 N 条，记录系统吞吐与单请求等待并发 系统吞吐 加速比 单请求等待
1 41.20 tok/s 1.00x 6.21 s
2 65.26 tok/s 1.58x 7.67 s
4 103.29 tok/s 2.51x 9.52 s <- 实用拐点
8 148.95 tok/s 3.62x 13.13 s <- 收益天花板
16 148.22 tok/s 3.60x 20.24 s <- 零收益，等待 +54%边际账（收益 vs 代价）
1 -> 2 : 吞吐 +58% 等待 +1.5 s 赚
2 -> 4 : 吞吐 +58% 等待 +1.9 s 赚
4 -> 8 : 吞吐 +44% 等待 +3.6 s 勉强划算
8 -> 16: 吞吐 +0% 等待 +7.1 s 纯亏
判断动作：看到「加并发/加卡/加带宽」这类听着就像解决方案的动作时，先问一句
—— 它的代价记在谁的账上？如果代价和收益记的不是同一个账本，就不能只看吞吐那一栏。
失效边界
这堵墙不堵在算力上，堵在通信上：四台机器跑一个实例，权重按张量并行切开，每次前向都要跨机器 all-reduce 同步；batch 越大，要同步的数据越多，到某个点通信吃掉的超过算力赚到的，曲线就平了。实操含义是——加卡解决不了这个问题，卡越多跨机同步的东西越多，墙反而更厚。适用边界：拐点 4 是，不同模型、不同硬件、不同 SLA 下拐点不同。另外「加速比永远小于并发数」是张量并行的普遍规律，但具体比例随互联带宽变化，不要直接套用上面的数值。
这堵墙不堵在算力上，堵在通信上：四台机器跑一个实例，权重按张量并行切开，每次前向都要跨机器 all-reduce 同步；batch 越大，要同步的数据越多，到某个点通信吃掉的超过算力赚到的，曲线就平了。实操含义是——加卡解决不了这个问题，卡越多跨机同步的东西越多，墙反而更厚。适用边界：拐点 4 是，不同模型、不同硬件、不同 SLA 下拐点不同。另外「加速比永远小于并发数」是张量并行的普遍规律，但具体比例随互联带宽变化，不要直接套用上面的数值。