并发估算是倒推出来的
并发上限不是拍脑袋定的数字，而是从显存反推：先算引擎可用的 KV 池，再算一条序列在该上下文长度下占多少，相除得到理论上限，最后用长度分布的高水位重算一次取保守值。理论值还要按折扣系数落地，因为块粒度对齐、碎片与调度开销都会吃掉一部分空间。
估算步骤
估算步骤
# 1) KV 池 = 卡容量 × 引擎显存比例 - 权重 - 工作区预留
# 2) 单序列 KV = 每 token 字节数 × 目标上下文长度
# 3) 理论上限 = KV 池 ÷ 单序列 KV
# 4) 用高水位长度（如 P95 或 P99）重算一次，取两者中的保守值
# 5) 落地再乘折扣系数：块对齐、碎片与调度开销合计按七八成计每一步的输入
| 步骤 | 需要的输入 | 常见偏差来源 |
|---|---|---|
| 算 KV 池 | 卡容量、引擎显存比例、权重与工作区占用 | 比例与实测不一致 |
| 算单序列 | 每 token 字节数、目标上下文长度 | 头数口径与长度取值 |
| 相除 | 两个中间结果 | 单位不统一 |
| 高水位重算 | 长度分布的分位值 | 用平均值代替高水位 |
| 折扣落地 | 实测曲线 | 不折扣，按理论上限配置 |
典型使用场景
- 容量规划：给出单实例可承载的并发数，作为扩容依据
- 参数取舍：比较缩短上下文与增加卡数两种方案的代价
- 压测设计：按估算结果设计并发梯度，快速找到拐点
- 故障复盘：对照当时配置反推理论值，判断是否本就超配
- 方案报价：把可承载并发写明，避免按理论值承诺
第 3 步得到的是理论上限：块粒度、碎片与调度都会打折，落地按七八成配置，留出的空间也用于吸收突发长请求。
用平均长度估并发是典型错误：长请求扎堆时会直接触发抢占重算，容量评估必须看长度分布的高水位。