В чём суть схемы: 70% экономии на GPU-инференсе без потери SLA
AssemblyAI снижает расходы на speech-to-text инференс примерно на 70% по сравнению с полностью On-Demand конфигурацией. Экономию даёт связка из четырёх элементов: EC2 Spot вместо основной массы On-Demand, ECS capacity providers для управления смешанным парком, диверсификация по семействам GPU g4dn, g5 и g6 и очередь Amazon SQS, которая возвращает незавершённые задачи после прерывания Spot. AWS описывает этот кейс в своём разборе.
Причина, по которой схема вообще нужна, в профиле нагрузки. Каждый аудиофайл проходит пайплайн глубоких моделей: акустические модели, языковые модели и этапы постобработки. Всё это работает на NVIDIA GPU, потому что сервис обязан укладываться в требования по задержке. В масштабе AssemblyAI держит тысячи GPU-инстансов, и полностью On-Demand парк был бы слишком дорогим.
Spot даёт скидку, но AWS может забрать инстанс с предупреждением за 2 минуты. Поэтому архитектура строится вокруг восстановления: незавершённая работа возвращается в очередь, её забирает другой воркер, а новый инстанс входит в строй с подготовленным образом. Без этого экономия превращается в потерянные задачи и сорванный SLA.
Почему полностью On-Demand для speech-to-text слишком дорого
Speech-to-text остаётся тяжёлой нагрузкой. Пайплайн включает несколько стадий, и каждая добавляет вычисления. GPU нужен не для ускорения ради ускорения, а чтобы выдерживать задержку на потоке запросов. Тысячи инстансов работают непрерывно, поэтому разница между On-Demand и Spot умножается на весь парк и на каждую минуту работы.
Держать большой On-Demand резерв на случай пиков дорого. Дешевле взять основную ёмкость на Spot и докупать On-Demand там, где Spot-пул просел или прерывания участились. Такой подход требует управления, и именно поэтому в схеме появляются ECS capacity providers и очередь.
Четыре столпа архитектуры AssemblyAI
Архитектура держится на четырёх элементах.
- ECS capacity providers со смесью Spot и On-Demand. Они решают, откуда брать вычислительные мощности и как переключаться при нехватке Spot.
- Диверсификация GPU Spot по семействам. В кейсе перечислены g4dn.xlarge, g4dn.2xlarge, g5.xlarge, g5.4xlarge и g6.2xlarge.
- Очередь Amazon SQS для восстановления. Незавершённые задачи возвращаются в очередь и подхватываются другими воркерами.
- Региональное развёртывание. US West (Oregon) us-west-2 и Europe (London) eu-west-2 закрывают требования data residency.
Кластер Amazon ECS работает в VPC в нескольких Availability Zones и размещает GPU-задачи. На каждом GPU запускается одна модель инференса. Такая конфигурация упрощает изоляцию нагрузки, но повышает требования к числу доступных карт: упаковать несколько моделей на одну GPU здесь не получится.
EC2 Spot и ECS capacity providers: как устроен парк GPU-инстансов
Amazon ECS запускает GPU-задачи, а capacity providers управляют ёмкостью. Провайдеры позволяют описать стратегию: сколько мощности брать из Spot-пулов, сколько из On-Demand и что делать при нехватке первого варианта. На масштабе тысяч инстансов ручное распределение быстро становится отдельной работой, поэтому декларативная стратегия экономит деньги и время команды.
Зачем смешивать Spot и On-Demand
Spot даёт основную экономию. У него есть цена: инстанс может уйти в любой момент. On-Demand-плечо выполняет роль базовой ёмкости и страховки на случай массовых прерываний или нехватки Spot. Точные доли смеси AWS в опубликованном разборе не приводит. Для своей нагрузки их придётся подбирать по метрикам прерываний, задержке и требованиям SLA.
Если критичная доля трафика не терпит повторов, ей нужен On-Demand или отдельный резерв. Экономия на 100% Spot может обернуться очередью из задач, которые некому обрабатывать.
Диверсификация по семействам g4dn, g5 и g6
AssemblyAI распределяет Spot-ёмкость по нескольким типам инстансов. Разные семейства снижают риск, что один пул закончится или будет отозван целиком. Логика простая: чем больше независимых пулов, тем выше шанс, что хотя бы часть capacity останется доступной.
| Семейство | Примеры | GPU | Роль в пуле |
|---|---|---|---|
| g4dn | g4dn.xlarge, g4dn.2xlarge | NVIDIA T4 | Массовая ёмкость |
| g5 | g5.xlarge, g5.4xlarge | NVIDIA A10G | Более производительные узлы |
| g6 | g6.2xlarge | NVIDIA L4 | Дополнительный пул нового поколения |
Плата за гибкость - разная производительность. T4, A10G и L4 обрабатывают модели с неодинаковой скоростью, поэтому планировщику нужно учитывать тип инстанса или нормализовать единицы работы. Иначе задержка начнёт скакать вместе с составом парка.
Стратегия price-capacity optimized выбирает Spot-пулы с учётом цены и доступной ёмкости, а не одного лишь минимума цены. В опубликованном разборе AWS не приводит параметров, с которыми её настроили в AssemblyAI. Схему можно переносить, а готовую конфигурацию один в один по этому тексту не собрать.
Очереди SQS и прерывания Spot: как не терять задачи
Очередь Amazon SQS превращает прерывание инстанса из аварии в штатное событие. Воркер на GPU-инстансе берёт задачу из очереди, обрабатывает и подтверждает. Если инстанс теряется, сообщение не подтверждено и работа возвращается в очередь. Другой воркер забирает её и повторяет.
Именно queue-based retry делает Spot допустимым для SLA. Инстанс можно потерять, задачу нельзя. Очередь разделяет эти два события: железо уходит, работа остаётся в системе.
Что происходит в 2-минутное окно прерывания
EC2 может отозвать Spot-инстанс с предупреждением за 2 минуты. За это время система должна успеть снять работу с уходящего узла и вернуть её в очередь. Последовательность выглядит так.
- Приходит уведомление о прерывании.
- Воркер прекращает брать новые задачи, чтобы не начинать работу, которую сразу придётся бросать.
- Незавершённая задача возвращается в Amazon SQS.
- Инстанс завершается, а задача достаётся другому воркеру.
- Новый инстанс поднимается из подготовленного образа и возвращается в пул.
Детали видимости сообщений, числа повторов и dead-letter queue в AWS-посте не раскрыты. Для своей системы их нужно задать явно: без ограничения повторов одна проблемная задача будет ходить по кругу и занимать GPU.
Кастомные AMI и скорость восстановления
Новый GPU-инстанс бесполезен, пока на нём нет окружения и артефактов моделей. Кастомный AMI с заранее подготовленными зависимостями и файлами моделей сокращает путь до первой обработанной задачи. Инстансу не нужно скачивать гигабайты и собирать окружение на холодную.
В кейсе упоминаются такие образы, но AWS не раскрывает их состав, размер и замеры времени запуска. Выигрыш зависит от веса моделей и скорости сети: чем больше артефакты, тем заметнее подготовленный образ. Для лёгкой модели разница может быть скромной, для тяжёлой она окупает возню с AMI.
Требования к задачам: идемпотентность и короткие единицы работы
Паттерн хорошо работает, когда единица работы короткая и повторяемая. Транскрипция одного аудиофайла подходит: её можно перезапустить, а результат записать по ключу задачи. Повторная обработка не должна дублировать списания, записи в базу или уведомления.
Идемпотентность здесь не украшение, а условие работы. Если задача длится час, двух минут на аккуратный возврат мало: либо дробите работу, либо принимайте, что часть прогресса потеряется. Для длинных пайплайнов нужна чекпоинтизация, иначе Spot будет регулярно откатывать вычисления назад.
Регионы и data residency: US West и Europe (London)
AssemblyAI разворачивает инфраструктуру в US West (Oregon) us-west-2 и Europe (London) eu-west-2. Это нужно клиентам из регулируемых отраслей: здравоохранения, финансов и юриспруденции. Им мало абстрактного облака; аудиоданные должны оставаться в заданных географических границах. AWS описывает это как часть требований data residency.
Почему одного региона недостаточно
Европейский клиент с требованиями data residency не может отправить аудио в Орегон, даже если там дешевле Spot. US-клиенты, наоборот, не всегда готовы гонять данные через Лондон. Два региона закрывают комплаенс и снижают задержку для локальных пользователей.
Региональное развёртывание удваивает операционную поверхность: capacity providers, очереди, AMI и мониторинг нужно держать в каждом регионе. Зато изоляция помогает при сбоях: проблема в одном регионе не обнуляет сервис целиком.
Кому подходит этот паттерн и какие у него ограничения
Схема Spot плюс очередь подходит, если у вас короткие и повторяемые GPU-задачи: транскрипция файлов, батч-инференс, обработка изображений, расчёт эмбеддингов. Она плохо подходит для долгих stateful-сессий, где потеря инстанса означает потерю получаса работы и невозможность аккуратного повтора.
Ограничения стоит назвать прямо.
- Операционная сложность. ECS, capacity providers, SQS, AMI и мониторинг прерываний нужно настроить и поддерживать.
- Риск нехватки Spot capacity. В нужном регионе и семействе может не быть свободных инстансов.
- Разная производительность GPU. T4, A10G и L4 дают неодинаковую скорость, а значит и неодинаковую задержку.
- Требование идемпотентности. Повтор задачи не должен ломать данные и дублировать побочные эффекты.
- Границы применимости цифры 70%. Это результат конкретной конфигурации AssemblyAI. AWS не раскрывает методику расчёта, поэтому для вашей нагрузки ориентир может оказаться другим.
Конкретные целевые значения задержки и SLA AWS тоже не приводит. Цифра «почти в 4 раза год к году», которая встречается в пересказах кейса, в опубликованном тексте AWS не подтверждена. Для планирования берите свою динамику запросов и закладывайте запас на прерывания.
Чек-лист перед переходом на Spot
- Разбейте работу на короткие единицы, которые можно перезапустить без потери смысла.
- Сделайте обработку идемпотентной: ключ задачи, проверка результата, защита от дублей.
- Настройте очередь и возврат незавершённых задач. Ограничьте число повторов и заведите dead-letter queue.
- Подготовьте AMI с зависимостями и артефактами моделей, чтобы новый инстанс быстрее входил в строй.
- Опишите capacity provider strategy: доля Spot, доля On-Demand, поведение при нехватке Spot.
- Выберите несколько семейств и размеров инстансов, чтобы не зависеть от одного пула.
- Проверьте регионы и требования data residency до запуска, а не после первого аудита.
- Настройте мониторинг прерываний, задержки и доли повторных задач.
Если управлять всем этим не хочется, есть альтернатива в виде управляемого инференса. В разборе Hugging Face Inference Endpoints показано, как переход с ECS/Fargate меняет задержку и стоимость, а также какие ограничения появляются при кастомизации. Для небольших команд это может оказаться проще, чем строить собственный отказоустойчивый парк.
Что взять из кейса AssemblyAI в свой стек
Главный актив кейса - связка, а не отдельная цифра. Spot даёт дешёвую ёмкость, capacity providers управляют смесью, диверсификация снижает риск пула, SQS возвращает задачи, подготовленный AMI сокращает простой. Уберите любой элемент, и экономия начнёт проедать SLA.
Схема не гарантирует 70% каждому. Если нагрузка плохо дробится, требует долгих сессий или чувствительна к задержке на каждом шаге, старт на On-Demand может оказаться дешевле с учётом инженерии и поддержки. Считайте цену инстансов и стоимость команды, которая будет разбираться с прерываниями.
AssemblyAI предлагает API для транскрипции, определения спикеров, анализа тональности, определения глав и редактирования PII. Продукт доступен на AWS Marketplace, а инфраструктурный кейс показывает, как такой сервис можно держать на Spot без постоянных сбоев.
Перед выбором платформы полезно проверить, какие требования к AI-инфраструктуре AWS реально подтверждает. Разбор Forrester Wave и чек-лист для оценки AWS помогают отделить маркетинговые заявления от документов, которые можно предъявить на внутреннем ревью.
Практический следующий шаг: возьмите одну очередь, один тип GPU-задач и один регион. Прогоните нагрузку с имитацией прерываний, замерьте долю повторных задач и задержку. Если SLA держится, добавляйте второе семейство инстансов и второй регион. Так вы получите свою цифру экономии, а не чужую.