容量压力测试是怎么做的？每一步都讲透

新桥通车前，工程队会用一排重车压上去做荷载试验——大桥要在受控条件下先「经历」最坏情况，才敢放真实车流上去。大模型服务的容量压力测试是同一件事：在上线前或扩容后，用受控流量把系统的真实容量摸出来，而不是等用户高峰替你做实验。

先带走一个判断：压测的目的并非跑出一个好看的最大值，而是找到「系统开始不听话的那个点」，以及距它还有多少安全余量。

先定要压出什么结论

没有目标的压测是自嗨。开工前先写清要回答的问题：系统能在时延不超标的前提下扛住多少并发？高峰流量是当前容量的几倍？瓶颈在算力、内存还是下游依赖？目标决定方案——为了摸拐点，就要阶梯式加压；为了验证冗余，就要模拟单节点故障后继续加压。结论还应写明验收口径：比如「P99 时延不超过 X 秒的条件下，吞吐不低于 Y」，让结果可判可验。对 Kimi 或海螺AI 这类外部能力的调用链路，同样要压出自家接入侧的容量上限，别默认平台侧容量等于自己的容量。

压测脚本的三个参数

压测流量由三个参数塑形：并发量，同一时刻压多少请求；到达节奏，均匀加压还是按真实流量的潮汐曲线模拟；请求构成，长短请求的比例、上下文长度分布，尽量按生产流量画像取样，纯短请求压出的数字对真实业务没有参考价值。三个参数合起来决定压测的可信度。特别提醒：生成式请求的响应长度差异巨大，脚本要模拟流式读取行为，否则测出的服务端压力会失真。

三个参数各管一段，设偏了哪一段会失真。

拐点怎么读

压测结果最有信息量的是拐点：随着并发上升，吞吐先线性增长，到某一点后增速放缓、时延陡增，那个位置就是系统的甜点边界。读拐点看三条曲线的相对位置——吞吐曲线、时延曲线、错误率曲线：吞吐趋平、时延抬头、错误率尚未起来的区间，就是最大可用容量；再往后，错误率抬头意味着系统进入挤兑状态。找到拐点后按惯例留余量，生产水位控制在拐点以下的一定比例，具体余量按业务波动幅度定。

压测数据的落地

压测报告要沉淀三样东西：容量基线，写明测试环境与参数，作为后续扩容决策的参照；瓶颈清单，按影响排序，附复现方式；遗留风险，哪些结论只在测试环境成立、生产环境待验证。压测本身也会产生大量日志与监控数据，归档策略与生产日志同规管理，见日志的保留与合规是怎么平衡的？。压测暴露的高风险项要在上线前收口处理——处理清单与核对顺序见上线前的检查清单有哪些？机制细节全梳理。

两点补充：压测环境尽量与生产同构，硬件或数据量级差太多，结论不可迁移；压测要避开生产高峰，压测流量进入生产环境时必须带标记，与真实流量区分，避免污染业务数据。压测期间触发的告警要提前静默或标记，分级逻辑见告警的分级是怎么定的？从原理到落地；若压测涉及发布与重启流程，停机方式的选择见推理服务的优雅停机？内部门道在这。

压测流程速查表

• 先定结论：容量上限、余量倍数、瓶颈位置、验收口径
• 三参数：并发量、到达节奏、请求构成贴真实画像
• 读拐点：吞吐趋平且时延抬头处，留余量上生产
• 落地三件：容量基线、瓶颈清单、遗留风险

关于容量压测再多问三句

• 多久压一次？：大版本发布、扩容、架构调整后必压，平时按季度例行，容量结论同样有保鲜期。
• 能不能直接在生产环境压？：影子流量压测可以做，但必须带标记、限范围、有急停开关，没有这三样就回测试环境去。
• 压测通过就一定扛得住高峰吗？：不必然，真实高峰的请求构成可能与脚本不同，所以脚本要定期用最新生产流量画像重新校准。