口径先写进确认单
压测前把指标字典写清楚：采样周期、统计维度是卡还是租户、有效产出怎么算、排队取哪个分位。口径含糊时同一份报告会有两种解读；字典应由客户方业务与运维共同签字，后续复测沿用同一份。
用真实负载回放
用客户历史请求或脱敏样本按原时间轴重放，比合成压力更能暴露调度、缓存与重试问题。录制要包含到达时间分布与输入长度分布；回放环境规格应与生产一致，否则跑分再好看也无法迁移到线上。
混合负载加故障演练
同时跑在线推理与离线批任务，观察优先级、配额与抢占是否按设计生效；再安排节点断电与驱动异常，确认任务能重调度而不是整体卡死。故障场景不测，首次硬件故障就会变成事故，恢复慢且责任难分。
判定写成条件不是比例
单次压测只证明峰值能力，验收应覆盖连续两周真实负载，按日看排队分位、有效吞吐、失败率与空转卡时。判定宜写成条件组合，例如时延达标且无持续空转；不承诺具体百分比，由客户方技术负责人签认。
适用与不适用
适合谁
- 正在验收自建或托管 GPU 集群的中大型企业
- 需要向内部审计说明算力投入的 IT 负责人
- 有多团队共享需求、需要统一口径的平台团队
不适合谁
- 没有历史负载样本、也不愿做压测的项目
- 期望一次跑分就完成验收的采购方
典型场景
某企业验收一批托管推理服务器，双方约定用两周历史请求回放：白天跑在线服务，夜间叠加批任务，中途安排一次节点断电演练。验收会逐项核对排队分位、失败重试与空转卡时，两项未达标写入整改清单，补测后才签认。
可执行步骤
- 在验收确认单里写清指标字典、采样周期、统计维度与有效产出的完整定义
- 录制一段脱敏的真实请求，完整保留到达时间分布与输入长度分布，再按原时间轴回放
- 按生产规格搭建回放环境，先跑单负载基线，再叠加在线与离线混合负载
- 安排节点断电、驱动异常与网络抖动演练，逐项核对重调度与告警是否生效
- 连续观测两周真实负载，按判定条件出具验收报告，未达标项进入整改复测
常见坑
- 只跑合成压测，输入长度与并发比例失真，上线后排队远超预期，扩容也补不回来，验收结论等于作废。
- 验收环境与生产规格不一致，跑分好看却无法迁移，复测还要重新搭环境，时间与信任一起被消耗。
- 完全不测故障场景，节点掉线后任务整体卡死，只能人工重启，恢复时间与原因都没人说得清，复盘也无依据。
自检与验收清单
- 指标字典是否由客户方业务与运维共同签字确认
- 回放样本是否脱敏，到达时间与长度分布是否接近真实
- 压测范围是否覆盖混合负载、故障注入与重调度验证
- 判定条件是否写成条件组合，而不是一个百分比
- 验收报告是否附原始数据、指标截图与可复现脚本
常见问题
压测要跑多久才算数？
建议覆盖一个完整业务周期，通常连续两周，含工作日峰值与周末低谷。短时压测只能验证峰值能力，看不出配额、缓存与调度在长跑后的退化，也暴露不了夜间空转带来的浪费。
验收指标应该由谁定？
由客户方业务与技术共同定，我方只提供测量方法与实现。指标要能对应业务后果，例如排队时长对应超时率；若由供应商单方设定，验收容易变成自证清白，出了问题时双方都不认账。
达不到约定指标怎么办？
先分清是配置、调度还是负载假设的问题，再决定整改或调整范围。合同应约定整改期与复测方式；若因客户侧负载假设变化导致，需走变更流程重新确认，而不是无限返工。