Shadow Engine Recovery in NVIDIA Dynamo

NVIDIA · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài của nhà cung cấp về tính năng đang ở dạng preview; số liệu do NVIDIA tự đo. Bài đi kèm về khởi động nhanh: NVIDIA 2026.

Bối cảnh

• Engine LLM ở production hay gặp lỗi phần mềm phục hồi được (process crash, lỗi CUDA phục hồi được, collective lỗi tạm thời) trong khi phần cứng và node vẫn khoẻ. Đường phục hồi chuẩn là cold restart: nạp weight vào HBM, compile kernel, capture CUDA graph; với model lớn mất vài phút, trong lúc đó các worker còn lại gánh traffic.
• Hai lý do engine mới không bỏ qua được bước khởi tạo: (1) weight gắn với process (bộ nhớ GPU thuộc CUDA context, process chết là driver giải phóng hết); (2) một số trạng thái không chuyển giao được: communicator NCCL/torch.distributed gắn với process, CUDA graph gắn với địa chỉ ảo lúc capture.

Thay đổi chính

• GPU Memory Service (GMS): sidecar mỗi GPU sở hữu bộ nhớ vật lý thay cho engine (dựa trên CUDA Virtual Memory Management: bộ nhớ vật lý và địa chỉ ảo có vòng đời riêng, đếm tham chiếu). Engine import handle và map vào địa chỉ ảo của mình một lần lúc khởi động; GMS không nằm trên đường truy cập nên đọc weight không tốn thêm. Hệ quả: weight sống sót khi engine chết, và hai engine trên cùng GPU dùng chung một bản weight. Tích hợp vào vLLM, SGLang, TensorRT-LLM qua một allocator plug-in cho pool weight.
• Shadow engine: một engine thứ hai khởi tạo đầy đủ (context, communicator, CUDA graph, warm-up, map weight qua GMS) rồi "đỗ": giải phóng phần có thể dựng lại, giữ dải địa chỉ của KV cache mà không có bộ nhớ vật lý, chờ khoá. Chi phí thường trực chỉ là context, graph, buffer communicator.
• Bầu active bằng flock: một pod gồm hai container engine, sidecar GMS và một file khoá chung. Engine active giữ khoá; khi process chết (shutdown, segfault, SIGKILL) kernel tự nhả khoá, shadow lấy khoá, map lại weight, cấp KV cache, đăng ký lại với router. Engine bị treo nhưng process còn sống thì liveness probe của Kubernetes giết nó và rơi vào cùng đường nhả khoá. Container cũ được khởi động lại và trở thành shadow mới.
• Kế toán bộ nhớ: weight chỉ một bản, map read-only; KV cache chỉ engine active giữ.

Vì sao (số liệu NVIDIA, 2026)

• Thử trên 2 worker GLM-5.2 (NVFP4, B200, TP=8, context 200K), tải tổng hợp 32.000 token vào / 1.000 token ra, 0,7 request/giây; SIGKILL một worker rồi quan sát 600 giây.
• Thời gian tới khi có lại worker thứ hai: 283 giây (cold restart) so với 7,3 giây (1,7 giây phát hiện + 5,6 giây promote). TTFT p50 sau lỗi 23.815 ms so với 1.311 ms; request chờ token đầu quá 5 giây: 201/399 so với 1/398.
• Giới hạn của bản preview: chỉ xử lý lỗi process, không xử lý lỗi phần cứng, node hay nhiều node (vẫn dùng reschedule thường); cần Kubernetes 1.34+ với DRA; shadow vào với KV cache rỗng nên TTFT tăng nhẹ sau cutover; vLLM là backend chính.

Bài học cho SWE

• Hot standby rẻ khi phần đắt nhất (weight) được tách khỏi vòng đời process và dùng chung; phần còn lại phải khởi tạo trước vì không chuyển giao được.
• Dùng cơ chế mà kernel tự dọn khi process chết (file lock) để bầu active: không cần heartbeat hay lease cho failover trong cùng máy.
• Phân loại lỗi theo phạm vi (process, node, phần cứng) rồi chọn cơ chế phục hồi cho từng loại; cơ chế nhanh nhất chỉ áp dụng cho loại lỗi phổ biến nhất.

Liên quan

• NVIDIA 2026 · Together AI 2026 (cold start vài phút) · Meta 2021
• Hạ tầng phục vụ LLM inference · Failover, replica và dự phòng dữ liệu