上架自检
核对卡数、显存、驱动与固件版本，跑显存校验与带宽测试，验证卡间通信与本地盘读写。这一步能提前发现运输损伤与配置错误，避免在业务压测时才暴露，也能为后续扩容留下基线数据，因此自检记录要逐台留存。
模型与吞吐
用目标模型与量化方式实测加载时间、显存占用、首字延迟与生成速度。记录不同并发下的变化曲线，而不是只报一个峰值数字，否则无法判断在业务高峰时是否会出现排队与超时，曲线比单点数字更能说明容量边界。
稳定性压测
按业务峰值的分级梯度持续施压，观察延迟抖动、显存泄漏与温度功耗。建议覆盖长上下文与长短混合请求，连续运行足够时长再判定，短时间的顺利通过不足以说明问题，压测报告中要写明判定标准。
故障演练
模拟单卡故障、网络中断与服务重启，验证调度是否能疏散、请求是否可重试、告警是否触达值班人。没有演练的冗余配置，在真实故障时往往不起作用，恢复时间也无法预估与承诺，演练记录应包含实际耗时与处置步骤。
报告与基线
报告应附脚本、配置、原始数据与环境说明，形成性能基线。后续扩容或升级用同一基线对比，才能判断变化来自硬件、驱动还是模型版本，避免每次都从头排查，基线数据要按机型分组保存，便于横向比较。
适用与不适用
适合谁
- 推理服务器到货、需要组织验收的技术团队
- 扩容前要建立性能基线的运维部门
- 采购合同中约定性能条款的甲方项目负责人
不适合谁
- 尚未确定目标模型与量化方式的团队
- 不接受长时间压测、要求当天出结论的项目
典型场景
某运营商为推理集群扩容后组织验收。团队先做上架自检，发现一张卡通信异常并更换；随后用目标模型跑三级并发梯度，记录长上下文下的延迟；最后做单卡下线演练，确认调度能在分钟级完成疏散。报告由技术与采购双方签认后归档。
可执行步骤
- 完成硬件自检与卡间通信带宽测试，记录异常卡并安排更换，异常卡要单独记录并复测
- 用目标模型测试加载时间、显存占用与首字延迟，并记录量化方式与显存占用
- 按分级并发梯度做稳定性压测，覆盖长上下文与长短混合请求，持续记录抖动数据
- 演练单卡与网络故障下的请求疏散，记录实际耗时与数据损失，形成演练报告
- 出具报告并建立性能基线，约定复测周期与责任人，归档到运维手册，供后续查阅
常见坑
- 只跑短请求压测，长上下文场景下的显存与延迟问题被掩盖，上线后问题集中爆发。修复窗口很窄。
- 压测时长不足，显存泄漏与温度相关问题未暴露，长稳运行几天后才出故障。排查线索几乎为零，这类问题在短时压测中很难出现。
- 未做故障演练，冗余配置在真实故障时不起作用，恢复时间远超预期。业务方难以接受，预案也没机会暴露自身问题。
- 报告缺少环境与脚本说明，后续无法复现与对比，基线形同虚设。后续优化没有参照，后续对比失去参照。
- 验收只看峰值吞吐，不看延迟分布，高峰期用户体验与报告结论不一致。报告结论与用户感受相互矛盾。
自检与验收清单
- 硬件自检与通信测试是否完成并留记录，异常项是否闭环
- 是否用目标模型与量化方式测试，是否注明版本
- 压测是否覆盖长上下文与混合请求，是否包含长上下文
- 故障疏散是否演练并记录实际耗时，耗时是否记录
- 报告是否附原始数据与性能基线，是否附基线数据
常见问题
压测要跑多久？
取决于业务重要程度，常见做法是覆盖一个完整业务高峰并持续观察，关键系统会延长到数十小时。时长不足时，显存泄漏与散热问题容易漏检，验收结论也会偏乐观，难以支撑上线决策。
性能不达标怎么办？
先定位是配置、驱动、框架参数还是模型本身的问题，再与供应商按合同条款协商。验收报告中的原始数据是沟通依据，因此测试过程要完整留档，避免口头争论与反复返工。
基线需要定期重测吗？
建议在重大版本升级、扩容或机房环境变化后重测，并每半年复核一次。没有基线的对比，性能下降往往只能凭感觉判断，也无法证明是设备还是软件的问题，复测也就失去意义。