AWS, NVIDIA и австралийский стартап Heidi Health опубликовали совместное решение, которое сокращает затраты на инференс автоматического распознавания речи (ASR) на 75%. Компания Heidi Health, разрабатывающая ИИ-ассистента для клинических консультаций, обрабатывает более 2,4 миллиона консультаций в неделю в 190 странах. Чтобы обеспечить субсекундную задержку транскрипции при пиковых нагрузках, ранее требовалось 16 GPU-инстансов Amazon EC2. После оптимизации с использованием NVIDIA CUDA Multi-Process Service (MPS) и Triton Inference Server достаточно четырёх инстансов, при этом задержка остаётся в пределах нормы: средняя менее 650 миллисекунд, p99 — менее 1000 миллисекунд.

Проблема, которую решали инженеры, типична для многих ASR-нагрузок: один запрос к модели Parakeet TDT 0.6B V2 использует лишь 15–20 процентов вычислительной мощности GPU, в частности, 142 потоковых мультипроцессоров (SM) NVIDIA L40S. Остальные 80 процентов простаивают во время каждого прямого прохода. Стандартный механизм временного разделения CUDA (time-slicing) усугубляет ситуацию: процессы получают доступ к GPU по очереди, а переключение контекста добавляет накладные расходы. В результате один GPU обрабатывает лишь около 62 запросов в секунду при приемлемой задержке, что и вынуждало использовать 16 инстансов.

МеханизмИзоляцияКонкурентное выполнениеЛучше всего подходит для
Time-slicing (по умолчанию)Полная изоляция контекстаНет — последовательноеНесколько крупных моделей
MIG (Multi-Instance GPU)Жёсткое физическое разделениеДа — фиксированные разделыМногоарендная изоляция
MPS (Multi-Process Service)Общий контекст, мягкие ограничения SMДа — конкурентные ядраМного мелких моделей на одном GPU

Для повышения утилизации GPU команда рассмотрела три механизма разделения: временное разделение (time-slicing), Multi-Instance GPU (MIG) и Multi-Process Service (MPS). Временное разделение — это последовательное выполнение процессов, что не даёт конкурентности. MIG создаёт жёсткие физические разделы с выделенными контроллерами памяти, что подходит для многоарендной изоляции, но менее гибко для множества мелких моделей. MPS, напротив, позволяет нескольким процессам одновременно использовать GPU через единый контекст, управляемый демоном MPS. Это устраняет накладные расходы на переключение контекста и поддерживает конкурентное выполнение ядер из разных процессов на разных SM. При этом не требуется изменений в коде приложений.

Один ASR-запрос использует лишь 15–20% вычислительной мощности GPU, остальное простаивает из-за временного разделения CUDA.

Diagram comparing default GPU time-slicing, where each request uses about 20% of SMs and 80% sits idle across 16 GPUs, with CUDA MPS running four concurrent 25% SM instances on 4 GPUs
Diagram comparing default GPU time-slicing, where each request uses about 20% of SMs and 80% sits idle across 16 GPUs, with CUDA MPS running four concurrent 25% SM instances on 4 GPUs · Источник: AWS Machine Learning Blog

В конкретной реализации для транскрипции используется конфигурация с 25-процентным выделением SM и четырьмя конкурентными процессами, каждый из которых занимает примерно 2,5 ГБ из 48 ГБ видеопамяти. Для диаризации — 12 процентов SM и восемь процессов, около 1,8 ГБ каждый. Дополнительно модель была оптимизирована с помощью ONNX Runtime и TensorRT: тяжёлый энкодер преобразован в аппаратно-оптимизированный формат, что снижает время вычислений на запрос. В итоге пропускная способность выросла до 92,1 запросов в секунду на GPU, а количество инстансов сократилось с 16 до 4.

Этот подход демонстрирует, что эффективное использование GPU — не только вопрос аппаратного обеспечения, но и правильной настройки программного стека. Для компаний, работающих с ASR в реальном времени, такие оптимизации могут означать существенную экономию на инфраструктуре. Решение доступно в виде референсной архитектуры, и его можно воспроизвести на базе Amazon EC2 с использованием открытых инструментов.