Dynamo Snapshot 使用 CRIU + cuda-checkpoint 实现 K8s 推理 5 秒内启动

NVIDIA 今天发布了 Dynamo Snapshot v1.1.1,一个用于 AI 推理工作负载的 Kubernetes 检查点/恢复系统,可在 github.com/ai-dynamo/dynamo 获取,snapshot-agent 容器在 NGC 上。架构配对两个工具:CRIU(Checkpoint/Restore in Userspace),长期存在的 Linux 进程冻结/解冻机制,与 cuda-checkpoint,CUDA 驱动程序中较新的功能,将 GPU 设备状态(contexts、streams、device memory、virtual mappings)转储到 CPU 内存。顺序很重要:cuda-checkpoint 首先将 GPU 状态移动到 CPU 内存,然后 CRIU 将 CPU 内存、线程、文件描述符和命名空间序列化到存储。恢复反转链。Kubernetes 上推理工作负载的冷启动延迟历史上一直是分钟级,Dynamo Snapshot 报告 gpt-oss-120b 初始化从数分钟下降到 5 秒以下(21x 加速),Qwen3-8B 恢复从 24 秒(upstream CRIU)下降到 4.7 秒(5.1x)经过优化。

值得停下来的机制是 KV cache 大小优化。推理工作负载携带大型 KV cache,否则将主导快照 artifact。Dynamo Snapshot 保留虚拟地址,但在捕获之前通过 cuMemUnmap 和 cuMemRelease 释放物理内存,将 artifact 大小从 190 GiB 减少到 6 GiB(B200 上的 Qwen3-0.6B)。恢复时,地址被重组,cache 被重新预热。K8s 集成使用三个自定义资源:特权 snapshot-agent DaemonSet、定义要快照的 model config 的 DynamoCheckpoint CR,以及引用恢复检查点的 DynamoGraphDeployment CR。Quiesce 和 resume 钩子通过信号文件在引擎初始化和分布式运行时启动之间触发。硬件要求是 x86_64 GPU 节点,NVIDIA 驱动程序 580.xx 或更新(多 GPU 为 590.xx 或更新),跨节点恢复需要 ReadWriteMany 存储。限制很重要,NVIDIA 披露了它们:此有限预览中仅 vLLM 后端,仅单 GPU 检查点(多 GPU 计划中),GMS(用于并发权重恢复的 GPU Memory Service)仅 PoC,使用 AIO 和 parallel memfd 的 CRIU 优化正在等待上游合并而不是已经发货,恢复对实时 TCP socket 状态敏感,特权 DaemonSet 要求对某些集群安全姿态来说非平凡。

两条值得跟踪的生态线索。首先,冷启动一直是反对 Kubernetes 上 AI 推理自动扩展的结构性论点,自从人们开始这样做。旋转新 pod 需要几分钟;需求高峰不等几分钟;SLA 违规随之而来。标准缓解措施一直是过度配置(为 GPU 空闲付费)、warm pools(仍为 GPU 空闲付费)和模型流式传输(更快但仍需 30 到 90 秒)。5 秒以下的恢复实质性地改变了那个数学。如果在你的工作负载上可重现,这是 Kubernetes 上弹性 AI 推理问题的第一个可信解决方案,而不是变通方法。其次,限制是采用时机的实质性解读。仅 vLLM 和仅单 GPU 意味着 Dynamo Snapshot 目前适合特定的部署形态(单 GPU vLLM serving),而不是通用的 K8s 功能。TensorRT-LLM 集成、多模态 worker、embedding 和 diffusion worker、多节点、多 GPU 都在路线图上但未发货。CRIU 上游合并(AIO 和 parallel memfd)是扩大采用超出 NVIDIA fork 的路径。对于评估生产用途的 builders,问题是你的 stack 是否符合当前限制,或者你等下个季度。

周一早上,如果你在 Kubernetes 上运行 vLLM 与单 GPU 推理,并一直为 warm-pool GPU 空闲付费以吸收需求高峰:在非生产集群上对你的实际工作负载尝试 Dynamo Snapshot。gpt-oss-120b 的 21x 是上限;你的真实数字取决于存储 IO(ReadWriteMany 很重要)、模型大小,以及你多积极地行使 KV cache unmap 路径。如果你今天在 TensorRT-LLM 或多 GPU 上,监控路线图和 CRIU 上游合并,而不是押注 Dynamo Snapshot 作为当前选项。如果你更广泛地构建推理平台,两工具架构(cuda-checkpoint 用于 GPU 状态,CRIU 用于 CPU 和进程状态,带有 KV cache 虚拟地址保留)是值得研究的工程模式,不管你是否采用 Dynamo Snapshot 本身。如果你运营特权 DaemonSets 因安全原因不可行的集群,这还不是你的解决方案;架构目前需要特权容器在主机级别驱动 cuda-checkpoint 和 CRIU。