Один ASR-запрос у Heidi занимал лишь 15-20% вычислительных ресурсов GPU, но из-за последовательного доступа остальные мощности простаивали. Вместо покупки новых инстансов команда уплотнила нагрузку и сократила требуемый парк с 16 GPU до четырех, сохранив задержку менее секунды. Для операторов вывод простой: если ASR уже работает, сначала проверьте плотность процессов, а не отправляйтесь за очередной моделью.
Что именно сделали
В AWS Machine Learning Blog описана производственная схема Heidi Health, которая обрабатывает более 2,4 млн клинических консультаций в неделю в 190 странах. В контуре используется NVIDIA Parakeet TDT 0.6B V2, ранее дообученная для распознавания клинической речи.
Один запрос к этой модели задействовал примерно 15-20% из 142 потоковых мультипроцессоров NVIDIA L40S. При стандартном time-slicing процессы получают GPU по очереди: параллельного исполнения нет, между переключениями возникает накладной расход. В результате одна GPU выдерживала около 62 запросов в секунду при средней задержке менее 650 мс и p99 менее 1000 мс. Чтобы пройти пиковую нагрузку с запасом под SLA, Heidi держала 16 GPU.
Команда заменила последовательный доступ на NVIDIA CUDA MPS. Сервис сводит работу нескольких процессов в общий GPU-контекст и позволяет их ядрам исполняться одновременно на разных вычислительных блоках. Для транскрибации настроили четыре параллельных процесса с лимитом 25% SM на каждый. Один процесс занимал около 2,5 ГБ из 48 ГБ VRAM. Для диаризации использовали восемь процессов по 12% SM, примерно по 1,8 ГБ памяти на процесс.
В опубликованной конфигурации производительность транскрибации достигла 92,1 запроса в секунду на GPU при задержке менее секунды. Требования к инфраструктуре снизились с 16 до четырех GPU, то есть на 75%.
MPS здесь главный, но не единственный
Заголовок AWS удобно прочитать как обещание четырехкратной экономии после запуска MPS-демона. Это было бы слишком красиво даже для облачного калькулятора.
В схеме есть еще два слоя. Вычислительно тяжелый Conformer-энкодер переведен на ONNX Runtime с TensorRT, где используются объединение операций, FP16 и оптимизация памяти. Декодер RNN-T TDT остался в PyTorch CUDA, поскольку генерацию токенов переменной длины удобнее обслуживать там. Запросами управляет NVIDIA Triton Inference Server: для транскрибации он накапливает их до 50 мс и формирует батчи предпочтительного размера 4, 8 или 16.
Поэтому честная формулировка результата такая: MPS убрал запрет на одновременную работу процессов, а остальной стек помог превратить эту конкуренцию за GPU в полезную загрузку. Заявленные 75% относятся к числу GPU в конкретном контуре Heidi, а не к любой ASR-системе на EC2.
Это важно и для порядка действий. В июне NVIDIA и AWS уже продвигали совместную инфраструктуру как способ выводить AI-системы в production без пропорционального роста сложности. Теперь появился воспроизводимый пример следующего уровня: экономику inference можно улучшать не заменой модели, а обслуживанием уже выбранной модели.
Выигрывают команды, у которых отдельный запрос занимает малую долю GPU, а поток достаточно плотный для параллельного исполнения и батчинга. Платить придется операционной сложностью: появляются MPS-квоты, несколько процессов, отдельные настройки для транскрибации и диаризации, Triton и гибридный runtime. Кроме того, мягкое разделение MPS не равно физической изоляции MIG. Чем плотнее консолидация, тем внимательнее придется следить за конкуренцией процессов и хвостовой задержкой.
Что проверить у себя
Первый маркер не счет AWS, а профиль GPU: сколько SM и VRAM реально занимает один запрос и сколько мощности простаивает. Затем стоит прогнать несколько уровней плотности процессов и сравнить RPS, среднюю задержку и p99 на собственном трафике.
Если после включения параллельного исполнения число процессов растет, загрузка GPU повышается, а p99 остается внутри SLA, покупать дополнительные инстансы рано. Если же p99 начинает выходить за пределы цели или процессы становятся нестабильными, граница консолидации уже пройдена. Именно эта кривая, а не цифра 75% из чужого блога, покажет реальную экономию вашего ASR.