Економічний висновок машинного навчання за допомогою мультифреймворкових моделей на Amazon SageMaker 

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

Amazon SageMaker багатоконтейнерні кінцеві точки (MCE) дозволяють групувати моделі на різних платформах і розгортати їх на одному хості, створюючи єдину кінцеву точку. Ви можете надати контейнери для різних фреймворків, які використовуєте для створення моделей, і SageMaker візьме всі ці контейнери та розмістить їх за однією кінцевою точкою. Наприклад, у вас можуть бути завантажені моделі PyTorch і TensorFlow на двох виділених кінцевих точках, які обслуговують однакові або абсолютно різні варіанти використання, і обидві ці моделі мають періодичний вхідний трафік, не використовуючи ресурси в повній мірі. У такому сценарії ви можете об’єднати їх за допомогою контейнерів в одну кінцеву точку за допомогою MCE, покращуючи використання ресурсів і одночасно зменшуючи витрати, пов’язані з тим, що обидві моделі обслуговуються з різних кінцевих точок.

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

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

Шаблони виклику MCE

Прямий виклик SageMaker MCE корисний у випадках, коли ви об’єднуєте непов’язані моделі в кінцеву точку MCE або виконуєте A/B-тест між моделями за кінцевою точкою MCE, щоб оцінити їх продуктивність. Ви можете викликати певний контейнер безпосередньо під час виклику API та отримати прогноз із цієї моделі.

За допомогою послідовного виклику ви можете з’єднати 2–15 контейнерів, а вихід одного стане входом наступного контейнера. Це ідеальний випадок використання, якщо, наприклад, у вас є багатоетапний конвеєр передбачення, де модель навчання Scikit використовується для проміжного передбачення, а результат передається в модель TensorFlow для остаточного висновку. Замість того, щоб розгортати їх як різні кінцеві точки, а іншу програму чи завдання оркеструвати ними та здійснювати кілька викликів API, ви можете розгорнути їх як SageMaker MCE, абстрагуючи логіку та налаштувавши їх для послідовного виклику, де SageMaker керує передачею даних між одним контейнером до іншого автоматично та видає вихід кінцевого контейнера клієнту, який надсилає запит API.

Послідовний виклик SageMaker MCE принципово відрізняється від конвеєра послідовного виведення SageMaker (докладніше в розділах нижче). Послідовний конвеєр виведення більше спрямований на організацію складних робочих процесів машинного навчання, таких як попередня обробка даних, побудова ансамблю моделей, впровадження умовних перевірок для визначення, яку модель викликати, або постобробка прогнозу, що включає бізнес-логіку перед тим, як прогноз надсилається до подальших програм. . Навпаки, послідовний виклик MCE призначений для з’єднання 2–14 моделей у конвеєр для висновку, при цьому кожна модель приймає прогноз попередньої моделі як вхідні дані.

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

Давайте розглянемо кілька варіантів використання та побачимо, як ви можете використовувати SageMaker MCE для оптимізації висновків ML.

Варіанти використання SageMaker MCE

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

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

У цьому прикладі ми маємо дві моделі (englishModel та germanModel), і ми визначаємо контейнери в SageMaker create_model побудувати та визначити InferenceExecutionConfig як «Пряме». Тепер ми можемо викликати кінцеву точку для висновку та визначити TargetContainerHostname як englishModel or germanModel залежно від клієнта, який здійснює виклик API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Ви також можете використовувати прямий виклик у MCE для запуску тестів A/B для порівняння продуктивності між моделями.

Наступна діаграма ілюструє нашу архітектуру.

Подібним чином, в інших випадках використання ML, коли навчена модель використовується для обробки запиту, модель отримує дані у форматі, який потрібно попередньо обробити (наприклад, додати), перш ніж їх можна буде передати в алгоритм для висновку. Коли алгоритми ML об’єднані разом, вихідні дані однієї моделі служать вхідними для наступної перед досягненням кінцевого результату. У цьому випадку ви можете створити послідовний конвеєр SageMaker MCE, де контейнери спілкуються один з одним у послідовності, визначеній у create_model конструювати замість того, щоб розгортати кожну з моделей у різних кінцевих точках і писати незалежну логіку для полегшення потоку даних між усіма цими моделями та викликами API. Наступна діаграма ілюструє цю архітектуру.

Для цього випадку ми використовуємо такий код:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

У цьому прикладі ми маємо два контейнери обробки (Processing-1 та Processing-2) для обробки функцій і перетворень даних, а також два контейнери висновків (Inference-1 та Inference-2), щоб запустити прогнозування моделі ML на попередньо оброблених даних. The PipelineModel екземпляр дозволяє визначити конвеєр виведення, що складається з лінійної послідовності чотирьох контейнерів, які обробляють запити на виведення даних. Контейнери розташовані в одному екземплярі, що дає змогу виконувати висновки з низькою затримкою.

Масштабуйте мультимодельні кінцеві точки для великої кількості моделей

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

Масштабування кінцевих точок MCE також є простим за допомогою SageMakerVariantInvocationsPerInstance попередньо визначену метрику, яка показує середню кількість разів на хвилину, коли кожен екземпляр кінцевої точки моделі викликається для визначення TargetScaling політики. SageMaker динамічно регулює кількість екземплярів, наданих для моделі, у відповідь на зміни у вашому робочому навантаженні. Коли робоче навантаження зростає, автомасштабування підключає до мережі більше екземплярів і завантажує цільові моделі та контейнери, щоб продовжувати обслуговувати запити. Коли робоче навантаження зменшується, автомасштабування видаляє непотрібні екземпляри та розвантажує контейнери моделі, щоб контейнери не споживали ресурси, і ви не платили за екземпляри, які не використовуєте. Час виконання першого запиту щодо даної моделі має додаткову затримку (так званий холодний старт) для завантаження моделі з Служба простого зберігання Amazon (Amazon S3) і завантажте його в пам’ять. Наступні виклики завершуються без додаткових витрат, оскільки модель уже завантажено. Перегляньте наступний код:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Дотримуючись попереднього прикладу налаштування політики, ми використовуємо SageMakerVariantInvocationsPerInstance попередньо визначену метрику, щоб налаштувати кількість екземплярів варіантів, щоб кожен екземпляр мав InvocationsPerInstance метрика 70.

Ми також можемо масштабувати MCE SageMaker на основі наших власних метрик, як-от CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationабо DiskUtilization, щоб збільшити чи зменшити кількість екземплярів на основі використання певного ресурсу. Для отримання додаткової інформації див Автоматично масштабуйте моделі Amazon SageMaker.

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

Безпечні MCE

Для MCE з прямим викликом кілька контейнерів розміщуються в одному екземплярі за допомогою спільної пам’яті та обсягу зберігання. Важливо захищати контейнери, підтримувати правильне відображення запитів на цільові контейнери та надавати користувачам правильний доступ до цільових контейнерів. Можна обмежити invoke_endpoint доступ до обмеженого набору контейнерів усередині MCE за допомогою sagemaker:TargetContainerHostname Управління ідентифікацією та доступом AWS (IAM) ключ умови. SageMaker використовує Ролі IAM щоб забезпечити політики на основі ідентифікації IAM, які ви використовуєте для визначення дозволених або заборонених дій і ресурсів, а також умов, за яких дії дозволені або заборонені. У наведених нижче політиках показано, як обмежити виклики певними контейнерами в кінцевій точці:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Відстежуйте мультимодельні кінцеві точки за допомогою показників Amazon CloudWatch

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

• ModelLoadingWaitTime – Інтервал часу, протягом якого запит виклику очікує завантаження або завантаження цільової моделі для виконання висновку.
• ModelUnloadingTime – Інтервал часу, необхідний для вивантаження моделі через контейнер UnloadModel Виклик API.
• Час завантаження моделі – Інтервал часу, потрібний для завантаження моделі з Amazon S3.
• ModelLoadingTime – Інтервал часу, необхідний для завантаження моделі через контейнер LoadModel Виклик API.
• ModelCacheHit - Кількість InvokeEndpoint запити, надіслані до кінцевої точки, де вже завантажено модель. Беручи Average Статистика показує співвідношення запитів, в яких модель вже була завантажена.
• LoadedModelCount – Кількість моделей, завантажених у контейнери кінцевої точки. Ця метрика випускається для кожного екземпляра. The Average статистика з періодом 1 хвилина повідомляє вам про середню кількість моделей, завантажених на екземпляр, і Sum статистика повідомляє вам про загальну кількість моделей, завантажених у всіх екземплярах у кінцевій точці. Моделі, які відстежує цей показник, не обов’язково є унікальними, оскільки ви можете завантажити модель у кілька контейнерів у кінцевій точці.

Є також кілька інших метрик, які використовуються кожним контейнером, що працює на примірнику, наприклад Invocations із зазначенням кількості InvokeEndpoint запити, надіслані до контейнера всередині кінцевої точки, ContainerLatency вказуючи час, потрібний кінцевій точці для відповіді цільового контейнера або всіх контейнерів у послідовному виклику, як це видно з SageMaker, і CPUUtilization та MemoryUtilizaton із зазначенням блоків ЦП і відсотка пам'яті.

Висновок

У публікації ми обговорювали, як багатоконтейнерні кінцеві точки SageMaker можуть бути корисними для оптимізації витрат і використання ресурсів. Приклади використання MCE включають, але не обмежуються, наступне:

• Розміщення моделей у різних фреймворках (таких як TensorFlow, PyTorch і Scikit-learn), які не мають достатнього трафіку для насичення повної потужності екземпляра
• Розміщення моделей з одного фреймворку з різними алгоритмами ML (такими як рекомендації, прогнозування або класифікація) і функціями обробки
• Порівняння подібних архітектур, що працюють на різних версіях фреймворку (наприклад, TensorFlow 1.x проти TensorFlow 2.x) для таких сценаріїв, як A/B-тестування

MCE SageMaker підтримують розгортання до 15 контейнерів на кінцевих точках у реальному часі та їх незалежний виклик для висновку з низькою затримкою та економії коштів. Моделі можуть бути повністю гетерогенними, з власним незалежним стеком для сервірування. Ви можете викликати ці контейнери послідовно або незалежно для кожного запиту. Безпечне розміщення кількох моделей із різних фреймворків на одному екземплярі може заощадити до 90% у порівнянні з розміщенням моделей у виділених кінцевих точках з одним екземпляром.

Про авторів

Дхавал Патель є головним архітектором машинного навчання в AWS. Він працював з різними організаціями — від великих підприємств до стартапів середнього розміру — над проблемами, пов’язаними з розподіленими обчисленнями та штучним інтелектом. Він зосереджується на глибокому навчанні, включаючи домени НЛП та комп’ютерного зору. Він допомагає клієнтам досягти високоефективного моделювання на Amazon SageMaker.

Вікрам Еланго є старшим архітектором рішень спеціаліста зі штучного інтелекту/ML в Amazon Web Services, що базується у Вірджинії, США. Vikram допомагає клієнтам глобальної фінансової та страхової галузі завдяки розробці та інтелектуальному лідерству створювати та розгортати програми машинного навчання в масштабі. Зараз він зосереджений на обробці природної мови, відповідальному штучному інтелекті, оптимізації висновків і масштабуванні ML на підприємстві. У вільний час він любить подорожувати, піти в походи, готувати їжу та кемпінг зі своєю сім’єю.

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