CUDA 13.4 chia sẻ GPU có giới hạn bộ nhớ trên Kubernetes

Một nhóm phát triển chỉ cần vài chục GB bộ nhớ GPU cho notebook, trong khi một dịch vụ suy luận nhỏ lại cần chạy liên tục. Nếu cấp nguyên GPU cho từng nhóm, tài nguyên dễ bị bỏ trống; nếu chỉ time-slicing, một tiến trình vẫn có thể dùng quá nhiều bộ nhớ. Bài toán của đội nền tảng là chia sẻ GPU mà vẫn biết mỗi workload được giữ tối thiểu bao nhiêu và không thể vượt trần nào.

Ngày 27/10/2026, NVIDIA công bố cơ chế mới trong CUDA 13.4, kết hợp với GPU Fractioning Operator mã nguồn mở và KAI Scheduler 0.18.0. Đối tượng chính của bài này là quản trị Kubernetes và đội MLOps đang vận hành nhiều workload AI trên cùng cụm GPU.

Điểm mới trong CUDA 13.4

Theo NVIDIA Technical Blog, CUDA 13.4 có thể áp giới hạn bộ nhớ trong suốt với ứng dụng. Workload có thể xin một lượng bộ nhớ chính xác, hoặc khai báo mức bảo đảm tối thiểu và mức tối đa được phép dùng thêm khi GPU còn rảnh. Khi tiến trình cấp phát quá trần, yêu cầu sẽ thất bại như khi chạy trên GPU nhỏ hơn.

Đây không phải là MIG. Multi-Instance GPU chia phần cứng thành các phiên bản cách ly, còn cơ chế mới dựa trên MPS và cho phép chia linh hoạt hơn. Hai chế độ tính toán cũng có khác biệt: time-slicing cho workload luân phiên dùng toàn GPU và có miền lỗi riêng; sm-sharing cho nhiều workload chạy đồng thời trên các SM nhưng cùng miền lỗi. Đội vận hành không nên coi hai chế độ là tương đương về cách ly.

Kubernetes cần thêm thành phần nào?

CUDA chỉ cung cấp khả năng thực thi giới hạn. GPU Fractioning Operator chạy trên từng node để quản lý MPS, áp giới hạn trước khi container khởi động và đo mức dùng theo từng phần GPU. Scheduler vẫn chịu trách nhiệm chọn thiết bị có đủ bộ nhớ và không trộn time-slicing với sm-sharing trên cùng một GPU.

KAI Scheduler 0.18.0 là bộ lập lịch đầu tiên tích hợp chế độ NvFractions. Nó ghi vào Pod các annotation về bộ nhớ yêu cầu, bộ nhớ tối đa, chế độ tính toán và thiết bị được gán. NVIDIA cho biết scheduler khác cũng có thể dùng cơ chế này nếu tạo đúng annotation; vì vậy đây không phải khóa cứng vào một bộ lập lịch duy nhất.

Tác động với khách thuê GPU tại Việt Nam

Chia nhỏ GPU có thể giúp môi trường thử nghiệm, notebook, dịch vụ embedding hoặc chatbot lưu lượng thấp dùng tài nguyên hiệu quả hơn. Tuy nhiên, điều đó không tự động biến một GPU thành nhiều GPU độc lập. Khách thuê cần hỏi rõ mô hình chia sẻ, mức bộ nhớ được bảo đảm, trần burst, chế độ tính toán và cách xử lý khi một workload lỗi.

Đối với tải cần tính ổn định hoặc yêu cầu cách ly mạnh, GPU riêng hay MIG vẫn có thể phù hợp hơn. Với sm-sharing, các workload tin cậy có thể dùng chung hiệu quả, nhưng một lỗi nghiêm trọng có khả năng ảnh hưởng các tiến trình trong cùng miền lỗi. Đây là quyết định kiến trúc, không chỉ là cách giảm chi phí.

Checklist thử nghiệm trước khi đưa vào hệ thống phục vụ khách hàng

1. Kiểm kê driver, CUDA, GPU Operator, KAI Scheduler và GPU Fractioning Operator; lập ma trận phiên bản tương thích.
2. Tạo workload cố tình chạm trần bộ nhớ để xác nhận lỗi được giới hạn trong container và không kéo theo workload bên cạnh.
3. Đo thời gian phản hồi, thông lượng, bộ nhớ đỉnh và độ lệch hiệu năng khi một workload khác tăng tải.
4. Thử riêng time-slicing và sm-sharing; không suy luận kết quả của chế độ này cho chế độ còn lại.
5. Xác nhận số liệu giám sát theo từng phần GPU, cảnh báo khi dùng gần trần và nhật ký thay đổi annotation.
6. Định nghĩa chính sách cho workload không tin cậy, job nhiều GPU, nâng cấp node và khôi phục sau lỗi.

Khi nào nên dùng?

Cơ chế mới đáng thử khi cụm có nhiều job nhỏ, tải biến động và đội nền tảng đã quản lý Kubernetes thành thạo. Nếu ứng dụng cần toàn bộ băng thông bộ nhớ, chạy multi-GPU chặt chẽ hoặc có yêu cầu cách ly nghiêm ngặt, hãy đo trên đúng mô hình trước khi chia sẻ.

Nếu đội của bạn đang cân nhắc thuê GPU server, hãy gửi loại mô hình, lượng VRAM đỉnh, số request đồng thời, phiên bản CUDA và yêu cầu cách ly tới hotro@thuemaychu.vn. Mục tiêu là xác định nên dùng GPU riêng, MIG hay mô hình chia sẻ trước khi dựng môi trường thử nghiệm; không mặc định workload nào cũng phù hợp với phân mảnh GPU.

Nguồn tham khảo