GPU推理负载：特征分析与压测

可视化演示

展示分布式一致性协议中Leader选举、日志复制与心跳通信的完整流程，支持节点故障模拟与消息速率调节。

两类负载类型

主厨做菜有两种累法：一种是一刻不停颠勺爆炒，锅气冲天，那种累是“算得累”；另一种是反复从冷库搬货、切配装盘，腿都快跑断了，那种累是“搬得累”。GPU跑推理也一样——有的模型每一步都要在巨大的参数矩阵上做乘法累加，计算量爆炸；有的模型每次推理只算一点点，但需要不停读取特征表和参数表，带宽消耗远大于算力消耗。

在性能工程里，我们用“算术强度”（Arithmetic Intensity）给负载分类，它的定义是单位字节访存能兑换多少次浮点运算：

$$\displaystyle I = \frac{N_{\text{flops}}}{B_{\text{bytes}}}$$

其中 $N_{\text{flops}}$ 是完成一次推理所需的浮点运算次数，$B_{\text{bytes}}$ 是推理过程中需要读写的总字节数。当 $I$ 大于 10 FLOP/Byte 时，负载通常是计算密集型的，比如大语言模型（LLM）的 Prefill 阶段；当 $I$ 小于 1 FLOP/Byte 时，负载是访存密集型的，典型代表是推荐系统的 Embedding 检索和序列排序模型。

1. 分子 FLOPs：处理一个请求要做多少次浮点乘加，数值越大说明“算得越狠”

$$\displaystyle N_{\text{flops}}$$

2. 分母访存字节：模型参数、中间激活值、特征表要读写多少数据，数值越大说明“搬得越勤”

$$\displaystyle B_{\text{bytes}}$$

3. 比值判型：每读 1 字节数据能换回多少次运算，比值越高越偏计算密集

$$\displaystyle I = \frac{N_{\text{flops}}}{B_{\text{bytes}}}$$

搞清负载类型，就等于摸清了主厨的“体力短板”：计算密集的模型瓶颈在 GPU 算力（CUDA Core 数量、频率），访存密集的模型瓶颈在显存带宽和缓存命中率。后续压测和容量规划都要围绕这个短板来设计。

动态批处理规律

高峰时段，聪明的厨师不会一单一单地炒菜，而是把三桌客人点的同一道宫保鸡丁合并成一锅下锅。GPU 推理的动态批处理（Dynamic Batching）就是这个思路：调度器把到达的请求先放进队列，攒够一批再一次性喂给 GPU 核心执行，用“一锅炒”摊薄启动开销和调度成本。

动态批处理的执行时间可以用一个线性模型描述：

$$\displaystyle T_{\text{batch}} = \alpha + \beta \cdot n$$

其中 $\alpha$ 是启动内核、搬运权重的固定开销，$\beta$ 是每个样本的边际计算耗时，$n$ 是批大小。单批的吞吐量就是 $n / T_{\text{batch}}$。当 $n$ 增大时，平均到每个样本上的固定开销被摊薄，吞吐量随之上升——但代价是请求必须先等在队列里，等待窗口越长，单请求延迟越差。

1. 固定开销 α：不管一批处理 1 个还是 32 个请求，启动内核和加载数据的时间基本不变，这是“起锅烧油”的成本

$$\displaystyle \alpha$$

2. 边际开销 βn：每多塞进一个样本，GPU 多花一段线性增长的计算时间，这是“多炒一份菜”的成本

$$\displaystyle \beta \cdot n$$

3. 单批吞吐：批大小除以单批总耗时，批越大吞吐越高，但受 $\alpha$ 限制有天花板

$$\displaystyle \frac{n}{\alpha + \beta \cdot n}$$

实际生产中有两种触发聚合的策略：一是队列长度达到预设批大小立即打包，二是超过最大等待窗口强制打包。前者保吞吐，后者保延迟。好的批处理调度器会把这两个阈值和业务 SLO 联动起来，让“合单”既高效又不让客人饿跑。

并发波动模式

餐厅一天有早市、午市、晚市三个高峰，尤其是午市瞬间涌进 50 桌客人。GPU 推理集群面对的流量同样不是一条平坦的直线，而是“锯齿 + 脉冲”的复杂波形。比如电商 App 晚上 8 点秒杀大促，搜索推荐请求在几秒内飙到平时的 5 倍。

实际负载建模中，到达率可以根据时间段分解为基线和突发两部分：

$$\displaystyle \lambda(t) = \lambda_{\text{base}} + A \cdot e^{-\frac{(t - t_0)^2}{2\sigma^2}}$$

其中 $\lambda_{\text{base}}$ 是日常平均到达率，$A$ 是突发事件的峰值增幅，$t_0$ 是爆发时刻，$\sigma$ 控制尖峰的陡峭程度。除了突发高峰，推理负载还有“长尾”特性：少数超长 Prompt、反复重试的请求，会像一桌点了 20 道菜又有忌口的客人，把整批请求的耗时拖得异常长。

1. 基线速率：非高峰时段的平均请求到达率，对应餐厅平峰期的客流量

$$\displaystyle \lambda_{\text{base}}$$

2. 突发脉冲项：高峰事件在 $t_0$ 时刻把流量顶上去，振幅 $A$ 越大峰值越猛

$$\displaystyle A \cdot e^{-\frac{(t - t_0)^2}{2\sigma^2}}$$

3. 高斯衰减核：离 $t_0$ 越远的时刻，突发影响按指数衰减，$\sigma$ 越小尖峰越陡

$$\displaystyle e^{-\frac{(t - t_0)^2}{2\sigma^2}}$$

理解波动模式的意义在于：压测必须用“脉冲 + 锯齿”的负载还原真实业务，容量规划则永远按峰值而非平均值来兜底。你以为餐厅平时能坐满 30 桌就够了，结果周五晚市涌进 80 桌，门口排队的人立刻骂声一片。

延迟吞吐权衡

主厨为了翻台率拼命合单炒大锅菜，结果前厅客人等到掀桌；如果一单一单精细炒，出菜量又远远不够。GPU 推理服务也面临同样的两难：延迟（Latency）和吞吐量（Throughput）是一对此消彼长的指标。延迟衡量单个请求从进来到返回的速度，吞吐量衡量系统每秒钟能消化多少请求。

二者关系可以用排队论里的利特尔定律描述：

$$\displaystyle L = \lambda \times W$$

$L$ 是系统中同时在排队的请求数，$\lambda$ 是到达率，$W$ 是请求在系统内的平均停留时间。结合批处理模型，吞吐量上限可以写成：

$$\displaystyle \text{吞吐量} = \frac{n}{\alpha + \beta \cdot n} \leq \frac{1}{\beta}$$

当批大小 $n$ 趋近无穷大时，吞吐量逼近极限 $1/\beta$，但每个请求都要等更久才能凑够一批。所以工程上不会无限加大批大小，而是用 SLO（服务水平目标）来划一条线：比如“P99 延迟必须小于 200ms”，在这条线下找最大吞吐量。

1. 利特尔定律：系统内积压的请求数等于到达率乘以每个请求的停留时间，积压越多则等待越久

$$\displaystyle L = \lambda \times W$$

2. 吞吐极限：批大小无限增大时，固定开销被完全摊薄，吞吐量收敛到 $1/\beta$，这是硬件物理上限

$$\displaystyle \lim_{n \to \infty} \frac{n}{\alpha + \beta \cdot n} = \frac{1}{\beta}$$

3. SLO 约束：在延迟红线内取最大吞吐量，而不是无脑追高吞吐

$$\displaystyle \max \text{QPS} \quad \text{s.t.} \quad P99 \leq T_{\text{slo}}$$

上菜快慢和出菜总量不可能两全。聪明的餐厅会设定“承诺 20 分钟内上完所有菜”的目标，然后算出最大翻台率；同样，AI 基础设施团队要盯住 P99 延迟的同时，在压测曲线上找到那个“SLO 约束下的吞吐拐点”。

压测方案设计

开张前，你请了一群朋友按真实的吃饭节奏来“演练”：瞬间涌入 50 人、疯狂加菜、催单、投诉，观察主厨会不会崩溃、出菜口会不会堵死。GPU 推理压测（Load Testing）就是这套思路——用负载生成器模拟真实请求流，在受控条件下观察系统的行为边界。

压测设计核心有四个步骤。首先是负载生成，请求的输入长度、模型种类、并发模式都要从线上流量采样，不能只用固定长度的假请求；其次是阶梯加压，最常见的模式是从 50 QPS 起步，依次加档到 100、200、400，每一档稳定运行 5 到 10 分钟，让队列充分积压；第三是关键指标采集，包括 QPS、成功率、P50/P95/P99 延迟、GPU 利用率、显存占用、温度；最后是瓶颈定位，观察当加压到哪一档时吞吐不再线性上涨、延迟开始指数飙升。

延迟分位数是压测中最核心的指标：

$$\displaystyle P99 = \min\{x \mid F(x) \geq 0.99\}$$

其中 $F(x)$ 是延迟的累积分布函数。P99 的含义是“99% 的请求的延迟都小于等于这个值”，它比平均值更能暴露尾部风险。

1. 累积分布函数：延迟不超过 $x$ 的请求占总请求的比例，这是“上菜速度的及格线分布”

$$\displaystyle F(x) = P(\text{延迟} \leq x)$$

2. P99 反查：从 0.99 这个概率值反推出对应的延迟门槛，1% 的最慢请求统统超过它

$$\displaystyle P99 = \min\{x \mid F(x) \geq 0.99\}$$

3. 拐点判据：继续加压但吞吐量不再增长，说明系统已到容量上限，这就是“压测找到了厨房的真正极限”

$$\displaystyle \frac{\Delta \text{吞吐}}{\Delta \text{QPS}} \to 0$$

压测的价值不是测出“最大 QPS 数字”，而是找到那条让延迟突然恶化的临界线。有了这条线，你就知道餐厅最多接多少桌客人会崩，以及该在什么水位触发“暂停接单”或“呼叫外援”。

容量规划评估

火锅店要按冬天最冷那天能来多少桌客人来备桌椅，而不是按夏天的平均人流。GPU 容量规划也一样：用压测得到的容量拐点，结合业务峰值预测，算出该买几张卡、给每个业务分多少配额。

核心估算公式是：

$$\displaystyle N_{\text{GPU}} = \frac{\text{峰值QPS} \times T_{\text{batch}}}{n \times U_{\text{target}}}$$

其中峰值 QPS 来自流量预测和负载建模，$T_{\text{batch}}$ 是压测测得的单批耗时，$n$ 是批大小，$U_{\text{target}}$ 是目标利用率（一般设定为 60%～70%，预留弹性应对突发）。除了一次性容量规划，线上还要做弹性伸缩：当 GPU 利用率超过 70% 并持续若干分钟就扩容，低于 30% 就缩容，把成本与稳定性结合起来。

1. 分子总耗时预算：峰值每秒钟要处理的请求数乘以单批耗时，得出“同时要烧多少锅菜”的总厨房工时

$$\displaystyle \text{峰值QPS} \times T_{\text{batch}}$$

2. 分母单批承载：每批能处理 $n$ 个请求，同时留出 $U_{\text{target}}$ 的余量而非打满

$$\displaystyle n \times U_{\text{target}}$$

3. 整除求商：两者相除就得到所需 GPU 卡数，向上取整并叠加冗余率

$$\displaystyle N_{\text{GPU}} = \frac{\text{峰值QPS} \times T_{\text{batch}}}{n \times U_{\text{target}}}$$

容量规划的产出不只是“买几张卡”，还包括资源配额（Quota）和弹性伸缩策略：给每个业务团队按压测结果分配合适的 GPU 份额，并让弹性伸缩与负载水位联动。这样既不会在高峰期崩盘，也不会在低谷期白白烧钱——就像餐厅既备足了晚市的桌位，又能在深夜把部分厨师调去休息。

AI 应用场景

Python 演示

import random  class DynamicBatchSim:    """模拟GPU动态批处理：请求到达、攒批、执行、统计延迟与吞吐。"""     def __init__(self, batch_size, window_ms, gpu_ms):        self.batch_size = batch_size        self.window_ms = window_ms        self.gpu_ms = gpu_ms        self.queue = []        self.done = 0        self.total_latency = 0.0     def tick(self, now_ms, arrivals):        self.queue.extend(arrivals)        while len(self.queue) >= self.batch_size:            batch = self.queue[:self.batch_size]            del self.queue[:self.batch_size]            finish = now_ms + self.gpu_ms            self.done += len(batch)            self.total_latency += sum(finish - r for r in batch)        if self.queue and now_ms - self.queue[0] >= self.window_ms:            batch = self.queue[:]            self.queue = []            finish = now_ms + self.gpu_ms            self.done += len(batch)            self.total_latency += sum(finish - r for r in batch)     def avg_latency(self):        return self.total_latency / max(self.done, 1)  def simulate(rate, batch_size, window_ms, gpu_ms, duration_s):    sim = DynamicBatchSim(batch_size, window_ms, gpu_ms)    dt = 0.005    t = 0.0    while t < duration_s:        arrivals = []        if random.random() < rate * dt:            arrivals.append(t * 1000.0)        sim.tick(t * 1000.0, arrivals)        t += dt    qps = sim.done / duration_s    return qps, sim.avg_latency()  if __name__ == "__main__":    for bs in [1, 2, 4, 8]:        qps, lat = simulate(rate=80, batch_size=bs, window_ms=20,                            gpu_ms=160, duration_s=20)        print("batch=%2d  QPS=%6.1f  avg_latency=%7.1fms" % (bs, qps, lat))

1. self.queue.extend(arrivals)新到的请求先进入队列等待攒批，就像顾客先在前厅排号。
2. while len(self.queue) >= self.batch_size:只要队列攒够一批就立即打包，触发“合单烹饪”。
3. finish = now_ms + self.gpu_ms记录这一批的完成时刻，模拟 GPU 执行一个批次耗时固定。
4. self.total_latency += sum(finish - r for r in batch)每个请求的延迟从到达时刻一直算到批处理完成，等待时间也被计入。
5. if self.queue and now_ms - self.queue[0] >= self.window_ms:等待窗口超时后强制把剩余请求打包，防止客人等太久。
6. qps = sim.done / duration_s压测结束后用总完成数除以总时长得到吞吐量。
7. for bs in [1, 2, 4, 8]:依次对比不同批大小下的表现，观察吞吐提升与延迟恶化的规律。

常见误区

面试题