技术观察

大模型服务崩一次为什么要几分钟才能回来：NVIDIA“影子引擎”把 283 秒恢复压到 7.3 秒

, , , , ,

大模型线上服务的可靠性问题，过去很容易被“多部署几个副本”掩盖。真正到了大规模推理集群，副本并不能消除故障成本：一个 worker 进程崩溃以后，剩余 worker 要立刻承接流量，首 Token 延迟升高，单用户生成速度下降；如果模型有数百 GB 权重，还要重新从存储加载、建立通信器、完成编译和 autotune、重新捕获 CUDA Graph，冷启动可能持续几分钟。对于面向 Coding Agent、搜索、客服和实时交互的推理服务，几分钟已经足以造成大量 SLA 违约。

NVIDIA 在 8 月 25 日介绍的 Shadow Engine Recovery，思路很像数据库和高可用系统中的“热备”，但它面对的是 GPU 内存和推理引擎特有的问题。官方在两节点 GLM-5.2 测试中人为 SIGKILL 一个 worker：传统冷重启需要 283 秒才恢复第二个 worker，影子引擎方案只用了 7.3 秒，其中大约 1.7 秒用于故障检测、5.6 秒用于影子引擎晋升。这个数字来自 NVIDIA 自己的实验环境，不能直接外推到所有模型和集群，但其底层机制很有工程价值。

LLM 冷启动为什么这么慢

普通 Web 服务崩溃后，容器重新拉起往往只要数秒。LLM 推理引擎不同，启动过程里有几项昂贵工作。第一项是权重加载。模型权重通常从本地 NVMe、网络存储或者对象存储读取到 CPU，再搬到 HBM；对于 tensor parallel 的大模型，还要按照分片规则放到多块 GPU。第二项是运行时准备。vLLM、TensorRT-LLM 等系统会根据硬件和模型做内核选择、编译、autotune，并初始化 CUDA Context。第三项是图和通信。CUDA Graph 依赖固定虚拟地址，NCCL、torch.distributed 通信器则绑定具体进程，这些状态没法简单从死亡进程“继承”给新进程。

更麻烦的是，进程一旦退出，它所属 CUDA Context 通常也会被销毁。权重虽然刚刚还在 GPU HBM 里，驱动却会跟着释放对应资源。新进程不能说“那几百 GB 数据明明还在那里，我继续用”，只能重新加载。这就是冷启动中最浪费的一部分：硬件和节点都没坏，真正丢失的只是进程，但昂贵模型状态仍然被一起清空。

Shadow Engine Recovery 的设计可以拆成两个核心问题：怎样让权重寿命超出推理进程，怎样提前完成那些不能转移的初始化。NVIDIA 分别用 GPU Memory Service 和预初始化的 shadow engine 来解决。

GMS 的关键，是把“物理显存”从进程生命周期里拆出来

GPU Memory Service（GMS）是一个按 GPU 部署的 sidecar。它不负责推理，也不位于模型每次访存的热路径上，而是独立持有某些 GPU 物理内存页。推理引擎通过 CUDA Virtual Memory Management API 导入这些物理页的 handle，并把它们映射到自己的 CUDA 虚拟地址空间。

这个机制和现代操作系统里的虚拟内存思路非常相似。物理页和虚拟地址不再必须属于同一个进程生命周期。只要 GMS 仍然持有引用，即使活跃推理进程退出，权重对应的物理 HBM 页面也不会消失。新引擎启动后重新映射即可，不需要把权重从存储再搬一遍。

更重要的是，两套引擎可以映射同一份物理权重。shadow engine 因此不需要在 HBM 里复制第二份几百 GB 的模型。NVIDIA 称其“marginal weight cost 为零”，这里指的是权重物理副本不增加；影子进程本身的 CUDA Context、通信缓冲区和 CUDA Graph 仍然会占显存，并不是完全没有资源成本。

GMS 对框架的侵入也相对有限。vLLM、SGLang、TensorRT-LLM 可以通过 torch.cuda.CUDAPluggableAllocator 把权重内存池接到 GMS，框架内部看到的权重仍然是普通 torch.Tensor。这种设计比要求推理框架重写一套模型加载和访问逻辑更容易落地。

“影子”真正提前做的是那些死后无法继承的工作

仅让权重不消失还不够。NCCL 通信器、CUDA Context 和捕获好的 CUDA Graph 都和进程本身绑定。Shadow engine 因此在系统正常运行时就先完整启动一次：映射权重、建立 NCCL/NIXL 通信器、完成 warm-up、编译与图捕获，之后进入休眠状态。

休眠时，它不持有自己的权重副本，也不物化 KV Cache，只保留未来接管时无法快速重建的状态。KV Cache 是活跃引擎非常大的显存消费者，如果影子也预先分配一份，双引擎共存就很难成立。因此当前方案只为 KV Cache 预留虚拟地址范围，等影子真正晋升以后再物化物理空间。

活跃引擎和影子引擎之间通过一个很朴素的 POSIX flock 做领导者选举。活跃进程持锁并注册到前端路由；影子阻塞等待。活跃进程崩溃、被 SIGKILL 或被 Kubernetes liveness probe 杀掉时，内核自动回收文件描述符并释放锁，影子立即获得锁，映射权重、创建 KV Cache、重新注册路由，随后开始服务。原来的容器再由编排系统重新拉起，完成初始化后变成新的影子。两套进程就这样轮换角色。

这个方案有一个很好的工程特征：故障切换逻辑基本封装在 worker 内部，外面的 router 和 orchestrator 不需要理解“主引擎/影子引擎”细节。系统边界越清晰，进入生产环境的阻力越小。

283 秒和 7.3 秒，差的不只是恢复时间

NVIDIA 的测试使用两个 worker，每个 worker 部署在 B200 节点上，运行 NVFP4 量化的 GLM-5.2，tensor parallel 为 8，最大上下文 200K，KV Cache 使用 FP8。合成请求包含 32K 输入 Token 和 1K 输出 Token，以每秒 0.7 请求的速度到达。故障发生后，两个 worker 只剩一个，单个 worker 需要临时承担全部流量。

冷重启场景下，第二个 worker 283 秒后才重新上线。故障窗口中 p50 TTFT 达到 23,815ms，p50 单用户 decode rate 降到 12 token/s；影子恢复中，第二 worker 7.3 秒恢复，故障后的 p50 TTFT 为 1,311ms，decode rate 约 46 token/s。超过 5 秒才收到首 Token 的请求，冷重启窗口里是 201/399，影子方案只有 1/398。

这组结果说明大模型高可用不能只盯“节点什么时候重新 Ready”。真正影响用户的是故障期间剩余容量是否被打爆。两个 worker 损失一个，相当于瞬间丢掉 50% 推理容量；如果恢复要四五分钟，排队、Batch 形态、KV Cache 命中率和延迟会连续恶化。恢复缩到几秒，用户侧体验可能只出现一个短暂抖动。

它还不是推理集群的“万能 HA”

Shadow Engine Recovery 当前是 preview，限制相当明确。它主要处理进程级软件故障：进程崩溃、可恢复 CUDA 错误、暂时性的 collective 失败。GPU 真坏了、节点宕机、电源故障或者多节点同时失效，仍然要依靠 Kubernetes 的标准重调度和跨节点容灾。这个边界很重要，因为同 GPU 上的 shadow 无法拯救已经失去的硬件。

第二个限制是 KV Cache 还不能跨晋升持久化。影子接管时需要重新物化 KV Cache，原进程里正在积累的 Prefix Cache 和请求状态并没有被直接继承。这也是切换后 TTFT 仍有轻微抬升的原因。NVIDIA 表示正在开发把 KV Cache 也放到可持久共享内存中的能力。

第三，当前部署要求 Kubernetes 1.34+ 开启 Dynamic Resource Allocation，并安装 NVIDIA GPU DRA Driver，主要支持 vLLM。对于已经稳定运行在老版本 Kubernetes、Slurm 或自研编排环境里的大集群，这不是“打开一个配置项就结束”的功能。

这套思路可能比具体实现更值得借鉴

Shadow Engine 的核心并不复杂：把昂贵、可共享、可持久的状态从易崩溃进程中剥离；把不可转移但耗时的初始化提前做完；真正发生故障时，只执行最短的角色切换路径。数据库有 WAL 和热备，存储系统有副本与元数据分离，网络设备有 standby control plane。大模型推理走到生产深水区以后，也开始出现自己的高可用原语。

这对企业部署私有大模型尤其有现实意义。过去很多系统把“模型能启动、API 能返回”当成上线标准，一旦接入研发、客服、工业运维或者自动化 Agent，恢复时间和容量抖动就会直接进入业务指标。一个 Agent 任务可能连续跑几十分钟甚至数小时，底层推理服务如果每次进程故障都重新冷启动几分钟，上层再完善的工作流也很难稳定。

下一阶段的推理基础设施竞争，性能之外会越来越强调可恢复性。模型权重、KV Cache、路由状态、Prefix Cache、工具调用上下文，哪些应该跟进程绑定，哪些应该被提升成独立服务，会成为架构设计的重要问题。Shadow Engine Recovery 只是其中一个答案，但它已经很清楚地说明：大模型基础设施开始从“把 GPU 跑满”进入“像数据库一样认真对待故障”的阶段。

参考资料

分享到