NVIDIA Recovery tự động hóa khôi phục job training phân tán
NVIDIA Recovery là dịch vụ mã nguồn mở điều phối khôi phục workload training ở cấp cụm. Công cụ phát hiện gián đoạn, quy kết nguyên nhân, loại trừ tài nguyên liên quan và restart hoặc dừng job theo policy đã cấu hình.
Một rank bị treo, timeout NCCL hoặc node GPU không còn phản hồi scheduler có thể làm cả job training phân tán dừng lại. Trong lúc đội hạ tầng kiểm tra log, khoanh vùng nguyên nhân và khởi động lại từ checkpoint, GPU có thể bị bỏ không.
Với cụm AI chạy trong mạng nội bộ, xử lý thủ công từng sự cố nhanh chóng trở thành điểm nghẽn khi số lượng job tăng lên. NVIDIA giới thiệu NVIDIA Recovery, một dịch vụ mã nguồn mở nhằm tự động hóa khôi phục workload training phân tán ở quy mô cụm.
Công cụ này không thay thế Slurm, Kubernetes hay hệ thống giám sát phần cứng. Vai trò của nó là điều phối recovery ở cấp workload: thu thập tín hiệu lỗi, quy kết nguyên nhân có thể xảy ra, loại trừ tài nguyên liên quan và restart hoặc dừng workload theo policy đã cấu hình.
Lớp recovery còn thiếu trong cụm AI
Một hạ tầng training thường đã có nhiều lớp bảo vệ:
Công cụ break-fix phát hiện node có vấn đề, đưa node ra khỏi phục vụ và chuyển sang quy trình khắc phục.
Scheduler hoặc workload manager quản lý cấp phát tài nguyên, hàng đợi và vòng đời job.
Trong Kubernetes, NVSentinel có thể theo dõi chỉ số sức khỏe GPU và sự kiện XID, sau đó cordon và drain node lỗi.
NVRx cung cấp cơ chế recovery, phát hiện treo và giảm ảnh hưởng của straggler bên trong từng training job.
Slurm quản lý tài nguyên, hàng đợi và thực thi workload trong nhiều môi trường HPC/AI.
Khoảng trống nằm ở khâu phối hợp giữa các lớp này. Một tín hiệu GPU bất thường chưa tự trả lời được job nào cần dừng hoặc khởi động lại, node nào nên tránh cấp phát tiếp, hay sự cố xuất phát từ phần cứng, phần mềm hệ thống hoặc ứng dụng.
NVIDIA Recovery nhắm tới lớp workload recovery cấp cụm. Theo NVIDIA, dịch vụ kết hợp log ứng dụng, GPU metrics và tín hiệu scheduler để xử lý gián đoạn trên nhiều workload dùng chung hạ tầng.
Vòng recovery gồm bốn bước
NVIDIA Recovery tổ chức xử lý sự cố thành bốn giai đoạn.
1. Detect — phát hiện
Anomaly Detector kết hợp log ứng dụng và tín hiệu scheduler để nhận diện crash, hang và straggler. NVIDIA cho biết hệ thống có thể nhận diện lỗi PyTorch, NCCL, CUDA và các mẫu lỗi interconnect.
Tín hiệu mất tiến độ hoặc mẫu treo giao tiếp có thể cho thấy job bị hang. Hiệu năng giảm kéo dài so với baseline gần đây có thể cho thấy straggler — worker chậm khiến cả job phải chờ.
2. Attribute — quy kết
Hệ thống sử dụng log ứng dụng và tín hiệu scheduler đã thu thập để phân loại sự gián đoạn, từ đó định hướng hành động recovery.
NVIDIA Recovery có thể tích hợp tùy chọn với NVIDIA Attribution để chẩn đoán sâu hơn, chẳng hạn phân biệt lỗi phần cứng, lỗi phần mềm hệ thống và lỗi ứng dụng. Đây là điểm quan trọng: một lỗi NCCL không mặc nhiên đồng nghĩa GPU bị hỏng.
3. Isolate — cô lập
Khi có bằng chứng liên quan đến một node, NVIDIA Recovery phối hợp loại node đó khỏi lựa chọn đặt workload.
Trong Kubernetes, việc giám sát sức khỏe GPU, xử lý XID, cordon và drain node thuộc vai trò của NVSentinel cùng lớp điều phối và quản lý workload của cụm. Với Slurm, nhiều hệ thống kiểm tra node bằng prolog và epilog script.
4. Recover — khôi phục
Dựa trên policy, hệ thống có thể restart hoặc stop workload. Mục tiêu là đưa training trở lại từ checkpoint trên năng lực còn khỏe, thay vì chờ xử lý hoàn toàn thủ công.
Cần phân biệt hai mốc thời gian: độ trễ đến hành động recovery kết thúc khi automation đã thực hiện hành động; còn thời điểm training thực sự chạy lại vẫn phụ thuộc scheduler và quá trình khôi phục checkpoint.
Slurm là tích hợp được mô tả rõ nhất
NVIDIA cung cấp một Advisor Controller tham chiếu để tích hợp với Slurm. Controller này có thể triển khai bằng Helm chart ở hai chế độ:
In-cluster
Qua SSH
Thiết kế này giúp NVIDIA Recovery không phụ thuộc chặt vào nội bộ scheduler. Với Slurm chạy trên Kubernetes, dự án Slinky có slurm-operator hỗ trợ các script kiểm tra sức khỏe node thông qua prolog và epilog.
NVIDIA cũng nêu lộ trình triển khai ban đầu:
Truy cập mã nguồn và issue tracker của repository dsx-ai-factory/NVIDIA-Recovery.
Chạy quickstart để triển khai cục bộ mà không cần GPU vật lý.
Bắt đầu ở monitor mode.
Đối chiếu khuyến nghị recovery với log ứng dụng, scheduler và dữ liệu sức khỏe GPU.
Chỉ bật hành động tự động khi đội vận hành đã xác nhận tín hiệu và policy phù hợp.
Monitor mode nên là bước bắt buộc
Các deployment mới mặc định khởi động ở monitor mode. Ở chế độ này, NVIDIA Recovery xuất bản khuyến nghị recovery nhưng chưa thực hiện hành động với scheduler.
Đây là hàng rào cần thiết trước khi trao quyền tự động dừng hoặc khởi động lại job. Đội vận hành nên kiểm tra:
Cảnh báo NCCL hoặc CUDA có khớp với log ứng dụng hay không.
Node được đề xuất loại trừ có tín hiệu XID hoặc bất thường về GPU health hay không.
Scheduler thực sự mất liên lạc với node, hay lỗi chỉ nằm trong container hoặc job.
Checkpoint của workload có sẵn sàng để khôi phục hay không.
Trường hợp straggler đến từ node, interconnect, dữ liệu, I/O hay cấu hình training.
NVIDIA Recovery duy trì audit trail gồm mẫu phát hiện, hành động đã thực hiện, thời điểm, mã định danh workload và kết quả quy kết. Recovery Console cung cấp dashboard trực tiếp cho operator trên các kiểu scheduler.
Số liệu NVIDIA công bố: phát hiện trong khoảng một phút
Trong giai đoạn từ ngày 9/7 đến 9/10 trên một cụm training, NVIDIA cho biết hệ thống theo dõi gần 200 job mỗi ngày và ghi nhận khoảng 8.550 anomaly detection.
Độ trễ phát hiện trung bình là 69 giây, còn độ trễ đến hành động recovery trung bình là 94 giây.
Đây là số liệu vận hành do NVIDIA công bố, không phải benchmark độc lập hay SLA áp dụng cho mọi cụm. Tài liệu cũng lưu ý rằng scheduler và thời gian restore checkpoint mới quyết định khi nào training quay lại trạng thái tạo ra tiến độ thực tế.
Kết luận: tự động hóa có kiểm soát
NVIDIA Recovery đáng chú ý với các cụm training phân tán thường gặp NCCL timeout, node GPU không phản hồi hoặc straggler. Công cụ này bổ sung lớp điều phối mà giám sát node và thư viện recovery bên trong từng job khó bao quát đầy đủ.
Với đội vận hành on-prem, cách tiếp cận hợp lý là bắt đầu bằng monitor mode, đối chiếu kết quả quy kết với dữ liệu của chính cụm, rồi mới kích hoạt các hành động tự động trên scheduler. Giá trị của hệ thống không chỉ nằm ở restart nhanh hơn, mà còn ở việc biến quyết định recovery thành quy trình có policy và audit trail.