Автоматическое создание субтитров для пользовательского контента может показаться простой задачей: взять готовую модель ASR, распознать аудио и сохранить результат. Именно так и выглядел наш первый MVP в RUTUBE — сервис на базе Whisper, который позволил быстро проверить гипотезу и запустить субтитры в production.

Однако вскоре стало ясно, что между «распознать речь» и «сделать субтитры для всего контента» лежит огромный пласт работы. Миллионы новых видео, ролики длиной до 24 часов, неизвестный язык, шумный пользовательский контент, требования к качеству текста и жёсткие ограничения по скорости — всё это превратило задачу из простого ASR в полноценную платформу с микросервисной архитектурой и собственной системой распознавания речи.

Меня зовут Дима Лукьянов, я лид команды обработки речи и аудио в RUTUBE TECH. В этой статье — рассказ о том, как мы прошли путь от MVP на базе Whisper до собственной масштабируемой платформы с пропускной способностью около 1200 видео в час на один ASR, и какие инженерные решения оказались ключевыми.

Зачем вообще нужны субтитры

На первый взгляд, субтитры — это небольшая функциональность для узкой аудитории. Но на практике их польза гораздо шире.

Они критичны:

• для пользователей с нарушениями слуха,
• для тех, кто смотрит видео без звука — в метро, офисе, в поездке,
• в шумной или, наоборот, слишком тихой обстановке,
• а также когда субтитры требуются по закону.

Субтитры — это текстовое представление видео.

Это значит, что они становятся основой для множества сервисов:

• автогенерации названий и описаний,
• тегирования и классификации контента,
• полнотекстового поиска по видео,
• ускорения модерации и автоматических проверок.

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

Требования к системе

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

• Полное покрытие UGC. Обработка всего контента — от коротких вертикальных роликов до многочасовых стримов.
• Высокая скорость. Цель — не более 1 минуты обработки на видео длиной ~15 минут. Это критично при десятках тысяч новых роликов ежедневно.
• Качество распознавания. Мы ориентировались на WER в диапазоне 0.1–0.2. Ниже — лучше, выше — заметно пользователю.
• Пунктуация и капитализация. Это must-have для читаемости и поиска по тексту.
• Поддержка нескольких языков. Архитектура должна позволять лёгкое расширение на другие языки.

MVP: «Давайте возьмём Whisper»

Первое решение было максимально простым:

• Видео добавляется в очередь Kafka.
• Worker забирает задачу.
• Извлекается аудиодорожка.
• Аудио отправляется в ASR на базе Whisper.
• Формируется файл субтитров.

Это позволило быстро запустить MVP, но уже на этапе тестирования выявились серьёзные проблемы.

Проблемы MVP

Производительность. С Faster Whisper в однопоточном режиме мы получали около 30 видео/час на инстанс. Для обработки миллиона видео в день потребовалось бы около 1400 инстансов — неприемлемо.

Ограничения Whisper. Модель сложно адаптировать под домен из-за особенностей архитектуры:

• отсутствие явного alignment между аудио и текстом,
• генеративные ошибки и «галлюцинации»,
• невозможность независимого улучшения компонентов.

Качество было нестабильным, особенно на шумном пользовательском контенте.

Монолитная архитектура. Весь пайплайн — в одном сервисе. Это приводило к:

• последовательной обработке,
• неэффективному использованию ресурсов,
• отсутствию гибкости,
• невозможности переиспользовать результаты.

MVP работал, но не масштабировался. Whisper — отличная универсальная модель, но не для высоконагруженного доменного продакшена.

Мы приняли решение перестроить архитектуру с нуля. Оказалось, что дешевле и надёжнее построить собственный ASR-пайплайн, чем пытаться масштабировать Whisper.

Архитектура production-платформы

В продакшене система разделена на два ключевых компонента: Speech Worker и ASR.

Speech Worker отвечает за управление задачами, интеграции и формирование финальных субтитров.

ASR занимается непосредственно распознаванием — превращением аудио в текст. Он состоит из:

• ASR Backend — пред- и постобработка, управление сессиями,
• Triton Inference Server — GPU-инференс модели.

Такое разделение позволило изолировать вычислительно тяжёлую часть и масштабировать её независимо.

Управление задачами

В основе — Kafka. Все задачи передаются через неё.

Обработка устроена так:

• чтение сообщений из Kafka батчами,
• каждое сообщение — отдельная задача (1 видео = 1 задача),
• ограничение числа одновременных задач,
• при достижении лимита — новые сообщения не считываются.

Лимит параллельных задач определяется пропускной способностью ASR — самого тяжёлого этапа.

Это даёт простой механизм масштабирования: добавляем инстансы ASR — поднимаем лимит — растёт пропускная способность.

Почему субтитры — это не просто текст

Субтитры = текст + тайминги + читаемость

Любая ошибка сразу бросается в глаза:

• если тайминги «плывут» — зритель теряет контекст,
• если строки разбиты плохо — текст становится трудно читать или теряет смысл.

Проблема читаемости

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

❌ Он в итоге принял решение начать всё сначала

«принял решение» — единая конструкция.

✅ Он в итоге принял решение начать всё сначала

Другой пример:

❌ Мы увеличили throughput в двадцать раз по сравнению с прошлой системой

Акцент «в двадцать раз» уехал на вторую строку.

✅ Мы увеличили throughput в двадцать раз по сравнению с прошлой системой

На первый взгляд — мелочи. Но именно из них складывается пользовательский опыт.

Как мы это решали

За основу взяты правила ручной верстки субтитров:

• оптимальная длина строк,
• корректные точки переноса,
• комфортная скорость чтения,
• время отображения текста.

Мы построили собственный пайплайн, включающий:

1. формирование предложений,
2. разбиение на строки,
3. корректировку таймингов.

Ключевой элемент — NLP на базе Spacy. Он анализирует текст и определяет, где можно, а где нельзя делать перенос, чтобы не нарушить смысл или ритм.

В итоге субтитры выглядят так, будто их верстал человек.

ASR: где начались настоящие сложности

Оффлайн-распознавание в пользовательских видео оказалось сложнее, чем казалось. Основные проблемы:

• произвольная длина аудио — от секунд до десятков часов,
• неизвестный язык,
• отсутствие речи в части роликов,
• шумы и артефакты разной природы.

Чтобы справиться, мы собрали собственный ASR-пайплайн из трёх этапов: предобработка, инференс акустической модели, постобработка.

Предобработка

1. Подготовка аудио. Экстракция дорожки, ресемплинг, поддержка HLS/DASH — всё для нормализации сигнала.
2. Детекция речи (WebRTC VAD). Быстрая фильтрация тишины и музыки — снижает нагрузку.
3. Детекция языка (AmberNet). Анализ 5 случайных 12-секундных фрагментов. Подходит даже для шумных данных.
4. Обработка длинных видео. Аудио читается кусками до 1 часа с восстановлением временных меток — позволяет работать с длинными записями при ограниченной памяти.

Акустическая модель

Мы выбрали FastConformer-L CTC с BPE-токенайзером. Модель обучена на ~10 тыс. часов данных с онлайн-аугментациями двух типов:

• фоновые — длительные шумы,
• кратковременные — щелчки, хлопки, перебивки.

Аугментации накладываются в реальном времени, создавая почти бесконечное число комбинаций «сигнал + шум».

Результат — стабильное качество на UGC и меньше галлюцинаций по сравнению с Whisper. Тестирование проводилось на специальном датасете, разбитом по категориям RUTUBE.

Для инференса используется Triton Inference Server. Обрабатывать всё аудио целиком — невозможно: слишком много GPU-памяти, большая часть которой простаивала бы.

Мы применили эффективный приём:

режем аудио на чанки по 8 секунд с перекрытием 1.6 секунды.

Это даёт два преимущества:

• эффективный батчинг — GPU загружен равномерно,
• лучший контекст — модель видит больше, чем при стриминге, но без лишних вычислений.

Благодаря этому 1 час аудио обрабатывается за ~11 секунд — примерно в 19 раз быстрее, чем Whisper, при сопоставимом качестве.

Постобработка

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

• словарь замен — нормализация доменных сущностей,
• детектор числительных — корректировка чисел,
• KenLM — языковая модель,
• BERT-пунктуатор — восстановление пунктуации и капитализации.

Все они доводят черновой текст до финального вида, пригодного для поиска, модерации и отображения.

Результаты

Нам удалось достичь целевых метрик:

• в среднем — ~5 секунд на полную обработку видео длиной ~15 минут,
• при параллельной обработке — до 1200 видео/час на один ASR.

Что оказалось важным

По ходу работы мы сделали несколько ключевых выводов:

• Стриминговый подход работает даже для оффлайн-задач. Чанкование и батчинг дают выигрыш по скорости и эффективности.
• Собственная модель — необходимость. Публичные решения хороши в бенчмарках, но плохо адаптируются под домен.
• Качество субтитров — это не только низкий WER. Читаемость, переносы, пунктуация и тайминги влияют на UX не меньше.
• Часть препроцессинга можно убрать. Хорошо обученная модель сама устойчива к шуму и артефактам.

Задача создания субтитров быстро выходит за рамки распознавания речи. Это и распределённая архитектура, и ML, и работа с текстом, и требования к UX.

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

Автоматическое создание субтитров для пользовательского контента может выглядеть довольно простой задачей: берем готовую ASR‑модель, распознаем аудио из видео и сохраняем результат.

Именно таким и был наш первый MVP в RUTUBE — сервис на базе Whisper, который позволил быстро проверить гипотезу и запустить субтитры в production. Но очень быстро стало понятно, что между «распознать речь» и «сделать субтитры для всего контента» лежит огромный пласт работы.

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

Меня зовут Дима Лукьянов, я лид команды обработки речи и аудио в RUTUBE TECH. В этой статье расскажу, как мы прошли путь от MVP на Whisper до собственной масштабируемой платформы с пропускной способностью около 1200 видео в час на один ASR и какие инженерные решения оказались ключевыми.

Зачем вообще нужны субтитры

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

Во‑первых, они критичны:

• для пользователей с нарушениями слуха,
• для тех, кто смотрит видео без звука (метро, офис, поездки),
• в шумной или, наоборот, слишком тихой обстановке,
• и для контента, где субтитры требуются по закону.

Но есть и менее очевидная, хотя куда более важная часть:

субтитры — это текстовое представление видео.

А значит, они становятся источником для целого набора сервисов:

• автогенерации названий и описаний,
• тегирования и классификации,
• полнотекстового поиска по видео,
• ускорения модерации и автоматических проверок.

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

Требования к системе

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

• Покрытие всего пользовательского контента (UGC).Обрабатывать нужно всё — от вертикальных роликов до многочасовых записей стримов.
• Высокая скорость.Целевой ориентир — не более1 минутыобработки для видео продолжительностью ~15 минут.Это критично, если на платформе ежедневно появляются десятки тысяч новых роликов.
• Качество распознавания.Мы ориентировались на WER ~0.1–0.2 в среднем по домену. Ниже — лучше, выше — уже заметно пользователю.
• Пунктуация и капитализация.Это must‑have для хорошей читаемости субтитров и для поиска по тексту.
• Масштабирование на другие языки.Даже если сейчас язык один, архитектура должна позволять горизонтальное расширение.

MVP: «Давайте возьмем Whisper»

Наше первое решение было максимально простым:

• Кладем ссылку на видео в очередь Kafka.
• Worker забирает сообщение из очереди.
• Извлекаем аудиодорожку из видео.
• Отправляем её в ASR на базе Whisper.
• По полученному распознаванию формируем файл субтитров.

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

1. Производительность

Мы использовали Faster Whisper для инференса и в однопоточном режиме получили около30 видео/час на один инстанс.

Быстрый расчет показал, что для продакшена с ~1 млн видео в день потребуется порядка 1400 инстансов. Очевидно, это не вариант.

2. Ограничения Whisper

Модель сложно адаптировать под конкретный домен из‑за особенностей архитектуры:

• отсутствует явный alignment между аудио и текстом;
• ошибки носят генеративный характер и могут приводить к «галлюцинациям»;
• компоненты нельзя улучшать независимо друг от друга.

В результате качество получалось нестабильным, особенно на сложном пользовательском контенте.

3. Монолит

Весь пайплайн был реализован внутри одного сервиса, что приводило к типичным проблемам:

• последовательная обработка;
• неэффективное использование ресурсов;
• отсутствие гибкости;
• невозможность переиспользовать результаты распознавания.

В итоге: MVP работает, но не масштабируется, так как. Whisper — отличная универсальная модель, но она не предназначена для высоконагруженного доменного продакшена.

Поэтому мы приняли решение полностью переработать архитектуру. На практике оказалось, что дешевле и предсказуемее построить собственный ASR pipeline, чем пытаться масштабировать исходное решение.

Архитектура production‑платформы

В продакшене мы разделили систему на две ключевые части:Speech WorkerиASR.

Speech Workerотвечает за управление задачами, интеграции с внешними сервисами и формирование финальных субтитров.

ASRзанимается непосредственно распознаванием речи — превращением аудио в текст. Она состоит из двух основных компонентов:

• ASR Backend, который выполняет предобработку и постобработку аудио, а также управляет сессиями распознавания;
• Triton Inference Server, обеспечивающий GPU‑инференс модели.

Такое разделение позволило изолировать вычислительно тяжёлую часть (ASR) и независимо её масштабировать.

Как мы управляем задачами

В основе системы взаимодействия лежит Kafka — через неё проходят все задачи на обработку.

Обработка устроена следующим образом:

• мы читаем сообщения из Kafka батчами;
• каждое сообщение превращается в отдельную задачу (1 видео = 1 задача);
• ограничиваем количество одновременно выполняемых задач;
• при достижении лимита просто перестаём читать новые сообщения.

Ключевой момент — лимит параллельных задач определяется пропускной способностью ASR, как самого тяжёлого этапа обработки.

Это даёт простой и эффективный механизм масштабирования: если нужно увеличить пропускную способность, достаточно добавить новые инстансы ASR и поднять лимит параллельных задач.

Почему субтитры — это не просто текст

Субтитры часто воспринимают как обычный набор строк, но на самом деле это куда более сложная конструкция:

субтитры = текст + тайминги + читаемость

Любая ошибка заметна сразу:

• если тайминги «плывут» — зритель теряет контекст;
• если строки разбиты плохо — текст становится тяжёлым или даже бессмысленным.

Проблема читаемости

Неправильный перенос строки может исказить смысл, замедлить чтение, ухудшить восприятие фразы. Например:

❌Он в итоге принялрешение начать всё сначала

«принял решение» — это единая конструкция.

✅Он в итоге принял решениеначать всё сначала

Другой пример:

❌Мы увеличили throughputв двадцать раз по сравнению с прошлой системой

акцент («в двадцать раз») уехал на вторую строку.

✅Мы увеличили throughput в двадцать разпо сравнению с прошлой системой

Это может показаться незначительным, но именно из таких мелочей складывается пользовательский опыт.

Как мы это решали

Мы взяли за основу правила ручной верстки субтитров:

• оптимальная длина строк,
• корректные точки переноса слов,
• комфортная скорость чтения,
• время отображения текста на экране.

И построили собственный пайплайн, который включает:

1. формирование предложений,
2. разбиение фраз на строки,
3. корректировка таймингов.

Ключевой элемент здесь —NLP на базе Spacy: он анализирует слова в тексте и подсказывает, когда переносить слово, а когда это нарушит смысл или ритм чтения.

В итоге субтитры выглядят так, как будто их верстал человек, а не алгоритм.

ASR: где начались настоящие сложности

Оффлайн‑распознавание аудио в пользовательских видео оказалось значительно сложнее, чем казалось на первый взгляд. На практике нам пришлось работать с четырьмя ключевыми проблемами:

• произвольная длина аудио (от секунд до десятков часов),
• неизвестный язык,
• отсутствие речи в части роликов,
• шумы и артефакты самой разной природы.

Чтобы справиться с этим, мы собрали собственный ASR‑пайплайн, который состоит из трех больших этапов: предобработка аудио, инференс акустической модели и постобработка текста.

Предобработка

1. Подготовка аудио.Экстракция аудио дорожки, ресемплинг, поддержка HLS/DASH. Всё это позволяет работать с любым входом и нормализовать сигнал.
2. Детекция речи (На базе WebRTC VAD).Быстрая фильтрация тишины, музыки и нерелевантных фрагментов. Это существенно снижает нагрузку при распознавании.
3. Детекция языка (AmberNet).Мы берём 5 случайных 12-секундных фрагментов, конкатенируем их и отправляем в детектор языка. Такой подход хорошо работает даже для шумных и нерегулярных данных.
4. Обработка длинных видео.Мы научились читать аудио кусками до 1 часа и корректно восстанавливать временные метки. Это позволяет работать с многочасовыми видео без потери качества и в условиях ограниченной памяти.

Акустическая модель

В качестве акустической модели мы выбралиFastConformer‑L CTCс BPE‑токенайзером. Модель обучена на ~10k часов данных с онлайн‑аугментациями, которые мы разделили на два типа:

• фоновые — длительные шумы окружения;
• кратковременные — щелчки, хлопки, перебивки.

Все аугментации накладываются в режиме реального времени, что даёт практически бесконечное количество комбинаций «чистый сигнал + шум».

В результате — стабильное качество на UGC и заметно меньше галлюцинаций по сравнению с Whisper. Итоговые замеры качества мы проводили на специально подготовленном тестовом датасете, разбитом на категории в соответствие с категориями видео на RUTUBE.

Для инференса мы используемTriton Inference Server.Обрабатывать многочасовое аудио целиком — не вариант: это потребовало бы слишком много GPU‑памяти, причём из‑за неравномерной длины роликов большая часть этой памяти простаивала бы впустую.

Поэтому мы применили простой, но очень эффективный приём:

режем аудио на чанки по 8 секунд с перекрытием 1.6 секунды.

Это даёт два ключевых преимущества:

• эффективный батчинг— GPU загружен равномерно, нет пустых прогонов;
• лучший контекст— модель видит больше, чем при чистом стриминге, но без лишних вычислений.

Благодаря этому1 час аудио обрабатывается примерно за 11 секунд, что примерно в19 раз быстрее Whisperпри сопоставимом качестве.

Постобработка

Чтобы получить качественный читаемый текст, мы используем несколько вспомогательных блоков:

• словарь замен (нормализация доменных сущностей);
• детектор числительных (корректировка чисел и количественных выражений);
• KenLMкак языковую модель;
• BERT‑пунктуатор для восстановления пунктуации и капитализации.

Все эти компоненты доводят черновой текст до финального вида, который уже можно использовать в поиске, модерации и отображении субтитров.

Результаты

В итоге нам удалось достичь целевых метрик:

• в среднем~5 секунд на полную обработкувидео длиной ~15 минут;
• при параллельной обработке — порядка1200 видео/час на один ASR.

Показатель

Время обработки, сек

Видео 15 мин

Экстракция аудио

Детекция речи

Детекция языка

Распознавание

Общее время

Что оказалось важным

По ходу работы мы сделали несколько практических выводов:

• Стриминговый подход работает даже для оффлайн‑задач.Чанкование и батчинг дают выигрыш и по скорости, и по эффективности использования ресурсов.
• Собственная модель — это необходимость.Публичные решения хорошо показывают себя в бенчмарках, но плохо адаптируются под конкретный домен.
• Качество субтитров ≠ только низкий WER.Читаемость, переносы, пунктуация и тайминги влияют на пользовательский опыт не меньше.
• Часть препроцессинга можно убрать.Если модель правильно обучена, она сама становится устойчивой к шуму и артефактам.

На практике задача создания субтитров быстро выходит за рамки распознавания речи. Это и распределённая архитектура, и ML, и работа с текстом, и требования к UX.

Система, которая начиналась как экспериментальный MVP, сегодня обрабатывает тысячи часов пользовательского контента в день — и делает это за секундные задержки.Это стало возможно только благодаря тому, что мы не стали рассматривать компоненты изолированно и оптимизировали весь процесс целиком.

Подписывайтесь на этот блог и каналСмотри за IT, если хотите знать больше о создании медиасервисов. Там рассказываем об инженерных тонкостях и продуктовых находках, делимся видео выступлений и кадрами из жизни команд Цифровых активов «Газпром-Медиа Холдинга» таких, как RUTUBE, PREMIER, Yappy.