Kubernetes phát triển để khắc phục tình trạng GPU nhàn rỗi và khoảng trống trong giám sát AI

Hệ sinh thái cloud-native đang nhanh chóng thích ứng với những yêu cầu đặc thù của các khối lượng công việc trí tuệ nhân tạo quy mô lớn. Khi các doanh nghiệp triển khai nhiều hơn các dịch vụ AI agentic và suy luận trên Kubernetes, họ phải đối mặt với những nút thắt cổ chai nghiêm trọng về hiệu quả sử dụng tài nguyên, xử lý sự cố và khả năng quan sát (observability). Những diễn biến gần đây cho thấy xu hướng tích hợp chặt chẽ hơn giữa cơ chế lập lịch và tự động co giãn, sự trưởng thành của nền tảng phục vụ suy luận mã nguồn mở, cùng các chiến lược mới để chẩn đoán những lỗi phức tạp trong cụm.

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

Hewlett Packard Enterprise (HPE) đã xác định một rào cản vận hành đáng kể đối với khách hàng sử dụng HPE Private Cloud AI: tình trạng khởi động lại pod thường xuyên trong môi trường container tạm thời (ephemeral). Guoping Jia, kỹ sư phần mềm hệ thống tại HPE, lưu ý rằng mặc dù Kubernetes cung cấp các lệnh khắc phục sự cố cơ bản, nhưng việc điều tra thủ công không thể mở rộng quy mô trong các cụm lớn. Để giải quyết vấn đề này, HPE đang quảng bá một công cụ mã nguồn mở tên là k8s-pod-restart-info-collector, giúp tự động thu thập dữ liệu chẩn đoán và gửi đến các kênh Slack, giảm bớt gánh nặng thủ công cho các nhà vận hành.

Đồng thời, các kỹ sư AWS Sajjan Gundapuneedi và Neelendra Bhandari đã chỉ ra một xung đột cấu trúc trong Kubernetes giữa trình lập lịch (scheduler) và trình tự động co giãn (autoscaler). Trình lập lịch đặt các pod lên các node hiện có, trong khi trình tự động co giãn cung cấp các node mới. Khi quản lý các bộ tăng tốc GPU khan hiếm, hai thành phần này thường không phối hợp được với nhau, khiến phần cứng đắt đỏ bị nhàn rỗi trong khi các pod vẫn chờ ở trạng thái pending. Sự lệch pha này đặc biệt gây rắc rối cho các khối lượng công việc suy luận bùng nổ (bursty inference) và agentic, vốn không thể chịu đựng độ trễ của việc cung cấp node lạnh (cold node provisioning).

Trong lĩnh vực phục vụ suy luận, dự án sandbox CNCF llm-d đã đạt phiên bản 1.0 tại Hội nghị PyTorch North America. Carlos Costa, người bảo trì chính và là kỹ sư xuất sắc của IBM, mô tả bản phát hành này là bước chuyển giao từ mã thử nghiệm sang hạ tầng sản xuất đáng tin cậy. Dự án đã được áp dụng tại các hãng công nghệ lớn bao gồm Tesla, AWS, Oracle và Google. IBM Research đã chứng minh rằng việc sử dụng llm-d cho các khối lượng công việc agentic giúp giảm chi phí suy luận xuống gấp 11,5 lần so với các cấu hình độc quyền, đạt tỷ lệ tái sử dụng cache khoảng 98%.

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

Thách thức kỹ thuật cốt lõi trong quản lý GPU nằm ở sự ngắt kết nối giữa việc bố trí (placement) và cung cấp (provisioning). Trình lập lịch quyết định nơi một pod sẽ chạy dựa trên năng lực hiện tại, nhưng nó thiếu tầm nhìn vào năng lực tương lai mà trình tự động co giãn có thể cung cấp. Ngược lại, trình tự động co giãn thêm các node dựa trên tổng yêu cầu tài nguyên nhưng không hiểu rõ các ràng buộc bố trí cụ thể hoặc cấu trúc liên kết thiết bị (device topology). Các đề xuất mới trong nhóm SIG-Autoscaling gợi ý tạo ra các API cho phép hai vòng lặp này giao tiếp trực tiếp. Điều này sẽ cho phép trình lập lịch bày tỏ các ưu tiên bố trí cho năng lực chưa được cung cấp, giúp trình tự động co giãn hoạt động như một đối tác nhận biết được trình lập lịch.

Đối với phục vụ suy luận, llm-d lấp đầy khoảng cách giữa các nhà phát triển ứng dụng PyTorch và các stack sản xuất cloud-native. Khác với các phiên bản trước chỉ tập trung vào benchmark hiệu suất thô, v1.0 nhấn mạnh vào hiệu suất bền vững và tính ổn định. Nó xử lý các mẫu lưu lượng bùng nổ điển hình của AI agentic bằng cách tối ưu hóa việc tái sử dụng cache và phân phối các tác vụ suy luận một cách hiệu quả trong toàn bộ cụm. Cách tiếp cận này cho phép các tổ chức chạy các mô hình mở với chi phí thấp hơn đáng kể so với các giải pháp thay thế hoàn toàn độc quyền.

Các khoảng trống về khả năng quan sát đang được giải quyết thông qua việc cung cấp ngữ cảnh tốt hơn cho các tác nhân AI. Roy Libman của Radar (Skyhook.io) đã chứng minh rằng các tác nhân lập trình AI như Claude Code có thể chẩn đoán lỗi Kubernetes chính xác hơn khi được cung cấp ngữ cảnh chỉ đọc thông qua các công cụ Model Context Protocol (MCP). Trong các bài kiểm tra liên quan đến 50 lỗi được chèn vào, tác nhân đã đưa ra chẩn đoán đúng trong vòng hai phút cho 86% trường hợp khi được cung cấp ngữ cảnh, so với chỉ 60% khi chỉ dựa vào quyền truy cập shell. Điều này cho thấy việc cung cấp ngữ cảnh có cấu trúc hiệu quả hơn so với việc cấp quyền truy cập dòng lệnh rộng rãi.

Chi tiết chính

• Công cụ k8s-pod-restart-info-collector của HPE tự động hóa việc thu thập thông tin chẩn đoán cho các lần khởi động lại pod, gửi dữ liệu trực tiếp đến Slack để hỗ trợ khắc phục sự cố trong các cụm lớn.
• Các kỹ sư AWS đề xuất tích hợp sâu hơn giữa trình lập lịch và trình tự động co giãn của Kubernetes để ngăn chặn tình trạng GPU nhàn rỗi do lỗi phối hợp.
• llm-d v1.0 được phát hành dưới dạng dự án sandbox CNCF, tập trung vào tính ổn định cấp độ sản xuất cho suy luận AI phân tán.
• IBM Research phát hiện ra rằng llm-d đã giảm chi phí suy luận xuống 11,5 lần cho các khối lượng công việc agentic so với các thiết lập độc quyền, với tỷ lệ tái sử dụng cache 98%.
• Các tác nhân lập trình AI chẩn đoán đúng 86% lỗi Kubernetes trong vòng hai phút khi được cung cấp ngữ cảnh phù hợp qua các công cụ MCP, vượt trội hơn so với chẩn đoán dựa trên shell.
• Kristiyan Ivanov lưu ý rằng các chỉ số đơn thuần không nắm bắt được các thay đổi trạng thái như cập nhật ACL hoặc mục slowlog, những thứ bị mất giữa các lần quét Prometheus trong môi trường tạm thời.

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

Đối với các kỹ sư phần mềm và lãnh đạo hạ tầng, sự kém hiệu quả trong việc sử dụng GPU đại diện cho tổn thất tài chính trực tiếp. Khi các trình lập lịch và trình tự động co giãn hoạt động trong các silo riêng biệt, các tổ chức trả tiền cho phần cứng tăng tốc nằm không trong khi các công việc xếp hàng chờ đợi. Các đề xuất tích hợp API hứa hẹn giải quyết vấn đề này bằng cách đảm bảo các quyết định cung cấp phù hợp với nhu cầu lập lịch, giảm lãng phí và cải thiện khả năng phản hồi của các dịch vụ AI. Điều này rất quan trọng khi các khối lượng công việc agentic trở nên phổ biến hơn, đòi hỏi các hệ thống có thể mở rộng và thu hẹp nhanh chóng mà không cần can thiệp thủ công.

Khả năng quan sát vẫn là điểm mù đối với nhiều đội ngũ vận hành AI ở quy mô lớn. Các công cụ giám sát truyền thống dựa vào các chỉ số chuỗi thời gian, bỏ sót các thay đổi trạng thái thoáng qua như cập nhật cấu hình hoặc sửa đổi kiểm soát truy cập. Khi các tác nhân AI tạo ra lưu lượng bùng nổ và thực hiện các hành động tự chủ, việc thiếu lịch sử bền vững và dấu vết kiểm toán khiến việc phân tích nguyên nhân gốc rễ trở nên khó khăn. Các kỹ sư giờ đây phải cân nhắc cách cung cấp ngữ cảnh phong phú cho cả nhà vận hành con người và trợ lý AI để duy trì độ tin cậy của hệ thống.

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

• Đánh giá công cụ k8s-pod-restart-info-collector nếu đội ngũ của bạn gặp khó khăn trong việc khắc phục sự cố thủ công các lần khởi động lại pod trong các cụm Kubernetes lớn.
• Xem xét các đề xuất của SIG-Autoscaling về tích hợp trình lập lịch-trình tự động co giãn để hiểu rõ những thay đổi sắp tới trong các API cung cấp tài nguyên.
• Cân nhắc thử nghiệm llm-d v1.0 cho các khối lượng công việc suy luận phân tán, đặc biệt nếu bạn đang chạy các dịch vụ AI agentic với mẫu lưu lượng bùng nổ.
• Triển khai các công cụ Model Context Protocol (MCP) để cung cấp ngữ cảnh chỉ đọc cho các tác nhân lập trình AI, cải thiện khả năng chẩn đoán các vấn đề của cụm.
• Kiểm toán stack quan sát của bạn để xác định các khoảng trống trong việc theo dõi các thay đổi trạng thái phi chỉ số, chẳng hạn như cập nhật ACL hoặc sửa đổi cấu hình.
• Khám phá phương pháp đo lường eBPF và các phương pháp thu thập cấp độ engine để nắm bắt dữ liệu tracing chi tiết mà các trình quét truyền thống bỏ sót.