Старт: Whisper, который не вывез
В 2024 году команда RUTUBE озаботилась субтитрами. Казалось бы, бери OpenAI Whisper — модель уровня SOTA, ставь на GPU и генерируй. Только вот одно — 30 ТБ видео в день. Это не хобби-проект, а промышленная река контента.
Цифры: к концу 2025 года RUTUBE хранит более 50 млн видео, каждое в среднем 5 минут. Ежедневно загружается 200–300 тысяч новых — плюс републикации.
Whisper (даже Large-v3-Turbo) на одной карте A100 обрабатывал 1 час аудио за ~45 секунд. Проблема: видео качается быстрее, чем распознаётся. Очередь росла по экспоненте. Через месяц работы половина свежих роликов висела без субтитров сутками.
Добавьте сюда капризы русского языка — мат, диалекты, музыку поверх речи — и точность падала до 75% на «тяжёлых» роликах. Пользователи жаловались, модерация — тоже: без текста не проверишь контент на нарушения.
Почему не AWS?
В теории можно было арендовать сотню GPU через AWS Batch или SageMaker. На практике — бюджет улетал в космос. Каждый час обработки обходился в $1.2 за GPU. При 30 ТБ в день (это ~100 000 часов аудио) — $120 000/сутки.
Была попытка использовать Amazon Transcribe — ещё дороже ($1.44 за час) плюс лимиты на размер файла. RUTUBE нужно было своё, дешёвое и масштабируемое.
Архитектура «как не надо» и «как надо»
Первая версия — монолит на FastAPI, который дёргал Whisper. Падал при нагрузке >50 параллельных запросов. Пришлось переписывать в микросервисы.
1 Декомпозиция: вырезаем аудио — отдельно, распознаём — отдельно
Сервис audio-extractor на FFmpeg режет видео на сегменты по 30 секунд. WHISPER не умеет длинные аудио без перегрузки VRAM, пришлось нарезать. Это же упростило параллельную обработку.
2 Очередь тысяч задач: RabbitMQ или Kafka?
Выбрали RabbitMQ с priority queues — срочные видео (новости, политика) обрабатываются быстрее. Kafka отсеяли из-за оверхеда при небольших сообщениях.
3 Эластичный пул воркеров на k8s
Каждый воркер — под с одной картой A10G (24ГБ VRAM). HPA (Horizontal Pod Autoscaler) масштабирует по загрузке очереди. Ночью — 20 подов, днём — 200.
| Метрика | Монолит | Микросервисы |
|---|---|---|
| Макс. парал. видео | 50 | ~5000 |
| Latency p95 | 4.2 мин | 45 сек |
| Стоимость (CPO за 1M мин) | $320 | $87 |
Когда Whisper перестал справляться
Даже с масштабированием Whisper выдавал ~92% Word Error Rate на чистой речи, но на видео с шумами — до 25% WER. Плюс западная модель плохо знает русскоязычные реалии: «Минцифры» превращалось в «Минс цифры», «Дзен» в «Зэн».
Решение — дообучение на корпусе RUTUBE. Собрали датасет: 200 000 часов размеченных субтитров (пользовательские и модерация). Использовали LoRA + Whisper Medium 2.0. За две недели дообучения на 4×H100 WER упал с 14% до 5.8%.
Предупреждение: дообучать Whisper на своём домене — это не просто «запустить код». Нужна чистка датасета, борьба с переобучением, A/B тесты. Без этого получите модель, которая отлично распознаёт мат из комедийных шоу, но заваливает новости.
Кстати, если хотите поиграться с локальным ASR — взгляните на сборку локального ASR на Python. Там без облаков, только bare metal.
Собственное решение: отказ от Whisper в пользу гибрида
Осенью 2025 команда поняла, что Whisper — тупик. Он патенто-независим? Да. Но лицензия MIT всё равно не покрывает коммерческие риски при масштабе RUTUBE. Плюс скорость инференса — 10–15x реального времени.
Построили гибридную систему:
- **Первый проход** — лёгкий CNN-LSTM (модель на 8M параметров) для Voice Activity Detection и грубой транскрипции.
- **Второй проход** — дообученный Whisper Medium для сложных сегментов (перекрытие речи/музыки, акценты).
- **Третий проход** — языковая модель на базе распознавания с использованием N-грамм и правил (топонимы, названия).
Нагрузка перераспределилась: 80% видео обрабатывается первым проходом за 3 секунды (WER ~10%), 20% уходят на тяжёлый Whisper. Средняя скорость выросла до 30× real-time. Детали о том, как строить мультимодальный поиск по видео, можно подсмотреть в статье про Amazon Bedrock с мультимодальным RAG.
Результаты: что получил RUTUBE
После внедрения гибрида (апрель 2026):
- Субтитры появляются в течение 3–5 минут после загрузки видео (было до 2 часов).
- Обработка 3.2 млн минут видео в сутки — без очереди.
- Стоимость снижена в 4 раза по сравнению с чистым Whisper на GPU.
- Точность распознавания — 96.5% (WER 3.5%) на основном контенте.
Интересный факт: пользователи стали чаще досматривать видео до конца — субтитры увеличили среднюю глубину просмотра на 17% (A/B тест). Плюс поиск по видео стал возможен: теперь можно найти момент в любом ролике по тексту. Это ещё один шаг к тому, что мы обсуждаем в статье про локальный RAG для видео.
Подводные камни, о которых молчат
**Первое.** Данные. Надо хранить сырые аудио-сегменты хотя бы неделю, чтобы откатывать модель при ошибках. Это +10 ПБ на GlusterFS.
**Второе.** Мониторинг. Без Prometheus + Grafana вы не увидите, что модель начала «галлюцинировать» ночью. RUTUBE развернул дашборд с метриками качества в реальном времени.
**Третье.** Энергопотребление. 200 GPU жрут ~40 кВт·ч. Даже при дешёвой электронике это $80 000 в месяц.
Выводы (не конвейерные)
Кейс RUTUBE — это не история про «давайте заменим Whisper», а про понимание, что инфраструктура важнее модели. Можно иметь самую точную ASR, но если она не вписана в архитектуру, которая умеет умирать и воскресать — грош цена.
Лично меня радует, что RUTUBE пошёл по пути открытых инструментов: kafka-like очереди, k8s, свои докер-образы. Это не про «купи Amazon Transcribe и спи спокойно», а про боль и инженерный опыт.
Кстати, если вам кажется, что локальные решения скучны — гляньте обзор бесплатных AI-сервисов для транскрибации аудио 2026. Там и для малого бизнеса есть варианты.
А вот следующий шаг для RUTUBE — полностью отказаться от проприетарных весов Whisper и перейти на открытые модели типа локальных TTS решений, чтобы лицензионные риски обнулить.
Ждём, когда RUTUBE выложит свою систему в опенсорс. Пока — держим кулаки.
