Áp dụng giới hạn bộ nhớ GPU trong Kubernetes với CUDA 13.4 và KAI Scheduler

NVIDIA đã phát hành CUDA 13.4, giới thiệu cơ chế thực thi ranh giới bộ nhớ minh bạch cho các khối lượng công việc trên GPU. Để triển khai tính năng này trong Kubernetes, GPU Fractioning Operator mã nguồn mở hiện hoạt động cùng với KAI Scheduler v0.18.0 để quản lý tài nguyên GPU phân đoạn. Sự kết hợp này cho phép các nhóm nền tảng chia sẻ GPU hiệu quả hơn trong khi vẫn duy trì sự cô lập bộ nhớ nghiêm ngặt.

Điều gì đã xảy ra

Nhiều khối lượng công việc suy luận AI và phát triển không cần đến toàn bộ một GPU. Việc gán thiết bị đầy đủ cho các tác vụ nhỏ dẫn đến lãng phí đáng kể dung lượng nhàn rỗi. Mặc dù GPU của NVIDIA từ lâu đã hỗ trợ chia sẻ thông qua Multi-instance GPU (MIG), time-slicing (cắt thời gian) hoặc Multi-Process Service (MPS), nhưng các phương pháp trước đây thiếu cơ chế thực thi bộ nhớ mạnh mẽ trong chế độ chia sẻ. Time-slicing cho phép các tiến trình luân phiên sử dụng nhưng không ngăn được một tiến trình tiêu thụ toàn bộ bộ nhớ khả dụng. MPS cho phép thực thi đồng thời nhưng phụ thuộc vào kỷ luật ứng dụng ở cấp độ người dùng đối với việc sử dụng bộ nhớ.

CUDA 13.4 giải quyết khoảng trống này bằng cách thực thi ranh giới bộ nhớ minh bạch ở cấp độ driver. Các ứng dụng chỉ thấy phần bộ nhớ được phân bổ cho chúng, và các yêu cầu cấp phát vượt quá giới hạn này sẽ thất bại ngay lập tức. Để thu hẹp khoảng cách giữa khả năng cấp thấp này và điều phối Kubernetes, NVIDIA đã giới thiệu GPU Fractioning Operator. Được lưu trữ dưới tổ chức KAI Scheduler trên GitHub, operator này chạy song song với NVIDIA GPU Operator. Nó quản lý việc thiết lập MPS trên mỗi node, áp dụng giới hạn bộ nhớ theo từng khối lượng công việc và báo cáo mức sử dụng theo từng phân đoạn thay vì theo toàn bộ GPU.

KAI Scheduler v0.18.0 tích hợp trực tiếp với operator này thông qua một chế độ chia sẻ GPU mới có tên là NvFractions. Bộ lập lịch chọn các GPU phù hợp dựa trên bộ nhớ khả dụng và ghi các annotation cụ thể vào đặc tả Pod. GPU Fractioning Operator đọc các annotation này và cấu hình node để thực thi các giới hạn bộ nhớ và chế độ tính toán được yêu cầu trước khi container khởi động. Sự tách biệt về mối quan tâm này đảm bảo rằng các quyết định lập lịch vẫn khác biệt so với việc thực thi ở cấp độ node.

Cách thức hoạt động

Hệ thống dựa vào hai chế độ tính toán để chia sẻ tài nguyên GPU: time-slicing và sm-sharing. Trong time-slicing, các khối lượng công việc luân phiên sử dụng toàn bộ GPU. Nếu một khối lượng công việc đang nhàn rỗi, khe thời gian của nó sẽ được phân phối lại cho các khối lượng công việc khác. Chế độ này cung cấp sự cô lập lỗi hoàn toàn, nghĩa là sự cố trong một khối lượng công việc không ảnh hưởng đến các khối lượng công việc khác. Trong sm-sharing, các bộ xử lý đa luồng (SMs) của GPU được chia nhỏ giữa các khối lượng công việc đồng thời. Tất cả các khối lượng công việc đang hoạt động chạy đồng thời, và các SM chưa sử dụng được phân bổ lại một cách động. Tuy nhiên, sm-sharing đặt các khối lượng công việc vào một miền lỗi duy nhất, nên sự cố trong một khối lượng công việc có thể ảnh hưởng đến các khối lượng công việc khác.

CUDA 13.4 thực thi giới hạn bộ nhớ bất kể chế độ tính toán nào. Một khối lượng công việc có thể yêu cầu một lượng bộ nhớ chính xác hoặc một phạm vi bao gồm mức tối thiểu được đảm bảo và mức tối đa có thể tăng đột biến (burstable). Nếu một khối lượng công việc cố gắng cấp phát bộ nhớ vượt quá giới hạn của mình, việc cấp phát sẽ thất bại giống như trên một GPU vật lý nhỏ hơn. Cơ chế thực thi này minh bạch đối với ứng dụng, không yêu cầu thay đổi mã. GPU Fractioning Operator đảm bảo các giới hạn này được áp dụng bằng cách cấu hình các daemon MPS cơ bản và giám sát mức sử dụng theo từng phân đoạn.

Các bộ lập lịch truyền đạt yêu cầu tới operator bằng cách sử dụng các annotation Pod chuẩn của Kubernetes. Các annotation này chỉ định yêu cầu bộ nhớ được đảm bảo, giới hạn burst tùy chọn, chế độ tính toán mong muốn và các thiết bị GPU cụ thể được gán. Operator phân tích cú pháp các trường này và chuyển đổi chúng thành các cấu hình ở cấp độ node. Cơ chế này cho phép bất kỳ bộ lập lịch Kubernetes nào có khả năng ghi các annotation này đều tận dụng được cơ chế thực thi bộ nhớ của CUDA, mặc dù KAI Scheduler là bộ đầu tiên cung cấp tích hợp gốc.

Chi tiết chính

• CUDA 13.4 giới thiệu cơ chế thực thi ranh giới bộ nhớ minh bạch, cho phép xác định lượng bộ nhớ chính xác hoặc phạm vi có thể tăng đột biến cho các khối lượng công việc GPU chia sẻ.
• GPU Fractioning Operator là một công cụ mã nguồn mở thiết lập MPS, áp dụng giới hạn bộ nhớ và đo lường mức sử dụng theo từng phân đoạn GPU.
• KAI Scheduler v0.18.0 bao gồm chế độ NvFractions ghi các annotation Pod cần thiết để operator thực thi.
• Các khối lượng công việc có thể lựa chọn giữa time-slicing (thực thi tuần tự với cô lập lỗi) và sm-sharing (thực thi song song với phân bổ SM động).
• Yêu cầu bộ nhớ có thể được định nghĩa dưới dạng kích thước tuyệt đối (ví dụ: "40Gi") hoặc dưới dạng một phần của GPU (ví dụ: "0.5").
• Quản trị viên bật tích hợp này trong quá trình cài đặt KAI Scheduler bằng một cờ Helm, giúp cài đặt GPU Fractioning Operator như một dependency.

Tại sao điều này quan trọng

Đối với các nhóm kỹ sư xây dựng hạ tầng ML, bản cập nhật này cải thiện đáng kể hiệu suất sử dụng tài nguyên mà không làm giảm sự ổn định. Trước đây, việc chia sẻ GPU thường có nghĩa là phải lựa chọn giữa sự cô lập kém (MPS) hoặc phân vùng cứng nhắc (MIG). Với CUDA 13.4 và GPU Fractioning Operator, các nhóm có thể đóng gói nhiều khối lượng công việc hơn vào phần cứng hiện có trong khi đảm bảo rằng không có tác vụ đơn lẻ nào có thể làm cạn kiệt bộ nhớ của các tác vụ khác. Điều này đặc biệt có giá trị đối với các dịch vụ suy luận và môi trường phát triển, nơi các khối lượng công việc khác nhau về quy mô và cường độ.

Khả năng xác định giới hạn bộ nhớ có thể tăng đột biến thêm tính linh hoạt cho các tác vụ batch hoặc nhiệm vụ huấn luyện đôi khi cần nhiều tài nguyên hơn. Nếu bộ nhớ còn trống, một khối lượng công việc có thể mở rộng sang đó; nếu không, nó vẫn nằm trong mức tối thiểu được đảm bảo. Việc phân bổ động này giảm bớt nhu cầu cấp phát thừa (over-provisioning). Hơn nữa, sự phân biệt rõ ràng giữa time-slicing và sm-sharing cho phép các kiến trúc sư khớp chế độ chia sẻ với yêu cầu chịu lỗi của khối lượng công việc. Các dịch vụ sản xuất quan trọng có thể sử dụng time-slicing để đảm bảo cô lập, trong khi các tác vụ batch có khả năng phục hồi tốt có thể sử dụng sm-sharing để đạt thông lượng cao hơn.

Bạn có thể làm gì

• Cài đặt KAI Scheduler v0.18.0 trở lên với cờ Helm global.nvFractions.set=true để bật hỗ trợ phân đoạn GPU.
• Xem xét repository GPU Fractioning Operator trên GitHub để tìm hướng dẫn cài đặt và chi tiết cấu hình.
• Cập nhật đặc tả Pod để bao gồm các annotation cho yêu cầu bộ nhớ, giới hạn và chế độ tính toán khi triển khai các khối lượng công việc phân đoạn.
• Chọn time-slicing cho các khối lượng công việc yêu cầu cô lập lỗi và sm-sharing cho những khối lượng công việc cần thực thi song song và sử dụng SM động.
• Giám sát mức sử dụng GPU theo từng phân đoạn bằng các metric do GPU Fractioning Operator cung cấp để tối ưu hóa việc phân bổ tài nguyên.
• Tham gia kênh Slack của KAI Scheduler hoặc các cuộc họp cộng đồng hai tuần một lần để đặt câu hỏi và đóng góp cho dự án.