基于Pod Snapshot的大模型推理服务快速恢复

背景信息

随着大语言模型（LLM）推理在云原生环境的大规模部署，弹性伸缩与快速恢复成为保障服务等级协议（SLA）的关键。然而，面对百亿参数级模型（如DeepSeek-V3），传统Pod重启流程面临以下问题：

• 模型加载延迟高：以DeepSeek-V3等MoE架构模型为例，完整加载流程包括从磁盘读取权重文件、反量化处理、权重格式转换（如NPU的NZ排布格式）、通信域初始化等多个串行步骤，冷启动耗时往往在分钟级。对于需要快速扩容应对流量洪峰或故障恢复的场景，这种延迟直接导致服务中断或降级。
• NPU设备状态不可迁移：大模型推理深度依赖NPU加速卡的运行时状态，包括已下发的计算任务、HCCL通信通道、设备端内存中的KV Cache与模型权重等。原生的容器快照技术（如CRIU）仅能处理CPU侧的进程状态，无法感知和保存NPU侧的硬件上下文，导致恢复后设备状态丢失、推理无法继续。
• 分布式通信拓扑断裂：大模型推理依赖TP/EP等跨节点并行策略，HCCL通信域与Pod IP强绑定。当Pod在故障恢复后被调度至新节点时，IP地址的变更将导致原有HCCL通信通道完全失效，必须通过重建通信域方可恢复分布式推理能力。
• 量化权重处理状态丢失：在W8A8等量化场景下，模型权重在加载后需经过后处理流程，包括转置操作、NZ格式转换以及量化参数展平等处理步骤，从而生成派生状态。这些派生状态并未包含在原始checkpoint快照中，Pod恢复后若从原始权重重新加载，将不可避免地需要重新执行上述耗时的后处理流程。

Pod Snapshot机制

为了解决上述问题，vllm-ascend引擎适配了Pod Snapshot快速恢复机制，实现原理请参见下图。

该机制的核心思路是在推理Pod正常运行时，将模型完整运行时状态持久化到共享存储；当Pod需要恢复时，通过CANN底层的快照API恢复NPU设备状态，并从共享存储直接还原模型权重至NPU显存，同时重建分布式通信拓扑，从而跳过耗时的模型加载与初始化流程，实现秒级恢复。

• 快照阶段：全链路状态冻结
  在模型加载及权重后处理（如量化参数派生、格式转换）完成后，系统会将从应用层到硬件层的完整状态序列化至共享存储。

  • 计算缓存持久化： 将旋转位置编码（RoPE）的余弦/正弦等非持久化缓存，以及量化层生成的缩放因子（Scale）、偏移量（Offset）等关键参数缓存至CPU侧，规避恢复后的重复计算。
  • 设备状态冻结： 底层调用CANN运行时API，锁定NPU上执行中的计算任务（In-flight tasks），并将完整的设备上下文备份至快照存储，实现状态的全链路冻结。

• 恢复阶段：显存直通与按需后处理

  新节点启动后，系统将绕过传统的磁盘解析和加载流程。

  • 硬件状态恢复： 优先通过CANN API恢复设备侧上下文，并重新加载底层的HCCL通信任务。
  • 内存映射直读： 利用mmap技术从共享存储加载模型状态，将权重与缓冲区数据由CPU内存直传至NPU显存，减少反序列化开销。
  • 按需触发派生逻辑： 针对W8A8量化层、MLA注意力机制及Attention Mask，系统仅在首次前向推理时，基于恢复标识自动触发后处理逻辑（涵盖矩阵转置、NZ格式转换及投影矩阵重建）。同时，强制刷新匹配当前序列长度的Mask缓存，确保推理状态的一致性与安全性。

• 通信域重建：分布式环境无缝衔接
  • 拓扑清洗与更新： 彻底清空原有的Ascend 并行通信组（TP/EP/网络投影等），并利用新Pod的真实网络信息（IP与主节点地址）更新分布式环境。通过递增初始化端口策略，有效规避网络冲突。
  • MoE路由重绑： 针对专家并行（EP）场景，重新绑定并行通信组与调度配置，并刷新HCCL通信标识，确保大模型路由分发的精准性。
  • 复用计算图： 依托TorchAir编译图启用的GE（Graph Engine）缓存机制，恢复后的计算图可直接复用，避免了重新编译的巨大性能损耗，实现通信与计算的高效桥接。

核心组件