推理平台的POC容易被一张峰值吞吐图带偏。项目组看到请求跑得快，就直接给出“性能顺利获得”；上线前才发现测试只覆盖短输入，扩容过程出现超时，流量回落后队列迟迟没有清空，模型版本也无法和报告对应。

POC范围：只验证约定模型、三类请求长度、目标资源池和入口策略下的延迟、吞吐、扩缩与恢复；公开榜单和供应商演示不替代本次时间线证据。

压测跑出高峰值不等于POC完成

同一轮POC至少要回答延迟在什么条件下创建、吞吐是否包含失败请求、弹性过程中业务如何感知，以及故障后能否恢复到可识别状态。没有绑定测试条件和恢复证据的性能结果，只能算实验现象。

固定测试对象

先冻结模型版本、运行时配置、输入输出长度分组、并发方式、资源池和入口策略。测试中如更换任一条件，应重新建立结果版本，不能把多套环境的数据合并成一条结论。

POC记录应让性能曲线与弹性动作落在同一条时间线上：

这张表不是通用打分卡。每轮POC都要填写时间戳、请求分组和停止线，缺少扩容中间过程时，不得用扩容后的稳定截图判定弹性顺利获得。

按时间线验证延迟与吞吐

将请求进入、排队、首Token、持续生成和完整响应拆开观察。吞吐统计要同时记录成功、超时、拒绝和取消，避免用总请求数掩盖失败。

把弹性过程纳入验收

从基线开始逐步加压，再制造突发流量并观察扩容，最后让流量回落。每个阶段记录实例、队列、资源、错误与恢复，不能只看最终副本数。

故障场景决定能否进入灰度

在受控环境验证实例异常、资源不足、入口超时和版本回退。记录触发方式、影响范围、保护动作、恢复步骤和复验结果；不在生产环境做破坏性故障注入。

如何形成采购结论

将结果分为顺利获得、补测和阻断。顺利获得表示约定条件下证据完整；补测表示样本或观察窗口不足；阻断表示版本不可追溯、权限失控、异常无法恢复或关键监控缺失。

压测条件要覆盖真实流量，而不是只追一个峰值

POC测试集应来自业务画像，而不是由压测工具随组织造一组等长请求。至少把输入长度、预期输出长度、流式方式和调用优先级分组，并保留各组在日常、峰值与突发时段的占比。在线问答需要观察首Token与长尾，长文生成要关注持续生成和取消，批量任务则要记录完成率与资源占用，三类数据不能合并成一个平均值。

执行时先预热到稳定状态，再运行足够长的基线窗口；加压阶段应逐级提高到目标负载，而不是一步打满。每一级都记录成功、超时、拒绝、取消、队列深度、实例变化和资源水位。若测试工具自身的连接数、网络带宽或客户端CPU先触顶，应停止该轮并修正工具端瓶颈，否则得到的是压测机上限，不是平台上限。

弹性验证还要把时间成本算进去。触发扩容、实例可接收流量、队列回落和资源释放是四个不同时间点。采购报告应展示完整时间线，并说明扩容期间旧实例是否承压、冷实例是否过早接流量、流量回落后是否出现频繁缩扩。只截取扩容后的稳定阶段，会隐去业务真正经历的等待和失败。

故障恢复要设停止线和复验项

异常场景应从可控、可恢复的故障开始，例如测试实例退出、无效凭证、超过配额或新版本健康检查失败。每次只改变一个故障变量，事先写明最大影响范围、停止条件和回退负责人。出现错误率持续越界、队列无法回落、告警缺失或上一稳定版本不可识别时，应立即停止加压并进入恢复，不为完成脚本而继续扩大影响。

恢复完成不能只看实例重新运行。项目组还要复验新请求是否成功、历史队列是否清空、错误和告警是否关闭、资源是否回收到预期范围，以及模型与配置是否回到已知版本。一次需要核心开发者手工修复才能恢复的测试，可以证明故障可救，但不能证明日常值班团队具备恢复能力。

采购证据还要包含实施成本与退出路径

平台报价之外，POC应记录压测脚本维护、模型适配、镜像制作、监控接入、入口改造、测试资源占用和跨团队投入。候选方案若依赖专用参数、长期驻场专家或额外商业组件才能达到结果，这些条件必须进入实施工作量与合同边界，不能只保留性能曲线。

退出条件也要在POC阶段验证：能否导出测试配置、样本标识、指标原始记录、模型与服务版本清单；停用候选平台后，调用方如何切回稳定入口；专用接口或观测字段需要多少改造才能迁移。可采购的POC结论既要证明“当前能运行”，也要说明“变化或失败时能恢复，停止采用时能退出”。

POC报告要让性能、弹性与恢复结论可追溯

原始附件保存每次请求分组的时序数据、实例事件和资源曲线；分析页解释峰值、长尾和错误发生在哪个阶段；采购结论页只写约定负载下可接受的范围。若报告无法从某个“弹性顺利获得”结论反查扩容触发、实例就绪、错误变化和队列回落时间，结论仍需补测。

判定也要贴合POC目标。基线与目标负载均稳定、突发期未越过停止线且回落后恢复到已知状态，才可放行约定范围；扩容有效但冷启动窗口样本不足，列为补测；队列不收敛、失败未统计或回退不能恢复同一版本，直接阻断该轮。

实施成本应记录压测脚本由谁维护、测试资源占用多久、弹性策略是否依赖专用组件，以及上线后由谁值守拐点告警。这些条件与性能曲线一起进入采购附件，避免把临时调优当成平台的无条件能力。

下一步建议

先选一个峰值风险高且请求分布清楚的业务，完成流量画像和停止线，再安排基线、逐级加压、突发扩容与回落恢复。顺利获得 AI推理服务POC怎么做？模型、伸缩、访问与监控4类验收项 补齐访问和监控验收；需要关联请求、实例与GPU证据时，可参照 AI模型可观测性怎么看？指标、链路和日志怎么定位问题 建立时间线。第一轮不追求覆盖所有模型，先证明一条代表性链路可复现。

常见问题

弹性扩容最终成功，为什么POC仍可能不顺利获得？

业务经历的是从突发发生到新容量真正接管流量的全过程，而不是扩容后的最终副本数。若扩容期间首Token长尾、超时或拒绝超过停止线，或者新实例在模型未就绪时接收请求，即使最终副本达到目标，也只能说明控制器执行了扩容。

POC应同时记录触发指标、扩容决策、实例创建、模型加载、健康检查、开始转发和队列回落。只有这些时间点可以和请求结果对齐，才能判断弹性是否保护了业务；缺失中间时间线时，应补测而不是直接放行。

还要让未来值班人员按既定手册完成一次缩容与再次升压，核对告警接收人、权限和回退入口。如果扩容只在原搭建者现场操作时成功，采购方得到的是专家服务条件，不是可交接的弹性能力。

吞吐提高时，怎样判断不是把失败请求也算进去了？

先固定“有效产出”的定义，例如请求成功、输出完整并满足业务超时边界，再分别展示到达量、完成量、拒绝、超时、取消和重试。总请求数或服务端接收数不能直接作为吞吐，因为请求可能仍在队列中，或已经失败却消耗过资源。

还要按输入输出长度分组。短请求占比变化会让总体吞吐看起来提高，因此比较候选或参数前后结果时，必须保持样本比例一致，并附上慢请求与失败请求的原始记录。

报告中还应写明压测客户端、网络和结果读取是否触顶。客户端先到上限时，平台吞吐会出现假平台期；如果不保留工具端资源证据，采购评审无法判断瓶颈属于候选平台还是测试设施。

POC需要覆盖多少模型和流量场景？

第一轮应优先覆盖最能代表采购风险的模型与请求组合，而不是追求模型数量。至少包含日常基线、目标峰值、短时突发和一个可控故障，并让输入输出长度、流式方式和优先级接近真实业务。

若不同模型的架构、显存占用或服务方式差异明显，应把它们拆为后续补测，不用一个模型的结果外推全部目录。报告要明确已测组合、未测组合和触发重新测试的版本或资源变化。

采购范围较大时，可按“核心生产模型、资源特征不同的代表模型、后续上线前补测模型”分层，而不是一次测完所有模型。每层都要指定负责人、预算和放行节点，避免未参测模型在合同签署后被默认纳入承诺。

什么情况下应该停止继续调优？

当队列持续无法回落、错误与长尾反复越过停止线、弹性必须依靠不可维护的专用操作，或每次优化都改变模型质量与接口行为时，应暂停继续追峰值，先解决架构或责任缺口。

补测应针对一个明确未知项，并写清环境、变量、成功标准和负责人。陆续在多轮调参仍无法稳定复现，说明问题不是缺少更多数据，而是当前方案尚未形成可采购的运行边界。

停止后要恢复已知配置，吊销临时凭证，清理测试路由与资源，并保存失败样本和参数差异。若决定淘汰候选，还应确认业务入口可切回、测试数据按制度处置、专用适配工作已登记，避免停止调优却留下持续成本。