NVIDIA 预览影子引擎恢复以实现更快的 LLM 故障转移

发生了什么

NVIDIA 在 Dynamo 中引入了影子引擎恢复作为预览功能，Dynamo 是其服务大型语言模型的平台。该设计在活动引擎旁边保留一个空闲的、完全初始化的引擎，并使用 GPU 内存服务在进程失败时保存和共享模型权重。

NVIDIA 在 2026 年 8 月 25 日的技术博客中描述了影子引擎恢复，作为 NVIDIA Dynamo 中的预览功能。该公司表示，LLM 引擎进程失败后的传统恢复需要将模型权重加载到高带宽内存中、编译内核、调整键值缓存大小、调整引擎以及重新捕获 CUDA 图表。对于大型模型来说，冷启动序列可能需要几分钟的时间，让剩余的工作人员吸收故障工作人员的流量。

提议的设计在每个工作线程的 GPU 上放置两个引擎进程。一个引擎服务请求，而另一个引擎完成初始化，然后在休眠状态下等待。 NVIDIA 的 GPU 内存服务（GMS）拥有用于独立于任一引擎进程的权重的物理内存。引擎将相同的物理权重页面映射到它们自己的 CUDA 地址空间中，因此备用模型不需要 HBM 中的模型权重的第二个副本。 NVIDIA表示GMS是一个per-GPU sidecar，分配物理页面并提供句柄；它不会位于稍后内核读取的路径中。

在进入休眠状态之前，影子引擎会建立其 CUDA 上下文、导入权重映射、创建 NCCL 和 NIXL 通信器、捕获 CUDA 图形并执行预热。它在停放时不会实现 KV 缓存。如果活动进程退出，操作系统将释放共享 POSIX 文件锁，允许影子进程获取锁、重新映射其权重、具体化其缓存并向路由器注册。 NVIDIA 表示故障引擎随后在后台重新启动，并成为下一个影子。

NVIDIA 通过故意终止两名工作人员 GLM-5.2 部署中的一名工作人员来测量设计。该设置使用量化的 NVFP4 权重、NVIDIA B200 节点、8 个张量并行度、200,000 个令牌最大上下文、一个 FP8 KV 缓存以及包含 32,000 个输入令牌和 1,000 个输出令牌的合成请求。请求达到每秒 0.7 个，并循环分发。在那次测试中，第二个工作线程在影子恢复后 7.3 秒后恢复服务，而冷重启则需要 283 秒。 NVIDIA 报告称，影子配置中的故障后中位时间较短，每个用户的解码率较高。

来源详情: developer.nvidia.com ↗

为什么这很重要

该功能针对的是 LLM 部署中的一个实际弱点：软件故障可能会使幸存的工作人员承担所有流量，而替换进程会重新加载权重并重建其执行状态。尽管 NVIDIA 的结果来自公司运行的一项基准测试，并且不涵盖硬件或节点故障，但更快的恢复可以减少延迟峰值和服务水平中断。

直接价值是针对一类故障的服务连续性，不会损坏底层硬件。 NVIDIA 特别将进程崩溃、可恢复的 CUDA 错误和瞬时集体故障描述为节点和 GPU 在进程状态丢失时可能保持健康的情况。在冷重启期间，幸存的工作人员可能会过载；该公司的测试报告称，基线中故障后第一个令牌的中位时间为 23,815 毫秒，而影子恢复的时间为 1,311 毫秒。

其结果还包括内存管理的变化，对推理系统如何使用昂贵的 GPU 容量产生影响。备用引擎通常需要权重的另一个完整副本，从而减少可用于请求处理的内存。 NVIDIA 表示，GMS 让并发引擎共享一个物理副本，而停放的影子仅保留其上下文、捕获的图形、通信器和映射。该公司将其描述为辅助引擎的边际重量成本为零，但消息来源并未提供所有添加的内存、CPU、存储或编排成本的完整核算。

该基准表明，即使模型本身没有改变，可用性工程也会对用户体验产生重大影响。 NVIDIA 报告称，与影子臂中的 398 个请求中的一个相比，在注入故障后，399 个基线请求中的 201 个请求超过了第一个令牌的 5 秒。它还报告称，有 226 个基线请求低于每个用户每秒 20 个令牌，而影子分支中没有一个。这些数字是 NVIDIA 所说的综合测试的测量结果，而不是跨模型、流量模式或生产环境会发生相同改进的独立证据。

该主张有重要的界限。该功能是预览功能，可解决引擎进程故障，而不是硬件、节点或多节点故障；那些仍然使用标准重新安排。提升的影子以空的 KV 缓存开始，因此 NVIDIA 表示切换后首次令牌时间略有增加。该公司正在努力转移前缀缓存索引和缓存内存，但没有给出完成日期。该消息来源也没有说明定价、全面上市时间、独立验证或超出所描述配置的工作负载的结果。

接下来看什么

NVIDIA 表示，该功能将在未来几个月内逐步推出。重要的测试将包括真实的工作负载、更广泛的后端支持、操作开销，以及未来版本是否可以在故​​障转移期间保留 KV 缓存状态，而不是在升级后重建它。

NVIDIA 表示，影子引擎恢复将在未来几个月内逐步推出，其中 vLLM 作为主要支持的后端。该博客称 vLLM、SGLang 和 TensorRT-LLM 均通过用于权重内存池的自定义 CUDA 可插入分配器集成了 GMS，但记录的恢复示例是围绕 vLLM 构建的。未来的发行说明应阐明哪些后端可以使用完整的恢复工作流程以及在什么部署条件下。

下一个技术里程碑是缓存连续性。如今，备用数据库在没有物理支持的情况下保留 KV 缓存地址范围，并且仅在升级后创建缓存。这减少了停放的占用空间，但这也意味着升级的引擎缺乏先前的对话和前缀缓存状态。保留该状态可以进一步减少切换后短暂的性能提升，同时引入来源尚未详细说明的额外同步和内存管理要求。

运营商需要根据自己的故障模式和基础设施来评估该功能。所述部署需要 Kubernetes 1.34 或更高版本、启用动态资源分配以及 NVIDIA GPU DRA 驱动程序。 NVIDIA 报告在其测试中检测注入故障需要 1.7 秒，促进阴影需要 5.6 秒，但这些时间可能取决于探测器、路由器、模型大小、集群配置和流量。该来源没有提供运行休眠引擎的比较资源要求。

独立测试应检查所报告的增益是否在不同模型、上下文长度、请求混合、自动缩放行为以及多 GPU 或多节点布局中持续存在。它还应该测量干净地检测到故障的频率，基于锁的切换在部分故障期间是否保持可靠，以及重新启动的引擎重新进入影子状态的速度。在这些问题得到解答之前，该功能最好被理解为软件故障恢复的有希望的预览，而不是推理中断的通用解决方案。

相关指南和测验