NVIDIA Workload Map thống nhất cách đọc tác vụ AI trên Kubernetes

Workload Map cung cấp lớp mô tả chung để scheduler và nền tảng quản lý hiểu nhiều loại tác vụ AI trên Kubernetes.

thuemaychu.vn5 Tháng 11, 2026 • 8 phút đọc

Nhiều loại tác vụ AI kết nối qua một lớp điều phối Kubernetes tới cụm GPU

Đội nền tảng thêm một framework AI mới thường phải viết lại bộ chuyển đổi cho scheduler, quan sát và phân bổ tài nguyên. JobSet, RayJob, PyTorchJob hay KServe đều mô tả cấu trúc theo cách khác nhau. Ngày 02/11/2026, NVIDIA giới thiệu Workload Map nhằm tạo một lớp mô tả chung. Bài này dành cho đội nền tảng Kubernetes và CTO đang vận hành nhiều loại workload AI trên cùng cụm GPU.

Workload Map giải quyết vấn đề gì

Theo NVIDIA Technical Blog, Workload Map không thay CRD của framework. CRD là định nghĩa tài nguyên mở rộng của Kubernetes. Công cụ đọc CRD hiện có rồi ánh xạ thành mô hình chung về thành phần, mẫu pod, số bản sao, tài nguyên và trạng thái. Scheduler hoặc bộ điều khiển dùng mô hình này thay vì tự phân tích từng schema.

Danh mục ngày 02/11 có định nghĩa cho JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet và NVIDIA Dynamo. Một định nghĩa JobSet có thể phục vụ CLI kiểm tra workload, KAI Scheduler và NVIDIA Run:ai. Elotl Nova cũng dùng Workload Map cho quyết định đa cụm.

Điều mới và điều không thay đổi

Điểm mới là hợp đồng mô tả có thể tái sử dụng. Khi framework đổi trường hoặc có CRD mới, đội nền tảng cập nhật định nghĩa thay vì sửa nhiều tích hợp. Tuy nhiên Workload Map không tự bảo đảm pod chạy được, không cấp GPU và không thay quota, admission policy, mạng hay lưu trữ.

Đây là dự án mã nguồn mở trong NVIDIA DSX AI Factory Platform. Khả năng tương thích cần được kiểm chứng với đúng phiên bản CRD. Danh sách có sẵn không có nghĩa mọi trường tùy chỉnh hoặc operator đã fork đều được hiểu đúng.

Tác động với cụm GPU dùng chung

Trong môi trường nhiều nhóm, lớp mô tả chung giúp đội vận hành nhìn leader, worker, replica và yêu cầu tài nguyên theo cùng cách. Nó có thể giảm thời gian đưa framework mới vào hệ thống và làm rõ workload nào cần gang scheduling — chỉ khởi chạy khi đủ cả nhóm tài nguyên cần thiết.

Khách thuê GPU tại Việt Nam nên quan tâm khi chạy nhiều node hoặc nhiều nhóm trên Kubernetes. Nếu chỉ dùng một máy cho tác vụ độc lập, lợi ích có thể nhỏ hơn chi phí vận hành thêm. Quyết định cần dựa trên số framework, tần suất thay đổi và mức tự động hóa mong muốn.

Checklist đánh giá trước khi tích hợp

Lập danh sách CRD, group/version/kind và operator trong môi trường thử nghiệm.
Đối chiếu từng loại với workload catalog; ghi rõ định nghĩa chưa có hoặc đã tùy biến.
Chạy CLI trên bản sao manifest, kiểm tra leader, worker, replica, GPU và trạng thái.
Thử workload nhỏ với scheduler hiện tại; so sánh quyết định trước và sau tích hợp.
Thiết lập kiểm thử khi nâng operator để phát hiện schema thay đổi.
Giữ đường quay lại; chưa áp dụng thẳng cho hệ thống đang phục vụ khách hàng khi chưa kiểm chứng quota và ưu tiên.

Khi nào nên áp dụng

Workload Map đáng thử khi nền tảng hỗ trợ nhiều loại workload hoặc mỗi lần thêm framework đều kéo theo nhiều adapter. Nếu vấn đề chính là thiếu GPU, nghẽn mạng hay tải dữ liệu chậm, lớp mô tả không xử lý nguyên nhân đó. Hãy đo thời gian tích hợp, số lỗi ánh xạ và độ ổn định lịch chạy, không chỉ đếm số CRD được hỗ trợ.

Workload Map có thay JobSet hoặc Ray Operator không?

Không. Nó đọc cấu trúc của các tài nguyên đó để cung cấp mô tả chung cho công cụ khác.

Có bắt buộc dùng NVIDIA Run:ai không?

Không. Bài công bố nêu nhiều tích hợp, còn dự án hướng tới mô hình có thể tái sử dụng.

Cụm một node có cần Workload Map không?

Thường không cấp thiết; giá trị tăng khi có nhiều framework, scheduler hoặc workload phân tán.

Nếu đội nền tảng muốn đánh giá Workload Map, hãy chuẩn bị phiên bản Kubernetes, danh sách CRD/operator, scheduler, số node GPU và manifest mẫu đã loại thông tin nhạy cảm. Gửi qua kênh liên hệ để trao đổi phạm vi thử nghiệm và cách đo hiệu quả trước khi thay đổi cụm dùng chung.