Jellow 编辑发布，AI 辅助生成并完成技术核对。 计算示例和实测结果会在文中分别说明。

模型刚好能放进一张 GPU，但 Decode 的每 token 延迟没有达标。把 tensor_parallel_size 从 1 改成 4，会接近四倍快吗？另一种情况更直接：模型单卡放不下，究竟该用几路张量并行（Tensor Parallelism，TP），还是沿层切成流水线并行？

答案不能只看 GPU 数量。张量并行把矩阵乘法分给多张卡，同时把原来留在卡内的数据依赖变成集合通信。本文从一次调度步骤中的激活形状 [T,H] 出发，算出标准 Megatron 式稠密 Transformer 的通信账，再给出可测量的加速条件。

核对日期为 2026-09-12。讨论范围是采用一维列并行/行并行的稠密 Decoder 推理；MoE、Sequence Parallel、Context Parallel 和特殊融合实现放在失效边界中处理。

先把“放得下”和“跑得快”拆开

对每个候选 TP 度数 p，先检查容量约束：

[
M{rank}(p)=M{weight}(p)+M{KV}(p)+M{runtime}(p)\le M_{usable}
]

M_usable 是扣除安全余量后的单卡可用显存。权重通常可按 p 分片，但 KV Cache、词表、临时工作区和框架保留内存是否等比例缩小取决于实现，不能直接把总显存除以 p。

容量检查只产生“可运行的候选集合”，不证明更多卡更快。如果模型能在单卡运行，以吞吐为目标时，合理基线不是一组 TP=p，而是相同 p 张卡上的 p 个 TP=1 副本。vLLM 的官方部署指南也把“模型能放入单卡”作为优先采用单卡推理的起点；节点内模型过大时才优先 TP，缺少 NVLink 的节点则建议考虑流水线并行以降低通信压力。vLLM Parallelism and Scaling

如果模型单卡放不下，最小可行 p 是容量基线。此时“成功”可能只是让模型能够运行，不能把它表述成相对单卡的实测加速。

为什么一个 MLP 只在末尾归并

设当前调度步骤有 T 个活跃 token，隐藏维度为 H，SwiGLU 中间维度为 I：

[
X\in\mathbb{R}^{T\times H},\quad
W_g,W_u\in\mathbb{R}^{H\times I},\quad
W_d\in\mathbb{R}^{I\times H}
]

Decode 每条活跃序列通常贡献一个新 token，因此此时 T 近似活跃批大小；Prefill 或 Chunked Prefill 中，T 是本步骤实际调度的 prompt token 总数，不等于请求数。

把前两个权重沿输出维切成 p 份，把下降投影沿输入维切成对应的 p 份：

[
Wg=[W{g,1},\ldots,W_{g,p}],\quad
Wu=[W{u,1},\ldots,W_{u,p}],\quad
Wd=\begin{bmatrix}W{d,1}\ \vdots \ W_{d,p}\end{bmatrix}
]

第 r 张卡计算：

[
Zr=\operatorname{SiLU}(XW{g,r})\odot(XW_{u,r})
\in\mathbb{R}^{T\times I/p}
]

[
P_r=ZrW{d,r}\in\mathbb{R}^{T\times H},\qquad
Y=\sum_{r=1}^{p}P_r
]

激活函数和逐元素乘法都留在本地分片内，只有最后的 [T,H] 部分和需要 All-Reduce。Megatron Core 的官方 API 仍以 ColumnParallelLinear 和 RowParallelLinear 表达这两种切分。Megatron Core 张量并行层文档

自注意力采用相同配对：Q/K/V 投影按头或输出列切分，注意力在各卡本地计算，输出投影按行切分后归并。原始 Megatron-LM 论文由此得到一个标准 Transformer 层前向两次 All-Reduce：注意力一次，MLP 一次。Megatron-LM 论文

这里的“两次”是本文成本模型的关键假设，不是所有推理引擎和模型结构的常数。

从 [T,H] 得到通信账

设激活通信数据类型每元素占 e_a 字节。一次 All-Reduce 的逻辑载荷为：

[
S=THe_a\quad\text{bytes}
]

对 p 个 rank，NVIDIA nccl-tests 给出的 All-Reduce 总线带宽修正因子是 2(p-1)/p。按每个 rank 的出口带宽折算，一次集合通信的数据项为：

[
V_{AR}=\frac{2(p-1)}{p}S
]

一个有 L 层的步骤包含 2L 次这样的归并，所以总线等价通信量为：

[
V_{step}=4L\frac{p-1}{p}THe_a
]

NVIDIA 对该因子的推导同时提醒：小消息应直接观察操作时间；消息足够大之后，时间才近似为固定开销加字节数除以带宽。因此可用下式做初筛：

[
\tau_{AR}(S,p)\approx \alpha_p+
\frac{2(p-1)S}{pB_p}
]

α_p 是一次集合通信的固定延迟，B_p 是指定 rank 布局下的有效总线带宽。NCCL 可能选择树、环、NVLS 或其他路径，这个式子不是替代实测的硬件承诺；生产判断应直接代入相同拓扑、相同载荷下测得的 τ_AR。

看一个纯计算示例。假定 H=8192、L=80、T=32，激活以 BF16 通信，p=4：

• 每次载荷 S=32×8192×2=524288 字节，即 512 KiB；
• 每步有 2L=160 次集合通信；
• 每个 rank 的总线等价通信量为 4×80×3/4×512 KiB=120 MiB。

120 MiB 看起来不大，但它被拆成 160 次有依赖关系的调用，固定延迟可能比峰值带宽更重要。这也是小 Decode 批量经常无法按卡数线性加速的原因。

加速成立需要满足什么不等式

令 GQA 的 KV 投影总宽度为 H_KV。忽略 bias 后，注意力投影 Q、K、V、O 的主要 FLOPs 为：

[
F{attn}=4T(H^2+HH{KV})
]

SwiGLU 三个线性层的 FLOPs 为：

[
F_{mlp}=6THI
]

因此每层主要投影计算量近似为：

[
F{proj}=4T(H^2+HH{KV})+6THI
]

这些式子按一次乘加计 2 FLOPs。它们没有包括注意力分数、归一化、采样和调度开销；长上下文会增加注意力计算，从而改变计算与通信的比例。

先作一个乐观假设：分片后的 GEMM 效率不下降，投影计算可按 p 等分。则：

[
tp\approx \frac{t{proj,1}}{p}+2L\tau_{AR}(THea,p)+t{other,p}
]

TP 比单卡快的必要条件是：

[
\left(1-\frac{1}{p}\right)t_{proj,1}

2L\tau{AR}+(t{other,p}-t_{other,1})
]

左侧是理想情况下省下的计算时间，右侧是新增通信及其他开销。代价并没有消失，而是从单卡 GEMM 转移到了集合通信、更小的本地 GEMM、同步等待和多卡资源占用。

还能得到一个活跃 token 数阈值。若单卡全部投影时间写成 t_proj,1=aT，并暂时忽略 t_other 的差值，则：

[
T>
\frac{2L\alpha_p}
{a(1-1/p)-4L\frac{p-1}{p}\frac{He_a}{B_p}}
]

分母必须为正；否则仅带宽项就已经吃掉理想计算收益，在这个简化模型中不存在能获益的 T。a 不应从 GPU 标称峰值推测，最好由 TP=1 的应用 trace 按 T 分桶拟合。

用纯 Python 核对分片恒等式和阈值直觉

下面程序只用 Python 标准语法。前半段以 ReLU 代替 SiLU，使整数结果可以精确比较；任何逐元素激活都不改变分片恒等式。后半段枚举一个明确标注的成本模型，结果不是 GPU 实测。

def mm(a, b):
    return [[sum(x*y for x, y in zip(row, col))
             for col in zip(*b)] for row in a]

def elem(a, b, fn):
    return [[fn(x, y) for x, y in zip(ar, br)]
            for ar, br in zip(a, b)]

def add(a, b):
    return elem(a, b, lambda x, y: x + y)

def col_shard(a, rank, p):
    n = len(a[0])
    assert n % p == 0
    q = n // p
    return [row[rank*q:(rank+1)*q] for row in a]

def row_shard(a, rank, p):
    n = len(a)
    assert n % p == 0
    q = n // p
    return a[rank*q:(rank+1)*q]

X = [[1, -1, 2, 0], [0, 2, -1, 1]]  # [T=2, H=4]
Wg = [[(r + 2*c) % 5 - 2 for c in range(6)] for r in range(4)]
Wu = [[(2*r + c) % 7 - 3 for c in range(6)] for r in range(4)]
Wd = [[(r - c) % 5 - 2 for c in range(4)] for r in range(6)]

gate = mm(X, Wg)
up = mm(X, Wu)
z = elem(gate, up, lambda g, u: max(0, g) * u)
dense = mm(z, Wd)

p = 2
partial = []
for rank in range(p):
    g = mm(X, col_shard(Wg, rank, p))
    u = mm(X, col_shard(Wu, rank, p))
    z_rank = elem(g, u, lambda x, y: max(0, x) * y)
    partial.append(mm(z_rank, row_shard(Wd, rank, p)))
reduced = add(partial[0], partial[1])
assert reduced == dense
print("algebra: OK", dense)

# 以下全是示例假设，不是硬件实测。
H, I, H_KV, L = 8192, 28672, 1024, 80
ACT_BYTES, P_EFF = 2, 120e12       # BF16；单卡投影有效 120 TFLOP/s
ALPHA, BUS_BW = 8e-6, 150e9        # 每次 8 us；总线带宽 150 GB/s

payload = 32*H*ACT_BYTES
traffic = 4*L*(4-1)*payload//4
assert payload == 512*1024
assert traffic == 120*1024**2
print("TP=4,T=32:", payload//1024, "KiB/call,",
      traffic//1024**2, "MiB/step/rank")

def estimate(T, p):
    f_layer = 4*T*(H*H + H*H_KV) + 6*T*H*I
    t1 = L*f_layer/P_EFF
    if p == 1:
        return t1, 1.0
    payload = T*H*ACT_BYTES
    t_ar = ALPHA + payload*2*(p-1)/p/BUS_BW
    tp = t1/p + 2*L*t_ar
    return tp, t1/tp

print("T  " + "  ".join(f"TP={p}" for p in (2, 4, 8)))
for T in (1, 4, 8, 16, 32):
    print(f"{T:<2} " + "  ".join(
        f"{estimate(T, p)[1]:.2f}x" for p in (2, 4, 8)))

执行输出：

algebra: OK [[-14, -20, 4, 38], [86, 40, -6, -52]]
TP=4,T=32: 512 KiB/call, 120 MiB/step/rank
T  TP=2  TP=4  TP=8
1  0.61x  0.72x  0.79x
4  1.26x  1.81x  2.31x
8  1.53x  2.42x  3.42x
16 1.71x  2.91x  4.51x
32 1.82x  3.25x  5.35x

这个枚举故意给分片 GEMM 理想的 1/p 加速，T=1 仍然变慢。真实小矩阵还可能因每卡的 I/p 过窄而降低计算效率，所以模型通常偏乐观。改变 ALPHA、BUS_BW 和 P_EFF，可以先判断哪些 TP 度数值得进入 GPU 压测，而不能据此宣布性能结果。

公平基线不是只有 TP=1

线上比较应报告卡数归一化 goodput：

[
G_{card}=\frac{\text{满足延迟 SLO 的输出 token 数}}
{\text{时间}\times\text{GPU 数}}
]

TP 可能让一个请求更快，却让每卡 goodput 下降；如果模型原本能单卡运行，这正是多副本基线不可省略的原因。

权重量化也不会自动等比例降低这里的通信量。公式中的 e_a 是归并激活的数据类型，不是权重位宽。4 bit 权重配 BF16 激活时，权重读取减少了，而 [T,H] 的 All-Reduce 仍可能按每元素 2 字节进行；必须从 trace 核对实际通信 dtype。

可复现的压测设计

先固定模型、权重与 KV 精度、框架提交版本、CUDA/NCCL 版本、GPU 型号与 rank 布局。对 TP=1、2、4、8 中满足容量和可整除条件的候选执行两阶段测试。

第一阶段隔离组件。记录真实 T 分布，并在目标拓扑上扫描覆盖 THe_a 的消息大小。例如单节点 4 卡可使用：

./build/all_reduce_perf -b 16K -e 4M -f 2 -g 4 \
  -d half -n 200 -w 50 -I 1 -K 20

nccl-tests 官方仓库说明了消息范围、预热、逐迭代时延和正确性检查参数；跨节点测试需改用与部署相同的 MPI rank 布局。NVIDIA nccl-tests

同时在完整引擎 trace 中记录：

• 每步活跃 token 数 T，并区分 Prefill 与 Decode；
• 每次 collective 的载荷、dtype、耗时和每层调用数；
• collective 位于关键路径上的时间，而不只是所有 kernel 时间之和；
• 分片 GEMM 的形状、耗时、SM 利用率与显存带宽；
• TPOT/ITL、TTFT、端到端延迟的 p50、p95、p99；
• 输出 token/s、满足 SLO 的 goodput，以及每卡归一化结果。

第二阶段回放相同到达过程与输入、输出长度分布。先保持调度参数一致以隔离 TP，再允许每个候选独立调优批量上限，比较各自能达到的最佳 SLO—goodput 前沿。只报离线大批吞吐会掩盖小 T 时的集合通信固定开销。

什么时候公式会失效

以下任一条件成立，都应从 trace 重新建立通信账：

• p 不能整除注意力头数、KV 头数或 MLP 中间维度，框架发生 padding、复制 KV 头或拒绝加载；
• GQA/MQA 的 KV Cache 分片策略与假设不同，尤其 p 大于 KV 头数；
• 开启 Sequence Parallel 后，部分 All-Reduce 被 All-Gather 与 Reduce-Scatter 替代；
• MoE 引入 token dispatch 和 All-to-All，负载不均衡也进入关键路径；
• 引擎融合了归并、残差或归一化，或者通过自定义 collective 改变调用次数；
• 跨节点链路、并发通信或 rank 放置使 α_p、B_p 与微基准不同；
• 长上下文的注意力计算占主导，此时只计算投影 FLOPs 会低估可并行计算；
• 本地 GEMM 过窄，实际计算时间明显高于 t_proj,1/p。

最直接的校验是：若 trace 中每步 collective 数不接近 2L，或载荷不是约 THe_a，就停止套用本文的简化公式。

排障要按因果链走

1. 先核对正确性与形状。 确认实际 p、rank 数、dtype、头数和中间维度切分；检查是否有 padding、KV 复制或意外降级。
2. 再核对物理路径。 运行 NCCL_RUN_DIAGNOSTICS=1，查看 nvidia-smi topo -m 和 P2P 状态。NCCL 2.31 的官方诊断可在通信器初始化时验证 GPU 间实际路径。NCCL Diagnostics
3. 用相同载荷测 collective。 如果 nccl-tests 本身就慢，先处理 NVLink、PCIe、NIC、NUMA 或 GPUDirect RDMA；不要先怪模型。
4. 比较微基准与应用 trace。 微基准正常而应用中的 All-Reduce 慢，检查 rank 放置、并发 stream、CPU 亲和性、框架同步及其他通信争用。
5. 通信正常再看 GEMM。 若 collective 关键路径占比不高但加速仍差，检查 I/p、每卡头数和实际 kernel 效率，修正理想 1/p 假设。
6. 最后回到调度与排队。 离线步骤变快而线上 p99 或 goodput 没改善，通常要检查 T 分布、排队、批量形成速度和副本负载，而不是继续增加 TP。

NCCL 的官方性能排障文档也建议先区分硬件路径、NCCL 和应用问题，并提醒不要因单一微基准收益就把环境变量强制带入生产。NCCL 2.31.2 Performance and Tuning

把卡数选择落成一条规则

先选出能放下模型且形状可分的 p。对每个候选，用真实 T 分桶测量 τ_AR(THe_a,p)，再检查：

[
\text{实测计算节省} > 2L\tau_{AR}+\text{其他新增开销}
]

模型能单卡运行时，只有 TP 在目标延迟下的每卡 goodput 优于多副本基线，或多副本无法满足单请求延迟 SLO，才值得占用多张卡。模型不能单卡运行时，默认选择满足容量和 SLO 的最小 TP 度数；跨越弱链路之前，先比较节点内 TP 加跨节点 PP。

卡数不是越多越好。真正的分界由活跃 token 数、每层 [T,H] 的归并延迟、本地 GEMM 退化和服务 SLO 一起决定。

继续阅读

• 在线推理能扛多少请求：别用固定并发替代到达率压测
• Codex 怎么和子 agent 协作：从一次任务分派看消息、上下文与状态管理
• 大模型推理加速（四）：推测解码为什么不改变分布，什么时候反而更慢

本站的内容生成、审核与纠错说明

Jellow 编辑发布，AI 辅助生成并完成技术核对。 计算示例和实测结果会在文中分别说明。

假设固定并发压测显示一个副本能完成 19 req/s，而线上流量是 6 req/s，能否据此断定容量充足？不能。固定并发中的新请求由旧请求完成触发：服务越慢，客户端发得越慢；真实用户却不会因为 GPU 忙就自动停止到达。

本文要解决的工程问题是：给定请求长度分布、到达模式和延迟 SLO，单副本可以安全接收多大的外生到达率。相关算子、缓存与服务文章汇总在模型推理加速专题页；本文只讨论容量测量。资料和接口核对日期为 2026-09-11，实际复现仍应固定 vLLM 版本或提交哈希。

从张量形状看“一个请求”有多重

先假设普通稠密因果注意力、单请求、h 个注意力头，每头维度为 d_h；输入长度 L≥1，实际生成长度 O≥1。

Prefill 中，Q 和 K 的形状都是 [h,L,d_h]。由缩放点积注意力 softmax(QKᵀ/√d_h)V 和因果遮罩可知，每层每头需要处理一个三角形。Transformer 原论文给出这一注意力定义。有效 query-key 点积数为：

A_prefill = h × L(L+1)/2

第一个输出 token 可以从 prefill 的 logits 取得。为了得到其余 O-1 个 token，decode 依次让形状 [h,1,d_h] 的 query 读取长度为 L+1 到 L+O-1 的 KV Cache：

A_decode = h × [(O-1)L + O(O-1)/2]

所以每层有效点积总数为：

A(L,O) = h × [L(L+1)/2 + (O-1)L + O(O-1)/2]

每个点积约含 2d_h 次浮点运算。这个式子没有计入投影、MLP、内核填充、批处理和调度，因此不是实际延迟模型；它只解释为什么容量实验必须保留 (L,O) 的联合分布。

一个反例是 (L,O)=(2048,128) 与 (512,1664)。两者都有 L+O-1=2175 个实际参与注意力的位置，每头总计都是 2175×2176/2=2,366,400 个有效点积；但前者的 prefill/decode 分别为 2,098,176/268,224，后者则为 131,328/2,235,072。总工作量相同，不代表 TTFT、TPOT 或批处理效率相同。

NVIDIA 的参数说明也要求按业务保留输入和输出长度分布：长输入主要增加 prefill 压力与 TTFT，长输出增加生成阶段压力与 ITL。固定长度测试可以用 ignore_eos 控制输出长度，但容量验收还应回放生产停止条件。若对 TTFT、TPOT、ITL 的口径不熟悉，可先看站内的推理指标入门。

固定并发把等待移到了哪里

用单服务器 FCFS 队列隔离这个问题。第 i 个请求的预定到达时间、服务时间、开始时间和完成时间分别为 a_i、s_i、b_i、f_i：

b_i = max(a_i, f_{i-1})

f_i = b_i + s_i

w_i = b_i - a_i

开放环压测先产生与完成事件无关的 a_i。在未条件化的泊松过程中，间隔独立服从 Exp(λ)，其中 λ 是目标 RPS。闭环并发为 1 时，下一个请求恰在前一个完成后发出，因此 a_i=f_{i-1}、w_i=0：它测到的是 1/E[s]，没有测到外生 λ 下的排队尾延迟。

并发上限大于 1 时同样可能发生代价转移。信号量、网关或连接池会把多余请求留在客户端；若计时从真正发往模型服务时才开始，用户等待就从指标中消失。vLLM 将 --request-rate 与 --max-concurrency 分开，并明确指出并发帽可能使实际执行率低于设定值。CLI 参数定义还提供 client_queue_time 和 e2el_including_client_queue 来显示这部分等待。

MLPerf LoadGen 的 Server 场景同样采用随机泊松到达，允许请求保持 outstanding，并按延迟阈值判定；Offline 场景报告吞吐。MLPerf 官方实现说明描述的是两个不同问题，不能互相替代。

vLLM 的有限速率不是未条件化泊松过程

截至 2026-09-11，vLLM 文档把 --burstiness=1 描述为泊松到达，其他正值对应 Gamma 间隔；但源码还有一个必须说明的实现细节。

在固定有限 request-rate、没有 ramp-up、且没有使用 self-timed trace 的路径中，vLLM 会先采样 Gamma 间隔；当 burstiness=1 时，这一步确实是指数间隔。随后程序累加所有间隔，并统一乘以：

normalize_factor = (num_requests/request_rate) / last_cumulative_delay

因此最后一个请求的计划偏移会精确对齐 num_requests/request_rate。当前 serve.py直接展示了采样与缩放逻辑。缩放以后，各间隔共同受总时长约束，不再是相互独立的未条件化指数变量；它与未条件化泊松过程存在实现差异。长时间测试中差异可能很小，但本文研究的正是到达过程，不能省略这个边界。

若生产突发和相关性很重要，最终验收应使用带真实时间戳的 timed_trace --self-timed，或使用能够按原始时间戳发送的外部负载发生器。本文后面的标准库例子使用未缩放的独立指数间隔，验证的是未条件化泊松队列，不是 vLLM 调度器的逐行复刻。

容量应由请求级联合 SLO 定义

令第 r 个独立重复运行中，第 i 个请求的联合指示量为：

I_{r,i} = 1[请求成功 且 TTFT≤B_f 且 TPOT≤B_d 且 E2E≤B_e]

未设置的约束可以删去，错误和超时必须记为 0。该次运行的达标率和合格请求吞吐为：

Â_r(λ) = Σ_i I_{r,i}/N_r

Ĝ_r(λ) = Σ_i I_{r,i}/T_r

分别查看 TTFT p99 和 TPOT p99 不等价于联合达标。两类违规若发生在不同请求上，各自有 99% 的请求通过时，联合通过率仍可能只有 98%。vLLM 对同一成功请求的全部 --goodput 条件执行逻辑 AND，再计算 good_completed/duration；它输出的是 request goodput，不是把错误纳入分母后的联合达标率。官方源码可以核对这一区别。DistServe 论文则把 per-GPU goodput 定义为达到 SLO attainment 目标时可承载的最大请求率。论文原文

FCFS 等待时间会向后传播，所以同一次运行中的 I_{r,i} 通常存在序列相关性。不能把几万个请求直接视为独立 Bernoulli 样本，再用逐请求 IID Wilson 区间决定 PASS/FAIL。

本文采用多个相互独立的完整运行。预先指定 R 组 seed，每次重新建立负载随机过程并按实验策略重置服务状态，以整次运行作为实验单位。定义保守下包络：

A_floor(λ) = min_{r=1..R} Â_r(λ)

只有每次运行都满足全部验收条件，候选 RPS 才通过：

λ* = max{λ | 对所有 r：Â_r≥q，错误率_r≤ε，实际发送率合格，且队列无持续上升}

这条 min 规则是预先声明的保守验收规则，不是“95% 置信下界”，也不声称具有某个未证明的覆盖率。如果无法做独立重启，可以按时间分块报告最差块，但块长度必须覆盖业务突发与队列相关时间；相邻小块不能被冒充为独立样本。

一个验证排队效应和重复判定的标准库例子

下面不是 GPU 实测。它运行 12 个相互独立的单服务器队列：80% 请求服务 20 ms，20% 服务 180 ms；E2E SLO 为 250 ms，目标达标率为 95%。不同重复分别生成服务序列与未缩放的泊松到达；不同 RPS 使用配对 seed，便于把负载随机性对齐后观察变化。

import math
import random

N, WARM, RUNS = 50_000, 5_000, 12
SLO, TARGET = 0.250, 0.95
SEEDS = tuple(range(101, 101 + RUNS))

def percentile(xs, p):
    ys = sorted(xs)
    return ys[max(0, math.ceil(p / 100 * len(ys)) - 1)]

def one_run(rate, seed):
    service_rng = random.Random(seed)
    arrival_rng = random.Random(seed + 10_000)
    service = [0.020 if service_rng.random() = WARM:
            waits.append(start - arrival)
            passed += (finish - arrival <= SLO)
    measured = N - WARM
    actual_rate = (measured - 1) / (arrival - first_measured_arrival)
    return percentile(waits, 95), passed / measured, actual_rate

closed_rates = []
for seed in SEEDS:
    rng = random.Random(seed)
    service = [0.020 if rng.random() = TARGET else "FAIL"
    print(f"{rate:>4} {rate*0.052:>4.2f} "
          f"{min(actuals):.2f}-{max(actuals):.2f} "
          f"{max(q95s)*1000:>14.1f} "
          f"{min(attains):.2%}-{max(attains):.2%} "
          f"{min(attains):>7.2%} {check}")

Python 3 标准库的实际输出为：

closed-loop: rate_range=19.07-19.43 req/s, min_attain=100.00%
rate rho actual_rps_range worst_p95q_ms attain_range       floor   slo_check
   2 0.10 1.99-2.01           64.2 98.85%-99.00%  98.85% PASS
   4 0.21 3.98-4.02          137.7 97.22%-97.50%  97.22% PASS
   6 0.31 5.96-6.03          170.7 94.70%-95.26%  94.70% FAIL
   8 0.42 7.95-8.04          232.7 90.84%-91.78%  90.84% FAIL
  10 0.52 9.94-10.05          314.9 85.52%-86.58%  85.52% FAIL
  14 0.73 13.91-14.07          673.9 64.74%-67.65%  64.74% FAIL
  18 0.94 17.89-18.10         3889.7 19.30%-26.52%  19.30% FAIL

固定并发基线在 12 次运行中得到 19.07—19.43 req/s，并且因为单次服务时间都小于 250 ms，最差达标率仍是 100%。开放环中，4 RPS 的 12 次运行全部超过 95%，而 6 RPS 的保守下包络只有 94.70%，因此这里只得到 4—6 RPS 的 SLO 夹点，不能把 4 RPS 杜撰成精确容量。

rho 使用理论均值 E[s]=0.8×0.020+0.2×0.180=0.052 s。即使平均利用率只有约 31%，服务时间方差和到达重叠也已让 6 RPS 的部分运行失守。这个模型没有模拟 GPU、网络或连续批处理；实际服务时间会随批次和调度变化，示例阈值不能搬到生产。

可复现的 vLLM 容量实验

先固定模型与软件版本、权重精度、并行度、调度参数、GPU 与驱动、客户端机器、网络、采样参数和缓存状态。数据集至少保留 (输入 token 数,实际输出 token 数,缓存命中条件) 的联合分布。

截至核对日，下面命令可作为固定 (1024,128) 长度桶的模板。800/50 ms 是占位 SLO，必须替换；它没有在本文环境中连接模型服务，也不是 GPU 实测。

vllm bench serve \
  --backend openai \
  --base-url http://127.0.0.1:8000 \
  --model MODEL_ID \
  --dataset-name random \
  --input-len 1024 \
  --output-len 128 \
  --ignore-eos \
  --temperature 0 \
  --request-rate 8 \
  --burstiness 1.0 \
  --num-prompts 10000 \
  --num-warmups 32 \
  --seed 11 \
  --percentile-metrics ttft,tpot,e2el,client_queue_time,e2el_including_client_queue \
  --metric-percentiles 50,95,99 \
  --goodput ttft:800 tpot:50 \
  --save-result \
  --save-detailed

当前 vLLM 的一个 --seed 不是独立的“到达种子”。serve.py 用它设置 Python random 和 NumPy RNG；数据集代码又把同一个值用于随机请求生成、抽样或顺序洗牌，具体作用取决于数据集和 --disable-shuffle；NumPy RNG 还用于到达间隔调度。serve.py与数据集源码共同给出了这一语义。

因此比较配置 A/B 时应使用配对设计：重复 1 的 A 和 B 都用 seed 11，重复 2 都用 seed 23，之后继续使用多组不同 seed。每一组 seed 是一个新的完整重复，同时改变该重复的请求随机性、顺序和到达调度；同一组中的 A/B 则共享这些随机条件。不能把换 seed 描述成只换“到达种子”。若必须固定请求序列而只改变到达时间，应准备固定顺序的数据或 timed trace，并由外部调度器控制时间戳。

不同重复之间还要按实验目标重置状态。vLLM 的基准说明提醒，重复请求可能命中上一次留下的前缀缓存并虚增吞吐；生产不依赖这种复用时，应重置缓存、重启服务或使用会重置缓存的 sweep 流程。

先粗扫得到一过一败的 RPS 夹点，再在夹点中加密。边界候选建议增加到至少 10—12 个预先指定的独立重复，并用更长生产时间窗复验。每次都要单独保存实际发送率、错误、联合达标率和队列时间序列，不能先合并所有请求再计算一个 IID 区间。

若生产网关限制并发，再增加相同的 --max-concurrency，同时报告客户端排队、用户视角 E2E、拒绝和超时。当前 --goodput 只接受 ttft、tpot、e2el，不接受客户端排队指标；有外部背压时必须从详细记录重新计算联合指示量，并把失败请求放回分母。

指标和排障顺序

一次容量扫描至少保存：设定与实际发送 RPS、成功/错误/超时数、客户端排队、TTFT/TPOT/E2E 的 p50/p95/p99、逐运行联合达标率及其最小值，并按 (L,O) 桶分解。

NVIDIA 的指标定义中，TTFT 通常包含排队、prefill 和网络，E2E 还覆盖 batching。数学上的 TPOT 只在实际输出 token 数大于 1 时定义，公式为 (E2E-TTFT)/(输出 token 数-1)；当 O=1 时分母为零，应从 TPOT 统计中排除或明确采用工具约定。当前 vLLM 在 goodput 检查中把这类请求的 TPOT 置为 0，属于实现约定，不能当作数学定义。工具实现仍可能不同。根据 vLLM Benchmark CLI，推测解码一次流式返回多个 token 时，ITL 记录的是流式事件间隔，而 TPOT 会把时间摊到 token 上，两者尤其不能混用。

排障按请求生命周期进行：

1. 负载发生器：实际发送率是否达到设定值；客户端 CPU、连接数或网络是否先饱和；排队是否藏在信号量之前。
2. 工作量：核对实际 (L,O)、停止原因、采样参数、前缀命中率和失败请求，先排除两次实验负载不同。
3. 服务队列：观察等待请求数和 queue time 是否持续上升。若上升，先降低 RPS 或增加副本，不要先调算子。
4. 阶段拆分：队列平稳但 TTFT 变差，检查 prompt 长度、缓存命中和 prefill；TPOT 变差则检查 decode、活动序列数和长输出干扰。
5. 资源证据：最后结合 KV Cache 使用率、抢占次数、GPU/CPU、显存带宽和网络判断瓶颈。vLLM 的生产指标清单提供等待请求数、queue time、prefill/decode 时间、KV Cache 使用率和抢占计数。

安全余量不是固定的 70% 或 80%。它取决于长度方差、突发程度、SLO、缓存和扩容反应时间。固定并发仍是有价值的饱和基线；只有开放环到达率、多个独立重复的联合 SLO、稳定队列和真实背压同时进入验收，测出的 RPS 才能用于容量决策。

继续阅读

• Codex 怎么和子 agent 协作：从一次任务分派看消息、上下文与状态管理
• 大模型推理加速（四）：推测解码为什么不改变分布，什么时候反而更慢
• 大模型推理加速（三）：FlashAttention 为什么更快，又没有省掉哪些计算

本站的内容生成、审核与纠错说明