«Не угадывать ёмкость, а измерять»: SageMaker AI ищет точку насыщения эндпоинта

Что такое concurrency sweep

Concurrency sweep решает задачу, которую обычно решают угадыванием: какой тип инстанса и какая конфигурация обслуживания дают максимум производительности на единицу цены при задержке в допустимых границах. Без системного подхода подбор ёмкости выглядит так: развернуть, вручную нагрузить, поправить, повторить — пока цифры не начнут казаться приемлемыми.

Цена ошибки названа прямо: выбрать пять инстансов ml.g7e.2xlarge там, где хватило бы одного, — значит сжечь бюджет на простаивающих GPU; выбрать слишком мало — значит получить очередь запросов, скачки задержки и деградацию сервиса для пользователей.

Concurrency sweep — это систематический подход к бенчмаркингу: контролируемые, постепенно растущие уровни параллельного трафика направляются в эндпоинт Amazon SageMaker AI, а его поведение анализируется. Механизм встроен в Amazon SageMaker AI Inference Recommendations, так что собственную инфраструктуру нагрузочного тестирования строить и поддерживать не нужно.

На каждом уровне замеряются два показателя: throughput — сколько токенов в секунду выдаёт эндпоинт, и задержка — сколько занимает каждый запрос. Прогрессивно увеличивая параллельность, например с 64 до 256, а затем до 1 024 одновременных запросов, можно построить кривую и найти точку насыщения: уровень, после которого дополнительный параллельный трафик перестаёт улучшать throughput и начинает ухудшать задержку.

Для планирования продакшена sweep даёт три опорные точки. Идеальный баланс — уровень параллельности, где throughput максимален при приемлемой задержке. Точка слома — где задержка пересекает порог соглашения об уровне сервиса (SLA). Коэффициент приведения к размеру — сколько инстансов нужно, чтобы покрыть пиковый трафик при известной ёмкости одного.

Четыре шага и требования

Рабочий процесс состоит из четырёх шагов: развернуть модель на эндпоинте SageMaker AI в нативном контейнере vLLM, настроить профиль нагрузки — число входных и выходных токенов и режим стриминга, — запустить sweep через API CreateAIBenchmarkJob и проанализировать результаты, чтобы определить оптимальную параллельность и подобрать размер парка. Каждый шаг опирается на предыдущий.

Из требований: аккаунт AWS с доступом к Amazon SageMaker AI, роль исполнения IAM с правами на SageMaker AI и Amazon S3, а также квота сервиса на эндпоинты ml.g7e.2xlarge.

Модель и профиль нагрузки

В разборе на эндпоинт ml.g7e.2xlarge развёртывается NVIDIA Nemotron-3 Nano 30B — модель со смесью экспертов, у которой активны только 3 миллиарда параметров. Инстанс построен на GPU NVIDIA Blackwell, что даёт выгодное соотношение цены и производительности для инференса. Используется контейнер vLLM Deep Learning Container для SageMaker AI, настраиваемый переменными окружения SM_VLLM_*.

Три настройки заслуживают пояснения. Флаг SM_VLLM_ENFORCE_EAGER обязателен, потому что Nemotron-3 Nano построена на гибридной архитектуре Mamba-Transformer, требующей немедленного режима исполнения. Утилизация памяти GPU выставлена в 0,85, чтобы оставить запас на рост KV-кэша при высокой параллельности. Префиксное кэширование включено, чтобы переиспользовать закэшированные пары ключ-значение там, где системные промпты повторяются между запросами.

Профиль нагрузки описывает, какой трафик имитировать. В примере средняя длина входного промпта — 1 024 токена, средняя длина ответа — 256 токенов, стриминг включён. Такие значения характерны для задач Retrieval Augmented Generation и суммаризации; если приложение использует короткие промпты и длинные генерации, например для написания кода, их следует изменить. Стриминг нужен, чтобы замерять время до первого токена (TTFT) — метрику, важную для интерактивных интерфейсов, где воспринимаемая отзывчивость значима не меньше сырой пропускной способности.

Как проходит сам прогон

Задание создаётся вызовом CreateAIBenchmarkJob. В примере используется список уровней параллельности 64, 256 и 1 024 — степени четвёрки, — а request_count задаёт 1 024 запроса на каждый уровень. Движок бенчмаркинга AIPerf проходит уровни последовательно внутри одного задания: последовательный, а не параллельный прогон означает, что каждое измерение отражает чистую изолированную нагрузку, что даёт статистически устойчивые оценки и сдерживает расходы.

По завершении задания результаты пишутся в путь Amazon S3, заданный в OutputConfig, в виде tar-архива с метриками по каждому уровню в формате JSON.

При разборе результатов важны четыре метрики: throughput в выходных токенах в секунду — выходит ли он на плато или продолжает расти; p99 сквозной задержки — где она пересекает SLA; разброс между p50 и p99, расширение которого сигнализирует об очередях под нагрузкой; и время до первого токена, критичное для стриминговых интерфейсов.

Если отложить throughput против задержки по уровням параллельности, точка насыщения видна как «колено» на кривой: throughput выравнивается, а p99 задержки резко уходит вверх. В тестовом сценарии это произошло на 256 одновременных запросах. Уровни ниже колена — безопасная зона работы; выше — эндпоинт перегружен, а пользователи ждут.

Автоматический поиск под пороги SLA

Фиксированный список уровней требует заранее знать диапазон. Если он неизвестен или нужно автоматизировать планирование ёмкости между версиями модели и типами инстансов, в тот же вызов CreateAIBenchmarkJob подставляется поисковый рецепт. Рецепт max-concurrency-under-sla принимает один или несколько порогов SLA и ищет максимальную параллельность, удовлетворяющую всем им.

Доступны четыре порога: ttft_sla_ms — максимальное время до первого токена по статистике p95, требует стриминга; tpot_sla_ms — максимальное время на выходной токен, также по p95 и со стримингом; e2e_sla_ms — максимальная сквозная задержка запроса по p99; error_rate_sla — максимальная доля неуспешных запросов по среднему.

В примере с порогом сквозной задержки p99 менее 50 секунд планировщик стартует с параллельности 16 и удваивает её на каждой итерации: 16 — 492,5 токена в секунду, 32 — 904,2, 64 — 1 433,4, 128 — 2 066,8, 256 — 2 823,4, все уровни проходят. На 512 происходит первое нарушение SLA: 2 782,3 токена в секунду и отказ. Планировщик сужает поиск до диапазона 256–512 и находит, что параллельность 320 укладывается в SLA при 2 781,8 токена в секунду; следующая проверенная точка, 284, не проходит. Поиск длится не дольше, чем задано в search_max_iterations.

Оптимизационный планировщик сходится к ответу за меньшее число итераций, чем линейный sweep: он начинает с широкого диапазона и постепенно сужает его, оценивая только те уровни параллельности, которые нужны для определения границы, — это снижает и число итераций, и общую стоимость поиска.

Одного SLA недостаточно

Для большинства продакшен-нагрузок одного порога мало: иногда модель должна соответствовать нескольким SLA одновременно. В интерактивных интерфейсах нужно контролировать и сквозную задержку, и время до первого токена — и рецепт max-concurrency-under-sla принимает несколько SLA в одних параметрах поиска.

В примере с двумя порогами — сквозная задержка p99 менее 50 секунд и TTFT p95 менее 1,5 секунды — картина меняется: итерации 16 (480,2 токена в секунду), 32 (888,6) и 64 (1 429,9) проходят, 128 (2 061,4) уже нет, а проверенная точка 80 (1 599,3) снова проходит. Максимальная поддерживаемая параллельность в этом случае — 80.

Убрать за собой и вывод

После бенчмаркинга разбор прямо требует удалить созданные эндпоинты, конфигурации эндпоинтов и модели: эндпоинты тарифицируются по часам независимо от того, приходит ли на них трафик.

Авторы формулируют вывод так: concurrency sweeps заменяют догадки данными в планировании ёмкости генеративных эндпоинтов. Вместо переподготовки «на всякий случай» или обнаружения узких мест уже в продакшене можно системно нанести на карту рабочий диапазон эндпоинта и принять решение о размере парка до того, как в систему придёт первый пользовательский запрос. Полный блокнот доступен в репозитории на GitHub, а в другом примере этим же механизмом бенчмаркится модель GLM 5.3 Flash.

Материал подготовили Mona Mona, Hrushikesh Gangur, Felipe Lopez, Lokeshwaran Ravi и Sheng Moua.