Tăng tốc Llama 2 70B với NVIDIA H100

Hành trình suy luận LLM được tăng tốc

The journey of accelerated LLM inference

Việc theo đuổi hiệu năng trong công cụ trả lời của Perplexity đã thúc đẩy chúng tôi áp dụng các công nghệ mới nhất mà NVIDIA và AWS cung cấp. Trong bài viết này, chúng tôi rất vui được chia sẻ kết quả từ các thí nghiệm mới nhất của mình: so sánh quá trình suy luận của Llama 2 70B trên các cài đặt phần cứng và phần mềm khác nhau.

Nền tảng suy luận LLM của chúng tôi, pplx-api, được xây dựng trên một ngăn xếp tối tân được hỗ trợ bởi các thư viện mã nguồn mở. Kể từ khi bản beta công khai của pplx-api bắt đầu vào tháng 10, chúng tôi đã giải quyết các thách thức về khả năng mở rộng và tìm hiểu cách tinh chỉnh cấu hình tốt nhất để đạt được quy mô lớn. Điều này đã dẫn chúng tôi đến việc thực hiện các thí nghiệm với các câu hỏi định hướng sau:

Hiệu năng thô tăng thêm bao nhiêu khi chuyển đổi GPU từ NVIDIA A100 sang NVIDIA H100, trong khi tất cả các cài đặt khác được giữ nguyên?

Mức tăng hiệu quả của lượng tử hóa dấu phẩy động 8-bit (fp8) mà H100 hỗ trợ nguyên bản là bao nhiêu? Chi phí độ chính xác của lượng tử hóa này là gì?

Độ song song tensor và kích thước lô ảnh hưởng như thế nào đến độ trễ và thông lượng token?

Xem xét các yếu tố trên, cấu hình nào mang lại sự cân bằng có khả năng mở rộng tốt nhất giữa hiệu năng và hiệu quả chi phí?

Thiết lập thí nghiệm

Chúng tôi đã chạy thí nghiệm sau dưới dạng một loạt các điểm chuẩn cục bộ để tránh độ trễ mạng.

Các chỉ số chính:

Độ trễ: Tổng thời gian để máy chủ suy luận tạo ra toàn bộ phản hồi.

Thông lượng: Số lượng token đầu ra, trên mỗi giây, trên mỗi GPU, mà máy chủ suy luận có thể tạo ra trên tất cả người dùng và yêu cầu.

Các hằng số:

Các yếu tố sau sẽ ảnh hưởng đến các chỉ số chính, vì vậy chúng tôi giữ chúng nhất quán qua các lần thử nghiệm khác nhau.

Mô hình AI

Hiệu năng tỷ lệ thuận với kích thước của LLM. Nhiều tham số hơn đòi hỏi nhiều phép tính hơn dẫn đến suy luận chậm hơn. Ví dụ, Llama 2 13B nhanh hơn Llama 2 70B khi các cài đặt khác như nhau. Chúng tôi gắn bó với Llama 2 70B trong thí nghiệm này vì chúng tôi muốn tối ưu hóa để phục vụ các mô hình mã nguồn mở có năng lực nhất.

Tập dữ liệu token Đầu vào/Đầu ra

Số lượng token đầu vào và đầu ra trong mỗi cặp yêu cầu/phản hồi mẫu có thể ảnh hưởng đến các phép đo hiệu năng. Nhìn chung, việc tạo token đầu ra chiếm ưu thế trong thời gian phản hồi tổng thể. Khi việc lấy mẫu dữ liệu chỉ tạo ra các phản hồi "có/không" từ LLM, phản hồi sẽ nhanh hơn so với các mẫu yêu cầu LLM viết tiểu luận. Tập dữ liệu của chúng tôi bao gồm các yêu cầu tổng hợp với 1024 token đầu vào tạo ra 512 token đầu ra. Phân phối này được chọn để phù hợp với phân phối lưu lượng truy cập đã quan sát trên bản triển khai công khai Llama2 70B của chúng tôi.

Phiên bản phần mềm

NVIDIA TensorRT-LLM (bản phát hành v0.5.0) là một thư viện mã nguồn mở để tối ưu hóa suy luận LLM. Được phát hành vào cuối năm 2023, nó tổng hợp nhiều tối ưu hóa suy luận của NVIDIA và cung cấp một lớp tùy chỉnh linh hoạt cho các tham số chính của thí nghiệm này: kích thước lô, lượng tử hóa và độ song song tensor.

Các biến số

Chúng tôi đã thử nghiệm qua 4 trục cấu hình: độ song song tensor, kiến trúc GPU, lượng tử hóa và kích thước lô tối đa. Các trục này có liên hệ với nhau vì mỗi trục đại diện cho một sự đánh đổi liên quan đến tài nguyên nghẽn cổ chai quan trọng là bộ nhớ GPU.

Kiến trúc GPU

Kiến trúc GPU Hopper thế hệ thứ chín (H100-HBM3-80GB / p5.48xlarge) mang lại rất nhiều tính năng so với thế hệ tiền nhiệm của nó, Ampere (A100-SXM4-80GB / p4de.24xlarge), bao gồm tỷ lệ tính toán gấp 2x-6x và băng thông bộ nhớ GPU gần gấp 2x. Băng thông bộ nhớ GPU là một chỉ số quan trọng đối với suy luận vì điểm nghẽn độ trễ chính của các phép nhân ma trận trong suy luận đến từ việc tải hàng gigabyte dữ liệu mô hình từ bộ nhớ GPU vào các thanh ghi tính toán. Dựa trên các thống kê này, chúng tôi giảνο rằng một phép so sánh tương đương giữa NVIDIA H100 và A100 sẽ thể hiện sự cải thiện gấp 2 lần về cả độ trễ và thông lượng.

Một điểm khác biệt chính giữa NVIDIA H100 và A100 là lõi tensor của H100 hỗ trợ nguyên bản các lệnh dấu phẩy động 8-bit (fp8), mở ra cánh cửa cho các tối ưu hóa tiếp theo được chi tiết dưới đây. Đây là lý do tại sao chúng tôi sử dụng fp8 và fp16 cụ thể cho H100.

Để giữ cho bộ nhớ trên mỗi GPU nhất quán trong thí nghiệm này, chúng tôi đã bám sát các nút có bộ nhớ GPU 8x80GB cho cả NVIDIA A100 và H100 của chúng tôi. Ngoài việc cho phép kích thước lô lớn hơn, bộ nhớ GPU rất quan trọng vì các tham số của mô hình được tải vào bộ nhớ GPU trong quá trình khởi động máy chủ để truy cập nhanh. Ví dụ: nếu mỗi trong số 70 tỷ tham số trong mô hình của chúng tôi là một số dấu phẩy động 16-bit, thì mô hình có kích thước khoảng 140GB, không thể vừa vặn trên một GPU duy nhất. Do đó cần có độ song song tensor, điều mà chúng tôi giải thích bên dưới.

Độ song song tensor

Độ song song tensor đề cập đến số lượng thiết bị GPU được tiêu thụ để chạy máy chủ suy luận. Khi chúng tôi phân bổ một số GPU, TensorRT-LLM sẽ gộp tài nguyên của chúng lại với nhau để giúp chúng tôi đạt được ngân sách bộ nhớ tối thiểu cần thiết để chạy Llama2 70B. Giả thuyết của chúng tôi là độ song song tensor thấp hơn sẽ dẫn đến độ trễ cao hơn (do tiêu thụ ít tài nguyên hơn để đáp ứng mỗi lô) nhưng thông lượng trên mỗi GPU cao hơn (do tận dụng tốt hơn) khi so sánh với độ song song tensor cao hơn.

Lượng tử hóa

Lượng tử hóa là việc giảm độ chính xác trong các trọng số và kích hoạt được sử dụng bởi các mạng thần kinh. Chúng tôi sử dụng kỹ thuật này để giảm một nửa lượng tiêu thụ bộ nhớ GPU khi chúng tôi chuyển từ fp16 sang fp8. Điều này làm cho việc chạy cùng một mô hình với mức sử dụng bộ nhớ GPU tổng thể thấp hơn trở nên khả thi, cho phép độ song song tensor thấp hơn, từ đó thúc đẩy thông lượng.

Các phương pháp thực hiện lượng tử hóa có tiềm năng làm giảm độ chính xác. Do đó, chúng tôi đã đánh giá độ chính xác cho các độ chính xác khác nhau bằng cách so sánh thống kê độ bối rối của chúng, một thước đo mức độ tốt của LLM trong việc dự đoán từng token tiếp theo trong câu, trên tập ngữ liệu WikiText. Đối với dấu phẩy động 8-bit và trọng số 8-bit với kích hoạt 8-bit và SmoothQuant (w8a8 SQ), không có sự thay đổi đáng kể nào về độ bối rối (< 1%) so với fp16 trên WikiText, vì vậy chúng tôi cảm thấy tự tin để tiếp tục. Tuy nhiên, w4a16 thể hiện sự thay đổi đáng kể 7% về độ bối rối, có khả năng là do độ chính xác thậm chí còn thấp hơn và các chuyển đổi động cần thiết giữa int4 và fp16.

Kích thước lô

Song song hóa thông qua việc gom lô là một chiến lược cổ điển để ép hiệu năng từ một hệ thống bị hạn chế tài nguyên. Bằng cách xử lý nhiều yêu cầu trong mỗi lần chuyển tiếp qua mạng thần kinh, việc gom lô được biết là làm tăng thông lượng đổi lấy một số độ trễ. Việc gom lô cũng làm tăng mức tiêu thụ bộ nhớ GPU vì kích thước của bộ đệm KV quản lý cơ chế chú ý phát triển tuyến tính theo kích thước lô.

Trong trường hợp của Llama 2 70B (có 80 lớp), fp16 với kích thước lô 32 cho kích thước ngữ cảnh 4096, kích thước của bộ đệm KV lên tới 40 GB đáng kể. Điều này cuối cùng ngăn cản Llama 2 70B fp16, với các trọng số chỉ riêng đã chiếm 140GB, vừa vặn thoải mái trong bộ nhớ GPU 160GB có sẵn ở độ song song tensor 2 (TP-2).

Kết quả

Chúng tôi đã quét qua các kết hợp tương thích của 4 biến số trong thí nghiệm và trình bày các xu hướng sâu sắc nhất dưới đây.

Hình 1 - Độ trễ của các yêu cầu với kích thước lô khác nhau trên năm cấu hình khác nhau, tất cả đều có độ song song tensor 8, mang lại độ trễ tốt nhất với 8 GPU có sẵn. Trong mỗi cấu hình, độ trễ thường tăng gấp đôi khi tăng kích thước lô từ 1 → 32, và lại tăng gấp đôi từ 32 → 128. Ở các kích thước lô đủ lớn, H100 xấp xỉ giảm một nửa độ trễ so với A100. A100 sử dụng độ chính xác hỗn hợp vì kiến trúc thiếu hỗ trợ nguyên bản cho fp8. w8a8 với SmoothQuant (SQ) nhằm mô phỏng fp8.

Sự cải thiện độ trễ của lượng tử hóa là khoảng 10% khi so sánh H100 fp16 → fp8 và A100 fp16 → w8a8 với SmoothQuant. Tuy nhiên, độ chính xác hỗn hợp w4a16 thực sự hoạt động tốt hơn ở kích thước lô thấp và kém hơn ở kích thước lô cao hơn so với fp16. Điều này có thể là do một số yếu tố, bao gồm các kernel tính toán ít được tối ưu hóa hơn, thời gian chuyển đổi giữa int4 và fp16, và thực tế là w4a16 vẫn sử dụng dấu phẩy động 16-bit cho các kích hoạt, dẫn đến không có tiết kiệm nào về kích thước của bộ đệm KV. Vì w4a16 cũng thể hiện độ chính xác thấp hơn, chúng tôi kết luận rằng chúng ta nên gắn bó với w8a8 SQ cho A100 và fp8 cho H100.

Hình 2 - Thông lượng trên các cấu hình TP-8 với các kiến trúc, lượng tử hóa và kích thước lô khác nhau. Đối với mỗi kiến trúc và lượng tử hóa, kích thước lô được chọn là lớn nhất thỏa mãn yêu cầu độ trễ 25600ms (20 token mỗi giây cho 512 token), để chúng ta có thể so sánh các cấu hình có độ trễ tương tự. Dưới yêu cầu này, H100 với BS-128 đạt 228% thông lượng so với A100 BS-64 sử dụng cùng định dạng lượng tử hóa (fp16) và thậm chí còn có độ trễ phản hồi thấp hơn mặc dù kích thước lô đã tăng gấp đôi. Lượng tử hóa với fp8 cải thiện hệ số này lên 251%.

Trong hai hình đầu tiên của chúng tôi, chúng tôi chỉ trình bày các cấu hình TP-8. H100 đạt 54% độ trễ và 184% thông lượng so với A100 khi cả hai sử dụng fp16 / BS-128 / TP-8, cải thiện thành 49% độ trễ và 202% thông lượng khi sử dụng fp8 trên H100. Sự cải thiện về hiệu năng này có thể được quy cho sự gia tăng sức mạnh tính toán và băng thông bộ nhớ giữa H100 và A100. Đáng chú ý, sự khác biệt ít rõ rệt hơn ở các kích thước lô thấp hơn, nơi việc sử dụng có thể thấp hơn.

Khi chúng tôi xây dựng nền tảng của mình, chúng tôi muốn tôn trọng các yêu cầu độ trễ nhất định cho người dùng của mình trong khi tối đa hóa thông lượng. Do đó, thay vì so sánh A100 và H100 ở cùng kích thước lô, việc so sánh thông lượng của chúng chỉ dưới các cấu hình nơi chúng đáp ứng yêu cầu độ trễ thực sự hợp lý hơn. Chúng tôi đặt mức cắt ở độ trễ 25600ms để hoàn thành 512 token đầu ra và thấy rằng H100 / TP-8 / fp8 / BS-128 mang lại 251% thông lượng so với A100 / TP-8 / fp16 / BS-64, vì nó có khả năng xử lý gấp đôi kích thước lô ở độ trễ thấp hơn. Cho rằng lượng tử hóa tiết kiệm bộ nhớ GPU, bây giờ chúng ta cần đánh giá cách độ song song tensor có thể thêm một lớp tối ưu hóa tiếp theo.

Hình 3 - Độ trễ qua các kích thước lô và độ song song tensor khác nhau cho H100 fp8. Độ trễ thường tăng gấp đôi khi tăng kích thước lô từ 1 → 32, và lại tăng gấp đôi từ 32 → 128. TP-2 liên tục chậm hơn khoảng gấp đôi so với TP-8 khi kích thước lô bằng nhau. Gấp đôi độ song song tensor đồng thời gấp đôi kích thước lô giúp giữ cho độ trễ tương đối ổn định vì số lượng lô được xử lý trên mỗi GPU vẫn đều đặn.

Khi nói đến lượng tử hóa và kiến trúc, có những người chiến thắng rõ ràng: H100 vượt trội hơn A100 và lượng tử hóa độ chính xác giảm giúp cải thiện việc sử dụng bộ nhớ, độ trễ và thông lượng. Tuy nhiên, kích thước lô và độ song song tensor đưa ra một sự đánh đổi trong các chỉ số chính của chúng tôi. Kích thước lô lớn hơn tối ưu hóa cho thông lượng với cái giá là tăng độ trễ và tiêu thụ bộ nhớ. Mặt khác, độ song song tensor cao hơn làm tăng tổng lượng bộ nhớ có sẵn và tối ưu hóa cho độ trễ, nhưng đánh đổi với thông lượng do chi phí đồng bộ hóa của phép nhân ma trận phân tán và nhờ vào việc khóa nhiều tài nguyên GPU hơn.

Hình 4 - Thông lượng qua các kích thước lô và độ song song tensor khác nhau cho H100 fp8. Thông lượng cao nhất đến từ TP-2 BS-128, ở mức 460% so với cơ sở của A100/TP-8/fp16/BS-64. Tuy nhiên, TP-2 BS-128 cũng là kết quả chậm nhất trong Hình 3.

Cấu hình tối đa hóa thông lượng của thí nghiệm chúng tôi là H100 / fp8 / TP-2 / BS-128, đạt 767 token đầu ra mỗi giây trên mỗi GPU. Đây là mức cải thiện 460% so với A100 / fp16 / TP-8 / BS-64. Tuy nhiên, nó đi kèm với cái giá là độ trễ tăng gấp đôi - gần 42000ms cho 512 token đầu ra - vì vậy nó có thể không phù hợp làm cấu hình sản xuất. Kết quả của TP-4 BS-128 (626 tok/sec/gpu ở thời gian phản hồi 26188ms) và TP-2 BS-32 (435 tok/sec/gpu ở thời gian phản hồi 18821ms) có thể đại diện cho các sự đánh đổi tốt hơn về các chỉ số chính của chúng tôi.

Kết luận

Kết quả của chúng tôi chứng minh rằng:

Chúng tôi đạt được độ trễ 54% và thông lượng 184% khi sử dụng H100 so với A100 với cùng cấu hình, cải thiện tương ứng thành 49% và 202% khi H100 tận dụng sự hỗ trợ nguyên bản cho fp8.

Khi tối đa hóa thông lượng chịu ràng buộc về độ trễ, H100 / fp8 / TP-8 / BS-128 mang lại thông lượng 251% so với A100 / fp16 / TP-8 / BS-64, vì nó có thể xử lý gấp đôi lô ở tốc độ nhanh hơn.

Tận dụng H100 với TP-2 cùng fp8, chúng tôi có thể đạt được 373% thông lượng của A100 / fp16 / TP-8 / BS-128, với mức tăng độ trễ dưới 10%.

Kích thước lô và độ song song tensor đặt ra sự đánh đổi giữa thông lượng và độ trễ đối với nhà vận hành hệ thống suy luận LLM.

Những kết quả này khiến chúng tôi cảm thấy tự tin về việc chuyển đổi hoàn toàn sang GPU H100 trong ngăn xếp phần cứng được cung cấp năng lượng bởi A100 trước đây của chúng tôi. Chúng tôi rất hào hứng khi có thể xác nhận các cải thiện hiệu năng được quảng cáo bởi NVIDIA và mong đợi những bước đột phá tiếp theo của họ trong phần cứng tăng tốc.

Tiếp theo là gì

Ranh giới tiếp theo của chúng tôi để tối ưu hóa là kiểm tra tác động đến độ chính xác và hiệu năng của độ thưa cấu trúc và độ chính xác int4, có thể làm giảm đáng kể dấu chân bộ nhớ GPU của Llama 2 70B và mang lại sự cải thiện lên đến 2x về độ trễ. Chúng tôi rất hào hứng tiếp tục hành trình suy luận cực nhanh và hy vọng trao quyền cho người dùng xây dựng các ứng dụng mạnh mẽ trên nền tảng của chúng tôi.

Trong thời gian ngắn tới, pplx-api sẽ dỡ bỏ các giới hạn tốc độ và cung cấp nhiều LLM Perplexity tùy chỉnh hơn, bao gồm một LLM được cung cấp năng lượng từ internet với khả năng địnhพื้น cho các sự thật.

Đăng ký Perplexity Pro tại perplexity.ai/pro. Nhận quyền truy cập vào pplx-api tiên tiến của chúng tôi và tận dụng các khả năng nâng cao này trong các dự án của bạn. Khám phá thêm về pplx-api trên blog của chúng tôi.

Quan tâm đến việc định hình tương lai của AI? Chúng tôi đang tuyển dụng! Hãy là một phần của đội ngũ thúc đẩy cơ sở hạ tầng LLM tạo sinh quy mô lớn. Khám phá các cơ hội tại Perplexity Careers.

Tác giả:

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats