Преобразование речи в текст делится на две совершенно разные рабочие нагрузки. С одной стороны, транскрипция в реальном времени связана с задержкой: голосовому агенту нужно выдать слова в течение нескольких сотен миллисекунд после того, как кто-то заговорил. С другой стороны, пакетная транскрипция связана с пропускной способностью: подкаст-сети, сервисы для создания заметок о встречах и архивы колл-центров имеют часы записанного аудио и хотят транскрибировать их как можно дешевле. Это означает пропуск через каждый GPU как можно большего количества часов аудио, с которым он может справиться.

Мы оптимизировали Qwen3-ASR 1.7B на Baseten для достижения минимальной стоимости за минуту аудио среди всех провайдеров транскрипции. По сравнению со стандартным vLLM, оптимизированный стек транскрибирует в 7 раз больше аудио в секунду при высокой параллельности.

Пропускная способность в зависимости от длины клипа для Qwen3-ASR 1.7B на обычном vLLM против оптимизированного стека Baseten на одном RTX PRO 6000 при 64 одновременных запросах. На обычном vLLM пропускная способность выходит на плато около 380x от реального времени (RTF), а аудиофайлы длиннее десяти минут не помещаются в один запрос. Оптимизированный стек продолжает расти до 2645x на 5-минутных клипах и до 3128x на часовых файлах.

Qwen3-ASR 1.7B: самая точная открытая модель транскрипции

Qwen3-ASR 1.7B — это модель распознавания речи с открытыми весами от команды Qwen, выпущенная под лицензией Apache 2.0. Она поддерживает более 30 языков и 22 китайских диалекта и находится на границе Парето Open ASR Leaderboard со средней частотой ошибок распознавания слов (WER) 5,4%.

Наша реализация Qwen3-ASR 1.7B для работы в реальном времени также обладает наивысшим качеством (т. е. самым низким WER) и минимальной задержкой в бенчмарке преобразования речи в текст от Coval, который включает ведущие модели транскрипции на рынке, как открытые, так и закрытые.

Частота ошибок распознавания слов (WER) в зависимости от размера моделей с открытыми весами на Open ASR Leaderboard. Qwen3-ASR 1.7B (5,40%) находится на границе Парето, в пределах 0,07 пункта от NVIDIA Nemotron 3.5 Transcribe 30B-A4B (5,33%), самой точной модели, при этом занимая лишь малую часть ее размера.

Qwen3-ASR обслуживается для пакетной транскрипции на Baseten с первого дня своего запуска. Вот как мы сделали ее быстрее стандартной реализации.

Наш оптимизированный стек Qwen3-ASR

Мы начали с совместимого с OpenAI эндпоинта транскрипций vLLM, который разбивает аудио на 30-секундные окна и пакетно передает их через модель. Оттуда мы профилировали каждый этап запроса под нагрузкой, уделяя особое внимание четырем аспектам:

Нативное декодирование аудио

Нативное декодирование аудио

Квантование KV-кеша (без потери качества)

Квантование KV-кеша (без потери качества)

Синхронизации между хостом и устройством

Синхронизации между хостом и устройством

Обработка запросов

Обработка запросов

Ниже приведены некоторые ключевые изменения, которые сделали возможным увеличение пропускной способности более чем в 7 раз.

Нативное декодирование аудио

Прежде чем модель начнет работу, сервер должен преобразовать загруженный файл M4A или MP3 в 16 кГц моно-семплы.

По умолчанию загрузчик аудио в vLLM использует PyAV для декодирования аудио по одному кадру за раз на Python с передискретизацией «на лету». Каждый шаг кадра удерживает глобальную блокировку интерпретатора Python, поэтому потоки декодирования сериализуются, а не выполняются параллельно. Это создает узкое место в процессоре при высокой параллельности, в то время как графический процессор простаивает.

Мы заменили загрузчик на torchcodec, который передает весь файл в FFmpeg в рамках одного нативного вызова, выполняющего декодирование, передискретизацию и микширование в моно перед возвратом тензора. Такой асинхронный подход освобождает блокировку интерпретатора, пока кодек обрабатывает запрос, с идентичным PyAV выводом.

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

Время декодирования одноминутного файла для питоновского декодера стандартного vLLM по сравнению с нативным декодером Baseten, измеренное на стороне сервера. Питоновский декодер сам по себе занимает 76 мс, но 2195 мс на файл при одновременном декодировании 8 файлов, поскольку потоки сериализуются на блокировке интерпретатора. Напротив, нативный декодер занимает 45 мс в одиночку и 48 мс при 8 файлах одновременно, поэтому пропускная способность декодирования масштабируется с количеством потоков.

Квантование KV-кеша

При высокой параллельности внимание (attention) над KV-кешем занимает наибольшую долю времени работы графического процессора. Внимание на этапе декодирования ограничено пропускной способностью памяти: каждый шаг считывает каждый кешированный ключ и значение для каждой выполняющейся последовательности, а при 1000 активных 30-секундных окнах это весь кеш на каждом шаге.

Хранение KV-кеша в формате FP8 вдвое сокращает количество байт, считываемых на каждом шаге, и удваивает количество последовательностей, помещающихся в памяти GPU. Одной из сложностей было то, что бэкенд FlashAttention-2 по умолчанию в vLLM не поддерживает кеш FP8 на RTX PRO 6000, что побудило нас использовать ядра FlashInfer. FP8 в FlashInfer улучшил использование памяти для ядра внимания с 50% до 80%.

Мы сохранили веса в формате BF16, так как квантование весов увеличило частоту ошибок распознавания (WER) на наших тестовых наборах. Хотя кеш FP8 также является с потерями, влияние на точность минимально, поскольку вычисления внимания остаются в полной точности, а каждый слой пересчитывает свой кеш из активаций полной точности.

Точность, выбранная для каждого этапа в оптимизированном декодере. Веса аудиокодера и декодера остаются в BF16, так как кодер занимает малую долю времени работы GPU, а квантованные до FP8 веса влияли на точность. KV-кеш, являющийся основным источником нагрузки на память, переведен в FP8, что требует вдвое меньше байт на шаг и позволяет обрабатывать вдвое больше последовательностей одновременно. Математика внимания выполняется в полной точности и пересчитывается из активаций полной точности на каждом слое, поэтому ошибки округления не будут накапливаться.

Минимизация синхронизаций между хостом и устройством

Под нагрузкой трассировки GPU показывали простои между шагами, даже когда ядра работали на пределе своих аппаратных возможностей.

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

Аудиокодер делал то же самое один раз за слой, считывая максимальную длину клипа обратно для определения размера своей маски внимания. Каждое считывание обратно представляет собой точку синхронизации: процессор не может поставить в очередь следующие ядра до ее возврата, поэтому GPU остается без работы.

Поскольку оба значения известны на процессоре до начала шага, мы сохраняем копии на стороне хоста и строим метаданные и маски на их основе, устраняя время простоя. Использование GPU под нагрузкой выросло с 86% до 97%, а движок переключился с ограничения по процессору на ограничение по графическому процессору.

Обработка запросов

Наряду с этими изменениями мы также оптимизировали прохождение запросов через сервер, чтобы предварительная обработка не отставала от GPU при 64 одновременных запросах.

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

Поскольку декодирование больше не сериализуется на блокировке интерпретатора, мы удвоили пул потоков предварительной обработки в каждом процессе.

Результаты

Для всех результатов, представленных ниже, «Vanilla vLLM» — это Qwen3-ASR 1.7B на стандартном vLLM без изменений, по сравнению с нашей оптимизированной реализацией с описанными выше изменениями. Обе версии работают на одной RTX PRO 6000 с теми же весами.

Результаты по пропускной способности: увеличение пропускной способности более чем в 7 раз

Секунды аудио, расшифрованные за секунду реального времени, при тестировании на 64 одновременных запросах показывают увеличение пропускной способности до 7 раз в нашей оптимизированной реализации по сравнению с vLLM.

Нам не удалось протестировать стандартный vLLM на аудиоклипах длиннее 10 минут, так как они не помещаются в один запрос.

Пропускная способность в зависимости от количества одновременных запросов для 5-минутных клипов на стандартном vLLM по сравнению с оптимизированным стеком Baseten. Стандартный vLLM выходит на плато примерно на 380-кратном факторе реального времени начиная с 16 одновременных запросов, в то время как оптимизированный стек продолжает масштабироваться до 2645-кратного при 64 одновременных запросах, поскольку этап декодирования больше не сериализует запросы, устраняя простаивание GPU.

Прирост увеличивается с длиной клипа: от 4 раз на 10-секундных клипах до 7 раз на 5-минутных клипах, а наш стек продолжает расти на 30-минутных и часовых файлах, которые ранее не помещались в один запрос.

Результаты по задержке: уменьшение задержки в 6,9 раза

Как и в случае с пропускной способностью, улучшения задержки также увеличиваются с ростом нагрузки. Для 5-минутных клипов время обработки одного запроса сократилось с 5,1 до 1,5 секунд, а при 64 одновременных запросах медианное значение упало с 50 секунд до 7,3 секунды.

Файлы, которые раньше приходилось разбивать на части на стороне клиента, теперь обрабатываются за один запрос: 3,0 секунды для 30 минут аудио и 4,7 секунды для полного часа.

Медианная задержка в зависимости от количества одновременных запросов для 5-минутных клипов на стандартном vLLM по сравнению с нашим оптимизированным стеком. На стандартном vLLM задержка растет с 5,1 с при одном запросе до 50,4 с при 64 одновременных запросах, в то время как оптимизированный стек остается в диапазоне от 1,5 с до 7,3 с во всем этом диапазоне, и этот разрыв увеличивается с 3,4x до 6,9x по мере роста нагрузки.

Стоимость часа аудио

Пропускная способность влияет на цену, так как вы можете сделать больше за ту же минуту (или секунду) работы GPU.

Исходя из прейскурантных цен Baseten для выделенной RTX PRO 6000 и указанной выше постоянной пропускной способности, оптимизированный деплой расшифровывает час аудио примерно за 1/10 цента ($0,0013 за час аудио), что в 8 раз дешевле по сравнению с тем же с тем же моделлем на стандартном vLLM ($0,011).

Наша реализация также стоит примерно в 277 раз дешевле популярных провайдеров с закрытыми весами, цены у которых варьируются от $0,21 до $0,36.

Стоимость Baseten рассчитана путем полной загрузки одной RTX PRO 6000 на часовых файлах с использованием прейскурантных цен; цены закрытых провайдеров оцениваются на основе опубликованных тарифов с оплатой по факту использования для их текущих флагманских пакетных моделей по состоянию на дату последнего обновления этого блога.

Попробуйте Qwen3-ASR для ваших задач пакетной транскрипции

Этот оптимизированный деплой Qwen3-ASR является стандартным в нашей Библиотеке моделей. Разверните его в один клик и вызывайте с помощью любого совместимого с OpenAI клиента транскрипции или объедините его с Nemotron 3 Diarization для создания транскриптов с разделением по спикерам.

Если вам вместо этого нужна транскрипция в реальном времени, наш потоковый пресет Qwen3-ASR обслуживает ту же модель. Для больших пакетных задач или конкретной модели, которую вы хотели бы оптимизировать, свяжитесь с нашими инженерами!