NVIDIA Dynamo Snapshot: Fast Startup for Inference Workloads on Kubernetes
Bài tóm tắt NVIDIA 2026 3. Quy mô lớn Độ khó: Khó
NVIDIA · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc
Bài của nhà cung cấp, mô tả prototype; một phần tối ưu CRIU chưa phát hành (chờ merge upstream). Bài sau dùng lại GPU Memory Service cho failover: NVIDIA 2026.
Bối cảnh
- Inference cần scale theo tải, nhưng cold start một worker trên Kubernetes mất vài phút; trong lúc đó GPU đã cấp nhưng không sinh token, và hệ không kịp hấp thụ đỉnh tải.
- Trạng thái cần lưu của một worker gồm phần GPU (context, stream, bộ nhớ device, ánh xạ địa chỉ ảo; host không thấy) và phần CPU (bộ nhớ, thread, file descriptor, namespace).
Thay đổi chính
- Ghép hai công cụ:
cuda-checkpointđổ trạng thái GPU về bộ nhớ CPU của process; CRIU ghi cả cây process xuống storage chung (NFS/SMB). Restore ở node khác theo chiều ngược lại. Process tiếp tục đúng tại lệnh nó bị dừng, không biết mình vừa được checkpoint. - Ở mức Kubernetes: DaemonSet đặc quyền
snapshot-agenttrên mỗi node, checkpoint ở mức container (cả lớp filesystem ghi được). Restore bằng một pod giữ chỗ nhẹ rồi khôi phục vào namespace của nó. Không dùng checkpoint/restore có sẵn của Kubernetes quaruncđể không phụ thuộc feature gate của từng cloud, kiểm soát tham số CRIU và để artifact ngoài OCI image. - Hook quiesce/resume: worker khởi tạo engine (nạp weight, warm kernel, capture graph) rồi ghi file "sẵn sàng checkpoint" trước khi kết nối control plane và đăng ký discovery, vì kết nối TCP đang mở không lưu được (IP pod đổi giữa checkpoint và restore). Worker chờ file "đã restore"; restore xong nó tiếp tục ngay trong vòng chờ rồi mới kết nối.
- Tối ưu 1, bỏ KV cache khỏi checkpoint: KV cache chiếm phần còn lại của GPU nhưng lúc checkpoint chưa phục vụ request nào nên không cần lưu; giải phóng bộ nhớ vật lý mà giữ địa chỉ ảo (CUDA graph đã ghi cứng địa chỉ). Qwen3-0.6B trên B200: artifact từ khoảng 190 GiB còn khoảng 6 GiB.
- Tối ưu 2, tăng tốc CRIU: restore song song các buffer memfd (bản gốc làm tuần tự từng buffer ≤2 GiB; gpt-oss-120b có hơn 120 GiB như vậy); thay vòng
preadvmột-đọc-một-lúc bằng Linux native AIO với tới 128 lần đọc đang bay, dùngO_DIRECTđể không làm đầy page cache (NFS không hỗ trợ thì lùi về buffered I/O, lợi ích giảm nhiều). Restore CRIU: Qwen3-8B 24 → 4,7 giây; gpt-oss-120b 119 → 15 giây (gấp 7,9 lần). - Tối ưu 3, tách weight ra khỏi checkpoint bằng GPU Memory Service: checkpoint CRIU của gpt-oss-120b từ 129 GiB còn 6,7 GiB, weight 74 GiB nằm ở artifact riêng, khôi phục song song qua kênh nhanh hơn (GPUDirect Storage, RDMA/NVLink). Thử với weight trải trên 8 SSD NVMe cục bộ: restore dưới 5 giây, thời gian khởi động gpt-oss-120b giảm 21 lần (theo NVIDIA).
Vì sao
- Chưa tối ưu thì với model lớn restore còn chậm hơn cold start, mất ý nghĩa; nút thắt chuyển dần từ kích thước artifact sang tốc độ copy của CRIU, rồi sang việc weight phải đi tuần tự qua RAM host trước khi lên GPU.
Bài học cho SWE
- Checkpoint/restore cần ứng dụng hợp tác: dừng ở trạng thái không có kết nối ra ngoài, và dựng lại kết nối sau restore.
- Đừng lưu thứ có thể dựng lại rẻ (KV cache trống); tách thứ lớn và bất biến (weight) khỏi trạng thái process để đi kênh riêng.
- Đo từng đoạn rồi mới tối ưu: mỗi lần gỡ một nút thắt thì nút thắt tiếp theo lộ ra (cùng mẫu với Mercari 2026, ScyllaDB 2026).
Liên quan
#LLM inference#Cold start#Checkpoint/restore#CRIU#cuda-checkpoint#Kubernetes DaemonSet#KV cache#Linux AIO#O_DIRECT#GPUDirect Storage#vLLM
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (3)