Thủ thuật
Tăng 33% hiệu suất GPU nhờ tối ưu hóa thứ tự phân bổ tài nguyên
(giờ Việt Nam)
Tóm tắt AI
Hugging Face vừa giới thiệu bộ phân bổ GPU mới giúp tối ưu hóa việc xử lý các tác vụ suy luận và batch, giúp tăng hiệu suất sử dụng phần cứng lên tới 33% mà không cần thay đổi hạ tầng.
Bản dịch AI

Quay lại các bài viết
Bài viết trước đã lập luận rằng hiệu suất sử dụng (utilization), chứ không phải trí tuệ (intelligence), mới là nơi hình thành rào cản thực sự tiếp theo trong AI doanh nghiệp, và bài viết kết thúc bằng việc lưu ý rằng chưa có một "cẩm nang" nào xuất hiện cho thấy một quy trình Quản lý GPU (GPU Management) trưởng thành sẽ trông như thế nào. Đây là giải pháp của chúng tôi.
Chúng tôi đã xây dựng một bộ phân bổ GPU có nhận thức về ràng buộc (constraint-aware GPU allocator) và so sánh nó với bộ lập lịch FIFO trên bảy kịch bản kiểm thử. Trên cùng một phần cứng, chạy cùng một khối lượng công việc, hiệu suất sử dụng GPU đã tăng tới 33 điểm phần trăm, và sản lượng có trọng số ưu tiên (priority-weighted output) tăng ở tất cả các kịch bản, với mức tăng lên tới 105%. Không có gì thay đổi về phần cứng. Thứ thay đổi chính là thứ tự đưa ra các quyết định phân bổ.
Một lưu ý về đo lường trước khi đi vào các con số. Mọi mức tăng dưới đây đều được thể hiện dưới dạng cải thiện so với kết quả của FIFO trên cùng một kịch bản. Hiệu suất sử dụng được báo cáo theo điểm phần trăm; giá trị được báo cáo dưới dạng phần trăm tăng trưởng của sản lượng có trọng số ưu tiên.
Quyết định, được trình bày một cách chính xác
"Giữ cho GPU luôn bận rộn" không phải là một quyết định mà hệ thống có thể thực thi. Quyết định này hẹp hơn và khó hơn nhiều: GPU nào chạy công việc nào, vào khung thời gian nào, với mức độ ưu tiên bao nhiêu. Về mặt hình thức, đó là một lựa chọn nhị phân cho mỗi tổ hợp GPU, công việc và khung thời gian, và đầu ra là một lưới — mọi GPU, trong toàn bộ thời gian lập lịch, với tên công việc trong mỗi ô hoặc không có gì cả.
Bốn loại khối lượng công việc cạnh tranh cho lưới đó: huấn luyện (training), suy luận thời gian thực (real-time inference), suy luận theo lô (batch inference) và lượng tử hóa (quantization). Chúng chia thành hai hình thái phân bổ, và sự phân chia này chính là nơi nảy sinh khó khăn. Huấn luyện, suy luận theo lô và lượng tử hóa có tính chất giống như lô (batch-like): một khi đã bắt đầu, mỗi công việc cần một khối GPU liên tục được giữ mà không bị gián đoạn cho đến khi hoàn thành. Suy luận thời gian thực thì ngược lại: có tính đàn hồi, được thúc đẩy bởi đường cong nhu cầu thay đổi theo từng khung thời gian, tăng và giảm theo lưu lượng truy cập.
Hai hình thái không tương thích cạnh tranh cho cùng một phần cứng trong cùng một khung thời gian là vấn đề cốt lõi. Một sự không đồng nhất thứ hai nằm bên trong một loại duy nhất: đối với cùng một mô hình cơ sở, các công việc huấn luyện kéo dài từ vài giờ đến vài ngày, và từ một GPU đến hàng chục GPU.
Cái giá của FIFO khi có sự tranh chấp
Điểm so sánh xuyên suốt là bộ lập lịch dựa trên FIFO: suy luận thời gian thực được phục vụ từ một phần dự phòng cố định, và mọi công việc khác được đặt theo thứ tự đến, không quan tâm đến mức độ ưu tiên.
Trong những điều kiện phù hợp, đó là một chính sách hợp lý. Khi cụm (cluster) có dư thừa, thứ tự phân bổ không làm mất đi hiệu suất sử dụng, mọi thứ đều vừa vặn bất kể trình tự, vì vậy FIFO và bất kỳ thứ gì phức tạp hơn đều lấp đầy cùng một phần của nhóm tài nguyên. Sự tranh chấp (contention) là nơi mà chi phí của việc sắp xếp thứ tự đó không còn vô hình và bắt đầu làm tiêu tốn cả năng lực. Sau đó, nó trở nên đắt đỏ theo hai cách riêng biệt, và đáng để xem xét từng cách một.
Phần dự phòng. Suy luận thời gian thực không thể chờ đợi năng lực; các GPU phải có mặt ngay khi lưu lượng truy cập cần đến chúng. Một bộ lập lịch đặt các công việc theo thứ tự đến không có cơ chế giải phóng GPU trong thời gian thấp điểm và thu hồi chúng trước thời điểm cao điểm tiếp theo, vì vậy cách duy nhất để đảm bảo tính sẵn sàng là lấy nhu cầu tối đa trong ngày của mỗi ứng dụng thời gian thực và dự phòng số lượng GPU đó cho cả ngày. Chi phí rơi vào mỗi giờ không phải là giờ cao điểm. Một ứng dụng cần sáu GPU vào giữa trưa và hai GPU lúc 4 giờ sáng sẽ giữ cả sáu GPU trong hai mươi bốn giờ, và bốn GPU nhàn rỗi đó không khả dụng cho bất kỳ công việc theo lô nào trong cả ngày. Chúng không được sử dụng, và chúng cũng không hề rảnh rỗi. Đó là lý do tại sao đường cơ sở nằm gần một nửa cụm trong hai kịch bản mà phần dự phòng chiếm ưu thế: 51,6% trong trường hợp hỗn hợp và 53,6% trong trường hợp nặng về huấn luyện. Khoảng một nửa nhóm tài nguyên, với phần lớn nửa nhàn rỗi được dự phòng thay vì rảnh rỗi. Chi phí này được trả bất kể cụm có bị tranh chấp hay không — sự tranh chấp chỉ làm cho nó trở nên rõ ràng.
Việc sắp xếp thứ tự. Dưới sự tranh chấp thực sự, những công việc nào có thể thực hiện được phụ thuộc vào thứ tự bạn đặt chúng, không chỉ vào việc có bao nhiêu năng lực tồn tại. Thứ tự không phải là yếu tố phá vỡ thế cân bằng được áp dụng sau khi vấn đề năng lực đã được giải quyết. Thứ tự là một quyết định về năng lực. FIFO đặt từng công việc khi nó đến, không cân nhắc giá trị của công việc đó và không kiểm tra xem còn những gì khác phải vừa vặn trong khung thời gian, vì vậy công việc ưu tiên cao phải chờ đợi phía sau bất cứ thứ gì yêu cầu trước, và năng lực bị cam kết vào các vị trí mà các công việc sau đó không thể sử dụng.
Hai yếu tố này kết hợp lại. Khối tài nguyên được giữ cho nhu cầu thời gian thực tối đa trong ngày bị loại khỏi danh sách cho mọi công việc theo lô trong hàng đợi, trong mọi giờ, và bất cứ thứ gì còn lại được phân phát theo thứ tự các yêu cầu đến.
Đó là sự tương đương của GPU với việc một hãng hàng không chỉ định máy bay cho bất kỳ chuyến bay thuê bao nào gọi đến trước, sau đó không còn gì để bay trên tuyến đường thực sự mang lại lợi nhuận. Và các GPU được dự phòng cả ngày cho một thời điểm cao điểm kéo dài vài giờ chính là những chiếc máy bay bị đình chỉ bay từ bài viết trước theo nghĩa đen nhất: ở chế độ chờ, không kiếm được gì, không khả dụng cho bất kỳ ai khác.

[Hình ảnh: các lưới phân bổ đặt cạnh nhau — bộ phân bổ ở trên, FIFO ở dưới, cùng một kịch bản]
Trên năm kịch bản kiểm thử được xây dựng cho sự tranh chấp thực sự, bộ phân bổ đã cải thiện cả hai trục cùng một lúc. Hiệu suất sử dụng chuyển từ dải 52–85% sang dải 72–88%. Giá trị có trọng số ưu tiên tăng từ 24,6% đến 105,1%, trung bình là 52%. Mọi kịch bản, cả hai chỉ số, không có sự đánh đổi nào cần phải giải thích.
Trường hợp đơn lẻ mạnh nhất là khối lượng công việc nặng về huấn luyện trên 8 GPU: hiệu suất sử dụng tăng từ 53,6% lên 87,0%, và giá trị tăng hơn gấp đôi, lên 105%. Ba mươi ba điểm của một tài sản cố định, vốn đã khấu hao, được phục hồi bằng cách thu hồi năng lực dự phòng và đặt phần còn lại theo thứ tự ưu tiên. (Số liệu này phản ánh một thứ tự cơ sở duy nhất.)
Bộ phân bổ loại bỏ cả hai hành vi trên. Nhu cầu thời gian thực được coi là một đường cong thay vì một mức trần, được phân bổ dựa trên nhu cầu tại mỗi khung thời gian, với các công việc giống như lô chiếm các khoảng thấp điểm, bị giới hạn bởi mức trần về số lượng GPU mà một công việc thời gian thực có thể hoán đổi giữa các khung thời gian liên tiếp. Và các công việc giống như lô được đặt theo mức độ ưu tiên trên toàn bộ khung thời gian thay vì theo thứ tự chúng đến. Phần còn lại của bài viết này là cách thực hiện.
Hiệu suất sử dụng là cần thiết. Mức độ ưu tiên là thứ biến nó thành giá trị.
Hiệu suất sử dụng đo lường mức độ chiếm dụng: phần nào của thời gian GPU khả dụng được phân bổ cho một việc gì đó. Nó không mang thông tin về việc việc đó có giá trị như thế nào. Một kịch bản tách biệt hoàn toàn hai yếu tố này, và khoảng cách chạy theo một hướng dễ bị bỏ lỡ.
Trong bài kiểm tra quy mô, 30 công việc trên 64 GPU, FIFO và bộ phân bổ tạo ra hiệu suất sử dụng giống hệt nhau, mỗi bên 44,9%, và thông lượng giống hệt nhau, 27 trên 30 công việc hoàn thành. Bộ phân bổ mang lại giá trị có trọng số ưu tiên cao hơn 15,9%. Mọi bảng điều khiển đều đọc giống nhau. Nhưng cụm đã tạo ra sản lượng khác biệt đáng kể.
Một mục tiêu không định giá mức độ ưu tiên có thể lấp đầy cụm đến cùng một mức độ, hoàn thành chính xác số lượng công việc như nhau, nhưng vẫn mang lại ít giá trị hơn. Bài viết trước đã lập luận rằng mức độ chiếm dụng là một thước đo kém để đánh giá liệu một cụm có đang tạo ra lợi nhuận hay không; đây là phiên bản đo lường của tuyên bố đó.
Ghi lại vấn đề
Giải pháp thay thế không phải là một danh sách dài hơn các quy tắc kinh nghiệm (heuristic). Một số ràng buộc chỉ có ý nghĩa trên toàn cục, và không quy tắc cục bộ nào có thể diễn đạt chúng: các khối liên tục, ngân sách cho mức độ biến động GPU chấp nhận được trên toàn bộ khung thời gian, sự đảm bảo rằng công việc đang chạy không bao giờ bị ưu tiên ngắt quãng (preempted). Để tôn trọng những điều đó, vấn đề phải được viết ra như một thực thể thống nhất.
Năm ràng buộc xác định một sự phân bổ hợp lệ:
Hàm mục tiêu có hai thành phần. Phân bổ một GPU cho một công việc giống như lô sẽ nhận được phần thưởng bằng mức độ ưu tiên của nó nhân với trọng số suy giảm theo thời gian. Việc không đáp ứng nhu cầu thời gian thực sẽ phải chịu một hình phạt tỷ lệ thuận với quy mô của sự thiếu hụt.
Quy mô tương đối của các trọng số đó chính là toàn bộ chính sách cấp độ dịch vụ, được thể hiện bằng một con số. Trọng số hình phạt thời gian thực lớn gấp 5 đến 10 lần trọng số phân bổ. Do đó, một đơn vị nhu cầu thời gian thực không được đáp ứng có chi phí bằng 5 đến 10 khung thời gian GPU của công việc lô có cùng mức độ ưu tiên. Sự bất đối xứng này là có chủ đích, và nó có nghĩa là các nghĩa vụ về độ trễ được thực thi bên trong cùng một quá trình tối ưu hóa đặt công việc lô, thay vì bởi một bộ tự động mở rộng (autoscaler) riêng biệt cạnh tranh với bộ lập lịch cho cùng các GPU đó.
Đó cũng là điều làm cho việc xử lý đàn hồi đối với nhu cầu thời gian thực trở nên an toàn. Bộ phân bổ có thể trao một GPU cho công việc lô trong thời gian thấp điểm vì việc không phục vụ đủ nhu cầu thời gian thực sau đó được định giá cao hơn nhiều so với bất cứ thứ gì mà công việc lô đó kiếm được — hình phạt, chứ không phải sự dự phòng tĩnh, mới là thứ bảo vệ tính sẵn sàng.
Trọng số thời gian suy giảm trên toàn bộ khung thời gian vì một lý do chỉ có ý nghĩa trong một hệ thống trực tuyến: đến lượt lập lịch tiếp theo, các công việc mới sẽ đến. Năng lực được sử dụng bây giờ có giá trị hơn năng lực được hứa hẹn sau này.
Bộ phân bổ đã biết các ràng buộc
Mô hình hình thức xác định một sự phân bổ hợp lệ, được chấm điểm tốt trông như thế nào. Trả lời một yêu cầu đến là một công việc riêng biệt, và nó thuộc về một thành phần riêng biệt. Đây là bài toán phân bổ tổ hợp NP-hard, và bộ lập lịch được gọi lại mỗi khi một công việc đến, vì vậy quyết định phải được đưa ra trong khoảng thời gian giữa hai yêu cầu API. Ngân sách độ trễ đó là ràng buộc cố định mà kiến trúc được thiết kế xung quanh, đó là lý do tại sao một heuristic nằm trên đường dẫn nóng (hot path) và mô hình hình thức nằm phía sau nó như là đặc tả mà heuristic được xây dựng để đáp ứng.
Heuristic đó không phải là một bộ phân bổ tham lam (greedy) chung chung. Các quy tắc của nó là các ràng buộc cấu trúc của mô hình hình thức, có nghĩa là mọi lưới mà nó tạo ra đều là một sự phân bổ hợp lệ theo cấu trúc. Không phải là thường hợp lệ. Mà là hợp lệ theo thiết kế.
Thiết kế đó, được áp dụng trên toàn bộ khung thời gian thay vì từng lần đến một, là thứ tạo ra sự gia tăng hiệu suất sử dụng. Bộ phân bổ nhìn thấy mọi công việc trong hàng đợi trước khi nó đặt bất kỳ công việc nào trong số đó, nó có thể giữ nhóm tài nguyên rảnh rỗi ở các hình thái mà công việc còn lại thực sự có thể chiếm dụng, một công việc lô cần một khối liên tục với kích thước nhất định vẫn còn chỗ khi đến lượt nó. Mức độ ưu tiên quyết định ai có quyền ưu tiên đối với chỗ đó. FIFO không có cái nhìn nào cả: nó cam kết năng lực cho bất kỳ công việc nào yêu cầu trước, và một công việc đến sau và cần một hình thái cụ thể có thể thấy không còn gì phù hợp, vì vậy nó không được lập lịch và các giờ GPU mà nó lẽ ra đã tiêu thụ sẽ không được yêu cầu.
Nó chạy trong 1 đến 2 mili giây trên năm kịch bản tranh chấp, và 15 mili giây ở 64 GPU và 30 công việc — đủ nhanh để chạy trên mọi yêu cầu đến.
Hệ thống cung cấp hai chế độ. Chế độ nhanh (Fast mode) chạy bộ phân bổ một mình và trả về lưới của nó; đây là đường dẫn nóng. Chế độ đầy đủ (Full mode) sử dụng lưới đó làm điểm bắt đầu cho mô hình hình thức, mô hình này cố gắng cải thiện nó — phù hợp với việc đánh giá định kỳ hơn là các quyết định theo từng yêu cầu.
Kết quả
Hiệu suất sử dụng được cải thiện trong mọi kịch bản ngoại trừ một kịch bản, nơi nó bằng nhau chính xác. Giá trị được cải thiện trong cả bảy kịch bản.
Bài viết được AI dịch và tổng hợp tự động từ Hugging Face: Blog. Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.