Представляємо набір інструментів порівняльного аналізу Amazon SageMaker без сервера

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

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

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

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

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

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

Ви можете завантажити набір інструментів і встановити його з GitHub репо. Почати роботу легко: просто встановіть бібліотеку, створіть Модель SageMakerі надайте назву вашої моделі разом із файлом у форматі рядків JSON, який містить зразок набору параметрів виклику, включаючи тіло корисного навантаження та тип вмісту. Надається зручна функція для перетворення списку прикладів аргументів виклику у файл рядків JSON або файл pickle для бінарних корисних даних, таких як зображення, відео чи аудіо.

Встановіть набір інструментів

Спочатку встановіть бібліотеку порівняльного аналізу у ваше середовище Python за допомогою pip:

pip install sm-serverless-benchmarking

Ви можете запустити наступний код із Студія Amazon SageMaker приклад, Екземпляр ноутбука SageMaker, або будь-який екземпляр з програмний доступ до AWS і відповідних Управління ідентифікацією та доступом AWS (IAM) дозволи. Необхідні дозволи IAM задокументовано в GitHub репо. Додаткові вказівки та приклади політик для IAM див Як Amazon SageMaker працює з IAM. Цей код запускає контрольний тест із стандартним набором параметрів на моделі, яка очікує введення CSV із двома прикладами записів. Рекомендується надати репрезентативний набір прикладів, щоб проаналізувати, як кінцева точка працює з різними вхідними корисними навантаженнями.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

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

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Зауважте, що це призведе до додаткових витрат на запуск екземпляра ml.m5.large SageMaker Processing протягом періоду тестування.

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

Конфігурація бенчмаркінгу

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

Існує два ключові параметри конфігурації: MemorySizeInMB та MaxConcurrency. MemorySizeInMB налаштовує обсяг пам’яті, який виділяється екземпляру, і може становити 1024 МБ, 2048 МБ, 3072 МБ, 4096 МБ, 5120 МБ або 6144 МБ. Кількість vCPU також масштабується пропорційно обсягу виділеної пам’яті. The MaxConcurrency Параметр регулює кількість одночасних запитів, які може обслуговувати кінцева точка. З MaxConcurrency 1, кінцева точка без сервера може обробляти лише один запит за раз.

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

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

Результати порівняльного аналізу

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

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

Після завершення порівняльного аналізу інструмент генерує кілька виходів у вказаному result_save_path каталог із такою структурою каталогів:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Команда benchmarking_report каталог містить консолідований звіт із усіма підсумковими результатами, які ми описуємо в цій публікації. Додаткові каталоги містять необроблені та проміжні результати, які можна використовувати для додаткового аналізу. Зверніться до GitHub репо для більш детального опису кожного вихідного артефакту.

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

Першим виходом у консолідованому звіті є зведена таблиця, яка містить показники мінімальної, середньої, середньої та максимальної затримки для кожного MemorySizeInMB успішне налаштування розміру пам'яті. Як показано в наведеній нижче таблиці, середня затримка виклику (invocation_latency_mean) продовжував покращуватися, коли конфігурацію пам’яті було збільшено до 3072 МБ, але після цього покращення припинилося.

На додаток до високорівневої описової статистики надається діаграма, яка показує розподіл затримки за спостереженням клієнта для кожної конфігурації пам’яті. Знову ж таки, ми можемо помітити, що конфігурація 1024 МБ не така продуктивна, як інші варіанти, але суттєвої різниці в продуктивності в конфігураціях 2048 і вище немає.

Amazon CloudWatch також надаються показники, пов’язані з кожною конфігурацією кінцевої точки. Тут є один ключовий показник ModelSetupTime, який вимірює, скільки часу знадобилося для завантаження моделі, коли кінцева точка була викликана в холодному стані. Показник не завжди може відображатися у звіті, оскільки кінцева точка запускається в гарячому стані. А cold_start_delay Параметр доступний для визначення кількості секунд для сну перед запуском тесту на розгорнутій кінцевій точці. Встановлення для цього параметра більшого числа, наприклад 600 секунд, повинно підвищити ймовірність виклику холодного стану та підвищити шанси зафіксувати цей показник. Крім того, ця метрика з більшою ймовірністю буде охоплена тестом одночасного виклику, який ми обговоримо далі в цьому розділі.

У наведеній нижче таблиці наведено показники, отримані CloudWatch для кожної конфігурації пам’яті.

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

Остаточним результатом порівняльного аналізу вартості та стабільності є рекомендована конфігурація пам’яті разом із таблицею порівняння вартості експлуатації безсерверної кінцевої точки з порівнянним екземпляром хостингу SageMaker. На основі зібраних даних інструмент визначив, що конфігурація 2048 МБ є найбільш оптимальною для цієї моделі. Хоча конфігурація 3072 забезпечує приблизно на 10 мілісекунд кращу затримку, це супроводжується збільшенням вартості на 30%, з 4.55 до 5.95 доларів США за 1 мільйон запитів. Крім того, результат показує, що безсерверна кінцева точка забезпечить економію до 88.72% порівняно з порівнянним екземпляром хостингу в реальному часі, коли щомісячно надходить менше 1 мільйона запитів на виклик, і беззбиткова кінцева точка в реальному часі після 8.5 мільйонів запитів.

Другий тип еталонного тесту необов'язковий і тестує різні MaxConcurency налаштування під різні моделі трафіку. Цей тест зазвичай виконується з використанням оптимального MemorySizeInMB конфігурація з тесту стабільності. Двома ключовими параметрами для цього тесту є список MaxConcurency параметри для тестування разом зі списком клієнтських множників, які визначають кількість змодельованих одночасних клієнтів, з якими тестується кінцева точка.

Наприклад, встановивши concurrency_benchmark_max_conc parameter до [4, 8] і concurrency_num_clients_multiplier до [1, 1.5, 2] запускаються дві кінцеві точки: одна з MaxConcurency з 4 та інші 8. Потім кожна кінцева точка порівнюється за допомогою (MaxConcurency x multiplier) кількість змодельованих одночасних клієнтів, що для кінцевої точки з паралельністю 4 перетворюється на контрольні тести тестування навантаження з 4, 6 і 8 одночасними клієнтами.

Перший результат цього порівняльного тесту – це таблиця, яка показує показники затримки, винятки обмеження та показники транзакцій за секунду (TPS), пов’язані з кожним MaxConcurrency конфігурація з різною кількістю одночасних клієнтів. Ці показники допомагають визначити відповідний MaxConcurrency налаштування для обробки очікуваного трафіку. У наведеній нижче таблиці ми бачимо, що кінцева точка, налаштована з максимальним паралелізмом 8, змогла обробляти до 16 одночасних клієнтів із лише двома регулюючими винятками з 2,500 викликів, зроблених із середньою швидкістю 24 транзакції на секунду.

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

Остаточний результат містить таблицю з показниками CloudWatch для кожного MaxConcurrency конфігурація. На відміну від попередньої таблиці, де показано розподіл затримки для кожної конфігурації пам’яті, яка не завжди може відображати холодний запуск ModelSetupTime метрика, ця метрика з більшою ймовірністю з’явиться в цій таблиці через більшу кількість запитів на виклик і більшу MaxConcurrency.

Висновок

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

Додаткові ресурси

Про авторів

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

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

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