Cách mở rộng quy mô suy luận học máy cho các trường hợp sử dụng SaaS nhiều bên thuê

Được xuất bản lại bởi Plato

Người theo dõi: 0

Bài đăng này được đồng viết với Sowmya Manusani, Kỹ sư Máy học Nhân viên của Sr. tại Zendesk

Zendesk là một công ty SaaS xây dựng phần mềm hỗ trợ, bán hàng và tương tác với khách hàng cho tất cả mọi người, lấy sự đơn giản làm nền tảng. Nó phát triển mạnh nhờ hơn 170,000 công ty trên toàn thế giới phục vụ hàng trăm triệu khách hàng của họ một cách hiệu quả. Nhóm Học máy tại Zendcaesk chịu trách nhiệm nâng cao các nhóm Trải nghiệm khách hàng để đạt được hiệu quả tốt nhất. Bằng cách kết hợp sức mạnh của dữ liệu và con người, Zendesk cung cấp các sản phẩm thông minh giúp khách hàng của họ làm việc hiệu quả hơn bằng cách tự động hóa công việc thủ công.

Zendesk đã xây dựng các sản phẩm ML từ năm 2015, bao gồm Bot trả lời, Dự đoán mức độ hài lòng, Nội dung Cues, Macro được đề xuất, và nhiều cái khác. Trong vài năm gần đây, với sự phát triển của học tập sâu, đặc biệt là trong NLP, họ đã nhìn thấy rất nhiều cơ hội để tự động hóa quy trình làm việc và hỗ trợ các đại lý hỗ trợ khách hàng của họ với các giải pháp Zendesk. Zendesk hiện đang sử dụng TensorFlow và PyTorch để xây dựng các mô hình học sâu.

Những khách hàng như Zendesk đã xây dựng thành công phần mềm quy mô lớn như một doanh nghiệp dịch vụ (SaaS) trên Amazon Web Services (AWS). Động lực chính cho mô hình kinh doanh SaaS thành công là khả năng áp dụng hình thức thuê nhiều lần trong ứng dụng và cơ sở hạ tầng. Điều này mang lại hiệu quả về chi phí và hoạt động vì ứng dụng chỉ cần được xây dựng một lần, nhưng nó có thể được sử dụng nhiều lần và cơ sở hạ tầng có thể được chia sẻ. Chúng tôi thấy nhiều khách hàng xây dựng các hệ thống an toàn, tiết kiệm chi phí, nhiều đối tượng thuê trên AWS ở tất cả các lớp của ngăn xếp, từ máy tính, lưu trữ, cơ sở dữ liệu đến mạng và giờ đây chúng tôi nhận thấy khách hàng cần áp dụng nó vào học máy (ML ).

Đánh đổi khó khăn giữa tái sử dụng mô hình và siêu cá nhân hóa

Việc cho thuê nhiều lần đối với các doanh nghiệp SaaS thường có nghĩa là một ứng dụng duy nhất được sử dụng lại giữa nhiều người dùng (khách hàng của SaaS). Điều này tạo ra hiệu quả về chi phí và giảm chi phí hoạt động. Tuy nhiên, các mô hình học máy đôi khi cần được cá nhân hóa ở mức độ cụ thể cao (siêu cá nhân hóa) để đưa ra dự đoán chính xác. Điều này có nghĩa là mô hình SaaS “xây dựng một lần, sử dụng nhiều lần” không phải lúc nào cũng được áp dụng cho ML nếu các mô hình có tính đặc hiệu. Lấy ví dụ về trường hợp sử dụng của các nền tảng hỗ trợ khách hàng. Ngôn ngữ mà người dùng bao gồm trong vé hỗ trợ khác nhau tùy thuộc vào vấn đề đó là vấn đề chia sẻ chuyến đi (“chuyến đi mất quá nhiều thời gian”) hay vấn đề mua quần áo (“bạc màu khi giặt”). Trong trường hợp sử dụng này, việc cải thiện độ chính xác của việc dự đoán hành động khắc phục tốt nhất có thể yêu cầu đào tạo mô hình xử lý ngôn ngữ tự nhiên (NLP) trên tập dữ liệu cụ thể cho miền doanh nghiệp hoặc ngành dọc. Zendesk đối mặt chính xác với thách thức này khi cố gắng tận dụng ML trong các giải pháp của họ. Họ cần tạo ra hàng nghìn mô hình ML tùy chỉnh cao, mỗi mô hình được điều chỉnh cho một khách hàng cụ thể. Để giải quyết thách thức triển khai hàng nghìn mô hình, tiết kiệm chi phí này, Zendesk đã chuyển sang Amazon SageMaker.

Trong bài đăng này, chúng tôi hướng dẫn cách sử dụng một số tính năng mới hơn của Amazon SageMaker, một dịch vụ học máy được quản lý hoàn toàn, để xây dựng khả năng suy luận ML của nhiều bên thuê. Chúng tôi cũng chia sẻ một ví dụ thực tế về cách Zendesk đạt được kết quả tương tự thành công bằng cách triển khai một phương tiện hài lòng giữa khả năng hỗ trợ siêu cá nhân hóa trong các mô hình ML của họ và việc sử dụng chung cơ sở hạ tầng tiết kiệm chi phí bằng cách sử dụng điểm cuối đa mô hình của SageMaker ( MME).

Điểm cuối đa mô hình của SageMaker

Điểm cuối đa mô hình của SageMaker cho phép bạn triển khai nhiều mô hình phía sau một điểm cuối suy luận duy nhất có thể chứa một hoặc nhiều trường hợp. Mỗi phiên bản được thiết kế để tải và phục vụ nhiều mô hình cho đến dung lượng bộ nhớ và CPU của nó. Với kiến trúc này, một doanh nghiệp SaaS có thể phá vỡ chi phí tăng tuyến tính của việc lưu trữ nhiều mô hình và đạt được việc tái sử dụng cơ sở hạ tầng phù hợp với mô hình nhiều người thuê được áp dụng ở những nơi khác trong ngăn xếp ứng dụng.

Sơ đồ sau minh họa kiến trúc của điểm cuối đa mô hình SageMaker.

Điểm cuối đa mô hình SageMaker tải động các mô hình từ Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) khi được gọi, thay vì tải xuống tất cả các mô hình khi điểm cuối được tạo lần đầu tiên. Kết quả là, một lệnh gọi ban đầu đến một mô hình có thể có độ trễ suy luận cao hơn so với các suy luận tiếp theo, được hoàn thành với độ trễ thấp. Nếu mô hình đã được tải trên vùng chứa khi được gọi, thì bước tải xuống sẽ bị bỏ qua và mô hình trả về các suy luận với độ trễ thấp. Ví dụ: giả sử bạn có một mô hình chỉ được sử dụng một vài lần trong ngày. Nó được tải tự động theo yêu cầu, trong khi các mô hình được truy cập thường xuyên được giữ lại trong bộ nhớ và được gọi với độ trễ thấp nhất quán.

Chúng ta hãy xem xét kỹ hơn cách Zendesk đã sử dụng SageMaker MME để triển khai ML quy mô lớn, hiệu quả về chi phí với tính năng ML Macros đề xuất của họ.

Tại sao Zendesk xây dựng các mô hình siêu cá nhân hóa

Khách hàng của Zendesk trải rộng trên toàn cầu trong các ngành dọc khác nhau với các ngữ nghĩa vé hỗ trợ khác nhau. Do đó, để phục vụ khách hàng tốt nhất, họ thường phải xây dựng các mô hình được cá nhân hóa được đào tạo về dữ liệu vé hỗ trợ dành riêng cho từng khách hàng để xác định chính xác ý định, macro và hơn thế nữa.

Vào tháng 2021 năm XNUMX, họ đã phát hành một tính năng NLP ML mới, Đề xuất Macro, đề xuất các macro (hành động được xác định trước) dựa trên hàng nghìn dự đoán mô hình cụ thể của khách hàng. Nhóm ML của Zendesk đã xây dựng mô hình phân loại NLP dựa trên TensorFlow được đào tạo từ lịch sử trước đây về nội dung vé và macro cho mỗi khách hàng. Với các mô hình này có sẵn, dự đoán macro được khuyến nghị bất cứ khi nào đại lý xem vé (như thể hiện trong ảnh chụp màn hình sau), điều này giúp đại lý phục vụ khách hàng một cách nhanh chóng. Vì macro dành riêng cho khách hàng, Zendesk cần các mô hình dành riêng cho khách hàng để phục vụ các dự đoán chính xác.

Dưới lớp vỏ của các Macro được Đề xuất của Zendesk

Các mô hình Macro được đề xuất là mạng thần kinh dựa trên NLP có kích thước khoảng 7–15 MB. Thách thức chính là đưa hàng nghìn mô hình này vào sản xuất với các giải pháp hiệu quả về chi phí, đáng tin cậy và có thể mở rộng.

Mỗi mô hình có các dạng lưu lượng truy cập khác nhau, với tối thiểu là hai yêu cầu mỗi giây và cao nhất là hàng trăm yêu cầu mỗi giây, phục vụ hàng triệu dự đoán mỗi ngày với độ trễ của mô hình là khoảng 100 mili giây khi mô hình khả dụng trong bộ nhớ. Điểm cuối của SageMaker được triển khai trong nhiều Khu vực AWS, phục vụ hàng nghìn yêu cầu mỗi phút cho mỗi điểm cuối.

Với khả năng lưu trữ nhiều mô hình trên một điểm cuối duy nhất, SageMaker đã giúp Zendesk giảm chi phí triển khai và tạo ra một giải pháp hiệu quả về chi phí khi so sánh với việc triển khai một điểm cuối mô hình duy nhất cho mỗi khách hàng. Sự cân bằng ở đây là ít kiểm soát hơn đối với việc quản lý theo từng mô hình; tuy nhiên, đây là một lĩnh vực mà Zendesk đang cộng tác với AWS để cải thiện các điểm cuối đa mô hình.

Một trong những tính năng đa mô hình của SageMaker là tải mô hình một cách lười biếng, tức là các mô hình được tải vào bộ nhớ khi được gọi lần đầu tiên. Điều này là để tối ưu hóa việc sử dụng bộ nhớ; tuy nhiên, nó gây ra tăng đột biến thời gian phản hồi ở lần tải đầu tiên, đây có thể được coi là vấn đề khởi động nguội. Đối với Macro được đề xuất, đây là một thách thức; tuy nhiên, Zendesk đã khắc phục điều này bằng cách triển khai chức năng tải trước trên cung cấp điểm cuối SageMaker để tải các mô hình vào bộ nhớ trước khi phục vụ lưu lượng sản xuất. Thứ hai, MME dỡ bỏ các mô hình được sử dụng thường xuyên khỏi bộ nhớ, do đó, để đạt được độ trễ thấp nhất quán trên tất cả các mô hình và tránh "hàng xóm ồn ào" ảnh hưởng đến các mô hình kém hoạt động khác, Zendesk đang cộng tác với AWS để thêm các tính năng mới, sẽ được thảo luận ở phần sau của bài đăng, để kích hoạt quản lý theo từng mô hình rõ ràng hơn. Ngoài ra, như một giải pháp tạm thời, Zendesk đã xác định đúng kích thước đội MME để giảm thiểu việc dỡ quá nhiều mô hình. Với điều này, Zendesk có thể phục vụ dự đoán cho tất cả khách hàng của họ với độ trễ thấp, khoảng 100 mili giây và vẫn tiết kiệm được 90% chi phí khi so sánh với các thiết bị đầu cuối chuyên dụng.

Trên MME định kích thước bên phải, Zendesk đã quan sát thấy trong quá trình thử nghiệm tải rằng có nhiều phiên bản nhỏ hơn (thiên về tỷ lệ ngang) đằng sau MME là lựa chọn tốt hơn so với việc có ít phiên bản bộ nhớ lớn hơn (tỷ lệ dọc). Zendesk quan sát thấy rằng bin đóng gói quá nhiều mô hình (vượt quá 500 mô hình TensorFlow trong trường hợp của họ) trên một phiên bản bộ nhớ lớn duy nhất không hoạt động tốt vì bộ nhớ không phải là tài nguyên duy nhất trên một phiên bản mà có thể là một nút cổ chai. Cụ thể hơn, họ quan sát thấy rằng TensorFlow tạo ra nhiều luồng (3 x tổng số vCPU phiên bản) trên mỗi mô hình, do đó, việc tải hơn 500 mô hình trên một phiên bản duy nhất đã khiến giới hạn mức hạt nhân bị vi phạm trên số lượng tối đa các chủ đề có thể được tạo ra trên một phiên bản. Một vấn đề khác với việc sử dụng ít trường hợp hơn, lớn hơn đã xảy ra khi Zendesk gặp phải sự cố điều chỉnh (như một cơ chế an toàn) trên một số trường hợp đằng sau MME vì tốc độ gọi mô hình duy nhất trên giây vượt quá mức Máy chủ đa mô hình (MMS) trên một phiên bản duy nhất có thể xử lý một cách an toàn mà không làm nâu phiên bản đó. Đây là một vấn đề khác đã được giải quyết khi sử dụng ngày càng nhiều các phiên bản nhỏ hơn.

Từ quan điểm khả năng quan sát, là một thành phần quan trọng của bất kỳ ứng dụng sản xuất nào, amazoncloudwatch các chỉ số như lệnh gọi, CPU, mức sử dụng bộ nhớ và các chỉ số dành cho nhiều mô hình cụ thể như mô hình được tải trong bộ nhớ, thời gian tải mô hình, thời gian chờ tải mô hình và lần truy cập bộ nhớ cache của mô hình là thông tin. Cụ thể, việc phân tích độ trễ của mô hình đã giúp Zendesk hiểu được vấn đề khởi động nguội và tác động của nó.

Dưới mui xe của MME tự động mở rộng quy mô

Đằng sau mỗi điểm cuối đa mô hình, có các phiên bản lưu trữ mô hình, như được mô tả trong sơ đồ sau. Các phiên bản này tải và loại bỏ nhiều mô hình đến và đi từ bộ nhớ dựa trên các mẫu lưu lượng truy cập đến các mô hình.

SageMaker tiếp tục định tuyến các yêu cầu suy luận cho một mô hình đến trường hợp mà mô hình đã được tải để các yêu cầu được phục vụ từ bản sao mô hình được lưu trong bộ nhớ cache (xem sơ đồ sau, hiển thị đường dẫn yêu cầu cho yêu cầu dự đoán đầu tiên so với yêu cầu dự đoán được lưu trong bộ nhớ cache đường dẫn). Tuy nhiên, nếu mô hình nhận được nhiều yêu cầu gọi và có các trường hợp bổ sung cho điểm cuối đa mô hình, thì SageMaker định tuyến một số yêu cầu đến một trường hợp khác để phù hợp với sự gia tăng. Để tận dụng lợi thế của việc mở rộng mô hình tự động trong SageMaker, hãy đảm bảo rằng bạn có ví dụ tự động mở rộng thiết lập để cung cấp năng lực phiên bản bổ sung. Thiết lập chính sách chia tỷ lệ cấp điểm cuối của bạn với thông số tùy chỉnh hoặc lệnh gọi mỗi phút (được khuyến nghị) để thêm nhiều phiên bản hơn vào nhóm điểm cuối.

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 các mô hình tương tự mà bạn có thể phân phối thông qua một vùng chứa phân phối được chia sẻ và không cần phải truy cập tất cả các mô hình cùng một lúc. MME phù hợp nhất cho các mô hình có cùng kích thước và độ trễ lệnh gọi. Có thể chấp nhận được một số thay đổi về kích thước mô hình; ví dụ: các mô hình của Zendesk có phạm vi từ 10–50 Mb, hoạt động tốt, nhưng các biến thể về kích thước có hệ số lớn hơn 10, 50 hoặc 100 lần là không phù hợp. Các mô hình lớn hơn có thể gây ra số lần tải và tải nhiều hơn các mô hình nhỏ hơn để có đủ dung lượng bộ nhớ, điều này có thể dẫn đến độ trễ tăng thêm trên điểm cuối. Sự khác biệt về đặc tính hiệu suất của các mô hình lớn hơn cũng có thể tiêu thụ tài nguyên như CPU không đồng đều, điều này có thể ảnh hưởng đến các mô hình khác trên ví dụ.

MME cũng được thiết kế cho các mô hình đồng lưu trữ sử dụng cùng một khuôn khổ ML vì chúng sử dụng vùng chứa được chia sẻ để tải nhiều mô hình. Do đó, nếu bạn có kết hợp các khung ML trong nhóm mô hình của mình (chẳng hạn như PyTorch và TensorFlow), thì các điểm cuối chuyên dụng của SageMaker hoặc 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 không được sử dụng thường xuyên có thể bị tắt tải thay cho các mô hình được gọi thường xuyên. Nếu bạn có nhiều mô hình không được truy cập thường xuyên, thì điểm cuối đa mô hình có thể phục vụ hiệu quả lưu lượng truy cập này và tiết kiệm chi phí đáng kể.

Tổng kết

Trong bài đăng này, bạn đã biết cách SaaS và đa thuê nhà liên quan đến ML và cách các điểm cuối đa mô hình của SageMaker cho phép suy luận ML nhiều lần và tiết kiệm chi phí. Bạn đã tìm hiểu về trường hợp sử dụng nhiều người thuê của Zendesk đối với các mô hình ML cho mỗi khách hàng và cách họ lưu trữ hàng nghìn mô hình ML trong SageMaker MME cho tính năng Macro được đề xuất của họ và tiết kiệm 90% chi phí dựa trên suy luận khi so sánh với các điểm cuối chuyên dụng. Các trường hợp sử dụng siêu cá nhân hóa có thể yêu cầu hàng nghìn mô hình ML và MME là một lựa chọn hiệu quả về chi phí cho trường hợp sử dụng này. Chúng tôi sẽ tiếp tục thực hiện các cải tiến trong MME để cho phép bạn lưu trữ các mô hình có độ trễ thấp và với các điều khiển chi tiết hơn cho từng mô hình được cá nhân hóa. Để bắt đầu với MME, hãy xem Lưu trữ nhiều mô hình trong một vùng chứa phía sau một điểm cuối.

Về các tác giả

Syed Jaffry là Kiến trúc sư giải pháp của Sr. với AWS. Ông làm việc với nhiều công ty từ các tổ chức quy mô vừa đến các doanh nghiệp lớn, dịch vụ tài chính đến ISV, trong việc giúp họ xây dựng và vận hành các ứng dụng an toàn, linh hoạt, có thể mở rộng và hiệu suất cao trên đám mây.

Sowmya Manusani là Kỹ sư Máy học Nhân viên Cấp cao tại Zendesk. Cô ấy làm việc để sản xuất các tính năng Máy học dựa trên NLP tập trung vào việc cải thiện năng suất của Đại lý cho hàng nghìn khách hàng của Zendesk Enterprise. Cô có kinh nghiệm xây dựng các đường ống đào tạo tự động cho hàng nghìn mô hình được cá nhân hóa và phục vụ chúng bằng các ứng dụng an toàn, linh hoạt, có thể mở rộng và hiệu suất cao. Khi rảnh rỗi, cô thích giải câu đố và thử vẽ tranh.

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à làm cho việc học máy trở nên 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.

Deepti Ragha là Kỹ sư phát triển phần mềm trong nhóm Amazon SageMaker. Công việc hiện tại của cô tập trung vào việc xây dựng các tính năng để lưu trữ các mô hình học máy một cách hiệu quả. Khi rảnh rỗi, cô thích đi du lịch, đi bộ đường dài và trồng cây.