Chia GPU Kubernetes: quota, priority và xử lý job chiếm tài nguyên
Run:ai mã nguồn mở bổ sung một lựa chọn điều phối GPU trên Kubernetes. Nhưng trải nghiệm dùng chung GPU vẫn phụ thuộc vào quota theo nhóm, thứ tự ưu tiên và quy tắc cảnh báo, thu hồi job chạy quá lâu hoặc sử dụng thấp.
Một pod giữ GPU trong khi job cần chạy gấp phải xếp hàng là tình huống quen thuộc ở cụm dùng chung. Vấn đề thường không chỉ nằm ở scheduler, mà ở “luật chơi”: ai được dùng GPU, được dùng bao nhiêu, workload nào được ưu tiên và khi nào một job phải nhường tài nguyên.
Theo chủ đề trên diễn đàn, Run:ai đã được mã nguồn mở, bổ sung thêm một lựa chọn điều phối GPU trên Kubernetes. Dù dùng công cụ nào, quota, priority và quy tắc xử lý job không còn tiến triển vẫn là phần quyết định trải nghiệm vận hành.
Bắt đầu từ đơn vị chịu trách nhiệm rõ ràng
Một thành viên chia sẻ cách chia quota theo namespace của từng team, kèm hàng đợi ưu tiên thấp để tận dụng GPU rảnh vào ban đêm. Đây là một cách tiếp cận dễ thảo luận và kiểm soát hơn so với cấp GPU theo từng yêu cầu riêng lẻ.
Có thể tách policy thành ba phần:
Quota theo team hoặc namespace: đặt giới hạn để một nhóm không chiếm toàn bộ GPU.
Priority theo loại workload: xác định job nào cần được phục vụ trước.
Hàng đợi ưu tiên thấp: dành cho job có thể chờ, nhằm tận dụng tài nguyên rảnh.
Điều cần tránh là gắn ưu tiên cao cho mọi workload. Khi tất cả đều “khẩn cấp”, priority sẽ không còn giúp đội vận hành đưa ra quyết định.
GPU sử dụng thấp là tín hiệu, không phải phán quyết
Một ý kiến khác trong cộng đồng đề xuất theo dõi GPU có mức sử dụng dưới 5% liên tục 30 phút để cảnh báo. Đây có thể là ngưỡng khởi đầu hữu ích để tìm job đáng kiểm tra.
Tuy nhiên, mức sử dụng GPU thấp chưa đủ để kết luận job vô ích. Một workload có thể chờ dữ liệu, checkpoint hoặc thực hiện bước xử lý không dùng GPU. Vì vậy, cảnh báo nên đến trước hành động thu hồi.
Một luồng xử lý đơn giản có thể là:
Người chạy khai báo thời gian chạy dự kiến khi gửi job.
Hệ thống cảnh báo khi job có dấu hiệu bất thường, chẳng hạn GPU sử dụng thấp kéo dài.
Chủ job có cơ hội xác nhận hoặc điều chỉnh workload.
Nếu job vượt thời gian đã khai báo, policy có thể cho phép dừng job và gửi thông báo.
Thành viên trong diễn đàn cũng cho biết đội của họ dừng và báo cho người chạy khi job quá thời gian đã khai báo. Điểm quan trọng là quy tắc này cần được công bố trước, thay vì phụ thuộc vào quyết định tình huống của người trực ca.
Một policy tối thiểu để bắt đầu
Trước khi cấu hình công cụ điều phối GPU, đội platform có thể thống nhất policy ở mức vận hành:
Mỗi team có namespace hoặc đơn vị sở hữu rõ ràng.
Mỗi đơn vị có quota GPU được thống nhất trước.
Job thông thường và job tận dụng GPU rảnh đi vào các hàng đợi khác nhau.
Người gửi job khai báo thời hạn chạy.
Job có tín hiệu sử dụng GPU thấp sẽ được cảnh báo.
Job vượt thời hạn có thể bị dừng theo policy và có thông báo lưu vết.
Mục tiêu không nhất thiết là làm GPU luôn bận. Quan trọng hơn là mọi quyết định đều trả lời được: job nào bị cảnh báo, dựa trên điều kiện gì, ai được thông báo và vì sao tài nguyên được thu hồi.
Thử GPU fractioning: nhìn cả hàng đợi lẫn kết quả job
Diễn đàn cũng đặt câu hỏi về cách đo hiệu quả khi thử nghiệm GPU fractioning. Chỉ số sử dụng GPU tăng chưa chắc đã đồng nghĩa hệ thống tốt hơn: GPU có thể bận hơn nhưng job chậm hơn hoặc hàng đợi khó dự đoán hơn.
Trước và sau thử nghiệm, đội vận hành có thể theo dõi:
Hàng đợi: job phải chờ bao lâu, workload ưu tiên cao có bị chậm không.
Mức sử dụng: thời gian GPU nhàn rỗi kéo dài có giảm không.
Kết quả job: job có hoàn thành trong thời hạn đã khai báo không.
Tác động vận hành: số cảnh báo, số lần thu hồi và các tranh chấp tài nguyên.
Nên thử nghiệm theo từng loại workload thay vì gộp tất cả vào một nhóm. Job batch có thể chấp nhận chờ khác với workload cần phản hồi nhanh.
Checklist cho đội platform
[ ] Quota gắn với namespace hoặc đơn vị sở hữu rõ ràng.
[ ] Priority phản ánh loại workload.
[ ] Job có thời hạn chạy được khai báo.
[ ] Cảnh báo đến trước khi thu hồi tài nguyên.
[ ] Lý do dừng job và thông báo được lưu lại.
[ ] Thử nghiệm GPU fractioning có chỉ số hàng đợi và kết quả job.
[ ] Policy được công bố để người dùng biết trước điều kiện bị cảnh báo hoặc dừng job.
Tóm lại, quota nên bám theo ranh giới mà team có thể chịu trách nhiệm; priority nên bảo vệ workload quan trọng; còn thu hồi GPU nên dựa trên tín hiệu và policy minh bạch, thay vì cảm nhận của người trực vận hành.