Как масштабировать выводы машинного обучения для сценариев использования мультитенантного SaaS

Переиздано Платоном

Читают: 0

Этот пост написан в соавторстве с Совмией Манусани, старшим штатным инженером по машинному обучению в Zendesk.

Zendesk — это SaaS-компания, которая создает программное обеспечение для поддержки, продаж и взаимодействия с клиентами для всех, взяв за основу простоту. Он процветает благодаря тому, что более 170,000 XNUMX компаний по всему миру эффективно обслуживают сотни миллионов клиентов. Команда машинного обучения в Zendcaesk отвечает за совершенствование команд по работе с клиентами для достижения наилучших результатов. Объединяя силу данных и людей, Zendesk предлагает интеллектуальные продукты, которые повышают производительность клиентов за счет автоматизации ручной работы.

Zendesk создает продукты машинного обучения с 2015 года, в том числе Ответный бот, Прогноз удовлетворенности, Подсказки контента, Предлагаемые макросыи многое другое. За последние несколько лет, с развитием глубокого обучения, особенно в NLP, они увидели много возможностей для автоматизации рабочих процессов и помощи агентам в поддержке своих клиентов с помощью решений Zendesk. В настоящее время Zendesk использует TensorFlow и PyTorch для создания моделей глубокого обучения.

Такие клиенты, как Zendesk, построили успешный крупномасштабный бизнес в сфере программного обеспечения как услуги (SaaS) на Amazon Web Services (AWS). Ключевым фактором успешной бизнес-модели SaaS является возможность применения мультиарендности в приложении и инфраструктуре. Это обеспечивает эффективность затрат и эксплуатации, поскольку приложение нужно создать только один раз, но его можно использовать много раз, а инфраструктуру можно использовать совместно. Мы видим, что многие клиенты создают безопасные, экономичные, мультиарендные системы на AWS на всех уровнях стека, от вычислительных ресурсов, хранилища, базы данных до сетей, а теперь мы видим, что клиентам необходимо применять его для машинного обучения (ML). ).

Трудный компромисс между повторным использованием модели и гипер-персонализацией

Мультитенантность для предприятий SaaS обычно означает повторное использование одного приложения многими пользователями (клиентами SaaS). Это обеспечивает эффективность затрат и снижает эксплуатационные расходы. Тем не менее, модели машинного обучения иногда должны быть персонализированы до высокой степени специфичности (гипер-персонализированы), чтобы делать точные прогнозы. Это означает, что парадигма SaaS «создай один раз, используй много раз» не всегда может быть применена к машинному обучению, если модели имеют специфику. Возьмем, к примеру, вариант использования платформ поддержки клиентов. Язык, который пользователи включают в заявку в службу поддержки, зависит от того, связана ли она с проблемой совместного использования («поездка заняла слишком много времени») или проблемой с покупкой одежды («обесцвечивание при стирке»). В этом случае для повышения точности прогнозирования наилучшего действия по исправлению может потребоваться обучение модели обработки естественного языка (NLP) на наборе данных, специфичном для бизнес-домена или отраслевой вертикали. Zendesk сталкивается именно с этой проблемой, когда пытается использовать машинное обучение в своих решениях. Им нужно было создать тысячи настраиваемых моделей машинного обучения, каждая из которых была адаптирована для конкретного клиента. Чтобы решить эту проблему развертывания тысяч моделей с минимальными затратами, Zendesk обратилась к Amazon SageMaker.

В этом посте мы покажем, как использовать некоторые из новых функций Создатель мудреца Амазонки, полностью управляемая служба машинного обучения, позволяющая создавать возможности многопользовательского вывода машинного обучения. Мы также поделимся реальным примером того, как Zendesk успешно добилась того же результата, развернув золотую середину между возможностью поддержки гипер-персонализации в своих моделях машинного обучения и экономичным совместным использованием инфраструктуры с помощью мультимодельных конечных точек SageMaker ( ММЕ).

Мультимодельные конечные точки SageMaker

Конечные точки SageMaker с несколькими моделями позволяют развертывать несколько моделей за одной конечной точкой вывода, которая может содержать один или несколько экземпляров. Каждый экземпляр предназначен для загрузки и обслуживания нескольких моделей в пределах своей памяти и мощности ЦП. Благодаря этой архитектуре бизнес SaaS может отказаться от линейно растущей стоимости размещения нескольких моделей и добиться повторного использования инфраструктуры в соответствии с моделью мультиарендности, применяемой в другом месте стека приложений.

На следующей диаграмме показана архитектура мультимодельной конечной точки SageMaker.

Мультимодельная конечная точка SageMaker динамически загружает модели из Простой сервис хранения Amazon (Amazon S3) при вызове вместо загрузки всех моделей при первом создании конечной точки. В результате при первоначальном вызове модели задержка вывода может быть выше, чем при последующих выводах, которые выполняются с малой задержкой. Если модель уже загружена в контейнер при вызове, шаг загрузки пропускается, и модель возвращает выводы с малой задержкой. Например, предположим, что у вас есть модель, которая используется всего несколько раз в день. Он автоматически загружается по запросу, а часто используемые модели сохраняются в памяти и вызываются с неизменно низкой задержкой.

Давайте подробнее рассмотрим, как Zendesk использовала SageMaker MME для экономичного гипермасштабируемого развертывания ML с помощью функции Suggested Macros ML.

Зачем Zendesk создавала гиперперсонализированные модели

Клиенты Zendesk разбросаны по всему миру и относятся к разным отраслевым вертикалям с разной семантикой обращений в службу поддержки. Поэтому, чтобы лучше обслуживать своих клиентов, им часто приходится создавать персонализированные модели, которые обучаются на данных обращений в службу поддержки для конкретных клиентов, чтобы правильно определять намерения, макросы и многое другое.

В октябре 2021 года они выпустили новую функцию NLP ML, Suggested Macros, которая рекомендует макросы (заранее определенные действия) на основе тысяч предсказаний моделей для конкретных клиентов. Команда машинного обучения Zendesk создала модель классификатора NLP на основе TensorFlow, обученную на основе предыдущей истории содержимого заявок и макросов для каждого клиента. При наличии этих моделей рекомендуется использовать прогноз макросов всякий раз, когда агент просматривает заявку (как показано на следующем снимке экрана), что помогает агенту быстро обслуживать клиентов. Поскольку макросы предназначены для клиентов, Zendesk нужны модели для клиентов, чтобы делать точные прогнозы.

Под капотом предлагаемых макросов Zendesk

Предлагаемые модели макросов представляют собой нейронные сети на основе НЛП размером около 7–15 МБ. Основная задача состоит в том, чтобы запустить в производство тысячи таких моделей с помощью экономичных, надежных и масштабируемых решений.

Каждая модель имеет разные шаблоны трафика, минимум два запроса в секунду и максимум сотни запросов в секунду, обрабатывая миллионы прогнозов в день с задержкой модели примерно 100 миллисекунд, когда модель доступна в памяти. Конечные точки SageMaker развернуты в нескольких регионах AWS, обслуживая тысячи запросов в минуту на каждую конечную точку.

Благодаря возможности размещать несколько моделей на одной конечной точке SageMaker помог Zendesk сократить накладные расходы на развертывание и создать экономичное решение по сравнению с развертыванием конечной точки с одной моделью для каждого клиента. Компромисс здесь заключается в меньшем контроле над управлением каждой моделью; однако это область, в которой Zendesk сотрудничает с AWS для улучшения конечных точек с несколькими моделями.

Одной из возможностей мультимоделей SageMaker является ленивая загрузка моделей, то есть модели загружаются в память при первом вызове. Это необходимо для оптимизации использования памяти; однако это вызывает скачки времени отклика при первой загрузке, что можно рассматривать как проблему холодного запуска. Для предлагаемых макросов это было проблемой; однако Zendesk преодолела эту проблему, внедрив функцию предварительной загрузки в дополнение к подготовке конечной точки SageMaker для загрузки моделей в память перед обслуживанием производственного трафика. Во-вторых, MME выгружает из памяти редко используемые модели, поэтому, чтобы добиться неизменно низкой задержки для всех моделей и избежать влияния «шумных соседей» на другие менее активные модели, Zendesk сотрудничает с AWS, чтобы добавить новые функции, более явное управление каждой моделью. Кроме того, в качестве временного решения Zendesk оптимизировала парк MME, чтобы свести к минимуму выгрузку слишком большого количества моделей. Благодаря этому Zendesk может обслуживать прогнозы для всех своих клиентов с малой задержкой, около 100 миллисекунд, и при этом достигать экономии 90% по сравнению с выделенными конечными точками.

В ходе нагрузочного тестирования Zendesk заметил, что при правильном размере MME наличие большего количества небольших экземпляров (предвзятое отношение к горизонтальному масштабированию) позади MME было лучшим выбором, чем меньшее количество более крупных экземпляров памяти (вертикальное масштабирование). Zendesk заметил, что упаковка слишком большого количества моделей (более 500 моделей TensorFlow в их случае) в один экземпляр с большой памятью не работает, потому что память — не единственный ресурс экземпляра, который может быть узким местом. В частности, они заметили, что TensorFlow порождает несколько потоков (3 x общее количество виртуальных ЦП экземпляра) для каждой модели, поэтому загрузка более 500 моделей в одном экземпляре приводит к нарушению ограничений уровня ядра на максимальное количество потоков, которые могут быть созданы в экземпляре. Другая проблема с использованием меньшего количества более крупных экземпляров возникла, когда Zendesk столкнулся с регулированием (в качестве механизма безопасности) в некоторых экземплярах позади MME, потому что скорость вызова уникальной модели в секунду превысила то, что Сервер с несколькими моделями (MMS) на одном экземпляре можно было безопасно обрабатывать, не снижая работоспособности экземпляра. Это была еще одна проблема, которая была решена с использованием большего количества экземпляров меньшего размера.

С точки зрения наблюдаемости, которая является важнейшим компонентом любого производственного приложения, Amazon CloudWatch такие метрики, как вызовы, ЦП, использование памяти и метрики для нескольких моделей, такие как загруженные модели в память, время загрузки модели, время ожидания загрузки модели и попадание в кэш модели, являются информативными. В частности, анализ задержки модели помог Zendesk понять проблему холодного запуска и ее влияние.

Под капотом автоматического масштабирования MME

За каждой конечной точкой с несколькими моделями стоят экземпляры размещения модели, как показано на следующей диаграмме. Эти экземпляры загружают и удаляют несколько моделей в память и из памяти на основе шаблонов трафика к моделям.

SageMaker продолжает направлять запросы на вывод для модели в экземпляр, где модель уже загружена, так что запросы обслуживаются из кэшированной копии модели (см. следующую диаграмму, на которой показан путь запроса для первого запроса на прогнозирование по сравнению с кэшированным запросом на прогнозирование). дорожка). Однако, если модель получает много запросов на вызов и есть дополнительные экземпляры для конечной точки с несколькими моделями, SageMaker направляет некоторые запросы другому экземпляру, чтобы учесть увеличение. Чтобы воспользоваться преимуществами автоматического масштабирования модели в SageMaker, убедитесь, что у вас есть настройка автоматического масштабирования экземпляра для предоставления дополнительной емкости экземпляра. Настройте политику масштабирования на уровне конечной точки с помощью настраиваемых параметров или вызовов в минуту (рекомендуется), чтобы добавить больше экземпляров в парк конечных точек.

Сценарии использования, наиболее подходящие для MME

Мультимодельные конечные точки SageMaker хорошо подходят для размещения большого количества похожих моделей, которые можно обслуживать через общий контейнер обслуживания, и при этом не требуется одновременный доступ ко всем моделям. MME лучше всего подходит для моделей, которые схожи по размеру и задержке вызова. Допускается некоторое изменение размера модели; например, размеры моделей Zendesk варьируются от 10 до 50 МБ, что прекрасно работает, но размеры в 10, 50 или 100 раз больше не подходят. Большие модели могут вызвать большее количество загрузок и выгрузок меньших моделей для размещения достаточного объема памяти, что может привести к дополнительной задержке на конечной точке. Различия в характеристиках производительности более крупных моделей также могут неравномерно потреблять ресурсы, такие как ЦП, что может повлиять на другие модели в экземпляре.

MME также предназначен для совместного размещения моделей, использующих одну и ту же платформу машинного обучения, поскольку они используют общий контейнер для загрузки нескольких моделей. Поэтому, если в вашем парке моделей есть несколько платформ машинного обучения (например, PyTorch и TensorFlow), лучшим выбором будут выделенные конечные точки SageMaker или хостинг с несколькими контейнерами. Наконец, MME подходит для приложений, которые могут допускать периодическое снижение задержки при холодном запуске, поскольку редко используемые модели могут быть разгружены в пользу часто вызываемых моделей. Если у вас есть длинный хвост редко используемых моделей, конечная точка с несколькими моделями может эффективно обслуживать этот трафик и обеспечивать значительную экономию средств.

Обзор

В этом посте вы узнали, как SaaS и мультиарендность связаны с машинным обучением, и как мультимодельные конечные точки SageMaker обеспечивают мультиарендность и экономическую эффективность для вывода машинного обучения. Вы узнали о многопользовательском сценарии использования Zendesk моделей машинного обучения для каждого клиента и о том, как они разместили тысячи моделей машинного обучения в SageMaker MME для своей функции «Предлагаемые макросы» и добились 90-процентной экономии затрат на логические выводы по сравнению с выделенными конечными точками. Варианты использования с гиперперсонализацией могут потребовать тысячи моделей машинного обучения, и MME — экономичный выбор для этого варианта использования. Мы продолжим улучшать MME, чтобы вы могли размещать модели с малой задержкой и более детальными элементами управления для каждой персонализированной модели. Чтобы начать работу с MME, см. Размещайте несколько моделей в одном контейнере за одной конечной точкой.

Об авторах

Сайед Джаффри является старшим архитектором решений в AWS. Он работает с целым рядом компаний, от организаций среднего размера до крупных предприятий, от финансовых служб до независимых поставщиков программного обеспечения, помогая им создавать и эксплуатировать безопасные, отказоустойчивые, масштабируемые и высокопроизводительные приложения в облаке.

Совмья Манусани является старшим штатным инженером по машинному обучению в Zendesk. Она работает над реализацией функций машинного обучения на основе NLP, направленных на повышение производительности агентов для тысяч клиентов Zendesk Enterprise. У нее есть опыт создания конвейеров автоматизированного обучения для тысяч персонализированных моделей и их обслуживания с использованием безопасных, отказоустойчивых, масштабируемых и высокопроизводительных приложений. В свободное время она любит разгадывать головоломки и пробовать рисовать.

Саураб Триканде является старшим менеджером по продуктам Amazon SageMaker Inference. Он увлечен работой с клиентами и делает машинное обучение более доступным. В свободное время Саураб любит ходить в походы, узнавать об инновационных технологиях, следить за TechCrunch и проводить время со своей семьей.

Дипти Рагха — инженер-разработчик программного обеспечения в команде Amazon SageMaker. Ее текущая работа сосредоточена на создании функций для эффективного размещения моделей машинного обучения. В свободное время она любит путешествовать, ходить в походы и выращивать растения.