企业官网建设流程全解析

并发压测模式 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}$）异步发射请求。

• 控制论数学特性：外部请求到达服从泊松分布，无论服务端内部此时是流畅运行、处于计算阻塞还是显存告急，新请求都会以恒定的统计强度持续砸向网关。
• 真实还原：一旦到达速率超过服务端的极限吞吐阈值，利特尔法则（Little's Law：$L = \lambda W$）瞬间生效，等待队列（Waiting Queue）呈现线性激增，精准暴露系统从平稳运行到彻底瘫痪的相变临界点。

8 卡 H100 生产集群的实测横向对账

我们在由 8 张 80GB H100 组成的张量并行（TP=8）推理集群上，使用 LLaMA-3-70B 模型（BF16 精度，输入 512 Tokens，输出 128 Tokens 真实分布），分别采用两种模式进行阶梯式加压测试：

数据背后的物理雪崩机制拆解

在并发模式下，即使我们将并发线程推至 $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，从而在虚假的温室里维持了表面的“稳定”。

生产容量规划与压测标准范式

在严谨的基础设施工程中，应当明确两类测试的定位与纪律：

1. 并发模式（Concurrency Mode）的唯一使命：用于寻找硬件在无排队干扰下的理论物理算力极限（Theoretical Peak Flops & Bandwidth），为系统设定物理天花板。
2. 速率模式（Request Rate Mode）是容量规划的唯一依据：在评估线上能够承诺的真实 SLA 时，必须采用服从泊松到达的开环速率测试。通过绘制 $\lambda \text{ vs. TTFT P99}$ 曲线，找到延迟曲线发生斜率剧烈突变的“膝点（Knee Point）”；将膝点 QPS 乘以 0.7~0.8 的安全水位系数，才是生产集群真正能够承诺的安全承载上限。

永远不要用闭环测试演出来的虚假繁荣去安慰自己。用真实的速率模型去撞击系统的极限，才能在真实世界的惊涛骇浪中守住高可用的生命线。