Rutube est Passé d'un Pilote Whisper à sa Propre Plateforme de Sous-titres et Reconnaissance Vocale

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

Почему Whisper не хватило На старте Whisper оказался удобным вариантом для проверки гипотезы.

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

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

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

Во что выросла система В итоге задача перестала быть «ещё одним

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

На больших объёмах это критично, потому что позволяет масштабировать отдельные компоненты независимо и не рушить весь конвейер из-за перегрузки в одном месте. Для такой платформы важны сразу несколько требований: Принимать поток из миллионов новых видео без ручного участия Обрабатывать ролики длиной до 24 часов без развала пайплайна Работать с неизвестным языком и шумным пользовательским аудио Держать качество текста на уровне, достаточном для публикации * Укладываться в ограничения по скорости и стоимости обработки Переход к собственной ASR в этом контексте выглядит логичным. Когда продукт работает на массовом UGC, универсальная внешняя модель помогает стартовать, но плохо подходит для тонкой настройки под реальные данные, инфраструктурные ограничения и целевые метрики.

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

Как добились скорости

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

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

Важен и экономический аспект. Чем выше throughput на один ASR-инстанс, тем проще масштабировать сервис без взрывного роста инфраструктурных затрат. Для платформ с постоянным потоком UGC это уже не вопрос удобства, а базовая экономика продукта.

Что это значит

История Rutube хорошо показывает границу между быстрым AI-прототипом и зрелым продуктом. Готовая модель вроде Whisper помогает быстро стартовать, но массовый сервис требует собственной архитектуры, контроля качества и оптимизации под реальные нагрузки. Для всех, кто строит AI-функции поверх пользовательского контента, это прямой сигнал: узкое место обычно находится не в одной модели, а во всём конвейере вокруг неё.