NVIDIA Dynamo预览版推出影子引擎恢复，LLM推理故障恢复时间从 283 秒缩短至 7.3 秒
NVIDIA在Dynamo中新增影子引擎恢复功能，通过GPU内存服务共享权重并预初始化备用引擎，将故障恢复时间从 283 秒降至 7.3 秒，显著减少服务中断影响。
AI解读：LLM推理引擎一旦进程崩溃，传统恢复方式需要冷启动：从存储重新加载权重到HBM、编译内核并捕获CUDA图，大型模型可能耗时数分钟。NVIDIA Dynamo的预览功能影子引擎恢复将大部分恢复工作移出服务路径，通过GPU内存服务（GMS）在活动和备用引擎间共享权重，避免HBM中重复副本，同时预先完整初始化一个影子引擎驻留在同一GPU上。基准测试显示，在双工作器GLM-5.2部署中故意终止一个工作器后，影子引擎恢复在 7.3 秒内恢复服务，而冷启动需要 283 秒；故障后TTFT中位数从 23815 毫秒降至 1311 毫秒，解码速率从 12 tok/s/用户提升至 46 tok/s/用户。该功能目前有局限：不支持硬件或节点故障，需要Kubernetes 1.34及以上并启用DRA，主要支持vLLM后端，且推广后初始TTFT可能略有增加（因KV缓存为空），跨推广的缓存状态迁移仍是活跃开发方向。对运维高可靠性LLM服务的团队来说，这能显著减少SLA违规风险，但早期采用需评估基础设施要求和当前限制。
NVIDIA在其博客中宣布，Dynamo的预览功能影子引擎恢复（Shadow Engine Recovery）旨在将LLM推理引擎故障后的冷重启过程移出服务路径。该功能使故障恢复从约 283 秒降至 7.3 秒，显著减少服务中断。
在标准的恢复路径中，进程崩溃后需从存储加载权重到HBM、编译内核并捕获CUDA图，大型模型可能耗时数分钟，期间幸存的worker必须吸收流量。影子引擎恢复解决了两个核心问题：权重与引擎进程绑定（进程退出时GPU内存被释放），以及初始化状态不可转移（如NCCL/通信器和CUDA图）。
核心机制：GPU内存服务与影子引擎
影子引擎恢复结合持久GPU内存、预热的备用引擎和worker级协调。GPU内存服务（GMS）作为每个GPU的sidecar，独立于引擎进程拥有物理内存资源，使权重在引擎重启后持续驻留，新引擎可映射同一物理内存。GMS基于CUDA虚拟内存管理API，支持物理内存和虚拟地址独立生命周期。
影子引擎是完整初始化的引擎进程，与活动引擎共享同一GPU。通过权重共享，第二个引擎无需复制权重，降低了内存占用。影子引擎在初始化后进入休眠状态，释放可回收内存（如KV缓存，仅保留地址范围），等待故障时被唤醒。
- GMS允许两个引擎映射同一权重张量，访问相同物理字节，每个引擎使用各自上下文中的虚拟地址，读写性能与引擎自分配内存相当。
- 影子引擎预计算了CUDA上下文、捕获的图和通信器（不可从其他进程继承）以及权重映射（通过GMS handle），延迟了KV缓存具体化以节省内存。
- VLLM、SGLang和TensorRT-LLM通过自定义torch.cuda.CUDAPluggableAllocator集成GMS，引擎内权重仍是普通张量，启用仅需在启动时切换标志。
恢复流程与同步
每个worker pod包含两个引擎容器、一个GMS sidecar和共享锁。正常运行时一个引擎持有锁并服务，另一个完全初始化但休眠。故障后，影子引擎获取锁、唤醒、重新映射权重并具体化KV缓存，然后注册到路由器。
同步使用POSIX flock保证互斥和可靠释放，进程退出（包括崩溃或被SIGKILL）时内核释放文件描述符，影子引擎可获取锁。内存核算显示权重由GMS分配一次并被所有引擎只读映射，KV缓存仅由活动引擎持有，而休眠的影子引擎保留CUDA上下文、缓冲区和图。
- 恢复序列包括：T0稳态、T1故障（进程退出）、T2切换（影子成为活动）、T3重启后角色交换。
- 死锁引擎由Kubernetes存活探针处理，级联SIGKILL触发相同的内核管理释放。
基准测试：GLM-5.2双worker场景
测试在NVIDIA B200节点上使用GLM-5.2（NVFP4量化）执行，每个节点一个worker，TP=8，最大上下文 200K，FP8 KV缓存。模拟负载包括 32000 个输入令牌和 1000 个输出令牌，每秒 0.7 个请求。比较冷启动和影子引擎恢复，Fault注入为SIGKILL一个worker，随后观察 600 秒。
结果显示，冷启动时幸存worker独自承担所有流量 283 秒，期间TTFT攀升超过 5 秒；影子引擎恢复在 7.3 秒内恢复服务（1.7 秒检测 + 5.6 秒提升）。故障后TTFT中位数分别为 23815 毫秒（冷启动）和 1311 毫秒（影子恢复），解码速率从 12 tok/s/用户提升至 46 tok/s/用户。
影子引擎恢复避免了 201 个超过 5 秒的请求和 226 个低解码速率请求，而冷启动分别有 1.7 秒和 46 个。表 1 对比了冷启动和影子引擎恢复在故障窗口的关键指标。
- 故障后TTFT p50：冷启动 23,815 ms，影子恢复 1,311 ms。
- 故障后解码速率p50：冷启动 12 tok/s/用户，影子恢复 46 tok/s/用户。
- 恢复时第二worker服务：冷启动 283 s，影子恢复 7.3 s（39 倍提升）。
当前范围与限制
影子引擎恢复不涵盖硬件、节点或多节点故障，这些仍依赖标准重新调度。需要Kubernetes 1.34或更新版本，启用动态资源分配（DRA）并安装NVIDIA GPU DRA驱动。
预览版不支持将GMS用于KV缓存，但该能力正在开发中；推广后的影子引擎从空KV缓存开始，导致切换后TTFT有轻微增加。跨推广的缓存状态迁移（包括前缀缓存索引和缓存内存）是当前工作重点。
vLLM是主要支持的推理后端，团队正在稳定实现并扩大工作负载支持，未来几个月将逐步推出。
- 动态资源分配（DRA）要求Kubernetes 1.34或更高版本。
- 不覆盖硬件、节点或网络故障。
- 影子引擎恢复可与Dynamo Snapshot组合，减少初始化期间的竞争。