GPU trên Kubernetes buộc đội vận hành tự xây lại nhiều lớp quan sát, phân bổ và kiểm soát vốn có sẵn cho CPU và bộ nhớ. Theo bài phân tích của The New Stack, các chỉ số GPU có thể sai khi nhiều pod dùng chung thiết bị, còn dữ liệu hiện có chưa đủ để chia chính xác năng lực tính toán và chi phí cho từng khối lượng công việc.
Với CPU và bộ nhớ, đội vận hành thường có thể dùng bảng điều khiển Grafana để đối chiếu lượng tài nguyên một bộ chứa yêu cầu với mức sử dụng thực tế. Tách dữ liệu theo không gian tên còn giúp ước lượng từng đội đang dùng bao nhiêu tài nguyên. GPU làm mất hiệu lực của phần lớn giả định đó, trong khi thường là khoản đắt nhất trên hóa đơn hạ tầng.
Vấn đề này đặc biệt đáng chú ý với các doanh nghiệp trong nước đang xây dựng hạ tầng AI. Đưa mô hình lên Kubernetes không chỉ đòi hỏi phần cứng tăng tốc. Cách đo, phân bổ và kiểm soát tài nguyên cũng phải thay đổi.
Tự xây hệ thống chỉ số
Kubernetes không cung cấp sẵn cho GPU mức quan sát theo từng bộ chứa tương đương CPU và bộ nhớ. Khi nhiều pod chia sẻ một thiết bị, công cụ giám sát có thể tạo ra số liệu nhất quán về hình thức nhưng không phản ánh đúng mức sử dụng của từng pod.
Nhân hệ điều hành đã theo dõi mức dùng CPU và bộ nhớ theo từng bộ chứa, nên việc lấy số liệu cho từng pod tương đối thuận tiện. Công cụ thường được dùng đầu tiên với GPU là trình xuất dữ liệu DCGM của NVIDIA. Theo The New Stack, công cụ này mặc định báo cáo ở cấp thiết bị vật lý.
Cách báo cáo đó hoạt động khi một pod dùng riêng một GPU, nhưng tạo ra số liệu sai khi nhiều pod chia sẻ cùng thiết bị bằng chia lát thời gian hoặc MPS. Nếu ba pod cùng chia sẻ một GPU, DCGM có thể gán cùng một giá trị cho cả ba. Khi cộng lại, bảng điều khiển sẽ hiển thị mức sử dụng 300% cho một GPU không hề tồn tại.
Nguyên nhân là trình điều khiển chỉ công bố một tập bộ đếm cho toàn bộ GPU, nên DCGM không có dữ liệu riêng để xác định pod nào đã dùng bao nhiêu. Những con số này vẫn có thể tạo thành biểu đồ đẹp và nhất quán. Sai lệch vì thế dễ lọt qua khâu kiểm tra trước khi được dùng để lập báo cáo hoặc phân bổ chi phí.
Tự tính lại kích thước tài nguyên
Kubernetes lập lịch GPU như một tài nguyên số nguyên, không giống cơ chế cấp phát linh hoạt của CPU. Trước khi tính phần tài nguyên lãng phí, đội vận hành phải xác định mỗi khối lượng công việc thực sự nhận được bao nhiêu năng lực từ GPU vật lý.
Với CPU, Kubernetes hỗ trợ đơn vị phần nghìn lõi, cấp phát vượt mức và khả năng tăng tải tạm thời. Giới hạn CPU dẫn đến điều tiết tốc độ, còn vượt giới hạn bộ nhớ có thể khiến tiến trình bị chấm dứt vì cạn bộ nhớ.
GPU không đi theo mô hình đó. Kubernetes nhìn GPU như một tài nguyên số nguyên, chẳng hạn nvidia.com/gpu: 1. Khối lượng công việc yêu cầu GPU nguyên chiếc, giá trị yêu cầu phải khớp với giới hạn và bộ lập lịch không cấp phát vượt mức.
Việc chia nhỏ phục vụ suy luận diễn ra bên dưới bộ lập lịch, thông qua chia lát thời gian hoặc MIG. Vì vậy, phép so sánh quen thuộc giữa lượng tài nguyên yêu cầu và lượng thực dùng gần như không còn ý nghĩa khi mới triển khai.
Tự dựng hàng rào kiểm soát
Bản ghi cấp phát của Kubernetes chưa đủ để chứng minh pod nào đang sử dụng GPU nào. Đội kỹ thuật phải đối chiếu quyết định của bộ lập lịch với hoạt động ở cấp tiến trình để phát hiện trường hợp một pod nhìn thấy hoặc chiếm nhiều thiết bị hơn phần được cấp.
Môi trường chạy bộ chứa của NVIDIA đọc biến NVIDIA_VISIBLE_DEVICES. Các ảnh bộ chứa CUDA nền đặt biến này thành giá trị cho phép nhìn thấy tất cả thiết bị. Trong cấu hình thông thường, phần bổ trợ thiết bị sẽ ghi đè giá trị đó và chỉ đưa vào những GPU đã được cấp cho pod.
Nếu không có thành phần ghi đè, hoặc môi trường chạy được cấu hình để tôn trọng biến do bộ chứa cung cấp, một pod có thể nhìn thấy và chiếm mọi GPU trên máy. Khi đó, bản ghi của bộ lập lịch và hoạt động thực tế trên phần cứng có thể khác nhau đáng kể.
Muốn biết tài nguyên thực sự được dùng thế nào, đội kỹ thuật phải quan sát đến cấp tiến trình rồi đối chiếu dữ liệu đó với quyết định cấp phát của Kubernetes. Đây cũng là một lớp kiểm soát cần cân nhắc khi triển khai AI tác tử trên Kubernetes.
Tự định nghĩa mức sử dụng GPU
Tỷ lệ sử dụng GPU không trực tiếp cho biết bao nhiêu năng lực tính toán hoặc băng thông bộ nhớ đã được tiêu thụ. Mỗi đội phải chọn tín hiệu phù hợp với khối lượng công việc thay vì dựa vào một tỷ lệ sử dụng tổng hợp.
Khi biểu đồ CPU hiển thị 80%, người vận hành thường hiểu khá rõ con số đang phản ánh điều gì. Theo The New Stack, chỉ số GPU phổ biến chỉ cho biết một nhân tính toán đã chạy trên GPU trong một phần của khoảng thời gian lấy mẫu. Nó không đo trực tiếp khối lượng tính toán hoặc lượng băng thông bộ nhớ đã tiêu thụ.
Vì vậy, GPU có thể hiển thị mức sử dụng 100% trong khi chỉ khai thác một phần nhỏ năng lực tính toán. Bộ nhớ cũng có thể cạn trước năng lực tính toán. Các khung phần mềm như vLLM thường chiếm phần lớn bộ nhớ GPU ngay khi khởi động, dù chưa chắc dùng hết.
Tín hiệu phù hợp có thể là mức chiếm dụng tính toán, dung lượng bộ nhớ, băng thông hoặc công suất điện. Lựa chọn phụ thuộc vào đặc điểm của khối lượng công việc. Chỉ nhìn vào tỷ lệ sử dụng tổng hợp dễ dẫn đến kết luận sai.
Tự xác định tài nguyên thuộc về ai
Bộ nhớ GPU có thể được quy về từng tiến trình, pod và nhóm sở hữu tương đối đáng tin cậy. Việc phân bổ năng lực tính toán khó hơn vì các bộ đếm hiện có không xác định chính xác tỷ lệ công việc khi nhiều tiến trình chạy song song trên cùng GPU.
Thư viện NVML của NVIDIA có thể cho biết mỗi tiến trình đang giữ bao nhiêu bộ nhớ trên GPU. Từ tiến trình, đội vận hành có thể truy ngược về pod và nhóm sở hữu. Tổng dung lượng của các tiến trình sẽ không bằng toàn bộ dung lượng trên thẻ vì trình điều khiển giữ lại một phần bộ nhớ cho chính nó.
Có thể hình dung bộ nhớ như mặt bàn trong một bếp dùng chung. Người quan sát thấy được nguyên liệu của từng người đang nằm ở đâu. Năng lực tính toán giống như bếp nấu mà mọi người thay phiên sử dụng trong các đợt kéo dài vài mili giây.
Nội dung dữ liệu dùng để phân bổ tài nguyên
Dữ liệu NVIDIA cung cấp không trả lời mỗi tiến trình đã dùng năng lực tính toán trong bao lâu. Nó gần với một cờ trạng thái được kiểm tra nhiều lần mỗi giây để xem tiến trình có đang hoạt động hay không. Nếu hai tiến trình cùng chạy, cả hai có thể đều hiện mức bận 90%. Con số này có thể đúng nhưng không cho biết tiến trình nào hoàn thành nhiều việc hơn.
Theo The New Stack, cách lấy mẫu ở cấp mã tiến trình bằng chế độ hạch toán của DCGM hoặc nvidia-smi chỉ có thể ước lượng tỷ trọng khi GPU lần lượt phục vụ từng tác vụ. Phương pháp này không còn đáng tin cậy khi nhiều tác vụ thực sự chạy song song, dù đây là cấu hình thường được chọn để cải thiện mức sử dụng. Nếu hai đội chia sẻ một GPU, công cụ hiện có không thể xác định chính xác đội nào dùng 70% và đội nào dùng 30%.
Lựa chọn thực tế là phân bổ chi phí dựa trên bộ nhớ vì dữ liệu này ổn định hơn, còn năng lực tính toán được dùng như tín hiệu hỗ trợ. Khi doanh nghiệp chuyển từ việc chỉ hiển thị chi phí sang thu hồi chi phí theo từng đội, độ chính xác trở thành điều kiện để duy trì sự công bằng.
Mỗi kiểu chia sẻ tạo ra một phép tính khác
Chia lát thời gian, MPS và MIG tạo ra các mô hình cách ly và cấp phát khác nhau. Hệ thống quan sát phải biết từng nút đang dùng cơ chế nào trước khi diễn giải số liệu hoặc phân bổ chi phí.
- Chia lát thời gian luân phiên cấp GPU cho các tác vụ, không tạo vùng cách ly và cho phép đăng ký vượt mức.
- MPS cho phép nhân tính toán từ nhiều tiến trình chạy đồng thời.
- MIG chia GPU thành các phân vùng phần cứng cố định.
The New Stack lưu ý rằng phần lớn nhà cung cấp đám mây vẫn tính phí toàn bộ GPU vật lý ngay cả khi khách hàng chỉ dùng một phân vùng MIG. Với GPU thuộc dòng A100 hoặc H100, thiết bị có thể được chia thành tối đa 7 phiên bản.
DRA, cơ chế phân bổ tài nguyên động, đã dần hoàn thiện qua các phiên bản Kubernetes gần đây. Tuy nhiên, hệ sinh thái liên quan, bao gồm những công cụ tự động điều chỉnh quy mô như Karpenter, vẫn đang bắt kịp. Mỗi phương thức chia sẻ làm thay đổi ý nghĩa của tài nguyên đã cấp, nên không thể áp dụng một phép tính chung cho mọi nút.
Tự đặt quy tắc chia hóa đơn
Để tính chi phí GPU cho từng khối lượng công việc, doanh nghiệp phải tách giá trị GPU khỏi chi phí gộp của nút rồi chọn quy tắc phân bổ cho các tác vụ dùng chung. Sai số trong bước này ảnh hưởng trực tiếp đến ngân sách sản phẩm và chi phí của từng đội.
Nhà cung cấp đám mây thường tính một nút GPU thành một dòng chi phí gộp CPU, bộ nhớ và GPU. Doanh nghiệp phải xác định giá trị phần GPU theo từng mẫu thiết bị rồi chia tiếp cho các tác vụ cùng sử dụng.
Theo số liệu AWS được The New Stack dẫn lại, lựa chọn A100 tương thích MIG rẻ nhất có giá 22 USD mỗi giờ, hoặc khoảng 14 USD mỗi giờ với phiên bản giá linh hoạt theo dung lượng thừa. Một máy tương đương nhưng chỉ có CPU có giá khoảng 5 USD mỗi giờ. Ngay cả khi dùng mức giá linh hoạt, chênh lệch vẫn lớn.
Sai số trong phép phân bổ vì thế không còn là vấn đề riêng của bảng điều khiển. Nó tác động đến ngân sách sản phẩm, chi phí của từng đội và quyết định có tiếp tục chạy một khối lượng công việc hay không.
Chi phí thật còn nằm ở công sức kỹ thuật
Chi phí GPU trên Kubernetes gồm cả hóa đơn hạ tầng và thời gian kỹ thuật để xây hệ thống quan sát, kiểm soát và phân bổ nội bộ. Đội nền tảng phải quyết định phần nào cần tự xây ngay và phần nào có thể chờ hệ sinh thái hoàn thiện.
Doanh nghiệp phải duy trì chỉ số, mức chính xác kỳ vọng, hàng rào kiểm soát, cách quy trách nhiệm và quy tắc chia chi phí. Đây là những lớp từng có sẵn hoặc tương đối dễ triển khai với CPU và bộ nhớ.
DRA đang trưởng thành, phân vùng phần cứng dần dễ triển khai hơn và khoảng trống công cụ thu hẹp theo từng phiên bản. Tuy vậy, cẩm nang dành cho CPU và bộ nhớ không thể được chuyển nguyên vẹn sang GPU.
Trước khi mở rộng cụm GPU, đội vận hành cần xác định dữ liệu nào đủ tin cậy để đo mức dùng, kiểm tra quyền truy cập và chia chi phí cho từng khối lượng công việc.
