性能测试体系：吞吐量压测

可视化演示

展示吞吐量压测：并发梯度策略、吞吐量随并发上升与饱和曲线、瓶颈定位与容量规划关联，通过交互理解AI推理服务峰值压测。

场景模型设计

餐厅要做“满座彩排”，不能只准备一道菜。真实晚高峰的菜单里有凉菜、热菜、汤羹、甜品，还有外卖订单穿插其中。如果彩排只让厨师反复炒同一道菜，一旦真正开业时客人点的菜五花八门，后厨节奏立刻乱套。AI 服务的流量同样五花八门——有短文本分类、有长文档摘要、有图片问答，所以压测的第一步不是盲目地发请求，而是先设计一份“流量菜单”，也就是场景模型。

场景模型要回答四个问题。首先是请求模式建模：各类请求占多大比例、输入输出 Token 长度分布如何，这决定了模型前向计算的负载特征。其次是测试数据构造：数据要贴近生产分布，否则缓存命中率会虚高，测出来的吞吐量到了线上就缩水。再次是链路范围界定：是只压推理服务本身，还是走完网关、鉴权、模型、存储的端到端链路。最后是场景参数配置：压测时长、步长、超时时间这些“火候”参数要预先设定。一份完整的场景模型，就是一场可被重复执行的“彩排脚本”。

菜单越贴近真实，彩排结论就越经得起开业考验。如果场景模型里只有“清一色的短请求”，那么压测报告再漂亮，也只是一份自欺欺人的假菜单。

并发梯度策略

开业彩排不能一开门就涌进一千人——后厨会瞬间被压垮，而且你根本分不清是灶台不够、还是传菜通道太窄。聪明的店主会分批放客：二十桌跑一轮、五十桌跑一轮、一百桌再跑一轮。这就是并发梯度的思想：从低到高、阶梯式地增加并发用户数，每一档停留一段时间采集数据，观察系统在每个压力档位下的反应。

具体策略有四种。阶梯式加压是最常规的做法：每档稳住几十秒，让指标充分暴露再进入下一档。突增式冲击则模拟秒杀、抢购这类瞬间流量，在极短时间把并发顶到高位，测试系统能否扛住“人来疯”。阈值区间探测是在疑似拐点附近用二分法加密测量，像试菜一样一点点加盐，找到味道刚好翻车的那个点。一旦系统过载，还要执行回退与恢复：阶梯式撤掉并发，观察吞吐和延迟能否回到健康水位——这决定了系统在真实故障后能否自愈。

一桌一桌地加人，才能知道第几桌客人开始让厨房冒烟。梯度加压不仅是保护系统的手段，更是绘制吞吐曲线的“逐点采样器”——没有梯度，拐点就无处藏身。

吞吐量指标

出菜速率不会一直随着客人数量上涨。客人太少时厨师闲着，加人出菜就变快；客人太多时传菜通道拥堵、厨师互相抢灶台，出菜速率反而下降。衡量“这间厨房最高能稳定出多少菜”的核心指标，就是QPS（每秒完成的请求数）。但只看 QPS 远远不够，它必须和延迟、错误率放在一起看，才能还原真实的系统状态。

这里有一个极其经典的公式——Little 定律：系统内同时等待处理的请求数，等于吞吐率乘以平均响应时间。假如延迟飙高而吞吐不变，系统里的积压请求会成倍膨胀，像等位区越挤越多人。压测的核心目标之一就是找到拐点：吞吐量从线性增长转为平缓、再从平缓转为下降的那个并发点。拐点之前是健康区，拐点之后进入饱和区，此时错误率抬头、延迟雪崩，用户体感急剧恶化。

拐点就是厨房的“小宇宙爆发上限”。越过它之后，继续塞客人不仅不会出更多菜，反而会让整个后厨系统陷入排队内耗——这正是吞吐量压测最想抓住的那个危险信号。

瓶颈定位

满座时发现上菜速度提不上去，可能是灶台太少（CPU 不足）、可能是传菜生跑不过来（网络 IO 不够）、也可能是冰箱到灶台之间路太窄、大家都在排队取料（锁竞争）。每条线索都要单独检查，这叫瓶颈定位——沿请求链路逐层排查，找到那个真正“卡脖子”的环节。

定位瓶颈有四步操作。分层排查从客户端超时现象入手，依次核查网关、推理服务、模型执行引擎和存储，每一层记录延迟分布，缩小嫌疑范围。资源水位分析看 CPU、GPU、内存、磁盘与网络的使用率：如果 CPU 已打满而吞吐停滞，计算资源就是瓶颈；如果 CPU 只有 40% 而吞吐已到顶，说明请求在等待锁、连接池或外部 IO。锁与连接池是 AI 服务里最隐蔽的瓶颈，线程互相等待会让 CPU 空闲、吞吐停滞，看似“没资源”实则“资源被堵住”。最后要用根因验证收尾：针对嫌疑环节单独压测或加日志，确认它确实是瓶颈，而不是“凭感觉背锅”。

厨房的每一次“卡菜”，都要拆到底，看到底是哪个环节在拖后腿。只有把瓶颈钉死在某个具体组件上，扩容和优化才有的放矢——否则就是把钱花在换更贵的灶台上，结果发现堵点其实在传菜口。

容量规划

彩排结束，老板手里有了一张“厨房能力表”：最多同时接待 300 桌、稳定出菜 400 份一小时。现在要做的决定是——周末晚高峰可能来 350 桌，要不要添炉灶？这个从压测结果到扩容决策的过程，就是容量规划。

容量规划分四步。结果汇总要先整理压测中的最大有效吞吐、SLO 边界并发和错误率曲线，而不是只看 QPS 峰值。容量估算用业务预估峰值乘以预留缓冲系数，比如预估峰值 800 QPS、预留 30% 缓冲，目标容量就是 1040 QPS。扩缩容建议遵循“水平扩展优先、垂直扩展其次”：多挂几个无状态推理实例通常比把单机从 8 核升到 16 核更灵活。最后是成本权衡：多一台 GPU 实例每月多少钱，比一比流量高峰打垮服务带来的损失，用数字说话。

不是厨房越大越好，够用且留有余地，才叫会经营。容量规划的智慧在于：既不因为压测出 1000 QPS 就盲目扩到 2000，也不因为省钱而把系统撑到拐点边缘。

监控配置

现代化的厨房里到处是仪表：灶台温度、备菜时长、传菜生步数、顾客等待时间。哪项指标异常，警报铃立刻响起——否则火情烧到屋顶才发现。AI 服务同样需要一套监控配置，在压测和运行时持续观察系统健康度。

监控配置分四层。业务指标监控盯的是 QPS、错误率、p95/p99 延迟，这些直接反映用户体感。系统资源监控覆盖 CPU、内存、GPU、磁盘与网络，回答“资源用到了什么程度”。告警阈值设定要围绕 SLO 设置，比如“p95 延迟超过 500ms 持续 5 分钟”或“错误率高于 5%”才触发，避免偶发抖动刷屏误报。观测面板把以上指标绘制成实时曲线，压测过程中肉眼捕捉拐点，生产中持续观察水位变化。

没有仪表盘的厨房，着了火都不知道。监控配置是压测的眼睛，也是生产环境的守夜人——它让每一次吞吐异常都有迹可循，让每一个告警都对应一个可行动的阈值。

自动化流水线

好的餐厅会把“满座彩排”变成制度：每周二打烊后，自动放一轮客人、自动记录出菜数据、自动对比上周水平。上周能出 600 份菜，这周降到 500，系统直接消息提醒店长。这就是自动化压测流水线——把压测的场景、执行、采集、对比固化成一条定时运行的流水线，让性能守护不再依赖某个工程师“想起来才测”。

流水线由四块拼成。任务编排用脚本串联起环境准备、数据灌入、压测执行、指标采集和报告生成，每个环节像流水线上的工位一样职责清晰。定时触发通常选在夜间低峰，避免压测流量干扰在线服务。结果归档把每次压测的指标存成历史基线，方便横向比较趋势。回归守护是流水线的守门员：新模型版本上线前自动跑一轮压测，如果吞吐量相比基线下降超过阈值，就拦截发布，把性能衰退挡在线上之前。

把经验沉淀为制度，让每一次代码变更都自动过一遍“厨房彩排”。自动化流水线的终极价值是：性能问题从“事后救火”变成“事前拦截”，让 AI 服务的每一次迭代都站在可验证的吞吐基线上。

AI 应用场景

Python 演示

"""吞吐量压测模拟与容量规划演示 用简化数学模型模拟一次压测: 每给定一个并发水平, 返回该状态下的QPS吞吐量、p95响应延迟和错误率, 再根据SLO自动给出容量建议。"""import math  class LoadSimulator:    """模拟一个AI推理服务的压测过程     concurrency_peak表示吞吐达到最高的并发点, 超过后系统进入过载区。    """     def __init__(self, max_qps=600, base_latency_ms=80, concurrency_peak=400):        self.max_qps = max_qps        self.base_latency_ms = base_latency_ms        self.concurrency_peak = concurrency_peak     def run(self, concurrency):        """给定并发值, 返回(吞吐qps, p95延迟ms, 错误率)"""        if concurrency <= self.concurrency_peak:            qps = min(concurrency * 1.5, self.max_qps)            error = 0.0        else:            overload = (concurrency - self.concurrency_peak) / self.concurrency_peak            qps = self.max_qps * math.exp(-0.5 * overload)            error = min(0.9, max(0, (concurrency - 650) / 2000))        latency = self.base_latency_ms * math.exp(concurrency / 520)        return qps, latency, error  def find_optimal(sim, max_concurrency=1200, slo_latency_ms=500, slo_error=0.05):    """线性扫描并发水平, 返回满足SLO且有效吞吐最大的压测点"""    best = None    for concurrency in range(50, max_concurrency + 1, 50):        qps, latency, error = sim.run(concurrency)        if latency <= slo_latency_ms and error <= slo_error:            effective = qps * (1 - error)            if best is None or effective > best[2]:                best = (concurrency, qps, effective, latency, error)    return best  def main():    sim = LoadSimulator()    print("=== 压测曲线: 并发, QPS, p95延迟ms, 错误率 ===")    for concurrency in range(50, 1001, 50):        qps, latency, error = sim.run(concurrency)        print("%5d  %8.1f  %8.1f  %6.1f%%" % (concurrency, qps, latency, error * 100))     best = find_optimal(sim)    if best:        concurrency, qps, effective, latency, error = best        print("\n=== 容量建议 ===")        print("推荐安全并发: %d" % concurrency)        print("对应吞吐: %.1f QPS" % qps)        print("有效吞吐: %.1f QPS" % effective)        print("预留30%%缓冲后需支撑: %.0f QPS" % (effective * 1.3))  if __name__ == "__main__":    main()

1. class LoadSimulator:用类封装压测模型，方便复用它来跑不同参数的服务
2. def run(self, concurrency):核心方法，输入一个并发值就返回（QPS、延迟、错误率）三元组
3. qps = min(concurrency * 1.5, self.max_qps)未饱和区吞吐随并发线性增长，但被最大 QPS 封顶
4. qps = self.max_qps * math.exp(-0.5 * overload)过载区吞吐指数衰减，模拟排队拥堵导致出菜变慢
5. latency = self.base_latency_ms * math.exp(concurrency / 520)延迟随排队呈指数增长，这是 SLO 被打破的主因
6. effective = qps * (1 - error)有效吞吐会因错误率打折，这才是用户真正“吃到的菜”
7. if best is None or effective > best[2]:在满足 SLO 的点里只保留有效吞吐最大的那一个
8. print("%5d %8.1f %8.1f %6.1f%%" % (concurrency, qps, latency, error * 100))格式化输出压测表，便于人工核对拐点位置

常见误区

面试题