Масштабирование модели основания на сотни моделей с помощью Amazon SageMaker – Часть 1

Увеличение масштаба модели основы на несколько сотен моделей с помощью Amazon SageMaker - Часть 1

Поскольку демократизация моделей основ (FMs) становится все более распространенной, а спрос на услуги, поддерживаемые искусственным интеллектом (AI), увеличивается, провайдеры программного обеспечения в виде сервиса (SaaS) ищут возможность использовать платформы машинного обучения (ML), поддерживающие несколько арендаторов – для внутренних клиентов из числа данных ученыхкомпании и внешних клиентов. Всё больше компаний осознают ценность использования FM для создания высокоиндивидуализированного и эффективного контента для своих клиентов. Тонкая настройка FM на основе ваших собственных данных может значительно повысить точность модели для вашего конкретного случая использования, будь то генерация электронных писем продажи с использованием контекста посещения страницы, генерация ответов на поиск, настроенных на услуги компании, или автоматизация обслуживания клиентов путем обучения на исторических разговорах.

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

Amazon SageMaker предлагает различные варианты вывода ML, включая реальное время, асинхронное и пакетное преобразование. В этой статье речь пойдет о предоставлении рекомендаций по размещению FM в масштабе экономичный способ. Конкретнее, рассматриваются быстрые и отзывчивые методы вывода в реальном времени, исследуются различные варианты реального времени для FM.

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

• Сократите задержку вывода реального времени с использованием стратегий маршрутизации Amazon SageMaker
• Упакуйте и разверните классические модели машинного обучения и LLMs легко с помощью Amazon SageMaker, часть 2 Интерактивные пользовательские взаимодействия в SageMaker Studio
• Упаковка и развертывание классических моделей машинного обучения и моделей линейного логистического менеджмента с помощью Amazon SageMaker, часть 1 улучшения PySDK

Сервис SageMaker Inference является полностью управляемым сервисом размещения ML. Он поддерживает создание генеративных приложений искусственного интеллекта, соответствующих стандартам регулирования, таким как FedRAMP. SageMaker обеспечивает экономичное масштабирование для рабочих нагрузок вывода высокого пропускного режима. Он поддерживает разнообразные рабочие нагрузки, включая реальное время, асинхронное и пакетное преобразование на аппаратных платформах, таких как AWS Inferentia, AWS Graviton, графические процессоры NVIDIA и процессоры Intel. SageMaker предоставляет полный контроль над оптимизациями, изоляцией рабочей нагрузки и контейнеризацией. Он позволяет создавать решения генеративного искусственного интеллекта в виде службы в масштабе с поддержкой множественных моделей и распределенным развертыванием контейнеров.

Проблемы с размещением моделей основ в масштабе

Ниже приведены некоторые проблемы с размещением FM для вывода в масштабе:

• Большой объем памяти – FM с десятками или сотнями миллиардов параметров модели часто превышают объем памяти одного ускорителя.
• Медленные трансформаторы – Авторегрессивное декодирование в FM, особенно с длинными входными и выходными последовательностями, усиливает операции ввода-вывода памяти. Это приводит к неприемлемо длительным периодам задержки, неблагоприятно влияющим на вывод в режиме реального времени.
• Стоимость – FM требуют ускорителей машинного обучения, обеспечивающих высокую память и вычислительную мощность. Достижение высокой пропускной способности и низкой задержки без ущерба одному из этих факторов требует специализированных навыков, позволяющих глубоко понимать соптимизацию аппаратно-программных решений.
• Удлиненное время выхода на рынок – Оптимальная производительность FM требует тщательной настройки. Этот специализированный процесс настройки, вместе с сложностями управления инфраструктурой, приводит к увеличению циклов выхода на рынок.
• Изоляция рабочей нагрузки – Размещение FM в масштабе создает проблемы в минимизации радиуса поражения и обработке шумных соседей. Способность масштабировать каждый FM в соответствии с модельными трафиковыми шаблонами требует серьезной работы.
• Масштабирование до сотен FM – Работа с сотнями FM одновременно влечет за собой значительные операционные затраты. Управление конечными точками, правильное разделение и выделение ускорителей, а также масштабирование для каждой модели – все это задачи, усложняющиеся с увеличением числа развертываемых моделей.

Функции оценки

Выбор правильной опции размещения важен, потому что это влияет на конечных пользователей, обслуживаемых вашими приложениями. В этом целях мы пользуемся понятием функций оценки, созданных Нилом Фордом и его коллегами из партнерской компании AWS Thought Works в их работе Building Evolutionary Architectures. Функции оценки предоставляют рекомендации по различным вариантам размещения на основе ваших целей. Функции оценки помогают получить необходимые данные для планируемой эволюции вашей архитектуры. Они устанавливают измеряемые значения для оценки того, насколько решение близко к достижению установленных целей. Функции оценки могут и должны быть адаптированы по мере изменения архитектуры, чтобы указывать на желаемый процесс изменения. Это предоставляет архитекторам инструмент для руководства своими командами, сохраняя при этом автономию команды.

Мы предлагаем рассмотреть следующие фитнес-функции при выборе подходящей опции для вывода ФМ в масштабе и с оптимальным соотношением стоимости:

• Размер основной модели – ФМ основаны на трансформерах. Трансформеры медленны и требуют много памяти при генерации длинных текстовых последовательностей из-за огромного размера моделей. Большие языковые модели (БЯМ) являются типом ФМ, которые при использовании для генерации текстовых последовательностей требуют огромных вычислительных мощностей и испытывают трудности с доступом к доступной памяти высокой пропускной способности (HBM) и вычислительной мощности. Это происходит потому, что значительная часть доступной пропускной способности памяти потребляется загрузкой параметров модели и процессом авторегрессивного декодирования. В результате, даже при использовании больших вычислительных мощностей, ФМ ограничены вводом/выводом памяти и вычислительными ограничениями. Поэтому размер модели определяет множество решений, таких как, поместится ли модель на один ускоритель или понадобятся ли несколько ускорителей ИИ, использующих разделение модели на экземпляр для выполнения вывода с более высокой пропускной способностью. Модели с более чем 3 миллиардами параметров обычно начинают требовать несколько ускорителей ИИ, поскольку модель может не поместиться в одно устройство ускорения.
• Производительность и латентность вывода ФМ – Многие модели и приложения машинного обучения имеют критические требования к латентности, при которых латентность вывода ФМ должна находиться в пределах, определенных сервисным уровнем. Латентность вывода ФМ зависит от множества факторов, включая:
  • Размер модели ФМ – Размер модели, включая квантизацию во время выполнения.
  • Оборудование – Вычислительная мощность (TFLOPS), размер и пропускная способность HBM, пропускная способность сети, скорость внутриэкземплярного межсоединения и пропускная способность хранения.
  • Среда программного обеспечения – Сервер моделей, библиотека параллельной обработки моделей, оптимизирующий движок модели, производительность коллективной коммуникации, архитектура модельной сети, квантизация и платформа машинного обучения.
  • Подсказка – Длина ввода и вывода и гиперпараметры.
  • Латентность масштабирования – Время масштабирования в ответ на трафик.
  • Латентность холодного старта – Функции, такие как предварительная загрузка модели, могут сократить латентность холодного старта при загрузке ФМ.
• Изоляция рабочей нагрузки – Это относится к требованиям изоляции рабочей нагрузки с точки зрения регулирования и соответствия, включая защиту конфиденциальности и целостности моделей и алгоритмов искусственного интеллекта, конфиденциальности данных во время вывода ИИ и защиту интеллектуальной собственности ИИ от несанкционированного доступа или с точки зрения управления рисками. Например, можно уменьшить влияние безопасности, целенаправленно уменьшив радиус поражения или предотвратив появление шумных соседей.
• Эффективность стоимости – Развертывание и поддержка модели ФМ и приложения машинного обучения в масштабируемой среде являются важным бизнес-процессом, и затраты могут существенно варьироваться в зависимости от выбранных параметров инфраструктуры моделирования, варианта размещения модели, платформ машинного обучения, характеристик модели машинного обучения, оптимизаций, политики масштабирования и других факторов. Рабочие нагрузки должны использовать аппаратную инфраструктуру оптимально, чтобы обеспечить контроль стоимости. Эта фитнес-функция относится к стоимости инфраструктуры, которая является частью общей полной стоимости владения (TCO). Стоимость инфраструктуры включает затраты на хранение, сеть и вычисление. Также важно понимать другие компоненты TCO, включая операционные расходы и расходы на безопасность и соответствие. Операционные расходы – это совокупные затраты на эксплуатацию, контроль и поддержку инфраструктуры машинного обучения. Операционные расходы рассчитываются как количество требуемых инженеров в соответствии с каждым сценарием и годовая зарплата инженеров, агрегированных за определенный период. Они автоматически снижаются до нуля для каждой модели в случае отсутствия трафика для экономии затрат.
• Масштабируемость – Это включает в себя:
  • Оперативные накладные расходы при управлении сотнями ФМ для вывода на платформе с множественным использованием.
  • Возможность упаковки нескольких ФМ в одну конечную точку и масштабирование для каждой модели.
  • Поддержка масштабирования на уровне экземпляра и контейнера модели на основе образцов нагрузки.
  • Поддержка масштабирования до сотен ФМ на конечной точке.
  • Поддержка первоначального размещения моделей во флоте и обработка нехватки ускорителей.

Представление измерений в фитнес-функциях

Мы используем круговую диаграмму, иногда называемую радарной диаграммой, для представления измерений в фитнес-функциях. Круговая диаграмма часто используется, когда вам нужно отобразить данные по нескольким уникальным измерениям. Эти измерения обычно являются количественными и, как правило, варьируются от нуля до максимального значения. Диапазон каждого измерения нормализован по отношению друг к другу, так что при построении круговой диаграммы длина линии от нуля до максимального значения измерения будет одинаковой для каждого измерения.

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

Идеально, вам хотелось бы, чтобы форма была равносторонней (пентагон). Это показывает, что вы способны оптимизировать все функции приспособленности. Но реальность в том, что достичь такой формы будет сложно – приоритизация одной функции приспособленности будет влиять на линии других радиусов. Это означает, что всегда будет компромисс в зависимости от того, что является наиболее важным для вашего приложения искусственного интеллекта, и у вас будет график, который будет смещен к определенному радиусу. Это критерий, который вы можете готовы понизить в приоритете в пользу других в зависимости от того, как вы оцениваете каждую функцию. В нашей диаграмме веса метрик каждой функции приспособленности определяются следующим образом – чем ниже значение, тем менее оптимально это для данной функции приспособленности (за исключением размера модели, в этом случае чем выше значение, тем больше размер модели).

Например, рассмотрим случай использования большой модели суммаризации (например, Anthropic Claude) для создания кратких описаний рабочих случаев и взаимодействий с клиентами на основе данных случаев и истории клиентов. У нас есть следующая диаграмма паука.

Поскольку это может включать конфиденциальные данные клиентов, вы решаете изолировать эту рабочую нагрузку от других моделей и разместить ее на отдельной точке входа для каждой FM. Это может затруднить масштабирование, так как вам придется запускать и управлять отдельными точками входа для каждой FM. Используемое вами приложение искусственного интеллекта используется службовыми агентами в реальном времени, поэтому задержка и пропускная способность имеют приоритет, отсюда и необходимость использования более крупных типов экземпляров, таких как P4De. В этой ситуации стоимость может оказаться выше, потому что приоритетом является изоляция, задержка и пропускная способность.

Еще один пример – это создание чат-бота для вопросов и ответов, настраиваемого для большого числа клиентов. Ниже приведена диаграмма паука, отражающая их приоритеты.

Каждая ситуация с чат-ботом может требовать индивидуальной настройки для каждого конкретного клиента. Используемые модели могут быть относительно меньшими (FLAN-T5-XXL, Llama 7B и k-NN), и каждый чат-бот работает в определенное время для разных часовых поясов каждый день. В решении также может быть включена методика Retrieval Augmented Generation (RAG) с базой данных, содержащей все элементы базы знаний, которые будут использоваться для вывода в реальном времени. Через этого чат-бота не передается никакие данные, связанные с конкретными клиентами. Задержки при запуске не являются критичными, так как чат-боты работают по расписанию. В этом случае вы можете выбрать архитектуру множественных моделей и, возможно, сократить затраты, используя более маленькие типы экземпляров (например, G5) и разместив несколько моделей на каждой точке входа в масштабе. За исключением изоляции рабочей нагрузки, функции приспособленности в этом случае могут иметь более равные приоритеты, и компромиссы уменьшены в определенной степени.

Конечный пример – приложение для генерации изображений с использованием модели, такой как Stable Diffusion 2.0, имеющей 3,5 миллиарда параметров. Наша диаграмма имеет следующий вид.

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

Применение функций приспособленности для выбора варианта хостинга FM

В этом разделе мы покажем вам, как применить предшествующие функции приспособленности для выбора правильного варианта хостинга FM на SageMaker FMs в масштабе.

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

Единые модельные точки SageMaker позволяют вам размещать одну FM на контейнере, размещенном на выделенных инстансах для низкой задержки и высокой пропускной способности. Эти точки являются полностью управляемыми и поддерживают автомасштабирование. Вы можете настроить единый модельный интерфейс в качестве предоставленной точки подключения, где вы передаете конфигурацию инфраструктуры точки подключения, такую ​​как тип и количество инстансов, где SageMaker автоматически запускает вычислительные ресурсы и масштабирует их в зависимости от политики автомасштабирования. Вы можете масштабировать размещение сотен моделей с использованием нескольких единичных модельных точек и использовать архитектуру на основе ячеек для увеличения устойчивости и снижения радиуса поражения.

При оценке функций приспособленности для предоставленной точки подключения одного образца рассмотрите следующее:

• Размер основной модели – Это подходит, если у вас есть модели, которые не помещаются в память одного ускорителя машинного обучения и, следовательно, требуют нескольких ускорителей на одном инстансе.
• Производительность и задержка вывода FM – Это актуально для задач генеративного искусственного интеллекта с задержкой.
• Изоляция рабочей нагрузки – Ваше приложение может требовать изоляции на уровне инстанса в облаке Amazon Elastic Compute Cloud (Amazon EC2) из-за требований безопасности соблюдения. Каждая FM получит отдельную точку входа вывода и не будет разделять экземпляр EC2 с другой моделью. Например, вы можете изолировать рабочую нагрузку по выводу модели, связанную с законом о портативной и доступной медицинской истории (HIPAA) (например, модель обнаружения PHI), в отдельной точке доступа с параметрами конфигурации отдельной группы безопасности с сетевой изоляцией. Вы можете изолировать свою рабочую нагрузку по выводу модели на базе графического процессора от других на основе экземпляров EC2 на базе Nitro, таких как p4dn, чтобы изолировать их от менее доверенных рабочих нагрузок. Экземпляры базирующиеся на системе Nitro обеспечивают уникальный подход к виртуализации и изоляции, позволяя вам защищать и изолировать обработку конфиденциальных данных от операторов и программного обеспечения AWS в любое время. Этот вариант также поддерживает развертывание моделей AWS Marketplace, предоставляемых сторонними поставщиками моделей на SageMaker.

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

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

Многомодельные точки являются лучшим выбором, если вам необходимо размещать небольшие модели, которые все могут поместиться в одну память ускорителя машинного обучения на инстансе. Эту стратегию следует рассматривать, если у вас есть большое количество (до тысяч) моделей примерно одинакового размера (менее 1 миллиарда параметров), которые можно обслуживать через общий контейнер на одном инстансе и не требуется одновременный доступ ко всем моделям. Вы можете загрузить модель, которую нужно использовать, а затем выгрузить ее для другой модели.

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

Наконец, многомодельные точки подходят для приложений, которые могут допускать время от времени задержку “холодного” старта, потому что модели, которые редко используются, могут быть выгружены для предпочтения часто запрашиваемых моделей. Если у вас есть большое количество редко используемых моделей, многомодельная точка может эффективно обслуживать этот трафик и обеспечить значительные экономии средств.

Рассмотрите следующее при оценке, когда использовать многомодельные точки:

• Размер основной модели – У вас могут быть модели, которые помещаются в память одного ускорителя машинного обучения на инстансе, и, следовательно, не требуют нескольких ускорителей.
• Производительность и задержка вывода FM – У вас могут быть задачи генеративного искусственного интеллекта, которые могут допустить задержку “холодного” старта, когда модель запрашивается и отсутствует в памяти.
• Изоляция рабочей нагрузки – Рассмотрите возможность совместного использования всех моделей с одним контейнером.
• Масштабируемость – Рассмотрите следующее:
  • Вы можете упаковать несколько моделей в одну точку подключения и выполнять масштабирование для каждой модели и экземпляра ML.
  • Вы можете включить автомасштабирование на уровне инстанса в зависимости от образца рабочей нагрузки.
  • Многомодельные точки поддерживают масштабирование до тысяч моделей на одну точку подключения. Вам не нужно поддерживать масштабирование и конфигурацию развертывания для каждой модели отдельно.
  • Вы можете использовать горячее развертывание, когда модель запрашивается в запросе вывода.
  • Вы можете динамически загружать модели в соответствии с запросом вывода и выгружать их при возникновении давления на память.
  • Вы можете время от времени разделять ресурсы с моделями.
• Эффективность стоимости – Рассмотрите возможность временного совместного использования ресурсов для моделей путем динамической загрузки и выгрузки моделей, что приводит к сэкономленным средствам.

Модель SageMaker с InferenceComponents

Новая модель SageMaker с InferenceComponents предоставляет масштабируемый подход к размещению нескольких FM в одной модели и масштабированию на уровне модели. Она позволяет точно управлять выделением ресурсов (ускорители, память, ЦП) и устанавливать автоматическое масштабирование для каждой модели, чтобы обеспечить гарантированную производительность и предсказуемую производительность. Вы можете управлять использованием вычислений для разных моделей по отдельности. Если у вас есть много моделей разных размеров и моделей, которые не помещаются в память одного ускорителя, это лучшая опция. Он также позволяет масштабироваться до нуля для экономии затрат, но требования к задержке вашего приложения должны быть достаточно гибкими, чтобы учесть время запуска моделей. Эта опция позволяет максимально гибко использовать вычисления, если уровень изоляции на уровне контейнера для каждого клиента или FM достаточен. Для получения более подробной информации о новой модели SageMaker с InferenceComponents обратитесь к подробной статье Уменьшение затрат на развертывание модели в среднем на 50% с использованием последних возможностей Amazon SageMaker.

Учитывайте следующее при определении, когда следует использовать модель с InferenceComponents:

• Размер основной модели – это подходит для моделей, которые не помещаются в память одного ускорителя и поэтому требуют несколько ускорителей в одном экземпляре.
• Производительность и задержка вывода FM – это подходит для задач генерации искусственного интеллекта с требованиями к задержке.
• Изоляция рабочей нагрузки – у вас могут быть приложения, где достаточно изоляции на уровне контейнера.
• Масштабируемость – учитывайте следующее:
  • Вы можете упаковывать несколько FM в одну модель и масштабироваться по отдельным моделям.
  • Вы можете включить масштабирование на уровне экземпляра и контейнера модели на основе шаблонов рабочей нагрузки.
  • Этот метод поддерживает масштабирование до сотен FM на одну модель. Вам не нужно настраивать политику автоматического масштабирования для каждой модели или контейнера.
  • Он поддерживает начальное размещение моделей во флоте и обработку недостаточного количества ускорителей.
• Экономичность – вы можете масштабироваться для каждой модели до нуля, когда отсутствует трафик для экономии затрат.

Упаковка нескольких FM на одном модельном узле: группировка моделей

Определение стратегии архитектуры вывода, которую вы используете в SageMaker, зависит от приоритетов и требований вашего приложения. Некоторые поставщики SaaS продаются в регулируемых средах, где требуются строгие условия изоляции. Им необходима опция, позволяющая развертывать некоторые или все их FM в выделенной модели. Но для оптимизации затрат и получения экономической эффективности, поставщикам SaaS также необходимы многопользовательские среды, где они могут размещать несколько FM на общем наборе ресурсов SageMaker. Большинство организаций, скорее всего, будут иметь гибридное окружение размещения, где они будут иметь как модельные конечные точки для одной модели, так и конечные точки с несколькими моделями или контейнерами в составе их архитектуры SageMaker.

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

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

Группировка моделей для MME

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

“`html

Модели, сгруппированные на MME, должны иметь стаггерированные паттерны трафика, чтобы позволить вам разделить вычисления между моделями для вывода результатов. Ваши паттерны доступа и задержка вывода также должны учитывать время “холодного” запуска при переключении между моделями.

Вот некоторые рекомендуемые критерии для группировки моделей для MME:

• Меньшие модели – Используйте модели с менее чем 1 миллиард параметров.
• Размер модели – Группируйте модели с похожим размером и размещайте их в одной конечной точке.
• Задержка вызова – Группируйте модели с похожими требованиями к задержке вызова, которые могут терпеть “холодные” запуски.
• Аппаратное обеспечение – Группируйте модели, используя одинаковый тип подлежащего им экземпляра EC2.

Группировка моделей для конечной точки с инференс-компонентами

Конечная точка SageMaker с InferenceComponents наилучшим образом подходит для размещения больших FMs (более 1 миллиарда параметров) в масштабе, требующем нескольких ускорителей или устройств ML на экземпляре EC2. Эта опция подходит для нагрузочных рабочих нагрузок с требованиями к задержке и приложений, где уровень изоляции на уровне контейнера является достаточным. Вот некоторые рекомендуемые критерии для группировки моделей для конечной точки с несколькими InferenceComponents:

• Аппаратное обеспечение – Группируйте модели, используя одинаковый тип подлежащего им экземпляра EC2.
• Размер модели – Рекомендуется группировать модель на основе ее размера, но это необязательно.

Резюме

В этой статье мы рассмотрели три варианта реального времени для вывода ML (одиночные конечные точки, множественные конечные точки и конечные точки с InferenceComponents) в SageMaker для эффективного размещения масштабных FMs с оптимальным соотношением стоимости и производительности. Вы можете использовать пять функций пригодности, чтобы выбрать подходящую опцию размещения SageMaker для масштабных FMs. Группируйте FMs и размещайте их на конечных точках вывода SageMaker, используя рекомендованные критерии группировки. Помимо обсужденных функций пригодности, вы можете использовать следующую таблицу, чтобы определить, какая Общая опция размещения SageMaker лучше всего подходит для вашего случая использования. Вы можете найти примеры кода для каждой из опций размещения FM на SageMaker в следующих репозиториях на GitHub: одиночная конечная точка SageMaker, множественные конечные точки и конечная точка InferenceComponents.

.	Конечная точка с одной моделью	Конечная точка с множественными моделями	Конечная точка с инференс-компонентами
Жизненный цикл модели	API для управления	Динамический через путь Amazon S3	API для управления
Поддерживаемые типы экземпляров	ЦПУ, одно- и многоGPU, экземпляры на базе AWS Inferentia	ЦПУ, экземпляры на базе одного GPU	ЦПУ, одно- и многоGPU, экземпляры на базе AWS Inferentia
Детализация метрики	Конечная точка	Конечная точка	Конечная точка и контейнер
Гранулярность масштабирования	Экземпляр ML	Экземпляр ML	Контейнер
Поведение масштабирования	Независимое масштабирование экземпляра ML	Модели загружаются и выгружаются из памяти	Независимое масштабирование контейнера
Закрепление модели	.	Модели могут быть выгружены в зависимости от памяти	Каждый контейнер может быть настроен для всегда загруженного или выгруженного состояния
Требования к контейнеру	Предварительно построенный SageMaker, совместимый контейнер Bring Your Own Container (BYOC)	MMS, Triton, BYOC с контрактами MME	Предварительно построенный SageMaker, совместимый контейнер BYOC
Варианты маршрутизации	Случайный или наименее загруженный	Случайный, с “липким” окном популярности	Случайный или наименее загруженный
Выделение аппаратных ресурсов для модели	Посвящено одной модели	Общее использование	Посвящено каждому контейнеру
Количество поддерживаемых моделей	Одна	Тысячи</