Chạy và tối ưu hóa suy luận đa mô hình với các điểm cuối đa mô hình của Amazon SageMaker

Amazon SageMaker điểm cuối đa mô hình (MME) cho phép bạn triển khai và lưu trữ nhiều mô hình một cách hiệu quả về mặt chi phí trong một điểm cuối duy nhất, sau đó mở rộng quy mô điểm cuối theo chiều ngang để đạt được quy mô. Như được minh họa trong hình dưới đây, đây là một kỹ thuật hiệu quả để triển khai nhiều mô hình trong cơ sở hạ tầng máy học (ML) của bạn. Chúng tôi đã thấy các doanh nghiệp phần mềm dưới dạng dịch vụ (SaaS) sử dụng tính năng này để áp dụng tính năng siêu cá nhân hóa trong mô hình ML của họ đồng thời đạt được chi phí thấp hơn.

Để có cái nhìn tổng quan cấp cao về cách MME hoạt động, hãy xem video Hội nghị thượng đỉnh AWS Mở rộng ML lên cấp độ tiếp theo: Lưu trữ hàng nghìn mô hình trên SageMaker. Để tìm hiểu thêm về các trường hợp sử dụng nhiều đối tượng thuê, siêu cá nhân hóa mà MME kích hoạt, hãy tham khảo Cách chia tỷ lệ suy luận máy học cho các trường hợp sử dụng SaaS nhiều bên thuê.

Trong phần còn lại của bài đăng này, chúng tôi sẽ tìm hiểu sâu hơn về kiến ​​trúc kỹ thuật của SageMaker MME và chia sẻ các phương pháp hay nhất để tối ưu hóa điểm cuối đa mô hình của bạn.

Các trường hợp sử dụng phù hợp nhất cho MME

Điểm cuối đa mô hình của SageMaker rất phù hợp để lưu trữ một số lượng lớn mô hình mà bạn có thể phân phối thông qua vùng chứa phân phát dùng chung và bạn không cần truy cập vào tất cả các mô hình cùng một lúc. Tùy thuộc vào kích thước của bộ nhớ phiên bản điểm cuối, một mô hình đôi khi có thể được dỡ khỏi bộ nhớ để tải một mô hình mới nhằm tối đa hóa việc sử dụng bộ nhớ hiệu quả. Do đó, ứng dụng của bạn cần phải chấp nhận những đột biến về độ trễ không thường xuyên trên các mô hình không được tải.

MME cũng được thiết kế cho các mô hình đồng lưu trữ sử dụng cùng một khung ML vì chúng sử dụng vùng chứa chung để tải nhiều mô hình. Do đó, nếu bạn có sự kết hợp của các khung ML trong nhóm mô hình của mình (chẳng hạn như PyTorch và TensorFlow), thì điểm cuối dành riêng cho SageMaker hoặc dịch vụ lưu trữ nhiều vùng chứa là lựa chọn tốt hơn.

Cuối cùng, MME phù hợp với các ứng dụng có thể chịu được hình phạt về độ trễ khởi động nguội không thường xuyên, vì các mô hình được tải trong lần gọi đầu tiên và các mô hình được sử dụng không thường xuyên có thể được tải xuống khỏi bộ nhớ để tải các mô hình mới. Do đó, nếu bạn có sự kết hợp của các mô hình được truy cập thường xuyên và không thường xuyên, thì điểm cuối nhiều mô hình có thể phục vụ lưu lượng truy cập này một cách hiệu quả với ít tài nguyên hơn và tiết kiệm chi phí cao hơn.

Chúng tôi cũng đã thấy một số tình huống trong đó khách hàng triển khai cụm MME có đủ dung lượng bộ nhớ tổng hợp để phù hợp với tất cả các mô hình của họ, nhờ đó tránh được việc giảm tải mô hình hoàn toàn nhưng vẫn tiết kiệm được chi phí nhờ cơ sở hạ tầng suy luận chung.

Mô hình container phục vụ

Khi bạn sử dụng Bộ công cụ suy luận SageMaker hoặc vùng chứa phân phát mô hình SageMaker dựng sẵn tương thích với MME, vùng chứa của bạn có Máy chủ đa mô hình (quy trình JVM) đang chạy. Cách dễ nhất để tích hợp Máy chủ đa mô hình (MMS) vào vùng chứa phân phát mô hình của bạn là sử dụng Bộ chứa phục vụ mô hình SageMaker tương thích với MME (tìm những loại có Loại công việc=suy luận và CPU/GPU=CPU). MMS là một công cụ mã nguồn mở, dễ sử dụng để phục vụ các mô hình deep learning. Nó cung cấp API REST với một máy chủ web để phục vụ và quản lý nhiều mô hình trên một máy chủ. Tuy nhiên, không bắt buộc phải sử dụng MMS; bạn có thể triển khai máy chủ mô hình của riêng mình miễn là nó triển khai API được MME yêu cầu.

Khi được sử dụng như một phần của nền tảng MME, tất cả các lệnh gọi API dự đoán, tải và hủy tải tới MMS hoặc máy chủ mô hình của riêng bạn đều được chuyển qua bộ điều khiển mặt phẳng dữ liệu MME. Lệnh gọi API từ bộ điều khiển mặt phẳng dữ liệu chỉ được thực hiện trên máy chủ cục bộ để ngăn chặn truy cập trái phép từ bên ngoài phiên bản. Một trong những lợi ích chính của MMS là nó cho phép giao diện được chuẩn hóa để tải, dỡ và gọi các mô hình có khả năng tương thích trên nhiều khung học sâu.

Cấu hình nâng cao của MMS

Nếu bạn chọn sử dụng MMS để phân phối mô hình, hãy xem xét các cấu hình nâng cao sau để tối ưu hóa khả năng mở rộng và thông lượng của các phiên bản MME của bạn.

Tăng tính song song suy luận trên mỗi mô hình

MMS tạo một hoặc nhiều quy trình công nhân Python cho mỗi mô hình dựa trên giá trị của default_workers_per_model tham số cấu hình. Những nhân viên Python này xử lý từng yêu cầu suy luận riêng lẻ bằng cách chạy mọi chức năng tiền xử lý, dự đoán và xử lý hậu kỳ mà bạn cung cấp. Để biết thêm thông tin, xem xử lý dịch vụ tùy chỉnh Kho lưu trữ GitHub.

Việc có nhiều hơn một nhân viên mô hình sẽ làm tăng tính song song của các dự đoán mà một mô hình nhất định có thể phục vụ. Tuy nhiên, khi một số lượng lớn mô hình đang được lưu trữ trên một phiên bản có số lượng CPU lớn, bạn nên thực hiện kiểm tra tải MME của mình để tìm giá trị tối ưu cho default_workers_per_model để ngăn chặn tình trạng cạn kiệt bộ nhớ hoặc tài nguyên CPU.

Thiết kế cho lưu lượng truy cập tăng đột biến

Mỗi quy trình MMS trong một phiên bản điểm cuối có một hàng đợi yêu cầu có thể được cấu hình bằng job_queue_size tham số (mặc định là 100). Điều này xác định số lượng yêu cầu MMS sẽ xếp hàng khi tất cả các tiến trình của nhân viên đều bận. Sử dụng tham số này để tinh chỉnh khả năng phản hồi của các phiên bản điểm cuối sau khi bạn đã quyết định số lượng công nhân tối ưu cho mỗi mô hình.

Trong tỷ lệ công nhân trên mỗi mô hình tối ưu, mặc định là 100 là đủ cho hầu hết các trường hợp. Tuy nhiên, đối với những trường hợp yêu cầu lưu lượng truy cập đến điểm cuối tăng đột biến, bạn có thể giảm kích thước hàng đợi nếu muốn điểm cuối không nhanh chóng chuyển quyền kiểm soát đến ứng dụng hoặc tăng kích thước hàng đợi nếu bạn muốn điểm cuối hấp thụ mức tăng đột biến .

Tối đa hóa tài nguyên bộ nhớ cho mỗi phiên bản

Khi sử dụng nhiều quy trình công nhân cho mỗi mô hình, theo mặc định, mỗi quy trình công nhân sẽ tải bản sao mô hình của chính nó. Điều này có thể làm giảm bộ nhớ phiên bản khả dụng cho các kiểu máy khác. Bạn có thể tối ưu hóa việc sử dụng bộ nhớ bằng cách chia sẻ một mô hình duy nhất giữa các quy trình công nhân bằng cách đặt tham số cấu hình preload_model=true. Ở đây, bạn đang đánh đổi khả năng song song suy luận giảm bớt (do một phiên bản mô hình duy nhất) với hiệu quả bộ nhớ cao hơn. Cài đặt này cùng với nhiều quy trình công nhân có thể là lựa chọn phù hợp cho các trường hợp sử dụng trong đó độ trễ mô hình thấp nhưng bạn phải xử lý trước và xử lý hậu kỳ nặng hơn (được thực hiện bởi các quy trình công nhân) cho mỗi yêu cầu suy luận.

Đặt giá trị cho cấu hình nâng cao MMS

MMS sử dụng tệp config.properties để lưu trữ cấu hình. MMS sử dụng thứ tự sau để định vị tệp config.properties này:

1. Nếu MMS_CONFIG_FILE biến môi trường được đặt, MMS tải cấu hình từ biến môi trường.
2. Nếu --mms-config tham số được chuyển tới MMS, nó sẽ tải cấu hình từ tham số đó.
3. Nếu có một config.properties trong thư mục hiện tại nơi người dùng khởi động MMS, nó sẽ tải config.properties tập tin từ thư mục làm việc hiện tại.

Nếu không có mục nào ở trên được chỉ định, MMS sẽ tải cấu hình tích hợp với các giá trị mặc định.

Sau đây là ví dụ dòng lệnh về cách khởi động MMS bằng tệp cấu hình rõ ràng:

multi-model-server --start --mms-config /home/mms/config.properties

Các số liệu chính để theo dõi hiệu suất điểm cuối của bạn

Các số liệu chính có thể giúp bạn tối ưu hóa MME thường liên quan đến mức sử dụng CPU và bộ nhớ cũng như độ trễ suy luận. Các chỉ số cấp độ phiên bản được MMS phát ra, trong khi các chỉ số độ trễ đến từ MME. Trong phần này, chúng tôi thảo luận về các số liệu điển hình mà bạn có thể sử dụng để hiểu và tối ưu hóa MME của mình.

Chỉ số cấp phiên bản điểm cuối (chỉ số MMS)

Từ danh sách số liệu MMS, CPUUtilization và MemoryUtilization có thể giúp bạn đánh giá xem phiên bản hoặc cụm MME của bạn có đúng kích cỡ hay không. Nếu cả hai chỉ số đều có tỷ lệ phần trăm trong khoảng 50–80% thì MME của bạn có kích thước phù hợp.

Thông thường, mức sử dụng CPU thấp và mức sử dụng bộ nhớ cao là dấu hiệu của cụm MME được cung cấp quá mức vì nó cho thấy rằng các mô hình được gọi không thường xuyên sẽ không được tải. Điều này có thể là do số lượng phiên bản điểm cuối được cung cấp cho MME cao hơn mức tối ưu và do đó bộ nhớ tổng hợp cao hơn mức tối ưu có sẵn cho các mô hình được truy cập không thường xuyên để duy trì trong bộ nhớ. Ngược lại, việc sử dụng các số liệu này gần như 100% có nghĩa là cụm của bạn chưa được cung cấp đầy đủ, do đó bạn cần điều chỉnh chính sách tự động mở rộng quy mô cụm của mình.

Số liệu cấp nền tảng (số liệu MME)

Từ danh sách đầy đủ các số liệu MME, một chỉ số chính có thể giúp bạn hiểu độ trễ của yêu cầu suy luận là ModelCacheHit. Số liệu này hiển thị tỷ lệ trung bình của các yêu cầu gọi mà mô hình đã được tải trong bộ nhớ. Nếu tỷ lệ này thấp, điều đó cho thấy cụm MME của bạn chưa được cung cấp đủ vì có thể không có đủ dung lượng bộ nhớ tổng hợp trong cụm MME cho số lần gọi mô hình duy nhất, do đó khiến các mô hình thường xuyên bị tải khỏi bộ nhớ.

Bài học từ hiện trường và chiến lược tối ưu hóa MME

Chúng tôi đã thấy những đề xuất sau đây từ một số trường hợp sử dụng MME ở quy mô cao đối với một số khách hàng.

Chia tỷ lệ theo chiều ngang với các phiên bản nhỏ hơn sẽ tốt hơn tỷ lệ theo chiều dọc với các phiên bản lớn hơn

Bạn có thể gặp phải hiện tượng điều chỉnh các lệnh gọi mô hình khi chạy yêu cầu mỗi giây (RPS) cao trên ít phiên bản điểm cuối hơn. Có các giới hạn nội bộ đối với số lượng lệnh gọi mỗi giây (tải và dỡ tải có thể xảy ra đồng thời trên một phiên bản) và do đó, tốt hơn là nên có số lượng phiên bản nhỏ hơn cao hơn. Việc chạy số lượng phiên bản nhỏ hơn cao hơn có nghĩa là tổng dung lượng tổng hợp của các giới hạn này cho điểm cuối cao hơn.

Một lợi ích khác của việc mở rộng theo chiều ngang với các phiên bản nhỏ hơn là bạn giảm nguy cơ cạn kiệt tài nguyên bộ nhớ và CPU của phiên bản khi chạy MMS với mức độ song song cao hơn, cùng với số lượng mô hình trong bộ nhớ cao hơn (như được mô tả trước đó trong bài đăng này).

Tránh bị đánh đập là trách nhiệm chung

Đập mạnh trong MME là khi các mô hình thường xuyên bị tải khỏi bộ nhớ và được tải lại do không đủ bộ nhớ, trong một phiên bản riêng lẻ hoặc tổng hợp trong cụm.

Từ góc độ sử dụng, bạn nên điều chỉnh kích thước phù hợp cho từng phiên bản điểm cuối riêng lẻ và điều chỉnh kích thước phù hợp cho kích thước tổng thể của cụm MME để đảm bảo có đủ dung lượng bộ nhớ cho mỗi phiên bản cũng như tổng hợp cho cụm cho trường hợp sử dụng của bạn. Nhóm bộ định tuyến của nền tảng MME cũng sẽ tối đa hóa việc sử dụng bộ nhớ đệm.

Đừng tích cực đóng gói quá nhiều mô hình trên các phiên bản bộ nhớ lớn hơn, ít hơn

Bộ nhớ không phải là tài nguyên duy nhất trong phiên bản cần lưu ý. Các tài nguyên khác như CPU ​​có thể là một yếu tố hạn chế, như được thấy trong kết quả kiểm tra tải sau đây. Trong một số trường hợp khác, chúng tôi cũng quan sát thấy các tài nguyên nhân khác như ID tiến trình bị cạn kiệt trên một phiên bản, do sự kết hợp của quá nhiều mô hình được tải và khung ML cơ bản (chẳng hạn như TensorFlow) sinh ra các luồng trên mỗi mô hình là bội số của các luồng có sẵn vCPU.

Kiểm tra hiệu suất sau đây minh họa một ví dụ về hạn chế CPU ảnh hưởng đến độ trễ của mô hình. Trong thử nghiệm này, một điểm cuối phiên bản duy nhất có một phiên bản lớn, mặc dù có đủ bộ nhớ để lưu giữ tất cả bốn mô hình trong bộ nhớ, nhưng lại tạo ra độ trễ của mô hình tương đối kém hơn khi tải khi so sánh với điểm cuối có bốn phiên bản nhỏ hơn.

độ trễ của mô hình điểm cuối phiên bản đơn

Mức sử dụng bộ nhớ và CPU điểm cuối phiên bản đơn

độ trễ của mô hình điểm cuối bốn phiên bản

Việc sử dụng bộ nhớ và CPU điểm cuối bốn phiên bản

Để đạt được cả hiệu năng lẫn hiệu quả về chi phí, hãy điều chỉnh kích thước phù hợp cho cụm MME của bạn với số lượng phiên bản nhỏ hơn cao hơn mà tổng thể sẽ mang lại cho bạn bộ nhớ và dung lượng CPU tối ưu trong khi vẫn tương đối ngang bằng với chi phí với số lượng phiên bản ít hơn nhưng lớn hơn.

Mô hình tinh thần để tối ưu hóa MME

Có bốn số liệu chính mà bạn phải luôn cân nhắc khi xác định kích thước phù hợp cho MME của mình:

• Số lượng và kích thước của các mô hình
• Số lượng mô hình duy nhất được gọi tại một thời điểm nhất định
• Loại và kích thước phiên bản
• Số lượng cá thể đằng sau điểm cuối

Bắt đầu với hai điểm đầu tiên, vì chúng thông báo cho điểm thứ ba và thứ tư. Ví dụ: nếu không có đủ phiên bản phía sau điểm cuối cho số lượng hoặc kích thước của các mô hình duy nhất mà bạn có thì bộ nhớ tổng hợp cho điểm cuối sẽ ở mức thấp và bạn sẽ thấy tỷ lệ trúng bộ nhớ đệm thấp hơn cũng như bị treo ở cấp điểm cuối do MME sẽ tải và dỡ các mô hình vào và ra khỏi bộ nhớ thường xuyên.

Tương tự, nếu lệnh gọi cho các mô hình duy nhất cao hơn bộ nhớ tổng hợp của tất cả các phiên bản phía sau điểm cuối, thì bạn sẽ thấy lần truy cập bộ nhớ đệm thấp hơn. Điều này cũng có thể xảy ra nếu kích thước của phiên bản (đặc biệt là dung lượng bộ nhớ) quá nhỏ.

Việc mở rộng quy mô theo chiều dọc với các phiên bản bộ nhớ thực sự lớn cũng có thể dẫn đến các vấn đề vì mặc dù các mô hình có thể vừa với bộ nhớ nhưng các tài nguyên khác như quy trình CPU và nhân cũng như giới hạn luồng có thể bị cạn kiệt. Tải thử nghiệm chia tỷ lệ theo chiều ngang trong giai đoạn tiền sản xuất để có được số lượng và kích thước phiên bản tối ưu cho MME của bạn.

Tổng kết

Trong bài đăng này, bạn đã hiểu sâu hơn về nền tảng MME. Bạn đã tìm hiểu những trường hợp sử dụng kỹ thuật nào mà MME phù hợp và đã xem xét kiến ​​trúc của nền tảng MME. Bạn đã hiểu sâu hơn về vai trò của từng thành phần trong kiến ​​trúc MME và những thành phần nào bạn có thể ảnh hưởng trực tiếp đến hiệu suất của nó. Cuối cùng, bạn đã có cái nhìn sâu hơn về các tham số cấu hình mà bạn có thể điều chỉnh để tối ưu hóa MME cho trường hợp sử dụng của mình và các số liệu bạn nên theo dõi để duy trì hiệu suất tối ưu.

Để bắt đầu với MME, hãy xem lại Điểm cuối đa mô hình của Amazon SageMaker sử dụng XGBoost và Lưu trữ nhiều mô hình trong một vùng chứa phía sau một điểm cuối.

Lưu ý

Syed Jaffry là Kiến trúc sư giải pháp chính của AWS. Anh làm việc với nhiều công ty từ các tổ chức cỡ vừa, doanh nghiệp lớn, dịch vụ tài chính và ISV để giúp họ xây dựng và vận hành các ứng dụng AI/ML có khả năng mở rộng và tiết kiệm chi phí trên đám mây.

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.