推理性能压测相关项目最容易在需求、平台和采购之间出现口径冲突。技术团队证明组件能运行，业务团队关心结果和时效，平台团队需要知道资源、版本与故障如何治理，采购还要判断支持范围和长期责任。只有把对象、条件、证据和退出方式写清，方案才具备企业决策价值。

压测证据边界：用业务流量分组生成负载，固定模型、客户端、资源和成功口径，完整保存基线、拐点、失败、恢复与工具端瓶颈；不引用脱离条件的峰值。

从业务日志生成压测请求分布

测试计划先提取代表性时间窗口中的输入长度、目标输出长度、流式方式、到达间隔、调用方优先级和业务超时。样本需要脱敏并保留分组标识；数据不足时可以提出假设，但采购报告必须标出假设来源和未覆盖流量。

压测卡应固定以下条件：

“成功”也要事先定义。状态码正常但输出不完整、超出业务时限或客户端已取消的请求，不能计入有效产出。

分阶段寻找退化拐点，而不是一步打满

预热和低压基线用于确认样本、指标与对象正确；逐级加压用于找到首Token、完整响应、错误或队列第一次明显退化的位置；突发阶段观察保护与扩容；回落阶段检查队列、实例和资源能否恢复。

每个阶段保留到达、完成、拒绝、超时、取消、重试、队列、实例和资源时间线。压测客户端的CPU、连接和网络也同步保存，避免把发压端上限误判为候选平台容量。

业务流量画像要能生成可重放的样本

压测开始前，业务方应给予请求类型、输入输出长度、流式方式、到达间隔、峰值持续时间、优先级和可接受失败方式。样本需要脱敏，并保留稳定标识，便于候选平台使用同一组请求。若只能拿到少量日志，可以先分组建立假设，但报告必须注明样本周期和未知范围。

不同业务不能简单合成平均请求。在线问答关注首Token与长尾，长文生成关注持续生成和取消，批量任务关注窗口内完成量与失败重试。每组都要定义“成功”是什么：返回状态正常并不一定代表完整输出，客户端超时后服务继续计算也不能算有效产出。

测试工具本身要先校准。客户端连接数、CPU、网络或结果写盘触顶时，会制造虚假平台瓶颈；客户端不读取流式内容，也可能改变服务行为。工具版本、并发模型、部署位置和自身资源指标应随报告保存。

压测顺序决定结果能否解释

先完成预热和低压基线，确认模型、入口、指标和样本都可识别；随后逐级加压，在每一级保持足够观察窗口；再制造短时突发，最后让流量回落。每个阶段记录请求、队列、实例、资源、错误与人工动作，标明性能开始劣化的拐点，而不是只截取峰值。

故障测试可选择实例退出、模型未就绪、资源不足、无效凭证或超限调用，并预设停止条件。错误持续越界、队列无法回落、数据边界异常或上一稳定版本不可恢复时，应终止测试。恢复后要复验队列、实例、版本、资源、告警和代表性请求，不能用进程重启替代业务恢复。

任何优化都应生成独立结果版本。调整批处理、缓存、并行、队列或入口重试后，用同一样本复测首Token、完整响应、吞吐、失败和资源。只保存最佳参数会让采购方无法判断维护成本，也无法在升级后恢复基线。

采购证据包要允许第三方复核

一份可进入采购的压测包至少包含测试计划、对象与版本清单、样本分组、资源与配置、脚本版本、原始结果、事件时间线、异常记录、限制条件和放行结论。汇总图用于沟通，但不能替代原始数据与配置摘要。供应商数据、客户侧数据和入口日志不一致时，要说明优先级与差异原因。

结论按“满足当前范围、需要补测、阻断采购”记录。性能优势不能抵消版本不可追溯、权限失控、敏感数据越界或无法恢复。每个补测项要有责任人、环境、成功条件和截止时间；长期无法满足的前置条件应转为合同限制或停止方案。

合同或验收附件还应写明结果适用的模型、资源、请求分布和观察窗口，以及哪些变化会触发重测。这样采购取得的不是永久性能保证，而是一组可复验的条件与责任。

实施成本与退出机制也属于压测结论

压测会暴露模型适配、镜像维护、入口改造、监控接入、脚本开发、测试资源和跨团队工时。某候选若需要特殊优化、额外组件或供应商专家驻场才能达到结果，应把这些依赖和后续值守成本列入比较。开源或商业标签都不能替代实际工作量。

POC结束前还要确认数据和环境如何收口：测试凭证吊销，临时路由和资源回收，样本与结果按制度留存，专用配置和接口差异导出。若停止采用候选方案，调用方能否切回稳定入口、模型与配置能否迁移、监控和审计记录能否保留，都应有明确动作。

压测的最终交付不是一个并发数字，而是业务画像、过程证据、成本条件、恢复能力和退出路径共同组成的采购依据。

采购附件要能由未参测人员重放

原始包保存测试脚本版本、样本分组、对象和资源清单、逐阶段结果、失败请求、工具端指标与事件时间线；分析页解释拐点和瓶颈；采购页只引用可追溯的图表，并明确结果适用的模型、流量分布与观察窗口。

有效吞吐达到目标且长尾、失败和恢复均在约定边界内，可放行当前组合；样本周期短、客户端瓶颈未排除或异常窗口不足，转入补测；版本无法识别、失败被排除在统计外或回落后队列无法清空，阻断结论。任何专用调优还要附上复现脚本和维护成本。

下一步建议

先让业务方确认一份可重放的请求分布和有效产出定义，再校准发压端，依次运行基线、加压、突发、故障和回落。测试结束后请未参与执行的人员按材料重放一组结果；若无法复现，先补证据而不是制作更漂亮的汇总图。通用验收动作可结合 AI推理服务POC怎么做？模型、伸缩、访问与监控4类验收项。

常见问题

压测请求应该使用真实业务日志还是合成数据？

优先从脱敏业务日志提取分布，再用合成数据补齐边界场景。真实日志能保留输入输出长度、到达间隔和调用方差异，但可能缺少未来峰值或故障条件；纯合成数据容易整齐，却可能与实际请求结构相差很大。

报告要标明每组样本来源、时间范围和占比。真实与合成样本分开统计，使采购方知道哪些结果代表现状，哪些用于验证容量边界。

真实日志必须脱敏并限制访问，合成样本则要覆盖长输入、突发和失败边界。样本库应保留稳定标识与版本，候选方案才能使用同一条件重放；业务分布变化后也要触发重新采样。

怎样确认瓶颈不在压测工具本身？

同步监控发压端的CPU、内存、连接、网络和结果读取，并观察提高客户端资源后平台到达量是否继续增长。流式请求还要确保客户端持续读取，否则连接处理方式会改变服务表现。

工具版本、并发模型和部署位置随报告保存。发压端先触顶时，本轮只能证明测试设施上限，不能作为平台最大容量。

可以增加发压节点或降低结果写盘开销做对照，观察平台到达量是否继续增长。采购证据应展示工具端与服务端同一时间线，不能只凭客户端报表判断瓶颈。

工具容量也要纳入测试预算与复用计划。

峰值吞吐很高，为什么还不能直接写入采购承诺？

峰值可能只存在于短暂稳定窗口，也可能包含超时、取消、失败或仍在排队的请求。采购需要的是在业务时限内完成的有效产出，以及达到该结果所需的模型、资源、请求分布和配置条件。

应同时给出长尾、错误、队列、资源和持续窗口，并说明拐点。脱离这些条件的峰值只能用作技术线索，不能外推为全年容量或SLA。

承诺还要绑定模型与配置版本、输入输出分组和资源条件，并写明变化后的重测规则。峰值若依赖专用优化或供应商驻场，应把维护与支持成本写入合同边界。

恢复与退出条件也应同步写入验收附件。

压测报告最少要保存哪些材料？

至少保存测试计划、模型与服务版本、样本分组、资源和配置、客户端脚本、原始结果、失败请求、事件时间线、异常恢复、限制条件和结论。每张汇总图应能反查到对应原始数据与配置版本。

还要记录测试凭证、临时路由和资源的收口动作。若候选停止采用，应能清理环境并保留必要审计证据，不让一次压测留下长期资源或安全负担。

未参测人员应能根据材料还原条件、复跑代表性样本并理解限制。原始记录、分析判断和采购决定分开保存，避免后续把实验现象误读为长期承诺。

材料还应写明复测触发条件。