业务团队要求推理服务在突发流量下自动扩容，平台团队展示副本数确实从少变多，测试人员却发现新实例就绪前请求已经超时。推理服务弹性验收的冲突正在这里：配置生效不等于业务可用，必须把流量、队列、副本和模型冷启动放到同一时间线上。

验收对象：验收的是一次流量变化从触发到恢复的完整行为，而不是伸缩器有没有修改副本字段。

先固定请求画像和业务边界

弹性测试开始前，应固定模型与服务版本、资源配额、请求样本、上下文分布、并发形态、超时规则和观察窗口。交互请求与批量任务若共用入口，需要分别标记，否则长请求可能掩盖真正的队列压力。

基线阶段先记录稳定流量下的请求量、排队时间、首Token或业务相关延迟、错误、资源和副本状态。本文不给予通用阈值；项目应由业务定义可接受体验，平台说明资源条件，SRE说明数据源。

伸缩信号必须早于业务失败

候选信号可以来自队列长度、等待时间、请求并发、服务延迟、资源状态或组合条件。单一GPU利用率可能无法区分计算饱和、显存不足和通信等待，单一CPU指标也未必反映模型服务压力。

验收时要记录信号何时越界、控制器何时决策、新副本何时被调度、模型何时加载完成、预热何时结束、入口何时开始送流。如果扩容动作发生在大量请求已经超时之后，副本最终增加也不能判定弹性顺利获得。

冷启动应拆成阶段，而不是一个总时长

冷启动通常包含调度等待、镜像或运行环境准备、模型获取与加载、健康就绪和业务预热。各阶段的主责与优化方式不同，合并为一个数字会让团队无法判断改进方向。

表格的作用是把冷启动责任拆开。没有业务请求验证的就绪状态，不能证明实例已经具备接流能力。

用时间线覆盖突发、回落和二次峰值

下面的图把流量、队列和可用副本放在同一时间轴，标出触发、准备、接流与回落。

测试至少包含稳定基线、突发升流、持续高位、流量回落、缩容和二次升流。二次峰值可暴露缩容过快、缓存失效或资源尚未释放等问题。资源不足场景还要检查系统是排队、拒绝还是降级，并确认调用方收到可解释结果。

按业务结果解释顺利获得、补测和阻断

顺利获得表示目标场景中的信号、扩容、接流和恢复都有可复核证据，且请求表现符合项目边界；补测表示策略发生作用，但观察窗口、样本或异常覆盖不足；阻断包括扩容后实例无法接流、持续超时、缩容造成中断或资源争用失控。

策略原理可参考已发布的 AI推理服务弹性伸缩分析；本次验收则应按 AI推理服务POC验收框架 保留测试条件与异常证据。

弹性结论必须绑定模型、请求、资源和策略版本。 任何一个对象变化，都应重新检查关键场景，不能把一次POC结果扩展为长期性能或SLA承诺。

弹性验收报告要让不同角色看到同一时间线

性能团队可能关注触发与扩容速度，业务团队更关心超时和排队，平台团队则要解释资源为什么迟迟不可用。弹性报告应以统一时间戳关联请求、队列、控制器、调度、模型加载、就绪和资源事件，避免各自拿一张图得出相反结论。

报告中的每个场景都要写明输入流量、模型与策略版本、预期行为、实际结果和恢复状态。突发升流如果在新实例接流前已经造成大量失败，应记录为业务缺口；缩容后再次升流出现异常，也不能被第一次扩容成功掩盖。无法关联的数据要标记缺失，而不是凭经验补齐。

放行时由业务确认可接受过渡行为，平台确认资源与策略，SRE确认观测、告警和处置，交付团队确认配置可复现。条件顺利获得必须限制应用、流量、时间和资源范围，并写明什么信号会触发停止或回滚。这样“弹性可用”才不会被理解成任何峰值都能自动消化。

进入灰度后继续使用同一时间线复核。模型、镜像、队列策略、资源池或预热方式改变时，只重测受影响环节，同时保留旧基线。持续对比可以帮助团队判断问题来自业务流量、冷启动还是资源供给，而不是反复调整副本上限。

弹性采购应把资源短缺和策略退出写成条件

采购方需要确认弹性能力依赖哪些外部对象：资源池是否预留容量，镜像与模型是否已经分发，伸缩信号由谁维护，入口何时向新副本送流。若候选方案只能修改副本数，而模型加载、预热或入口就绪依赖人工，它给予的是局部自动化，交付范围和运行班表应如实说明。

合同验收可约定四份材料：请求与队列时间线、控制器和调度事件、新副本业务探测、缩容及二次峰值结果。材料要带模型、请求、资源与策略版本，不预写脱离环境的固定时长。资源不足时系统应呈现可解释状态，并按约定触发排队上限、拒绝、降级或人工扩容，而不是无限等待。

实施工作量还包括业务请求分级、指标接入、告警阈值校准、预热样本维护、容量预留和变更回归。交互、批量与低优先级请求如果共享队列，平台团队要设计隔离或抢占边界；业务团队则确认过渡期可以接受的等待和失败。两类工作都不能由伸缩组件自动替代。

退出或回滚弹性策略时，应能恢复上一版信号、最小与最大副本、队列和流量保护配置，并确认已启动副本是否安全收敛。若错误策略导致持续振荡，值班人员要有暂停自动伸缩、固定安全容量和停止缩容的权限。该手册应在上线前演练并纳入交接。

下一步建议

先用脱敏的真实请求建立稳定流量基线，再设计一次突发和一次二次峰值。将伸缩事件、服务日志、队列、请求结果和资源状态导出到同一时间轴。对每个缺口写明责任人、补测条件和回滚动作，再决定是否进入灰度。

常见问题

弹性验收为什么不能只看副本数？

副本数只说明控制器或人工操作改变了期望实例数量，不说明新实例是否取得资源、模型是否加载、健康检查是否准确，也不说明入口何时开始送流。业务真正感受到的是等待、错误、超时和恢复，而这些都可能在副本变化之外发生。

因此验收要把触发信号、调度事件、模型加载、就绪、请求结果和队列变化放在同一时间线上。只有实例在目标窗口内接流并让业务结果回到可接受范围，副本变化才成为有效证据。

弹性报告应按统一时间戳保存请求失败、队列变化、调度事件、模型加载和入口接流，不能由副本曲线单独签字。模型、资源池或预热方式变化后，应使用同一流量脚本重跑受影响阶段。

冷启动时间能直接写进SLA吗？

不宜把一次冷启动测试直接写成无条件SLA。冷启动受模型大小、制品位置、镜像缓存、资源可得性、节点状态和预热方式影响，同一服务在不同环境与时段可能表现不同。测试结果第一时间是一组有条件的工程事实。

若要进入服务目标或合同讨论，应明确模型版本、资源前提、缓存状态、统计窗口、数据源和例外条件，并顺利获得多轮观察校准。还要区分扩容准备时间与用户可感知的请求结果，避免用内部事件代替业务承诺。

若冷启动进入合同或服务目标，还要约定资源短缺、缓存失效和首次拉取如何归类，以及由哪个数据源计算。建议先在内部SLO中观察多个窗口，再由采购与业务决定是否形成外部承诺。

队列积压时应该先扩容还是先限流？

取决于请求价值、后端容量、冷启动速度和可接受等待。若扩容能在业务超时前完成，并且仍有资源，扩容可以吸收峰值；若上游已接近故障或冷启动来不及，限流、排队上限或明确降级能防止压力继续扩散。

实践中通常需要两者联动：队列信号驱动扩容，同时用保护策略限制不可恢复的积压。验收应分别测试被接受、排队、拒绝和降级的请求结果，并让调用方知道如何处理，而不是只优化平台内部指标。

运行手册应给出队列深度、等待时间、资源余量和冷启动阶段的组合判断，并允许值班人员暂停伸缩、设置队列上限或固定安全副本。每种动作都要有恢复检查，防止限流解除后形成二次峰值。