Đo lường kết quả AI trước khi mở rộng cụm GPU

Các trưởng nhóm DevOps quản lý khối lượng công việc trí tuệ nhân tạo (AI) trên Kubernetes thường đối mặt với một xung động hấp dẫn nhưng tiềm ẩn rủi ro chi phí: khi hàng đợi batch-job tăng lên, hãy mua thêm đơn vị xử lý đồ họa (GPU). Tuy nhiên, một phân tích gần đây cho thấy việc mở rộng phần cứng hiếm khi là giải pháp đầu tiên hoặc tốt nhất. Trước khi cung cấp thêm năng lực, các đội kỹ thuật phải đo lường nghiêm ngặt xem liệu các tài nguyên hiện tại của họ có thực sự tạo ra kết quả giá trị hay chỉ đơn thuần trông có vẻ bận rộn.

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

Luận điểm cốt lõi tập trung vào sự khác biệt giữa việc phân bổ tài nguyên và giá trị kinh doanh. Một GPU được phân bổ không giống như một GPU đang hoạt động, và một GPU đang hoạt động chưa chắc mang lại kết quả hữu ích. Các đội ngũ được khuyến khích nhìn xa hơn các chỉ số sử dụng đơn giản và thay vào đó, xác định rõ thế nào là thành công cho từng khối lượng công việc cụ thể. Điều này bao gồm việc thiết lập các hạn chót rõ ràng, thời gian chạy dự kiến và ngưỡng chất lượng trước khi cân nhắc bất kỳ sự mở rộng hạ tầng nào.

Ví dụ, một chatbot dịch vụ khách hàng yêu cầu năng lực suy luận (inference) nhất quán, độ trễ thấp suốt 24/7. Ngược lại, một job đánh giá mô hình có thể chỉ cần hoàn thành trước cuộc họp đồng bộ nội bộ. Việc phân loại chung chung các khối lượng công việc thành inference hoặc training không nắm bắt được những sắc thái này. Một số tác vụ batch inference có thể chờ hàng giờ mà không gây ảnh hưởng, trong khi một số job training lại có hạn chót cứng nhắc, không thể thương lượng. Bằng cách ghi chép lại các yêu cầu này, các đội ngũ có thể tách biệt tính linh hoạt về thời gian khởi động khỏi khả năng chịu gián đoạn, cho phép lập lịch hiệu quả hơn mà không cần thêm phần cứng mới.

Chi tiết chính

• Các khối lượng công việc phải được phân loại theo hạn chót và mức độ khẩn cấp chứ không chỉ dựa vào loại kỹ thuật, phân biệt giữa những job có thể chờ và những job không thể.
• Dàn trải thời gian khởi động job có thể giảm đáng kể nhu cầu đỉnh; bốn job mỗi job cần hai GPU có thể chạy trên tổng cộng bốn GPU nếu chúng được khởi động theo cặp thay vì tất cả cùng lúc.
• Hoạt động GPU cao không đảm bảo thông lượng khả dụng, vì các bộ xử lý đa luồng (streaming multiprocessors) có thể nhàn rỗi trong khi chờ các thao tác bộ nhớ.
• Năng lực bền vững nên được đo lường thông qua các bài kiểm tra tải đại diện, giữ nguyên mô hình và phần cứng trong khi tăng tỷ lệ truy cập.
• Chi phí trên mỗi kết quả đã được xác minh là một chỉ số hữu ích hơn so với chi phí hạ tầng thô, kết hợp dữ liệu OpenCost với các kiểm tra chất lượng ở cấp ứng dụng.
• Dung lượng dự phòng có thể là một chi phí chấp nhận được nếu nó đảm bảo độ tin cậy trong các đợt tăng đột biến, miễn là triển khai đáp ứng các yêu cầu chất lượng với mức giá hợp lý.

Bối cảnh

Để hiểu cách tiếp cận này, cần nắm vững cách phục vụ AI hiện đại hoạt động trên Kubernetes. Các công cụ như Kueue đóng vai trò là điểm kiểm soát tiếp nhận (admission control), sử dụng hạn ngạch và chính sách để quyết định khi nào công việc đi vào cụm. Điều này cho phép các đội ngũ thực thi hạn chót và quản lý tài nguyên một cách động. Tuy nhiên, bản thân công cụ không giải quyết được vấn đề lập kế hoạch; các kỹ sư vẫn phải xác định cách biểu diễn các yêu cầu của khối lượng công việc và đảm bảo rằng trình lập lịch tôn trọng chúng.

Ngoài ra, các chỉ số từ các engine phục vụ như vLLM cung cấp cái nhìn sâu sắc về hiệu suất nhưng có thể gây hiểu lầm nếu được diễn giải riêng lẻ. Ví dụ, mức sử dụng KV-cache cho biết lượng bộ nhớ bị chiếm dụng nhưng không trực tiếp chuyển đổi thành năng lực phục vụ. Tương tự, các công cụ profiling của Nvidia có thể hiển thị mức độ hoạt động cao bao gồm các warp đang chờ bộ nhớ, nghĩa là GPU về mặt kỹ thuật đang bận nhưng không tính toán hiệu quả. Năng lực thực sự được xác định bởi tốc độ duy trì cao nhất đáp ứng giới hạn độ trễ và lỗi dưới tải thực tế.

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

Đối với các đội ngũ tự lưu trữ (self-host) phần mềm của mình, chi phí vốn cho phần cứng chuyên dụng như GPU là rất lớn. Mua thêm đơn vị chỉ dựa trên độ dài hàng đợi có thể dẫn đến việc cấp phát quá mức và lãng phí ngân sách. Bằng cách tập trung vào kết quả, các tổ chức có thể xác định những điểm kém hiệu quả trong cấu hình hiện tại. Nếu hàng đợi job tăng do việc gom lô (batching) kém hoặc lựa chọn mô hình không tối ưu, việc thêm GPU sẽ không khắc phục được nguyên nhân gốc rễ. Nó chỉ làm tăng chi phí vận hành một quy trình kém hiệu quả.

Hơn nữa, việc liên kết dữ liệu chi phí với các kết quả đã được xác minh thay đổi cách các đội ngũ đánh giá hiệu quả. Sử dụng các công cụ như OpenCost, các kỹ sư có thể phân bổ chi phí cho các khối lượng công việc cụ thể và sau đó ghép nối dữ liệu đó với telemetry phục vụ. Điều này tiết lộ chi phí thực tế cho mỗi kết quả đúng. Một mô hình rẻ tiền nhưng không đáp ứng tiêu chuẩn chất lượng sẽ đắt đỏ hơn về lâu dài so với một mô hình đắt hơn nhưng mang lại kết quả đáng tin cậy. Góc nhìn này chuyển cuộc thảo luận từ tối ưu hóa hạ tầng thuần túy sang tối ưu hóa giá trị kinh doanh.

Cuối cùng, phương pháp này hỗ trợ ra quyết định tốt hơn khi so sánh các cấu hình khác nhau. Nếu một GPU nhỏ hơn hoặc ít bản sao hơn có thể tạo ra cùng số lượng kết quả đạt yêu cầu với chi phí thấp hơn, thì khoản tiết kiệm đó là thực tế. Tăng mức sử dụng trên một GPU lớn hiện có mà không cải thiện kết quả không mang lại giá trị tương đương. Mục tiêu là một triển khai cung cấp các kết quả yêu cầu với chi phí hợp lý, đủ dư địa để xử lý các sự cố và đợt tăng đột biến.

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

• Ghi chép hạn chót, thời gian chạy và khả năng chịu gián đoạn cho mọi khối lượng công việc AI trong cụm của bạn để phân biệt các job linh hoạt với các job quan trọng.
• Triển khai lập lịch dàn trải cho các batch job để làm phẳng nhu cầu đỉnh, sử dụng các công cụ như Kueue để thực thi chính sách tiếp nhận.
• Thực hiện các bài kiểm tra tải với cài đặt mô hình và phần cứng không đổi để tìm thông lượng bền vững tối đa đáp ứng mục tiêu độ trễ và lỗi của bạn.
• Tích hợp dữ liệu OpenCost với nhật ký ứng dụng để tính chi phí trên mỗi kết quả đã được xác minh, đảm bảo bạn tính cả các lần thử lại và thời gian nhàn rỗi.
• Xem xét cấu hình phục vụ của bạn để đảm bảo hoạt động GPU cao tương quan với thông lượng thực tế, kiểm tra các nút thắt cổ chai bộ nhớ hoặc sự kém hiệu quả của cache.
• So sánh các mô hình và kích thước phần cứng thay thế dựa trên chi phí trên mỗi kết quả đúng, không chỉ dựa vào chi phí hạ tầng thô, để xác định các cơ hội tiết kiệm thực sự.