Trước khi mở rộng cụm GPU, đội vận hành cần đo kết quả, thời hạn và năng lực phục vụ đã kiểm chứng. Chi phí trên mỗi kết quả đạt yêu cầu cũng cần được tính. Một cụm GPU được phân bổ hết hoặc có hàng đợi dài chưa chứng minh rằng hệ thống thiếu phần cứng. Nguyên nhân có thể nằm ở lịch chạy, cấu hình phục vụ, mô hình hoặc cách phân bổ tài nguyên.
Theo phân tích của The New Stack, GPU đã được phân bổ, GPU đang hoạt động và khối lượng công việc tạo ra giá trị là ba trạng thái khác nhau. Bài viết cũng đưa ra ví dụ về bốn tác vụ cần tổng cộng tám giờ GPU. Các tác vụ vẫn có thể hoàn thành bằng bốn GPU nếu được chạy thành hai đợt liên tiếp.
Phân biệt ba trạng thái này là yêu cầu cơ bản khi xây dựng hạ tầng trí tuệ nhân tạo. Tỷ lệ sử dụng tài nguyên chỉ có ý nghĩa khi được đặt cạnh chất lượng đầu ra, độ trễ, thời hạn và chi phí.
nội dung cần đo trước khi mở rộng cụm GPU
Mỗi khối lượng công việc cần có kết quả mục tiêu, thời hạn hoàn thành, thời gian chạy dự kiến, yêu cầu tài nguyên và mức chấp nhận gián đoạn. Các thông tin này cho biết công việc nào phải chạy ngay, công việc nào có thể chờ và liệu hàng đợi hiện tại có thực sự đòi hỏi thêm GPU hay không.
Một chatbot chăm sóc khách hàng có thể cần năng lực suy luận liên tục, trong khi kết quả đánh giá mô hình chỉ cần sẵn sàng trước buổi đồng bộ cho đợt phát hành nội bộ tiếp theo. Vì vậy, nhãn suy luận hoặc huấn luyện không đủ để xác định mức độ khẩn cấp. Một tác vụ suy luận theo lô có thể chờ, còn một tác vụ huấn luyện lại có thể mang thời hạn cố định.
Đội ngũ cũng phải định nghĩa thế nào là đầu ra có giá trị. Với dịch vụ suy luận, định nghĩa này nên gồm ngưỡng chất lượng theo nhiệm vụ và mục tiêu độ trễ. Một yêu cầu đã hoàn tất hoặc một phản hồi có cấu trúc hợp lệ chưa chứng minh rằng hệ thống đạt mục tiêu.
Khả năng trì hoãn thời điểm bắt đầu và khả năng chịu gián đoạn cần được ghi nhận riêng. Một tác vụ có thể chờ trước khi chạy nhưng vẫn cần hoạt động liên tục sau khi đã bắt đầu.
Tận dụng khả năng sắp lịch trước khi mở rộng
Giảm nhu cầu GPU vào giờ cao điểm
Sắp lịch theo thời hạn có thể giảm nhu cầu GPU tại thời điểm cao nhất mà không làm thay đổi tổng lượng tính toán. Nếu các tác vụ không phải bắt đầu cùng lúc, đội vận hành có thể dùng năng lực hiện có theo nhiều đợt. Cách này tránh bổ sung phần cứng chỉ để xử lý một đỉnh tải ngắn.
The New Stack đưa ra một ví dụ với bốn GPU tương thích, có thể dùng cho công việc theo lô từ 12 giờ đến 17 giờ. Bốn tác vụ đánh giá độc lập sẵn sàng lúc 12 giờ. Mỗi tác vụ cần hai GPU trong một giờ và toàn bộ kết quả phải hoàn thành trước 17 giờ.
Nếu khởi chạy cả bốn tác vụ ngay lập tức, hệ thống cần tám GPU. Nếu chạy hai tác vụ lúc 12 giờ và hai tác vụ còn lại lúc 13 giờ, cả bốn sẽ hoàn thành trước 14 giờ bằng bốn GPU sẵn có. Theo phép tính trong bài gốc, hai lịch chạy đều tiêu thụ tám giờ GPU khi chưa tính chi phí khởi động.
Việc chạy lệch giờ làm giảm nhu cầu đỉnh mà không làm lỡ thời hạn. Trước khi bổ sung GPU để xử lý hàng đợi, đội vận hành cần kiểm tra mức linh hoạt của thời điểm bắt đầu và thời hạn hoàn thành.
Kiểm soát thời điểm tiếp nhận công việc
Kueue cung cấp điểm kiểm soát tiếp nhận công việc dựa trên hạn mức và chính sách đã cấu hình. Công cụ này không tự quyết định thời hạn hoặc yêu cầu của từng tác vụ. Đội ngũ vẫn phải biểu diễn và thực thi các điều kiện đó. Hàng đợi linh hoạt hỗ trợ hoạch định năng lực. Nó cũng giúp tránh khởi chạy sớm rồi phải tạm dừng tác vụ.
Đo lượng công việc hữu ích mà hệ thống duy trì được
Đo năng lực bằng tải đại diện
Năng lực phục vụ hữu ích là mức tải cao nhất mà hệ thống có thể duy trì trong khi vẫn đáp ứng yêu cầu về chất lượng, lỗi và độ trễ. Chỉ số hoạt động GPU không thể tự xác định mức năng lực này. Đội ngũ cần thử tải với mô hình, phần cứng, cấu hình phục vụ và cơ cấu yêu cầu đại diện.
Theo tài liệu đo lường của Nvidia, hoạt động của bộ đa xử lý luồng có thể bao gồm cả các warp đang chờ truy cập bộ nhớ. Vì vậy, mức hoạt động GPU cao không cho biết hệ thống còn bao nhiêu thông lượng.
Số yêu cầu đang chạy, số yêu cầu đang chờ, mức sử dụng bộ nhớ đệm và số lần tạm dừng cung cấp thêm bối cảnh. Tuy nhiên, không chỉ số riêng lẻ nào chứng minh được năng lực phục vụ tổng thể.
Xác định mức tải bền vững
Để đo năng lực hữu ích, hãy giữ nguyên mô hình, phần cứng, thiết lập phục vụ và cơ cấu yêu cầu. Sau đó, tăng dần tốc độ yêu cầu đến và quan sát thông lượng, chất lượng cùng độ trễ. Mức tải bền vững phải đáp ứng giới hạn lỗi và các phân vị độ trễ đã chọn. Đây là cơ sở để ước tính năng lực phục vụ.
Với tác vụ sinh nội dung có tương tác, phép đo cần bao gồm thời gian đến token đầu tiên và tốc độ cung cấp các token tiếp theo. Không nên chỉ dùng thời gian hoàn thành trung bình. Sau đó, đội ngũ có thể so sánh lưu lượng sản xuất với năng lực đã kiểm chứng.
Hàng đợi ngắn có thể phản ánh một đợt tăng tải tạm thời. Hàng đợi kéo dài là dấu hiệu cần chẩn đoán, nhưng chưa xác định được tài nguyên nào đang giới hạn hệ thống.
Gắn dữ liệu chi phí với kết quả đã kiểm chứng
Tính chi phí trên mỗi kết quả đạt yêu cầu
Chi phí hạ tầng nên được tính trên mỗi kết quả đáp ứng yêu cầu chất lượng và được giao đúng thời hạn. Phép tính cần bao gồm GPU, CPU, bộ nhớ, thời gian khởi động và các lần thử lại. Tài nguyên nhàn rỗi có liên quan cũng phải được tính, thay vì chỉ theo dõi chi phí GPU hoặc tỷ lệ sử dụng.
Với các hệ thống như tác tử trí tuệ nhân tạo trên Kubernetes, đội vận hành có thể kết hợp chi phí khối lượng công việc, dữ liệu phục vụ và kết quả ứng dụng bằng định danh công việc cùng dấu thời gian.
Ghép chi phí với hồ sơ kết quả
The New Stack đề xuất dùng dữ liệu phân bổ của OpenCost theo từng khoảng thời gian. Dữ liệu này được ghép với dữ liệu đo lường và hồ sơ kết quả. Chi phí trên mỗi kết quả cần bao gồm GPU, CPU, bộ nhớ và hạ tầng liên quan. Cách phân bổ chi phí dùng chung và chi phí nhàn rỗi phải được ghi rõ. Những khoản chi bên ngoài OpenCost có thể được bổ sung riêng nhưng không được tính hai lần.
Chi phí trên mỗi kết quả đã kiểm chứng bằng tổng chi phí có thể quy thuộc chia cho số kết quả đạt yêu cầu. Các kết quả đó phải đáp ứng ngưỡng chất lượng và được giao đúng thời hạn. Những lần thử lại, lỗi, thời gian khởi động và khoảng nhàn rỗi cần được tính nếu chúng góp phần vào tổng chi phí. Kết quả kinh doanh cuối cùng chỉ được đếm một lần.
Nếu độ chính xác được ước tính bằng cách đánh giá mẫu, phương pháp lấy mẫu và mức độ không chắc chắn cũng phải được ghi lại. OpenCost cung cấp dữ liệu phân bổ chi phí, còn ứng dụng cung cấp định nghĩa kết quả và bằng chứng đánh giá. Năng lực phục vụ vẫn cần một phép đo riêng.
Kiểm tra liệu năng lực dự phòng có xứng đáng với chi phí
Năng lực dự phòng có thể là một khoản chi hợp lý nếu nó giúp hệ thống duy trì chất lượng, đáp ứng thời hạn và hấp thụ các đợt tăng tải. Việc đánh giá cần dựa trên chi phí cho mỗi kết quả đạt yêu cầu, không dựa riêng vào tỷ lệ sử dụng GPU.
So sánh chi phí sau khi đạt ngưỡng chất lượng
Theo ví dụ của The New Stack, dịch vụ nhận 1.000 tác vụ mỗi giờ và yêu cầu độ chính xác 98%. Cũng theo The New Stack, mô hình nhỏ chỉ đạt 90% nên không phù hợp, ngay cả khi GPU rẻ và luôn hoạt động hết công suất.
Trong ví dụ này, một mô hình mạnh hơn có thể tạo ra 990 kết quả đúng và đúng hạn với chi phí 2 đô la Mỹ mỗi giờ, dù chỉ sử dụng một phần năng lực phục vụ đã được kiểm thử. Theo phép tính của The New Stack, chi phí tương ứng khoảng 2,02 đô la Mỹ cho mỗi 1.000 kết quả đạt yêu cầu. Phần năng lực còn trống có thể là mức giá chấp nhận được để duy trì chất lượng và hấp thụ các đợt tăng tải.
Thử cấu hình ít tài nguyên hơn
Bước tiếp theo là thử một GPU nhỏ hơn, giảm số bản sao hoặc thay đổi cách gom lô mà vẫn giữ nguyên kết quả và độ tin cậy. Theo ví dụ của The New Stack, cấu hình đã kiểm thử vẫn tạo ra 990 kết quả đạt yêu cầu với chi phí 1,50 đô la Mỹ. Chi phí khi đó giảm xuống khoảng 1,52 đô la Mỹ cho mỗi 1.000 kết quả đạt yêu cầu.
Khoản tiết kiệm đến từ việc dùng ít tài nguyên hơn để tạo ra cùng một kết quả. Chỉ tăng tỷ lệ sử dụng trên GPU ban đầu mà không cải thiện kết quả sẽ không tạo ra giá trị tương đương.
Khi hai mô hình đều đáp ứng yêu cầu tối thiểu, mức chất lượng cao hơn có thể xứng đáng với chi phí bổ sung nếu nó giảm lỗi nghiêm trọng hoặc giảm khối lượng rà soát của con người. Chi phí trên mỗi kết quả đúng chỉ phù hợp để so sánh khi các kết quả có giá trị và hậu quả sai sót tương tự nhau.
Thay đổi từng biến và chọn theo bằng chứng
Mỗi lần thử nên thay đổi một biến lớn rồi so sánh chi phí, số kết quả đã kiểm chứng, độ trễ và khả năng đáp ứng thời hạn dưới mức tải đại diện. Cách thử này giúp xác định liệu cải tiến đến từ lịch chạy, cách gom lô, quy mô triển khai, mô hình hay số lượng GPU.
Hệ thống vẫn cần năng lực dự phòng cho các đợt tăng tải và sự cố. Mức hoạt động thấp chỉ có ý nghĩa nếu phần năng lực chưa dùng thực sự có thể phục vụ công việc khác.
Một GPU được cấp riêng cho một Pod không thể chuyển sang Pod khác cho đến khi tài nguyên được giải phóng. Vì vậy, chỉ số sử dụng thấp không tự động đồng nghĩa với khả năng điều phối linh hoạt.
Từ dữ liệu kiểm thử, đội ngũ có thể chọn trì hoãn các tác vụ linh hoạt, cải thiện cách gom lô, điều chỉnh quy mô triển khai, đổi mô hình hoặc bổ sung GPU. Mục tiêu là cung cấp đúng kết quả với chi phí có thể giải trình và đủ năng lực dự phòng để đáp ứng yêu cầu, thay vì giữ mọi GPU luôn bận.
Quyết định mở rộng cụm GPU chỉ nên được đưa ra sau khi phép đo trên tải thực tế cho thấy cấu hình hiện tại không thể đáp ứng đồng thời yêu cầu về kết quả, thời hạn, độ trễ và chi phí.
