Покращуйте високоцінні дослідження за допомогою Hugging Face і кінцевих точок асинхронного висновку Amazon SageMaker

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

читають: 0

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

Клієнти схильні перетравлювати інформацію з публічних і приватних джерел. Потім вони застосовують усталені або спеціальні моделі обробки природної мови (NLP), щоб узагальнити та визначити тенденцію та отримати ідеї на основі цієї інформації. Моделі НЛП, які використовуються для таких типів дослідницьких завдань, мають справу з великими моделями і зазвичай включають довгі статті, які потрібно узагальнити з урахуванням розміру корпусу, і виділених кінцевих точок, які наразі не оптимізовані за витратами. Ці програми отримують пакет вхідного трафіку в різний час доби.

Ми вважаємо, що клієнти отримають значну вигоду від можливості зменшувати масштаб до нуля та нарощувати свої можливості висновків за потреби. Це оптимізує витрати на дослідження та не погіршує якість висновків. У цьому дописі обговорюється, як Hugging Face разом з Amazon SageMaker асинхронний висновок може допомогти досягти цього.

Ви можете створювати моделі узагальнення тексту за допомогою кількох інфраструктур глибокого навчання, таких як TensorFlow, PyTorch і Apache MXNet. Ці моделі зазвичай мають велике вхідне навантаження з кількох текстових документів різного розміру. Розширені моделі глибокого навчання вимагають попередньої обробки з інтенсивними обчисленнями перед виведенням моделі. Тривалість обробки може становити кілька хвилин, що позбавляє можливості виконувати висновки в реальному часі шляхом передачі корисних даних через HTTP API. Натомість вам потрібно обробляти вхідні дані асинхронно зі сховища об’єктів, наприклад Служба простого зберігання Amazon (Amazon S3) з автоматичним формуванням черги та попередньо визначеним порогом паралельності. Система повинна мати можливість отримувати сповіщення про стан і зменшувати непотрібні витрати шляхом очищення ресурсів після виконання завдань.

SageMaker допомагає науковцям і розробникам даних готувати, створювати, навчати та швидко розгортати високоякісні моделі машинного навчання (ML), об’єднуючи широкий набір можливостей, спеціально створених для ML. SageMaker надає найдосконаліші контейнери з відкритим кодом для обслуговування моделей для XGBoost (контейнер, SDK), Scikit-Learn (контейнер, SDK), PyTorch (контейнер, SDK), TensorFlow (контейнер, SDK), і Apache MXNet (контейнер, SDK).

SageMaker пропонує чотири варіанти розгортання навчених моделей ML для створення висновків на основі нових даних.

Висновок у реальному часі Кінцеві точки підходять для робочих навантажень, які потрібно обробляти з низькими вимогами до затримки в порядку від мс до секунд.
Пакетне перетворення ідеально підходить для офлайн-прогнозування великих пакетів даних.
Безсерверний висновок Amazon SageMaker (у режимі попереднього перегляду та не рекомендований для виробничих робочих навантажень на момент написання цієї статті) — це спеціально створений варіант висновку, який полегшує вам розгортання та масштабування моделей ML. Безсерверний висновок ідеально підходить для робочих навантажень, які мають періоди простою між стрибками трафіку та можуть допускати холодний запуск.
Асинхронний висновок кінцеві точки ставлять вхідні запити в чергу. Вони ідеально підходять для робочих навантажень із великими розмірами запитів (до 1 ГБ), а час обробки висновків становить кілька хвилин (до 15 хвилин). Асинхронний висновок дає змогу заощадити на витратах завдяки автоматичному масштабуванню кількості екземплярів до нуля, коли немає запитів для обробки.

Огляд рішення

У цій публікації ми розгортаємо a Модель PEGASUS який був попередньо навчений робити резюме тексту з Обіймати обличчя до Послуги хостингу SageMaker. Для простоти ми використовуємо модель як є з Hugging Face. Однак ви можете точно налаштувати модель на основі спеціального набору даних. Ви також можете спробувати інші моделі, доступні в Hugging Face Model Hub. Ми також надаємо кінцеву точку асинхронного висновку, яка містить цю модель, з якої ви можете отримувати прогнози.

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

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

Ми також використовуємо Amazon CloudWatch метрики для моніторингу розміру черги, загального часу обробки та оброблених викликів.

На наступній діаграмі ми показуємо кроки, пов’язані з виконанням висновку за допомогою кінцевої точки асинхронного висновку.

Наші попередньо навчені PEGASUS Модель ML спочатку розміщується на кінцевій точці масштабування.
Користувач завантажує статтю, яку потрібно підсумувати, у вхідне відро S3.
Кінцева точка асинхронного висновку викликається за допомогою API.
Після завершення висновку результат зберігається у вихідному сегменті S3.
An Служба простих сповіщень Amazon Сповіщення (Amazon SNS) надсилається користувачеві з повідомленням про завершення успіху чи невдачі.

Створіть кінцеву точку асинхронного висновку

Ми створюємо кінцеву точку асинхронного висновку, подібну до кінцевої точки, розміщеної в реальному часі. Кроки включають створення моделі SageMaker, а потім налаштування кінцевої точки та її розгортання. Різниця між двома типами кінцевих точок полягає в тому, що конфігурація кінцевої точки асинхронного висновку містить AsyncInferenceConfig розділ. Тут ми вказуємо вихідний шлях S3 для результатів виклику кінцевої точки та додатково включаємо теми SNS для повідомлень про успіх і невдачу. Ми також вказуємо максимальну кількість одночасних викликів на екземпляр, визначену замовником. Перегляньте наступний код:

AsyncInferenceConfig={ "OutputConfig": { "S3OutputPath": f"s3://{bucket}/{bucket_prefix}/output", # Optionally specify Amazon SNS topics for notifications "NotificationConfig": { "SuccessTopic": success_topic, "ErrorTopic": error_topic, } }, "ClientConfig": { "MaxConcurrentInvocationsPerInstance": 2 #increase this value up to throughput peak for ideal performance } }

Докладніше про API для створення конфігурації кінцевої точки для асинхронного висновку див Створіть кінцеву точку асинхронного висновку.

Викликати кінцеву точку асинхронного висновку

На наступному знімку екрана показано коротку статтю, яку ми використовуємо як вхідне корисне навантаження:

Наступний код завантажує статтю як input.json файл до Amazon S3:

sm_session.upload_data( input_location, bucket=sm_session.default_bucket(), key_prefix=prefix, extra_args={"ContentType": "text/plain"})

Ми використовуємо URI Amazon S3 для вхідного файлу корисного навантаження для виклику кінцевої точки. Об’єкт відповіді містить місце виведення в Amazon S3 для отримання результатів після завершення:

response = sm_runtime.invoke_endpoint_async(EndpointName=endpoint_name, InputLocation=input_1_s3_location)
output_location = response['OutputLocation']

На наступному знімку екрана показано зразок результату після підсумовування:

Докладні відомості про API для виклику кінцевої точки асинхронного висновку див Викликати кінцеву точку асинхронного висновку.

Поставте в чергу запити на виклик із заданим користувачем паралельним доступом

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

Автоматичне масштабування примірників у кінцевій точці асинхронного висновку

Ми встановили політику автоматичного масштабування з мінімальною ємністю нуль і максимальною ємністю п’ять примірників. На відміну від кінцевих точок, розміщених у реальному часі, кінцеві точки асинхронного висновку підтримують масштабування екземплярів до нуля шляхом встановлення мінімальної ємності на нуль. Ми використовуємо ApproximateBacklogSizePerInstance метрика для конфігурації політики масштабування з цільовою невиконаною чергою в п’ять на екземпляр для подальшого масштабування. Ми встановлюємо час відновлення для ScaleInCooldown до 120 секунд і ScaleOutCooldown до 120 секунд. Значення для ApproximateBacklogSizePerInstance вибирається на основі трафіку та вашої чутливості до швидкості масштабування. Чим швидше ви розширюєтеся, тим менше ви зазнаєте витрат, але ймовірніше, що вам доведеться знову розширювати масштаб, коли надходять нові запити. Чим повільніше ви розширюєтеся, тим більше витрат ви несете, але менша ймовірність того, що ви матимете запит надходить, коли вас не вистачає.

client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services resource_id='endpoint/' + endpoint_name + '/variant/' + 'variant1' # This is the format in which application autoscaling references the endpoint response = client.register_scalable_target(
ServiceNamespace='sagemaker', #
ResourceId=resource_id,
ScalableDimension='sagemaker:variant:DesiredInstanceCount',
MinCapacity=0,
MaxCapacity=5
) response = client.put_scaling_policy(
PolicyName='Invocations-ScalingPolicy',
ServiceNamespace='sagemaker', # The namespace of the AWS service that provides the resource.
ResourceId=resource_id, # Endpoint name
ScalableDimension='sagemaker:variant:DesiredInstanceCount', # SageMaker supports only Instance Count
PolicyType='TargetTrackingScaling', # 'StepScaling'|'TargetTrackingScaling'
TargetTrackingScalingPolicyConfiguration={ 'TargetValue': 5.0, # The target value for the metric. 'CustomizedMetricSpecification': { 'MetricName': 'ApproximateBacklogSizePerInstance', 'Namespace': 'AWS/SageMaker', 'Dimensions': [{'Name': 'EndpointName', 'Value': endpoint_name }], 'Statistic': 'Average',
}, 'ScaleInCooldown': 120, # ScaleInCooldown - The amount of time, in seconds, after a scale-in activity completes before another scale in activity can start. 'ScaleOutCooldown': 120 # ScaleOutCooldown - The amount of time, in seconds, after a scale-out activity completes before another scale out activity can start.
# 'DisableScaleIn': True|False - indicates whether scale in by the target tracking policy is disabled.
# If the value is true, scale-in is disabled and the target tracking policy won't remove capacity from the scalable resource.
}
)

Докладніше про API для автоматичного масштабування кінцевої точки асинхронного висновку див Автоматичне масштабування кінцевої точки асинхронного висновку.

Налаштуйте сповіщення від кінцевої точки асинхронного висновку

Ми створюємо дві окремі теми SNS для сповіщень про успіх і помилку для кожного результату виклику кінцевої точки:

sns_client = boto3.client('sns')
response = sns_client.create_topic(Name="Async-Demo-ErrorTopic2")
error_topic = response['TopicArn']
response = sns_client.create_topic(Name="Async-Demo-SuccessTopic2")
success_topic = response['TopicArn']

Інші варіанти сповіщень включають періодичну перевірку виводу відра S3 або використання сповіщень відра S3 для ініціалізації AWS Lambda функція завантаження файлу. Сповіщення SNS включені в розділ конфігурації кінцевої точки, як описано раніше.

Докладніше про те, як налаштувати сповіщення від кінцевої точки асинхронного висновку, див Перевірити результати прогнозу.

Відстежуйте кінцеву точку асинхронного висновку

Ми відстежуємо кінцеву точку асинхронного висновку за допомогою вбудованих додаткових показників CloudWatch, специфічних для асинхронного висновку. Наприклад, ми відстежуємо довжину черги в кожному екземплярі за допомогою ApproximateBacklogSizePerInstance і загальна довжина черги с ApproximateBacklogSize.

Повний список показників див Моніторинг кінцевих точок асинхронного висновку.

Ми можемо оптимізувати конфігурацію кінцевої точки, щоб отримати найбільш економічно ефективний екземпляр із високою продуктивністю. Наприклад, ми можемо використовувати екземпляр із Amazon Elastic Inference або AWS Inferentia. Ми також можемо поступово збільшувати рівень паралелізму до піку пропускної здатності, налаштовуючи інші параметри сервера моделі та контейнера.

Графіки CloudWatch

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

На наступному знімку екрана показано показники екземпляра до того, як почали надходити запити. Ми починаємо з живої кінцевої точки з нульовими екземплярами:

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

Як показано на наведеному нижче знімку екрана, кількість екземплярів зросла зі збільшенням кількості висновків:

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

Прибирати

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

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

response = client.deregister_scalable_target(ServiceNamespace='sagemaker',ResourceId='resource_id',ScalableDimension='sagemaker:variant:DesiredInstanceCount')

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

sm_client.delete_endpoint(EndpointName=endpoint_name)

Вам також потрібно видалити об’єкти S3 і теми SNS. Якщо ви створили будь-які інші ресурси AWS для використання та дій із сповіщеннями SNS, ви також можете видалити їх.

Висновок

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

Щоб почати роботу з асинхронним висновком SageMaker, перегляньте Асинхронний висновок.

Про авторів

Дінеш Кумар Субрамані є старшим архітектором рішень у команді UKIR SMB, яка базується в Единбурзі, Шотландія. Він спеціалізується на штучному інтелекті та машинному навчанні. Дінеш любить працювати з клієнтами в різних галузях, щоб допомогти їм вирішити їхні проблеми із сервісами AWS. Поза роботою він любить проводити час із сім’єю, грати в шахи та насолоджуватися музикою різних жанрів.

Рагу Рамеша є архітектором рішень ML у команді Amazon SageMaker Service. Він зосереджується на допомозі клієнтам створювати, розгортати та переносити робочі навантаження ML на SageMaker у великих масштабах. Він спеціалізується на машинному навчанні, штучному інтелекті та комп’ютерному зорі, а також має ступінь магістра комп’ютерних наук в UT Dallas. У вільний час захоплюється подорожами та фотографією.