Запускайте й оптимізуйте мультимодельний висновок за допомогою мультимодельних кінцевих точок Amazon SageMaker

Amazon SageMaker мультимодельна кінцева точка (MME) дає змогу економічно ефективно розгортати та розміщувати кілька моделей в одній кінцевій точці, а потім горизонтально масштабувати кінцеву точку для досягнення масштабу. Як показано на наведеному нижче малюнку, це ефективна техніка для впровадження багатоканальних моделей у вашій інфраструктурі машинного навчання (ML). Ми бачили, як компанії, які займаються програмним забезпеченням як послугою (SaaS), використовують цю функцію для застосування гіперперсоналізації у своїх моделях ML, одночасно досягаючи нижчих витрат.

Щоб отримати загальний огляд того, як працює MME, перегляньте відео AWS Summit Масштабування ML на наступний рівень: розміщення тисяч моделей на SageMaker. Щоб дізнатися більше про гіперперсоналізовані сценарії використання з кількома клієнтами, які підтримує MME, див Як масштабувати висновок машинного навчання для випадків використання SaaS з кількома клієнтами.

У решті цієї публікації ми глибше зануримося в технічну архітектуру SageMaker MME і поділимося найкращими практиками для оптимізації ваших мультимодельних кінцевих точок.

Випадки використання найкраще підходять для MME

Багатомодельні кінцеві точки SageMaker добре підходять для розміщення великої кількості моделей, які можна обслуговувати через спільний контейнер обслуговування, і вам не потрібно отримувати доступ до всіх моделей одночасно. Залежно від розміру пам’яті екземпляра кінцевої точки модель може час від часу вивантажуватися з пам’яті на користь завантаження нової моделі, щоб максимізувати ефективне використання пам’яті, тому ваша програма має бути терпимою до випадкових стрибків затримки на вивантажених моделях.

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

Нарешті, MME підходить для додатків, які можуть терпіти випадкову затримку холодного запуску, оскільки моделі завантажуються під час першого виклику, а моделі, які рідко використовуються, можуть бути вивантажені з пам’яті на користь завантаження нових моделей. Таким чином, якщо у вас є поєднання моделей, до яких часто і рідко звертаються, кінцева точка з кількома моделями може ефективно обслуговувати цей трафік з меншими ресурсами та більшою економією коштів.

Ми також спостерігали деякі сценарії, коли клієнти розгортають кластер MME із достатньою сукупною ємністю пам’яті, щоб відповідати всім їхнім моделям, таким чином повністю уникаючи розвантаження моделі, але все ще досягаючи економії коштів завдяки спільній інфраструктурі висновків.

Модель сервірувальних контейнерів

Коли ви використовуєте SageMaker Inference Toolkit або попередньо зібрану модель SageMaker, що обслуговує контейнер, сумісний із MME, ваш контейнер має Багатомодельний сервер (процес JVM) працює. Найпростіший спосіб інтегрувати мультимодельний сервер (MMS) у ваш контейнер обслуговування моделі – це використовувати Сервірувальні контейнери моделі SageMaker сумісні з MME (шукайте ті, у яких Job Type=inference і CPU/GPU=CPU). MMS — це простий у використанні інструмент із відкритим кодом для обслуговування моделей глибокого навчання. Він надає REST API з веб-сервером для обслуговування та керування кількома моделями на одному хості. Проте використовувати MMS не обов’язково; ви можете реалізувати власну модель сервера, якщо він реалізує API, необхідні MME.

При використанні як частини платформи MME усі передбачувані, завантажувальні та вивантажувальні виклики API до MMS або вашого власного сервера моделі направляються через контролер площини даних MME. Виклики API від контролера площини даних здійснюються лише через локальний хост, щоб запобігти неавторизованому доступу ззовні примірника. Однією з ключових переваг MMS є те, що він забезпечує стандартизований інтерфейс для завантаження, вивантаження та виклику моделей із сумісністю з широким спектром інфраструктур глибокого навчання.

Розширене налаштування MMS

Якщо ви вирішите використовувати MMS для обслуговування моделі, розгляньте такі розширені конфігурації, щоб оптимізувати масштабованість і пропускну здатність ваших примірників MME.

Збільште паралелізм висновків для кожної моделі

MMS створює один або кілька робочих процесів Python для кожної моделі на основі значення default_workers_per_model параметр конфігурації. Ці робочі Python обробляють кожен окремий запит на висновок, запускаючи будь-які надані вами функції попередньої обробки, передбачення та постобробки. Для отримання додаткової інформації див спеціальний обробник служби Репо GitHub.

Наявність кількох робочих моделей підвищує паралелізм передбачень, які може обслуговувати дана модель. Однак, якщо велика кількість моделей розміщено на екземплярі з великою кількістю процесорів, вам слід виконати навантажувальний тест вашого MME, щоб знайти оптимальне значення для default_workers_per_model щоб запобігти виснаженню будь-якої пам'яті або ресурсів ЦП.

Дизайн для стрибків трафіку

Кожен процес MMS в екземплярі кінцевої точки має чергу запитів, яку можна налаштувати за допомогою розмір_черги_задань параметр (за замовчуванням 100). Це визначає кількість запитів MMS у черзі, коли всі робочі процеси зайняті. Використовуйте цей параметр, щоб точно налаштувати швидкість реагування екземплярів кінцевих точок після того, як ви визначитеся з оптимальною кількістю працівників на модель.

У оптимальному співвідношенні працівників на модель стандартного значення 100 має бути достатньо для більшості випадків. Однак у тих випадках, коли трафік запиту до кінцевої точки різко зростає, ви можете зменшити розмір черги, якщо ви хочете, щоб кінцева точка не могла швидко передати керування додатку, або збільшити розмір черги, якщо ви хочете, щоб кінцева точка поглинала сплеск .

Максимально збільште ресурси пам’яті на екземпляр

У разі використання кількох робочих процесів на модель за замовчуванням кожен робочий процес завантажує власну копію моделі. Це може зменшити доступну пам’ять для інших моделей. Ви можете оптимізувати використання пам’яті шляхом спільного використання однієї моделі між робочими процесами, установивши параметр конфігурації preload_model=true. Тут ви обмінюєтеся зменшеним паралелізмом висновку (через єдиний екземпляр моделі) більшою ефективністю пам’яті. Цей параметр разом із кількома робочими процесами може бути хорошим вибором для випадків використання, коли затримка моделі низька, але ви маєте більш важку попередню обробку та постобробку (виконувану робочими процесами) на запит висновку.

Встановіть значення для розширених конфігурацій MMS

MMS використовує файл config.properties для зберігання конфігурацій. MMS використовує такий порядок, щоб знайти цей файл config.properties:

1. Якщо MMS_CONFIG_FILE встановлено змінну середовища, MMS завантажує конфігурацію зі змінної середовища.
2. Якщо --mms-config параметр передається в MMS, він завантажує конфігурацію з параметра.
3. Якщо є config.properties у поточній папці, де користувач запускає MMS, завантажується config.properties файл із поточного робочого каталогу.

Якщо нічого з перерахованого вище не вказано, MMS завантажує вбудовану конфігурацію зі значеннями за замовчуванням.

Нижче наведено приклад командного рядка запуску MMS із явним файлом конфігурації:

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

Ключові показники для моніторингу продуктивності вашої кінцевої точки

Ключові показники, які можуть допомогти вам оптимізувати ваш MME, як правило, пов’язані з використанням ЦП і пам’яті та затримкою висновку. Метрики на рівні екземпляра надходять від MMS, тоді як метрики затримки надходять від MME. У цьому розділі ми обговорюємо типові показники, які можна використовувати, щоб зрозуміти та оптимізувати свій MME.

Метрики на рівні екземпляра кінцевої точки (метрики MMS)

Від список метрик MMS, CPUUtilization і MemoryUtilization можуть допомогти вам оцінити, чи правильний розмір вашого екземпляра або кластера MME. Якщо обидва показники мають відсоткове співвідношення між 50–80%, то ваш MME має правильний розмір.

Як правило, низький CPUUtilization і високий MemoryUtilization є ознакою надмірно забезпеченого кластера MME, оскільки це вказує на те, що моделі, які рідко викликаються, не вивантажуються. Це може бути через більшу за оптимальну кількість екземплярів кінцевих точок, наданих для MME, і, отже, більша за оптимальну сукупна пам’ять доступна для моделей, до яких рідко звертаються, щоб залишитися в пам’яті. І навпаки, майже 100% використання цих показників означає, що ваш кластер недостатньо забезпечений, тому вам потрібно налаштувати політику автоматичного масштабування кластера.

Метрики на рівні платформи (метрики MME)

Від повний список метрик MME, ключовим показником, який може допомогти вам зрозуміти затримку вашого запиту на висновок, є ModelCacheHit. Ця метрика показує середнє співвідношення запитів на виклик, для яких модель уже була завантажена в пам’ять. Якщо цей коефіцієнт низький, це вказує на те, що ваш кластер MME недостатньо забезпечений, тому що, ймовірно, у кластері MME недостатньо сукупної пам’яті для кількості унікальних викликів моделі, тому моделі часто вивантажуються з пам’яті.

Уроки з поля та стратегії оптимізації MME

Ми побачили наведені нижче рекомендації в результаті широкомасштабного використання MME кількома клієнтами.

Горизонтальне масштабування з меншими екземплярами краще, ніж вертикальне масштабування з більшими екземплярами

Ви можете зіткнутися з обмеженням під час викликів моделі під час виконання високих запитів на секунду (RPS) на меншій кількості екземплярів кінцевих точок. Існують внутрішні обмеження на кількість звернень за секунду (завантажень і вивантажень, які можуть відбуватися одночасно в екземплярі), і тому завжди краще мати більшу кількість менших екземплярів. Запуск більшої кількості менших екземплярів означає більшу загальну сукупну ємність цих обмежень для кінцевої точки.

Ще одна перевага горизонтального масштабування з меншими екземплярами полягає в тому, що ви зменшуєте ризик виснаження ЦП і ресурсів пам’яті екземпляра під час запуску MMS із вищими рівнями паралелізму разом із більшою кількістю моделей у пам’яті (як описано раніше в цій публікації).

Уникати побиття – це спільна відповідальність

Молотіння у MME – це коли моделі часто вивантажуються з пам’яті та перезавантажуються через брак пам’яті, або в окремому екземплярі, або в сукупності в кластері.

З точки зору використання, вам слід вибрати правильний розмір індивідуальних екземплярів кінцевих точок і правильний розмір загального розміру кластера MME, щоб забезпечити достатній обсяг пам’яті, доступний для екземпляра, а також у сукупності для кластера для вашого випадку використання. Парк маршрутизаторів платформи MME також максимізує використання кешу.

Не будьте агресивними, розміщуючи занадто багато моделей у меншій кількості більших екземплярів пам’яті

Пам’ять — це не єдиний ресурс екземпляра, про який слід пам’ятати. Інші ресурси, як-от ЦП, можуть бути стримуючим фактором, як видно з наведених нижче результатів тестування навантаження. У деяких інших випадках ми також спостерігали, як інші ресурси ядра, як-от ідентифікатори процесів, були вичерпані на екземплярі через комбінацію занадто великої кількості завантажених моделей і основного фреймворку ML (наприклад, TensorFlow), що породжує потоки для кожної моделі, які були кратними доступним vCPU.

Наступний тест продуктивності демонструє приклад обмеження ЦП, що впливає на затримку моделі. У цьому тесті кінцева точка одного екземпляра з великим екземпляром, маючи більш ніж достатньо пам’яті, щоб зберегти в пам’яті всі чотири моделі, створила порівняно нижчу затримку моделі під навантаженням порівняно з кінцевою точкою з чотирма меншими екземплярами.

затримка моделі кінцевої точки окремого екземпляра

використання центрального процесора та пам'яті в єдиному екземплярі

затримка моделі кінцевої точки чотирьох екземплярів

використання ЦП і пам'яті чотирьох екземплярів

Щоб досягти як продуктивності, так і економічності, виберіть правильний розмір кластера MME із більшою кількістю менших екземплярів, які в сукупності забезпечать вам оптимальну пам’ять і потужність ЦП, водночас відносно однакові за ціною з меншою кількістю, але більших екземплярів пам’яті.

Ментальна модель для оптимізації MME

Є чотири ключові показники, які ви завжди повинні враховувати під час правильного визначення розміру MME:

• Кількість і розмір моделей
• Кількість унікальних моделей, викликаних у певний час
• Тип і розмір екземпляра
• Кількість екземплярів за кінцевою точкою

Почніть з перших двох пунктів, тому що вони інформують третій і четвертий. Наприклад, якщо за кінцевою точкою недостатньо екземплярів для кількості або розміру унікальних моделей, які у вас є, сукупна пам’ять для кінцевої точки буде низька, і ви побачите нижчий коефіцієнт звернень до кешу та перевантаження на рівні кінцевої точки, оскільки MME буде часто завантажувати та вивантажувати моделі в пам’ять і з неї.

Подібним чином, якщо виклики для унікальних моделей перевищують загальну пам’ять усіх екземплярів за кінцевою точкою, ви побачите нижче звернення до кешу. Це також може статися, якщо розмір екземплярів (особливо обсяг пам'яті) занадто малий.

Вертикальне масштабування з дуже великими екземплярами пам’яті також може призвести до проблем, оскільки, хоча моделі можуть поміститися в пам’ять, інші ресурси, як-от процеси ЦП і ядра, а також обмеження на потоки можуть бути вичерпані. Завантажте горизонтальне масштабування на етапі підготовки до виробництва, щоб отримати оптимальну кількість і розмір екземплярів для вашого MME.

Підсумки

У цій публікації ви глибше зрозуміли платформу MME. Ви дізналися, для яких технічних випадків використання MME підходить, і розглянули архітектуру платформи MME. Ви отримали глибше розуміння ролі кожного компонента в архітектурі MME і компонентів, на продуктивність яких ви можете безпосередньо впливати. Нарешті, ви глибше розглянули параметри конфігурації, які можна налаштувати, щоб оптимізувати MME для вашого випадку використання, і показники, які слід контролювати, щоб підтримувати оптимальну продуктивність.

Щоб почати роботу з MME, перегляньте Мультимодельні кінцеві точки Amazon SageMaker із використанням XGBoost та Розмістіть кілька моделей в одному контейнері за однією кінцевою точкою.

Про автора

Сайєд Джаффрі є головним архітектором рішень в AWS. Він співпрацює з низкою компаній із середніх організацій, великих підприємств, фінансових служб і незалежних постачальників програмного забезпечення, щоб допомогти їм створювати та використовувати економічно ефективні та масштабовані програми AI/ML у хмарі.

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