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。