Đạt được hiệu suất cao trên quy mô lớn cho việc phân phối mô hình bằng cách sử dụng các điểm cuối đa mô hình của Amazon SageMaker với GPU

Amazon SageMaker điểm cuối đa mô hình (MME) cung cấp một cách có thể mở rộng và tiết kiệm chi phí để triển khai một số lượng lớn các mô hình máy học (ML). Nó cung cấp cho bạn khả năng triển khai nhiều mô hình ML trong một vùng chứa phục vụ duy nhất phía sau một điểm cuối duy nhất. Từ đó, SageMaker thay mặt bạn quản lý việc tải và dỡ các mô hình cũng như mở rộng quy mô tài nguyên dựa trên các mẫu lưu lượng truy cập của bạn. Bạn sẽ được hưởng lợi từ việc chia sẻ và tái sử dụng tài nguyên lưu trữ cũng như giảm bớt gánh nặng vận hành khi quản lý một số lượng lớn mô hình.

Trong tháng mười một 2022, MME đã thêm hỗ trợ cho GPUs, cho phép bạn chạy nhiều mô hình trên một thiết bị GPU và thay đổi quy mô các phiên bản GPU sau một điểm cuối duy nhất. Điều này đáp ứng nhu cầu mạnh mẽ của MME đối với các mô hình mạng thần kinh sâu (DNN) được hưởng lợi từ việc tăng tốc điện toán với GPU. Chúng bao gồm thị giác máy tính (CV), xử lý ngôn ngữ tự nhiên (NLP) và các mô hình AI tổng quát. Những lý do cho nhu cầu bao gồm:

• Các mô hình DNN thường có kích thước và độ phức tạp lớn và tiếp tục phát triển với tốc độ nhanh chóng. Lấy các mô hình NLP làm ví dụ, nhiều mô hình trong số chúng vượt quá hàng tỷ tham số, yêu cầu GPU phải đáp ứng các yêu cầu về độ trễ thấp và thông lượng cao.
• Chúng tôi nhận thấy nhu cầu tùy chỉnh các mô hình này ngày càng tăng để mang lại trải nghiệm siêu cá nhân hóa cho người dùng cá nhân. Khi số lượng các mô hình này tăng lên, cần có một giải pháp dễ dàng hơn để triển khai và vận hành nhiều mô hình trên quy mô lớn.
• Các phiên bản GPU đắt tiền và bạn muốn sử dụng lại các phiên bản này càng nhiều càng tốt để tối đa hóa việc sử dụng GPU và giảm chi phí vận hành.

Mặc dù tất cả những lý do này cho thấy các MME có GPU là một tùy chọn lý tưởng cho các mô hình DNN, nhưng bạn nên thực hiện kiểm tra tải để tìm cấu hình điểm cuối phù hợp đáp ứng các yêu cầu trong trường hợp sử dụng của mình. Nhiều yếu tố có thể ảnh hưởng đến kết quả kiểm thử tải, chẳng hạn như loại phiên bản, số lượng phiên bản, kích thước mô hình và kiến ​​trúc mô hình. Ngoài ra, thử nghiệm tải có thể giúp hướng dẫn các chiến lược tự động thay đổi quy mô bằng cách sử dụng các chỉ số phù hợp thay vì các phương pháp thử và sai lặp đi lặp lại.

Vì những lý do đó, chúng tôi tổng hợp bài đăng này để giúp bạn thực hiện kiểm tra tải thích hợp trên MME có GPU và tìm cấu hình tốt nhất cho trường hợp sử dụng ML của bạn. Chúng tôi chia sẻ kết quả thử nghiệm tải của mình đối với một số mô hình DNN phổ biến nhất trong NLP và CV được lưu trữ bằng MME trên các loại phiên bản khác nhau. Chúng tôi tóm tắt thông tin chi tiết và kết luận từ kết quả thử nghiệm của mình để giúp bạn đưa ra quyết định sáng suốt về việc định cấu hình triển khai của riêng mình. Đồng thời, chúng tôi cũng chia sẻ phương pháp được đề xuất để thực hiện kiểm tra tải cho MME trên GPU. Các công cụ và kỹ thuật được khuyến nghị xác định số lượng kiểu máy tối ưu có thể tải cho mỗi loại phiên bản và giúp bạn đạt được hiệu suất giá tốt nhất.

Tổng quan về giải pháp

Để biết phần giới thiệu về MME và MME có GPU, hãy tham khảo Tạo điểm cuối đa mô hình và Chạy nhiều mô hình học sâu trên GPU với các điểm cuối đa mô hình của Amazon SageMaker. Đối với bối cảnh kiểm tra tải trong bài đăng này, bạn có thể tải xuống mã mẫu của chúng tôi từ Repo GitHub để tái tạo kết quả hoặc sử dụng nó làm mẫu để đánh giá các mô hình của riêng bạn. Có hai sổ ghi chép được cung cấp trong repo: một dành cho các mô hình CV thử nghiệm tải và một dành cho NLP. Một số mẫu có kích thước và cấu trúc khác nhau đã được đo điểm chuẩn trên các loại phiên bản GPU khác nhau: ml.g4dn.2xlarge, ml.g5.2xlarge và ml.p3.2xlarge. Điều này sẽ cung cấp một mặt cắt ngang hợp lý về hiệu suất trên các chỉ số sau cho từng phiên bản và loại mô hình:

• Số kiểu máy tối đa có thể tải vào bộ nhớ GPU
• Độ trễ phản hồi từ đầu đến cuối được quan sát ở phía máy khách cho mỗi truy vấn suy luận
• Thông lượng truy vấn tối đa mỗi giây mà điểm cuối có thể xử lý mà không gặp lỗi
• Người dùng hiện tại tối đa trên mỗi phiên bản trước khi phát hiện yêu cầu không thành công

Bảng sau đây liệt kê các mô hình được thử nghiệm.

Bảng sau đây liệt kê các phiên bản GPU đã thử nghiệm.

Như đã đề cập trước đây, ví dụ mã có thể được áp dụng cho các mô hình và loại phiên bản khác.

Lưu ý rằng các MME hiện chỉ hỗ trợ các phiên bản GPU đơn lẻ. Để biết danh sách các loại phiên bản được hỗ trợ, hãy tham khảo Các thuật toán, khung và phiên bản được hỗ trợ.

Quy trình benchmark bao gồm các bước sau:

1. Truy xuất một mô hình được đào tạo trước từ một trung tâm mô hình.
2. Chuẩn bị tạo phẩm mô hình để phân phát trên MME SageMaker (xem Chạy nhiều mô hình học sâu trên GPU với các điểm cuối đa mô hình của Amazon SageMaker để biết thêm chi tiết).
3. Triển khai MME SageMaker trên phiên bản GPU.
4. Xác định số lượng mô hình tối đa có thể được tải vào bộ nhớ GPU trong một ngưỡng được chỉ định.
5. Sử dụng Khung kiểm tra tải Locust để mô phỏng lưu lượng gọi ngẫu nhiên các mô hình được tải trên phiên bản.
6. Thu thập dữ liệu và phân tích kết quả.
7. Nếu muốn, hãy lặp lại các Bước 2–6 sau khi biên dịch mô hình thành TensorRT.

Bước 4 và 5 đảm bảo một cái nhìn sâu hơn. Các mô hình trong MME GPU SageMaker được tải vào bộ nhớ theo kiểu động. Do đó, ở Bước 4, chúng tôi tải một tạo phẩm mô hình ban đầu lên Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) và gọi mô hình để tải nó vào bộ nhớ. Sau lần gọi ban đầu, chúng tôi đo lượng bộ nhớ GPU đã tiêu thụ, tạo một bản sao của mô hình ban đầu, gọi bản sao của mô hình để tải nó vào bộ nhớ và đo lại tổng lượng bộ nhớ GPU đã tiêu thụ. Quá trình này được lặp lại cho đến khi đạt đến ngưỡng phần trăm sử dụng bộ nhớ GPU được chỉ định. Đối với điểm chuẩn, chúng tôi đặt ngưỡng thành 90% để cung cấp bộ nhớ đệm hợp lý để suy luận trên các lô lớn hơn hoặc để lại một số không gian để tải các mô hình ít được sử dụng khác.

Mô phỏng lưu lượng người dùng

Sau khi chúng tôi đã xác định số lượng mô hình, chúng tôi có thể chạy kiểm tra tải bằng cách sử dụng Khung kiểm tra tải Locust. Thử nghiệm tải mô phỏng các yêu cầu của người dùng đối với các mô hình ngẫu nhiên và tự động đo lường các số liệu như độ trễ phản hồi và thông lượng.

Locust hỗ trợ các hình dạng kiểm tra tải tùy chỉnh cho phép bạn xác định các mẫu lưu lượng truy cập tùy chỉnh. Hình dạng đã được sử dụng trong điểm chuẩn này được hiển thị trong biểu đồ sau. Trong 30 giây đầu tiên, điểm cuối được khởi động với 10 người dùng đồng thời. Sau 30 giây, người dùng mới được sinh ra với tốc độ hai người mỗi giây, đạt 20 người dùng đồng thời ở mốc 40 giây. Sau đó, điểm cuối được đo điểm chuẩn đều đặn với 20 người dùng đồng thời cho đến mốc 60 giây, tại thời điểm đó Locust lại bắt đầu tăng số lượng người dùng với tốc độ hai người dùng mỗi giây cho đến khi có 40 người dùng đồng thời. Mô hình thử nghiệm tăng cường và ổn định này được lặp lại cho đến khi điểm cuối được tăng cường lên tới 200 người dùng đồng thời. Tùy thuộc vào trường hợp sử dụng của mình, bạn có thể muốn điều chỉnh hình dạng kiểm tra tải trong locust_benchmark_sm.py để phản ánh chính xác hơn các mẫu lưu lượng truy cập dự kiến ​​của mình. Ví dụ: nếu bạn định lưu trữ các mô hình ngôn ngữ lớn hơn, thử nghiệm tải với 200 người dùng đồng thời có thể không khả thi đối với một mô hình được lưu trữ trên một phiên bản duy nhất và do đó, bạn có thể muốn giảm số lượng người dùng hoặc tăng số lượng phiên bản. Bạn cũng có thể muốn kéo dài thời lượng kiểm tra tải để đánh giá chính xác hơn độ ổn định của điểm cuối trong một khoảng thời gian dài hơn.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Lưu ý rằng chúng tôi chỉ đánh giá điểm cuối bằng các mô hình đồng nhất, tất cả đều chạy trên cơ sở phân phối nhất quán bằng PyTorch hoặc TensorRT. Điều này là do MME phù hợp nhất để lưu trữ nhiều mô hình có các đặc điểm tương tự, chẳng hạn như mức tiêu thụ bộ nhớ và thời gian phản hồi. Các mẫu điểm chuẩn được cung cấp trong Repo GitHub vẫn có thể được sử dụng để xác định xem việc cung cấp các mô hình không đồng nhất trên MME có mang lại hiệu suất và độ ổn định mong muốn hay không.

Kết quả benchmark cho các mẫu CV

Sử dụng sổ ghi chép cv-benchmark.ipynb để chạy kiểm tra tải cho các mô hình thị giác máy tính. Bạn có thể điều chỉnh tên mô hình được đào tạo trước và các tham số loại phiên bản để thử nghiệm tải hiệu suất trên các kết hợp loại phiên bản và mô hình khác nhau. Chúng tôi đã cố tình thử nghiệm ba mẫu CV ở các phạm vi kích thước khác nhau từ nhỏ nhất đến lớn nhất: resnet50 (25 triệu), convnext_base (88 triệu) và vit_large_patch16_224 (304M). Bạn có thể cần phải điều chỉnh mã nếu bạn chọn một mô hình bên ngoài danh sách này. Ngoài ra, máy tính xách tay mặc định hình dạng hình ảnh đầu vào là tensor hình ảnh 224x224x3. Hãy nhớ điều chỉnh hình dạng đầu vào cho phù hợp nếu bạn cần định chuẩn các mô hình chụp ảnh có kích thước khác.

Sau khi chạy qua toàn bộ sổ ghi chép, bạn sẽ nhận được một số hình ảnh phân tích hiệu suất. Hai chi tiết đầu tiên về hiệu suất của mô hình liên quan đến việc tăng người dùng đồng thời. Các số liệu sau đây là ví dụ trực quan hóa được tạo cho ResNet50 mô hình chạy trên ml.g4dn.2xlarge, so sánh PyTorch (trái) với TensorRT (phải). Biểu đồ đường trên cùng hiển thị độ trễ và thông lượng của mô hình trên trục y với số lượng nhân viên khách hàng đồng thời ngày càng tăng được phản ánh trên trục x. Biểu đồ thanh dưới cùng hiển thị số lượng yêu cầu thành công và không thành công.

Nhìn qua tất cả các mô hình thị giác máy tính mà chúng tôi đã thử nghiệm, chúng tôi nhận thấy những điều sau:

• Độ trễ (tính bằng mili giây) cao hơn và thông lượng (yêu cầu mỗi giây) thấp hơn đối với các mô hình lớn hơn (resnet50 > convnext_base > vit_large_patch16_224).
• Độ trễ tăng tỷ lệ thuận với số lượng người dùng khi có nhiều yêu cầu hơn được xếp hàng đợi trên máy chủ suy luận.
• Các mô hình lớn tiêu tốn nhiều tài nguyên điện toán hơn và có thể đạt đến giới hạn thông lượng tối đa với ít người dùng hơn so với mô hình nhỏ hơn. Điều này được quan sát thấy với vit_large_patch16_224 mô hình, đã ghi lại yêu cầu không thành công đầu tiên ở 140 người dùng đồng thời. Lớn hơn đáng kể so với hai mô hình được thử nghiệm khác, nó cũng có nhiều yêu cầu không thành công nhất ở mức độ đồng thời cao hơn. Đây là một tín hiệu rõ ràng rằng điểm cuối sẽ cần mở rộng ra ngoài một phiên bản duy nhất nếu mục đích là hỗ trợ hơn 140 người dùng đồng thời.

Khi kết thúc quá trình chạy sổ tay, bạn cũng nhận được bản so sánh tóm tắt giữa các mô hình PyTorch và TensorRT cho từng chỉ số trong số bốn chỉ số chính. Từ thử nghiệm điểm chuẩn của chúng tôi, tất cả các mô hình CV đều có hiệu suất mô hình tăng sau khi biên dịch TensorRT. lấy của chúng tôi ResNet50 lại làm ví dụ, độ trễ giảm 32% trong khi thông lượng tăng 18%. Mặc dù số lượng người dùng đồng thời tối đa vẫn giữ nguyên cho ResNet50, cả hai mô hình còn lại đều cải thiện 14% về số lượng người dùng đồng thời mà chúng có thể hỗ trợ. Tuy nhiên, việc cải thiện hiệu suất của TensorRT phải trả giá bằng việc sử dụng bộ nhớ cao hơn, dẫn đến các MME tải ít mô hình hơn. Tác động nhiều hơn đối với các mô hình sử dụng mạng thần kinh tích chập (CNN). Trên thực tế, mô hình ResNet50 của chúng tôi đã tiêu thụ khoảng gấp đôi bộ nhớ GPU khi chuyển từ PyTorch sang TensorRT, dẫn đến số lượng mô hình được tải ít hơn 50% (46 so với 23). Chúng tôi chẩn đoán hành vi này hơn nữa trong phần sau.

Kết quả điểm chuẩn cho các mô hình NLP

Đối với các mô hình NLP, hãy sử dụng sổ ghi chép nlp-benchmark.ipynb để chạy kiểm tra tải. Việc thiết lập sổ ghi chép sẽ trông rất giống nhau. Chúng tôi đã thử nghiệm hai mô hình NLP: bert-base-uncased (109 triệu) và roberta-large (335 triệu). Cả mô hình được đào tạo trước và trình mã thông báo đều được tải xuống từ trung tâm Hugging Face và tải trọng thử nghiệm được tạo từ trình mã thông báo bằng cách sử dụng một chuỗi mẫu. Độ dài chuỗi tối đa được mặc định là 128. Nếu bạn cần kiểm tra chuỗi dài hơn, hãy nhớ điều chỉnh thông số đó. Chạy qua sổ ghi chép NLP sẽ tạo ra cùng một bộ trực quan hóa: Pytorch (trái) so với TensorRT (phải).

Từ những điều này, chúng tôi đã quan sát thấy lợi ích hiệu suất thậm chí còn cao hơn của TensorRT cho các mô hình NLP. Lấy roberta-large mô hình trên phiên bản ml.g4dn.2xlarge chẳng hạn, độ trễ suy luận giảm đáng kể từ 180 mili giây xuống 56 mili giây (mức cải thiện 70%), trong khi thông lượng được cải thiện 406% từ 33 yêu cầu mỗi giây lên 167. Ngoài ra, số lượng yêu cầu đồng thời tối đa người dùng tăng 50%; các yêu cầu không thành công không được quan sát cho đến khi chúng tôi đạt được 180 người dùng đồng thời, so với 120 đối với mô hình PyTorch ban đầu. Về mặt sử dụng bộ nhớ, chúng tôi thấy có ít hơn một mô hình được tải cho TensorRT (từ chín mô hình xuống còn tám mô hình). Tuy nhiên, tác động tiêu cực nhỏ hơn nhiều so với những gì chúng tôi quan sát được với các mô hình dựa trên CNN.

Phân tích về sử dụng bộ nhớ

Bảng sau đây cho thấy phân tích đầy đủ về tác động sử dụng bộ nhớ từ PyTorch đến TensorRT. Chúng tôi đã đề cập trước đó rằng các mô hình dựa trên CNN bị ảnh hưởng tiêu cực hơn. Các ResNet50 đã giảm hơn 50% số lượng mẫu được tải trên cả ba loại phiên bản GPU. Convnext_base đã có mức giảm thậm chí còn lớn hơn ở mức khoảng 70% trên bảng. Mặt khác, tác động đến các mô hình máy biến áp là nhỏ hoặc hỗn hợp. vit_large_patch16_224 và roberta-large có mức giảm trung bình lần lượt là khoảng 20% ​​và 3%, trong khi bert-base-uncased đã cải thiện khoảng 40%.

Xem xét tổng thể tất cả các điểm dữ liệu liên quan đến hiệu suất vượt trội về độ trễ, thông lượng và độ tin cậy cũng như tác động nhỏ đến số lượng mô hình tối đa được tải, chúng tôi đề xuất mô hình TensorRT cho kiến ​​trúc mô hình dựa trên máy biến áp. Đối với CNN, chúng tôi tin rằng cần có thêm phân tích hiệu suất chi phí để đảm bảo lợi ích hiệu suất lớn hơn chi phí cho cơ sở hạ tầng lưu trữ bổ sung.

Các bảng sau đây liệt kê kết quả điểm chuẩn hoàn chỉnh của chúng tôi cho tất cả chỉ số trên cả ba loại phiên bản GPU.

Bảng sau đây tóm tắt kết quả trên tất cả các loại phiên bản. Phiên bản ml.g5.2xlarge mang lại hiệu suất tốt nhất, trong khi phiên bản ml.p3.2xlarge thường hoạt động kém hơn mặc dù là phiên bản đắt nhất trong ba phiên bản. Các phiên bản g5 và g4dn thể hiện giá trị tốt nhất cho khối lượng công việc suy luận.

Làm sạch

Sau khi bạn hoàn thành kiểm tra tải, hãy dọn dẹp các tài nguyên đã tạo để tránh phát sinh thêm phí. Các tài nguyên chính là các điểm cuối SageMaker và tệp phần mềm mô hình trong Amazon S3. Để giúp bạn dễ dàng, các tệp sổ ghi chép có mã dọn dẹp sau đây để giúp bạn xóa chúng:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Kết luận

Trong bài đăng này, chúng tôi đã chia sẻ kết quả thử nghiệm và phân tích của mình cho nhiều mô hình mạng thần kinh sâu khác nhau chạy trên các điểm cuối đa mô hình SageMaker với GPU. Các kết quả và thông tin chi tiết mà chúng tôi đã chia sẻ sẽ cung cấp mặt cắt ngang hợp lý về hiệu suất trên các chỉ số và loại phiên bản khác nhau. Trong quá trình này, chúng tôi cũng đã giới thiệu phương pháp được đề xuất để chạy thử nghiệm điểm chuẩn cho MME SageMaker có GPU. Các công cụ và mã mẫu mà chúng tôi cung cấp có thể giúp bạn bắt đầu nhanh quá trình kiểm tra điểm chuẩn và đưa ra quyết định sáng suốt hơn về cách lưu trữ hàng trăm mô hình DNN trên phần cứng điện toán được tăng tốc một cách hiệu quả về mặt chi phí. Để bắt đầu đo điểm chuẩn cho các mẫu của riêng bạn với hỗ trợ MME cho GPU, hãy tham khảo Các thuật toán, khung và phiên bản được hỗ trợ và Repo GitHub để biết thêm các ví dụ và tài liệu.

Giới thiệu về tác giả

James Wu là Kiến trúc sư Giải pháp Chuyên gia về AI / ML Cấp cao tại AWS. giúp khách hàng thiết kế và xây dựng các giải pháp AI / ML. Công việc của James bao gồm một loạt các trường hợp sử dụng ML, với mối quan tâm chính là tầm nhìn máy tính, học sâu và mở rộng ML trong toàn doanh nghiệp. Trước khi gia nhập AWS, James là kiến ​​trúc sư, nhà phát triển và nhà lãnh đạo công nghệ trong hơn 10 năm, bao gồm 6 năm trong lĩnh vực kỹ thuật và 4 năm trong ngành tiếp thị & quảng cáo.

Vikram Elango là Kiến trúc sư Giải pháp Chuyên gia về AI / ML tại Amazon Web Services, có trụ sở tại Virginia Hoa Kỳ. Vikram giúp khách hàng trong lĩnh vực tài chính và bảo hiểm có khả năng thiết kế, lãnh đạo tư tưởng để xây dựng và triển khai các ứng dụng học máy trên quy mô lớn. Anh ấy hiện đang tập trung vào xử lý ngôn ngữ tự nhiên, AI có trách nhiệm, tối ưu hóa suy luận và mở rộng ML trong toàn doanh nghiệp. Khi rảnh rỗi, anh ấy thích đi du lịch, đi bộ đường dài, nấu ăn và cắm trại cùng gia đình.

Simon Zamarin là một Kiến trúc sư giải pháp AI / ML có trọng tâm chính là giúp khách hàng khai thác giá trị từ tài sản dữ liệu của họ. Khi rảnh rỗi, Simon thích dành thời gian cho gia đình, đọc sách khoa học viễn tưởng và thực hiện nhiều dự án nhà tự làm khác nhau.

Saurabh Trikande là Giám đốc Sản phẩm Cấp cao của Amazon SageMaker Inference. Anh ấy đam mê làm việc với khách hàng và được thúc đẩy bởi mục tiêu dân chủ hóa việc học máy. Ông tập trung vào những thách thức cốt lõi liên quan đến việc triển khai các ứng dụng ML phức tạp, mô hình ML nhiều người thuê, tối ưu hóa chi phí và làm cho việc triển khai các mô hình học sâu dễ tiếp cận hơn. Khi rảnh rỗi, Saurabh thích đi bộ đường dài, tìm hiểu về các công nghệ tiên tiến, theo dõi TechCrunch và dành thời gian cho gia đình.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/