状态（Status）： Draft 作者（Authors）： @Your_community 创建日期（Created）： 2026-05-08 更新日期（Updated）： 2026-05-08 相关 Issue/PR： #123（关联 Issue/PR 以便追踪背景）
本特性实现推理服务的镜像快照能力，支持大模型推理服务快速启动和故障场景下的快速恢复。通过MindCluster的Infer Operator、NodeD和Docker Runtime组件协作，在推理任务完成warmup后生成Host和Device侧快照，在异常删除Pod后通过快照快速恢复服务，将推理服务启动时间从30分钟以上缩短至秒级。
大模型推理服务启动流程复杂，包括模型加载、权重初始化、KV Cache预热等多个阶段。当前大模型体量大，从开始预热启动到可对外提供服务通常存在30分钟以上的延迟，导致：
在线推理无法按时启动：业务需要快速上线，但冷启动耗时过长 故障场景无法快速恢复：Pod异常删除后重新启动需要完整的预热流程 资源利用率低：长时间预热占用NPU资源但无法提供服务
支持推理服务快速启动，将启动时间从30分钟+缩短至1min内（有预热），无预热场景缩短至2min内 支持故障场景下的快速恢复，减少业务中断时间 支持快照完整性校验，确保快照可用性 兼容现有Infer Operator工作负载管理机制
用例分析。 场景 描述 价值 首次部署 推理服务首次部署时生成快照 后续实例可快速启动 故障恢复 Pod异常删除后快速恢复 减少业务中断时间 弹性扩容 新增推理实例时使用快照启动 快速响应业务需求 版本升级 新版本部署后重新生成快照 保持快照时效性
术语 解释 Device快照 NPU侧的快照，由vLLM引擎触发，包含模型权重、KV Cache等Device内存状态 Host快照 Host侧的容器完整状态快照，包含容器内存、挂载信息、环境变量等，由Docker Runtime执行 Warmup 推理引擎的预热阶段，包括模型加载、权重初始化、KV Cache预热等 PVC Persistent Volume Claim，持久化存储卷声明，用于存储快照文件
快照生成： 1、用户在任务yaml中配置快照生成开关、npu快照存存储路径、host快照存储路径（NPU快照就绪探针配置） 2、infer operator拉起服务阶段，判断快照特性开关状态，在多个P/D实例中选择一个实例（可选择第一个实例），对实例中所有Pod注入任务yaml配置的NPU快照存储路径变量，并为Pod写入annotation相关配置（存储路径等），其中路径需要包含Pod唯一性信息（用于区分不同Pod对应的快照） 3、NodeD监听pod ready状态并读取annotation中存在host快照路径，调用docker runtime启动host快照生成，成功生成后在annotation中写入完成状态 4、infer operator检测Pod annotation快照状态是否都为已完成，如果完成则回复对应实例的客服务状态；如果状态为失败或者超过5min状态仍未变为完成，则认为快照失败，清理该实例下所有Pod对应镜像存储路径（标记失败，避免恢复阶段误用），最后恢复对应实例的课服务状态 5、Infer operator支持对已生成Host镜像进行SHA-哈希操作，用于对共享存储中的镜像进行完整性校验
快照恢复： 1、发生异常删除Pod后，infer operator在创建Pod前判断如果打开快照生成开关且存在有效快照，注入NPU快照存储路径到环境变量，并写入annotationhost快照路径 2、拉起Pod后创建容器，docker-runtime判断pod annotation是否存在合法的快照路径，存在则读取快照恢复；不存在则走镜像拉取流程 3、Infer Operator针对新拉起的Pod所承载的环境变量需要写入metadata文件并挂载，用于推理进程获取最新的环境变量（容器中环境变量为历史容器中的变量，无法修改）
快照校验逻辑：
校验项 说明 文件存在性 检查快照文件是否存在 文件大小 文件大小应大于最小阈值（避免空文件） SHA256校验 校验checksum.sha256文件中的哈希值
列出考虑过但放弃的其他方案，给出优劣对比，说明不选择的理由。
安全项 设计 快照存储安全 使用PVC存储快照，支持加密存储；快照路径包含Pod唯一性信息，避免不同Pod快照混淆 快照完整性校验 使用SHA256哈希校验，确保快照未被篡改；恢复前进行校验 权限控制 NodeD和Docker Runtime以特权容器运行，需用户自行安全加固；快照生成和恢复操作需通过RBAC权限验证 数据隔离 快照按namespace隔离存储；不同推理服务的快照存储在不同路径 快照清理 快照失败时自动清理存储路径；避免无效快照被误用
可观测性设计 监控项 实现方式 快照生成状态 通过Pod Annotation记录快照状态 快照生成耗时 在日志中记录快照生成时间戳 快照大小 记录快照文件大小，用于容量规划 快照恢复成功率 记录恢复成功/失败次数 快照校验状态 记录校验结果
故障处理 故障场景 处理方式 Device快照失败 vLLM引擎侧处理，Pod不置为Ready，MindCluster不启动Host快照 Host快照失败 NodeD更新Annotation状态为failed；Infer Operator清理快照路径，恢复服务状态 快照超时 Infer Operator检测超时（默认5分钟），清理快照路径，恢复服务状态 快照文件损坏 恢复时校验失败，走正常镜像拉取流程 快照路径不存在 Docker Runtime检测路径不存在，走正常镜像拉取流程
若本提案相关特性/功能组件/模块等支持被开发者集成调用（二次开发），则需要提供便捷易用的编程与调用能力。要站在开发者如何进行编程开发、接口调用及系统集成的使用方式上，给出相应的编程模型定义和设计，包括各要素的可获取方式和途径。
开发者在使用本特性/模块时候需要关注的编程模型，比如使用的软硬件环境，编程语言等。 开发环境设计：明确好开发者使用的软/硬件环境、开发&调试工具链、编程框架、要提供的加速库或算子等。 开发约束：开发者使用过程中的约束和限制说明，如硬件平台、编程语言限制等。 可验收设计：提供相应功能、性能指标等的验收环境、标准或用例设计，保证最终的实现可达成既定目标。
给出相关组件/模块被集成调用的API定义或变更、对接上下游主流生态技术栈的适配方案、提供功能被使用或集成的参考代码或方法等。
...
测试设计。 1、用户任务yaml快照开关配置为开启并配置了快照路径，部署任务当推理服务可用后，快照路径下可发现对应pod快照文件，推理业务日志中出现快照生成成功日志 2、发生异常删除Pod，重新拉起后，推理业务日志中出现快照恢复成功日志且推理服务快速恢复
测试项 测试步骤 预期结果 快照配置注入 创建InferServiceSet，配置快照开关和路径 Pod Annotation中包含正确的快照配置；环境变量VLLM_NPU_SNAPSHOT_PATH注入正确 Device快照触发 vLLM完成warmup后触发Device快照 Device快照文件生成；Pod变为Ready状态 Host快照生成 Pod Ready后NodeD触发Host快照 Host快照文件生成；Annotation状态更新为completed 快照SHA256校验 快照生成完成后计算校验值 校验文件生成；Annotation包含checksum 快照恢复 Pod异常删除后重建 Docker Runtime检测到快照配置；快照恢复成功；Pod秒级启动 Metadata挂载 快照恢复时挂载metadata文件 推理引擎可读取最新环境变量 快照失败处理 模拟快照生成失败 Annotation状态更新为failed；快照路径被清理；服务状态恢复 快照超时处理 模拟快照超时（5分钟） Infer Operator检测超时；快照路径被清理；服务状态恢复 快照校验失败 模拟快照文件损坏 校验失败；走正常镜像拉取流程 快照路径不存在 删除快照文件后恢复 Docker Runtime检测路径不存在；走正常镜像拉取流程
兼容性测试 测试项 测试场景 未配置快照 InferServiceSet未配置snapshotConfig时，系统正常工作 快照开关关闭 snapshotConfig.enabled=false时，Pod正常启动，不生成快照 首次部署无快照 首次部署时不存在快照，Pod正常启动并生成快照 快照版本不匹配 快照与当前镜像版本不匹配时，校验失败并走正常流程
欢迎加入社区，感谢您对社区的贡献 🎉!
/label add triaged
状态（Status）： Draft
作者（Authors）： @Your_community
创建日期（Created）： 2026-05-08
更新日期（Updated）： 2026-05-08
相关 Issue/PR： #123（关联 Issue/PR 以便追踪背景）
1. 概述
1.1 简介
本特性实现推理服务的镜像快照能力，支持大模型推理服务快速启动和故障场景下的快速恢复。通过MindCluster的Infer Operator、NodeD和Docker Runtime组件协作，在推理任务完成warmup后生成Host和Device侧快照，在异常删除Pod后通过快照快速恢复服务，将推理服务启动时间从30分钟以上缩短至秒级。
1.2 动机
大模型推理服务启动流程复杂，包括模型加载、权重初始化、KV Cache预热等多个阶段。当前大模型体量大，从开始预热启动到可对外提供服务通常存在30分钟以上的延迟，导致：
在线推理无法按时启动：业务需要快速上线，但冷启动耗时过长
故障场景无法快速恢复：Pod异常删除后重新启动需要完整的预热流程
资源利用率低：长时间预热占用NPU资源但无法提供服务
1.3 目标
支持推理服务快速启动，将启动时间从30分钟+缩短至1min内（有预热），无预热场景缩短至2min内
支持故障场景下的快速恢复，减少业务中断时间
支持快照完整性校验，确保快照可用性
兼容现有Infer Operator工作负载管理机制
2. 用例分析
用例分析。
场景 描述 价值
首次部署 推理服务首次部署时生成快照 后续实例可快速启动
故障恢复 Pod异常删除后快速恢复 减少业务中断时间
弹性扩容 新增推理实例时使用快照启动 快速响应业务需求
版本升级 新版本部署后重新生成快照 保持快照时效性
术语 解释
Device快照 NPU侧的快照，由vLLM引擎触发，包含模型权重、KV Cache等Device内存状态
Host快照 Host侧的容器完整状态快照，包含容器内存、挂载信息、环境变量等，由Docker Runtime执行
Warmup 推理引擎的预热阶段，包括模型加载、权重初始化、KV Cache预热等
PVC Persistent Volume Claim，持久化存储卷声明，用于存储快照文件
3. 方案设计
3.1 总体方案
快照生成：
1、用户在任务yaml中配置快照生成开关、npu快照存存储路径、host快照存储路径（NPU快照就绪探针配置）
2、infer operator拉起服务阶段，判断快照特性开关状态，在多个P/D实例中选择一个实例（可选择第一个实例），对实例中所有Pod注入任务yaml配置的NPU快照存储路径变量，并为Pod写入annotation相关配置（存储路径等），其中路径需要包含Pod唯一性信息（用于区分不同Pod对应的快照）
3、NodeD监听pod ready状态并读取annotation中存在host快照路径，调用docker runtime启动host快照生成，成功生成后在annotation中写入完成状态
4、infer operator检测Pod annotation快照状态是否都为已完成，如果完成则回复对应实例的客服务状态；如果状态为失败或者超过5min状态仍未变为完成，则认为快照失败，清理该实例下所有Pod对应镜像存储路径（标记失败，避免恢复阶段误用），最后恢复对应实例的课服务状态
5、Infer operator支持对已生成Host镜像进行SHA-哈希操作，用于对共享存储中的镜像进行完整性校验
快照恢复：
1、发生异常删除Pod后，infer operator在创建Pod前判断如果打开快照生成开关且存在有效快照，注入NPU快照存储路径到环境变量，并写入annotationhost快照路径
2、拉起Pod后创建容器，docker-runtime判断pod annotation是否存在合法的快照路径，存在则读取快照恢复；不存在则走镜像拉取流程
3、Infer Operator针对新拉起的Pod所承载的环境变量需要写入metadata文件并挂载，用于推理进程获取最新的环境变量（容器中环境变量为历史容器中的变量，无法修改）
快照校验逻辑：
校验项 说明
文件存在性 检查快照文件是否存在
文件大小 文件大小应大于最小阈值（避免空文件）
SHA256校验 校验checksum.sha256文件中的哈希值
3.2 技术选型（可选）
列出考虑过但放弃的其他方案，给出优劣对比，说明不选择的理由。
3.3 安全隐私与DFX设计
安全项 设计
快照存储安全 使用PVC存储快照，支持加密存储；快照路径包含Pod唯一性信息，避免不同Pod快照混淆
快照完整性校验 使用SHA256哈希校验，确保快照未被篡改；恢复前进行校验
权限控制 NodeD和Docker Runtime以特权容器运行，需用户自行安全加固；快照生成和恢复操作需通过RBAC权限验证
数据隔离 快照按namespace隔离存储；不同推理服务的快照存储在不同路径
快照清理 快照失败时自动清理存储路径；避免无效快照被误用
可观测性设计
监控项 实现方式
快照生成状态 通过Pod Annotation记录快照状态
快照生成耗时 在日志中记录快照生成时间戳
快照大小 记录快照文件大小，用于容量规划
快照恢复成功率 记录恢复成功/失败次数
快照校验状态 记录校验结果
故障处理
故障场景 处理方式
Device快照失败 vLLM引擎侧处理，Pod不置为Ready，MindCluster不启动Host快照
Host快照失败 NodeD更新Annotation状态为failed；Infer Operator清理快照路径，恢复服务状态
快照超时 Infer Operator检测超时（默认5分钟），清理快照路径，恢复服务状态
快照文件损坏 恢复时校验失败，走正常镜像拉取流程
快照路径不存在 Docker Runtime检测路径不存在，走正常镜像拉取流程
3.4 编程与调用设计
若本提案相关特性/功能组件/模块等支持被开发者集成调用（二次开发），则需要提供便捷易用的编程与调用能力。要站在开发者如何进行编程开发、接口调用及系统集成的使用方式上，给出相应的编程模型定义和设计，包括各要素的可获取方式和途径。
3.4.1 编程模型基本设计
开发者在使用本特性/模块时候需要关注的编程模型，比如使用的软硬件环境，编程语言等。
开发环境设计：明确好开发者使用的软/硬件环境、开发&调试工具链、编程框架、要提供的加速库或算子等。
开发约束：开发者使用过程中的约束和限制说明，如硬件平台、编程语言限制等。
可验收设计：提供相应功能、性能指标等的验收环境、标准或用例设计，保证最终的实现可达成既定目标。
3.4.2 接口定义与设计
给出相关组件/模块被集成调用的API定义或变更、对接上下游主流生态技术栈的适配方案、提供功能被使用或集成的参考代码或方法等。
3.4.2.1 xxx（API Name）
3.4.2.2 xxx（API Name）
...
3.4.3 使用说明
4. 测试设计
测试设计。
1、用户任务yaml快照开关配置为开启并配置了快照路径，部署任务当推理服务可用后，快照路径下可发现对应pod快照文件，推理业务日志中出现快照生成成功日志
2、发生异常删除Pod，重新拉起后，推理业务日志中出现快照恢复成功日志且推理服务快速恢复
测试项 测试步骤 预期结果
快照配置注入 创建InferServiceSet，配置快照开关和路径 Pod Annotation中包含正确的快照配置；环境变量VLLM_NPU_SNAPSHOT_PATH注入正确
Device快照触发 vLLM完成warmup后触发Device快照 Device快照文件生成；Pod变为Ready状态
Host快照生成 Pod Ready后NodeD触发Host快照 Host快照文件生成；Annotation状态更新为completed
快照SHA256校验 快照生成完成后计算校验值 校验文件生成；Annotation包含checksum
快照恢复 Pod异常删除后重建 Docker Runtime检测到快照配置；快照恢复成功；Pod秒级启动
Metadata挂载 快照恢复时挂载metadata文件 推理引擎可读取最新环境变量
快照失败处理 模拟快照生成失败 Annotation状态更新为failed；快照路径被清理；服务状态恢复
快照超时处理 模拟快照超时（5分钟） Infer Operator检测超时；快照路径被清理；服务状态恢复
快照校验失败 模拟快照文件损坏 校验失败；走正常镜像拉取流程
快照路径不存在 删除快照文件后恢复 Docker Runtime检测路径不存在；走正常镜像拉取流程
兼容性测试
测试项 测试场景
未配置快照 InferServiceSet未配置snapshotConfig时，系统正常工作
快照开关关闭 snapshotConfig.enabled=false时，Pod正常启动，不生成快照
首次部署无快照 首次部署时不存在快照，Pod正常启动并生成快照
快照版本不匹配 快照与当前镜像版本不匹配时，校验失败并走正常流程
5. 缺点与风险 (可选)
6. 现有技术 (可选)
7. 未解决问题 (可选)
欢迎加入社区，感谢您对社区的贡献 🎉!