Nghịch lý GPU nhàn rỗi trong khi tác vụ AI vẫn xếp hàng: Giải mã vấn đề phân bổ trên Kubernetes

Mức độ sử dụng GPU cho thấy hoạt động tính toán, chứ không cho biết liệu dung lượng có thực sự khả dụng hay không. Một GPU có thể báo cáo mức sử dụng thấp trong khi vẫn được phân bổ hoàn toàn cho một khối lượng công việc (workload). Bài viết này giải thích lý do tại sao các khối lượng công việc phải xếp hàng bên cạnh những GPU trông có vẻ nhàn rỗi, cách mà việc phân bổ, bộ nhớ, vị trí đặt và các nút thắt cổ chai của ứng dụng góp phần vào tình trạng này, cũng như cách các phương pháp chia sẻ GPU khác biệt nhau về những đánh đổi.

Tóm tắt:

Các khối lượng công việc AI có thể phải chờ GPU ngay cả khi việc giám sát cho thấy hoạt động tính toán đang nhàn rỗi. Một GPU có hoạt động tính toán thấp không nhất thiết là dung lượng khả dụng cho một khối lượng công việc khác, vì các quy tắc phân bổ, yêu cầu bộ nhớ, khả năng tương thích phần cứng, tính cô lập và các ràng buộc về vị trí đặt quyết định những gì thực sự có thể chạy. Bài viết này sẽ giải thích cách phân biệt tình trạng thiếu hụt phần cứng thực sự với nút thắt cổ chai về phân bổ, vị trí đặt hoặc ứng dụng. Sử dụng số liệu trung bình 5% mức sử dụng GPU từ báo cáo năm 2026 của Cast AI làm điểm thu hút nghiên cứu, nhưng không được ngụ ý rằng các khối lượng công việc xếp hàng và GPU nhàn rỗi xảy ra cùng nhau trong cùng một môi trường đo lường, hoặc 95% dung lượng GPU có thể được thu hồi ngay lập tức.

Những điểm chính

• Các chỉ số sử dụng GPU đo lường hoạt động tính toán, không phải trạng thái phân bổ. Một GPU báo cáo mức sử dụng tính toán 5% vẫn có thể được phân bổ hoàn toàn với dung lượng bằng 0 khả dụng cho các khối lượng công việc mới.
• Theo mặc định, Kubernetes gán toàn bộ GPU cho các pod. Một khối lượng công việc đang chiếm giữ thiết bị sẽ chặn tất cả các khối lượng công việc khác bất kể nó thực sự sử dụng bao nhiêu phần trăm GPU.
• Các khối lượng công việc xếp hàng bên cạnh những GPU trông có vẻ nhàn rỗi có ít nhất bốn nguyên nhân gốc rễ riêng biệt. Chỉ một trong số đó được giải quyết bằng cách chia sẻ GPU.
• Time-slicing, MIG và MPS có những đánh đổi khác nhau về tính cô lập bộ nhớ, yêu cầu phần cứng, khả năng quan sát và hỗ trợ từ nhà cung cấp đám mây. Không có phương pháp duy nhất nào phù hợp với mọi khối lượng công việc.
• Trình tự chẩn đoán rất quan trọng: kiểm tra trạng thái phân bổ, sau đó đến mức chiếm dụng bộ nhớ, các ràng buộc về vị trí đặt và cuối cùng là các nút thắt cổ chai của ứng dụng. Theo đúng thứ tự đó.
• Cast AI hỗ trợ cả ba phương pháp chia sẻ với tính năng tự động bin-packing và không yêu cầu thay đổi các tệp manifest của khối lượng công việc.

Mức sử dụng GPU cho bạn biết điều gì và bỏ lỡ điều gì

Mức sử dụng GPU là một cụm từ bao hàm ít nhất bốn phép đo khác nhau, và việc đánh đồng chúng là con đường nhanh nhất dẫn đến chẩn đoán sai. Những gì hầu hết các bảng điều khiển hiển thị là mức sử dụng tính toán: tỷ lệ phần trăm các streaming multiprocessor (SM) đang hoạt động trong một khoảng thời gian nhất định. Con số đó cho bạn biết chip silicon bận rộn như thế nào khi nó chạy. Nó không cho bạn biết liệu thiết bị có khả dụng cho một khối lượng công việc mới hay không.

Một mô hình được tải vào VRAM sẽ chiếm dụng bộ nhớ đó liên tục. Dịch vụ suy luận (inference service) có thể trả lời một yêu cầu mỗi phút, giữ cho hoạt động tính toán ở mức 5%, nhưng thiết bị đã được phân bổ, bộ nhớ đã bị chiếm dụng và Kubernetes sẽ không lập lịch bất kỳ thứ gì khác trên đó. Từ góc độ của bộ lập lịch, GPU đó không khả dụng. Từ bảng điều khiển giám sát của bạn, nó trông gần như nhàn rỗi.

Bảng dưới đây tách biệt bốn chỉ số thường được nhóm chung dưới tên gọi "mức sử dụng GPU" và làm rõ mỗi chỉ số cho biết và không cho biết điều gì.

Báo cáo tối ưu hóa Kubernetes năm 2026 của Cast AI, đã phân tích hàng chục nghìn cụm sản xuất từ tháng 1 năm 2025 đến tháng 4 năm 2026, ghi nhận mức sử dụng tính toán GPU trung bình là 5% trước khi áp dụng bất kỳ tối ưu hóa nào. Bài đăng trên blog về báo cáo đi kèm lưu ý rằng một cụm trong tập dữ liệu duy trì mức sử dụng GPU 49% trên 136 chiếc H200, một khoảng cách được mô tả gần như hoàn toàn là do kỹ thuật chứ không phải do phần cứng. Mức trung bình 5% đó phản ánh một mô hình thực tế về việc cấp phát thừa và sử dụng thiếu trên toàn bộ đội ngũ thiết bị. Nó không có nghĩa là 95% dung lượng đang trống để tiếp nhận các khối lượng công việc mới. Mỗi cụm, và mỗi GPU trong đó, cần có quy trình chẩn đoán riêng trước khi kết luận đó có giá trị.

Bốn lý do khiến khối lượng công việc phải xếp hàng bên cạnh dung lượng GPU nhàn rỗi

Bộ lập lịch Kubernetes coi GPU là khả dụng hoặc không khả dụng. Nó đưa ra quyết định đó dựa trên số lượng tài nguyên nvidia.com/gpu trên mỗi node, không phải dựa trên tỷ lệ phần trăm silicon đang hoạt động. Bốn điều kiện riêng biệt có thể tạo ra hàng đợi ngay cả khi hoạt động tính toán trông có vẻ thấp.

Một khối lượng công việc chiếm giữ toàn bộ thiết bị

Theo mặc định, NVIDIA Kubernetes Device Plugin phân bổ GPU một cách độc quyền. Khi một pod yêu cầu nvidia.com/gpu: 1, nó nhận quyền sở hữu duy nhất đối với một thiết bị vật lý trong suốt vòng đời của nó. Không pod nào khác có thể sử dụng thiết bị đó, bất kể khối lượng công việc đang chiếm giữ thực sự tiêu thụ bao nhiêu tài nguyên tính toán hoặc bộ nhớ.

Đây là nguyên nhân phổ biến nhất của mô hình "xếp hàng bên cạnh thiết bị nhàn rỗi" trong các cụm suy luận. Một tập hợp các mô hình, mỗi mô hình giữ một GPU chuyên dụng nhưng chỉ phục vụ các yêu cầu không thường xuyên hoặc tần suất thấp, khiến mọi thiết bị đều bị phân bổ. Một khối lượng công việc mới đến sẽ thấy nvidia.com/gpu: 0 khả dụng trên node và phải chờ đợi, mặc dù tổng hoạt động tính toán trên toàn node có thể dưới 10%.

Device plugin tập trung vào việc phân bổ, không phải thu hồi. Cluster autoscaler của Kubernetes có thể cung cấp các node mới nhưng sẽ không thu hồi dung lượng nhàn rỗi trên các node hiện có. Vấn đề nằm ở lớp lập lịch, và giải pháp đòi hỏi phải thay đổi cách các thiết bị được trình bày cho bộ lập lịch. Đó chính xác là những gì các cơ chế chia sẻ GPU thực hiện.

Bộ nhớ bị chiếm dụng, không chỉ là sử dụng thiếu

Mức sử dụng tính toán thấp không có nghĩa là bộ nhớ khả dụng. Hai kịch bản minh họa cho phạm vi này. Một mô hình 70B tham số được tải ở định dạng FP16 tiêu thụ khoảng 140 GB VRAM (chỉ tính trọng số cơ sở; ở độ dài ngữ cảnh 4K, KV cache thêm 15–20% so với trọng số cơ sở, trong khi ở độ dài ngữ cảnh 128K, các yêu cầu KV cache có thể vượt quá hoàn toàn trọng số cơ sở). Mô hình đó yêu cầu hai hoặc nhiều GPU A100 80GB để có thể tải được. Một mô hình 13B FP16 chiếm khoảng 26 GB và vừa với một GPU A100 80GB duy nhất, nhưng nó vẫn giữ VRAM đó liên tục. Hoạt động tính toán có thể báo cáo 8%, vì hầu hết các yêu cầu hoàn thành nhanh chóng, nhưng thiết bị không thể chấp nhận thêm khối lượng công việc nào khác.

Trước khi cấu hình chia sẻ, hãy kiểm tra xem có áp dụng lượng tử hóa (quantisation) hay không. Một mô hình 7B được lượng tử hóa INT4 chiếm khoảng 4 GB so với khoảng 14 GB ở định dạng FP16, điều này làm thay đổi phép tính đặt chung (co-location) cho các cấu hình time-slicing và MIG. INT8 cắt giảm yêu cầu xuống khoảng một nửa so với FP16, thường với những đánh đổi về chất lượng có thể chấp nhận được đối với các khối lượng công việc suy luận.

Điều này đặc biệt quan trọng đối với các nhóm đang cân nhắc time-slicing (chia sẻ thời gian) như một giải pháp. Time-slicing thực hiện đa nhiệm quyền truy cập vào tài nguyên tính toán, nhưng nó không phân vùng bộ nhớ. Tất cả các bản sao (replicas) đều dùng chung không gian địa chỉ VRAM. Nếu hai khối lượng công việc (workloads) cùng vượt quá bộ nhớ thiết bị, chúng sẽ không thể cùng tồn tại một cách an toàn. Việc chẩn đoán giới hạn bộ nhớ trước khi chọn phương pháp chia sẻ sẽ giúp ngăn ngừa lỗi triển khai và sự mất ổn định tiềm ẩn của khối lượng công việc.

Hãy kiểm tra mức sử dụng bộ nhớ bằng `nvidia-smi` trước khi giả định rằng một phương pháp chia sẻ sẽ hữu ích. Nếu cột bộ nhớ trống (free memory) gần bằng 0 trên các thiết bị liên quan, thì giới hạn nằm ở dung lượng VRAM chứ không phải ở việc lập lịch tính toán. MIG cung cấp các phân vùng bộ nhớ được cô lập ở cấp độ phần cứng có thể giải quyết một số khía cạnh của vấn đề này, nhưng nó đòi hỏi phần cứng tương thích và làm thay đổi cách lập lịch cho các khối lượng công việc.

Các quy tắc đặt vị trí (placement rules) loại trừ phần cứng vốn có thể sử dụng được

Một khối lượng công việc có thể không được lập lịch không phải vì GPU đã được phân bổ hết, mà vì bộ lập lịch không thể tìm thấy node nào đáp ứng đồng thời tất cả các ràng buộc về vị trí. Các quy tắc node affinity chỉ định model hoặc thế hệ GPU, các ràng buộc topology spread yêu cầu số lượng node tối thiểu, và các taints không có tolerations tương ứng đều có thể ngăn cản việc lập lịch ngay cả khi số lượng thiết bị thô trông có vẻ đủ.

Một yêu cầu `nvidia.com/gpu: 1` với node selector yêu cầu A100 sẽ không được đặt vào node chỉ có H100, ngay cả khi các H100 đó đang rảnh rỗi và có khả năng xử lý. Tương tự, một khối lượng công việc yêu cầu nhiều bản sao time-sliced hơn mức mà bất kỳ node đơn lẻ nào cung cấp, mà không phân bổ dàn trải trên các node, có thể thất bại hoàn toàn mặc dù tổng công suất của toàn bộ hệ thống là đủ.

Lệnh chẩn đoán ở đây là `kubectl describe pod <pending-pod>`. Hãy xem phần Events để tìm các lý do như `MatchNodeSelector`, `InsufficientResource`, hoặc `TaintToleration`. Các lỗi về vị trí thường trông giống như tình trạng thiếu hụt công suất, và chúng được giải quyết thông qua cấu hình lập lịch, không phải bằng cách mua thêm phần cứng.

Khối lượng công việc đang chạy đang chờ đợi một thứ khác

Không phải mọi chỉ số tính toán thấp đều báo hiệu vấn đề phân bổ. GPU tính toán ở trạng thái nhàn rỗi trong quá trình tiền xử lý CPU, tải dữ liệu, truyền tải PCIe và các vòng lặp mạng. Một máy chủ suy luận (inference server) LLM đang chờ bước token hóa chậm hoặc chờ lấy KV cache từ bộ nhớ từ xa sẽ hiển thị hoạt động %SM thấp, nhưng GPU đó không khả dụng cho các yêu cầu suy luận của khối lượng công việc khác. Nó bị chặn ở một lớp khác.

Danh mục này khó chẩn đoán nhất nếu chỉ dựa vào các chỉ số GPU. Mức tính toán thấp kéo dài trên một khối lượng công việc đang hoạt động, đã được lập lịch thường chỉ ra một điểm nghẽn bên ngoài GPU. Việc tăng số lượng GPU sẽ không giúp ích gì. Các biện pháp khắc phục bao gồm tăng tài nguyên CPU, điều chỉnh cấu hình batching, cải thiện độ trễ lưu trữ hoặc thiết kế lại đường ống dữ liệu (data pipeline).

Sử dụng `nvidia-smi dmon` hoặc các chỉ số DCGM để quan sát mức sử dụng tính toán theo thời gian. Một khối lượng công việc luân chuyển giữa 0% và mức tính toán cao trong các đợt ngắn thường bị giới hạn bởi CPU trong các khoảng thời gian 0%. Một khối lượng công việc bị kẹt ở mức tính toán thấp liên tục trong khi vẫn đang nhận yêu cầu là do đang chờ I/O hoặc mạng. Cả hai mô hình này đều khác biệt với tình trạng thiếu hụt phân bổ và đòi hỏi các biện pháp khắc phục khác nhau.

Ví dụ về phân bổ GPU trong Kubernetes

Kịch bản dưới đây là giả định và được xây dựng để minh họa vấn đề phân bổ. Nó không đại diện cho hiệu suất đo lường từ bất kỳ cụm (cluster) cụ thể nào.

Hãy xem xét một node có bốn GPU, mỗi GPU được phân bổ độc quyền cho một dịch vụ suy luận. Mỗi dịch vụ xử lý các truy vấn của sinh viên theo đợt, với hoạt động tính toán cao điểm là 15% trong thời gian bận rộn và dưới 3% trong giờ thấp điểm. Một dịch vụ suy luận thứ năm được triển khai và chuyển sang trạng thái Pending. Bộ lập lịch tìm thấy `nvidia.com/gpu: 0` khả dụng trên node và xếp hàng pod đó.

Chuyển sang time-slicing không đảm bảo bất kỳ sự cải thiện thông lượng cụ thể nào. Điều nó thay đổi là tính khả dụng của thiết bị từ góc độ của bộ lập lịch. Mỗi GPU giờ đây quảng bá bốn khe cắm thay vì một. Dịch vụ thứ năm có thể được lập lịch. Việc độ trễ tổng thể cải thiện hay suy giảm phụ thuộc vào tần suất các yêu cầu của dịch vụ chồng chéo lên nhau, dung lượng VRAM mà mỗi model chiếm dụng và liệu có model nào thể hiện hoạt động SM bùng phát gây tranh chấp trong các cửa sổ cao điểm hay không.

Cách duy nhất để biết câu trả lời cho một hỗn hợp khối lượng công việc cụ thể là kiểm tra nó. Các bước chẩn đoán sau đây mô tả cách thực hiện điều đó mà không cần cam kết với một cấu hình có thể gây hại cho độ trễ sản xuất.

So sánh GPU chuyên dụng, time-slicing, MIG và MPS

Có bốn mô hình phân bổ cho khối lượng công việc GPU trong Kubernetes. Mỗi mô hình giải quyết một khía cạnh khác nhau của vấn đề chia sẻ, và mỗi mô hình đều có những ràng buộc xác định liệu nó có phù hợp với một khối lượng công việc nhất định hay không. Không có phương pháp nào là đúng cho mọi trường hợp.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗