并发压测模式 vs 速率压测模式两种基准测试给出的截然不同结论在大语言模型推理集群的上线验收与容量规划评审中测试工程师最常使用的两种基准压测方法是并发控制模式Concurrency Mode闭环模型与速率控制模式Request Rate Mode开环模型。在许多团队的技术报告中这两种截然不同的测试范式常常被严重混淆。甚至有工程师在汇报中得出“我们系统在 64 并发线程下运行极其平稳因此线上能够稳定承载 64 QPS 真实业务流量”的荒谬推论。这种基于经验直觉的等价推导不仅在排队论数学上是错误的在系统工程中更会直接埋下导致集群在早晚高峰被瞬间击穿的致命隐患。本文通过详尽的控制论模型推导与 8 卡 H100 生产集群实测对账彻底拆解这两种测试模式给出的截然相反的性能结论。控制论视角的两大压测范式解构───────────────────────────────────────────────────────────── | 范式一: 并发控制模式 (Concurrency / Closed-Loop 闭环系统) | | [ 固定 N 个 Worker 协程 ] ──发送请求── [ 推理服务集群 ] | | ▲ │ | | └────── 收到当前响应后才发下一笔 ──────┘ | | (物理特征: 系统变慢 - 客户端发包自适应变慢 - 永远不排队) | ───────────────────────────────────────────────────────────── vs ───────────────────────────────────────────────────────────── | 范式二: 速率控制模式 (Request Rate / Open-Loop 开环系统) | | [ 泊松时钟发生器 (λ req/s) ] ──无视状态强制发射── [ 推理集群 ] | | │ | | (物理特征: 系统变慢 - 外部流量不减 - 队列积压 - 显存被吃光 - 瞬间雪崩) | ─────────────────────────────────────────────────────────────1. 并发控制模式闭环反馈控制客户端启动固定数量的并发工作线程例如 $N 64$。每个 Worker 发送一个请求后强制阻塞等待服务端完整返回所有生成的 Token 之后才立即发送下一笔请求。控制论数学特性客户端的真实发包速率 $R$ 与服务端当前处理该请求的整体端到端耗时 $T$ 构成刚性的负反馈强绑定$$R \frac{N}{T}$$致命盲区当服务端因为处理某几个突发长 Prompt、触发内存碎片整理或发生垃圾回收导致处理耗时 $T$ 从 100ms 延长到 1000ms 时客户端的实际发包速率 $R$ 会自动、同步地下降 10 倍。这种机制人为屏蔽了外部流量的持续冲击使得服务端的调度队列长度永远被强制锁死在 $N$ 以内永远测不出真实流量下的排队雪崩。2. 速率控制模式开环外生输入客户端完全解耦与服务端的处理状态严格按照外生给定的泊松到达率例如恒定 $\lambda 30\text{ req/s}$异步发射请求。控制论数学特性外部请求到达服从泊松分布无论服务端内部此时是流畅运行、处于计算阻塞还是显存告急新请求都会以恒定的统计强度持续砸向网关。真实还原一旦到达速率超过服务端的极限吞吐阈值利特尔法则Littles Law$L \lambda W$瞬间生效等待队列Waiting Queue呈现线性激增精准暴露系统从平稳运行到彻底瘫痪的相变临界点。8 卡 H100 生产集群的实测横向对账我们在由 8 张 80GB H100 组成的张量并行TP8推理集群上使用 LLaMA-3-70B 模型BF16 精度输入 512 Tokens输出 128 Tokens 真实分布分别采用两种模式进行阶梯式加压测试压测测试模式与参数配置测得总吞吐 (Tokens/s)TTFT P50 (ms)TTFT P99 (ms)TPOT P99 (ms)调度抢占换页率生产真实系统状态并发模式 ($N 32$)2,890448821.20%表面数据极其亮眼平稳运行并发模式 ($N 64$)3,4606014823.80%达到峰值吞吐零错误无异常并发模式 ($N 128$)3,62011833028.50%吞吐微幅上升看起来“抗压极强”速率模式 ($\lambda 20\text{ req/s}$)2,820469521.60%平稳承载排队延迟趋近于 0速率模式 ($\lambda 30\text{ req/s}$)3,4206518524.20%接近算力饱和红线速率模式 ($\lambda 35\text{ req/s}$)1,280 (暴跌 62%)1,92013,400 (13.4s)188.042.8%发生排队雪崩服务彻底瘫痪数据背后的物理雪崩机制拆解在并发模式下即使我们将并发线程推至 $N 128$系统依然测出了高达3620 Tokens/s的华丽吞吐测试报告上看起来集群甚至具备承载 128 并发的能力。然而当我们切换到真实的速率模式仅仅将请求速率从 30 req/s 微幅提升到35 req/s时整个集群在短短 30 秒内发生了灾难性的系统性雪崩───────────────────────────────────────────────────────────── | 速率模式 35 QPS 触发的雪崩链路: | | 1. 每秒持续涌入 35 笔请求瞬间打爆单 Step 的 Prefill 算力预算 | | 2. 新请求在 Waiting Queue 线性积压排队等待延迟突破 10 秒 | | 3. 为给新请求分配初始显存块调度器触发紧急抢占 (Preemption) | | 4. 42.8% 的长请求 KV Cache 被强行换出 (Swap Out) 到 Host 内存 | | 5. PCIe 总线被巨额内存搬运吃满GPU 核心陷入严重的等待停顿 | | 6. 最终有效 Token 产出断崖式暴跌 62%! | ─────────────────────────────────────────────────────────────闭环并发测试之所以没有测出这个崩溃点正是因为当系统开始变慢时客户端的 128 个 Worker 会自动被卡在等待回包上发包速率被服务端反向压制到了不足 28 req/s从而在虚假的温室里维持了表面的“稳定”。生产容量规划与压测标准范式在严谨的基础设施工程中应当明确两类测试的定位与纪律并发模式Concurrency Mode的唯一使命用于寻找硬件在无排队干扰下的理论物理算力极限Theoretical Peak Flops Bandwidth为系统设定物理天花板。速率模式Request Rate Mode是容量规划的唯一依据在评估线上能够承诺的真实 SLA 时必须采用服从泊松到达的开环速率测试。通过绘制 $\lambda \text{ vs. TTFT P99}$ 曲线找到延迟曲线发生斜率剧烈突变的“膝点Knee Point”将膝点 QPS 乘以 0.7~0.8 的安全水位系数才是生产集群真正能够承诺的安全承载上限。永远不要用闭环测试演出来的虚假繁荣去安慰自己。用真实的速率模型去撞击系统的极限才能在真实世界的惊涛骇浪中守住高可用的生命线。