“推理实例启动需要两分钟”这个数字很难指导优化，因为它可能包含调度等待、镜像拉取、卷挂载、模型下载、摘要校验、引擎加载、GPU 内存分配、首次编译、健康检查和首个请求。不同节点缓存状态会让同一版本差异巨大。冷启动验收应把这些阶段分开，既测最冷的新节点，也测稳定节点的常规扩容，并将最终目标定义为“何时能返回首个正确结果”。
建立统一的阶段时间戳
从扩容或创建请求开始，记录调度绑定、容器创建、镜像就绪、存储挂载、服务进程启动、模型加载开始与结束、就绪通过、入口接流量和首请求完成。各系统日志使用的时钟必须可比较。若平台只能看到 Pod Ready，就无法区分模型下载慢还是调度无容量。时间戳还要关联节点、模型摘要、镜像摘要和配置版本。
冷缓存与热缓存要分开报告
节点已有镜像和模型缓存时，启动会明显更快，但故障切换到新节点往往遇到冷缓存。验收至少包含全冷、镜像热模型冷、全部热三种状态，并说明缓存清理方法。不能在同一节点连续重启十次后只报告最好值。若采用预热 DaemonSet 或本地缓存，应把预热自身的带宽、磁盘和一致性纳入架构。
模型加载完成不等于首请求稳定
某些后端在首次请求执行额外初始化、算法选择或缓存建立。就绪探针若只检查进程，会把未预热实例放入流量池。可以设计不含敏感数据的最小预热请求，验证输出结构和关键依赖，同时控制开销。首次请求、前若干请求和稳定窗口都应测量，避免用户成为实际预热流量。
扩容并发会改变单实例结果
一次启动一台实例无法代表突发扩容。多节点同时拉镜像和模型会争用仓库、对象存储、出口、DNS 和认证，加载时还会竞争主机内存与磁盘。应逐级增加同时启动数量，观察共享依赖的队列和失败重试。扩容控制器需要限速、抖动和最大并发，避免健康检查尚未稳定就继续扩大风暴。
失败路径必须计入验收
测试一次镜像拉取失败、模型摘要不符、仓库超时、GPU 资源不足和预热请求失败，确认实例不会错误进入 Ready，也不会无限重试占满控制面。错误信息应直接指出失败阶段。回退到旧版本时，要测量旧制品是否仍在缓存或仓库可用，不能假设回退一定比前进更快。
容量报告还应区分实例首次创建与进程原地重启。两者经过的镜像、卷、调度和网络阶段不同，恢复策略也不同。自动扩缩容应使用与其真实动作对应的指标，不能拿进程重启的短时间去承诺新节点扩容速度。
报告应包含
- 三种缓存状态和不同并发扩容规模下，每个阶段的中位与高分位耗时。
- 镜像、模型、主机内存、GPU 显存、磁盘和网络在加载窗口的峰值。
- 就绪条件、预热请求、入口放流时间和首个正确业务结果。
- 共享仓库、DNS、认证或节点资源不足时的失败、退避和恢复行为。
- 模型、镜像、驱动、运行时和节点类型的完整版本与摘要。
Triton 可暴露服务与推理相关指标，具体字段和版本行为可参考 NVIDIA Triton Metrics 文档。容器和编排阶段还需结合所在平台的事件与指标。冷启动结果只对已记录的模型、缓存、节点和依赖条件有效，不应被包装为无条件性能承诺。
WeChat
Profile