RustSTT

Задача

Транскрипция, приходящая, когда разговор уже ушёл дальше, это не реальное время. Целевое железо тоже разное: где-то есть GPU, где-то Apple silicon, а где-то ничего, и сервис должен быть достоин запуска везде.

Система

Потоковый сервис распознавания на Rust. Аудио поступает через WebSocket, а результаты возвращаются, пока речь ещё идёт. Несколько архитектур распознавания стоят за одним интерфейсом, и тот же сервис работает на CPU, CUDA или Metal в зависимости от машины.

Моя роль

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

Самое сложное

Один сервис, три очень разные целевые платформы и бюджет задержки, который не двигается. То, что быстро на GPU с CUDA, не быстро на CPU ноутбука, а потоковый путь должен оставаться предсказуемым везде.

Архитектурные решения

1. Один интерфейс перед несколькими архитектурами распознавания. Вызывающие просят транскрипцию, а не конкретную модель, поэтому движок можно добавить или заменить, не трогая транспорт.
2. Поток через WebSocket вместо запроса и ответа. Аудио идёт непрерывно, а частичные результаты возвращаются, пока человек ещё говорит, и только так результат полезен во время разговора.
3. Целевая платформа — это выбор развёртывания, а не форк. CPU, CUDA и Metal стоят за одной абстракцией, поэтому одна кодовая база обслуживает и ноутбук, и GPU-сервер.
4. Веса моделей входят в runtime-образ. Запущенный экземпляр ничего не скачивает и не делает исходящих вызовов, чтобы их достать, поэтому ведёт себя одинаково и в день выпуска, и через год, и может работать там, где выхода наружу нет вовсе. Цена — это размер образа, и платится она один раз при сборке, а не на каждом холодном старте.

Текущее состояние

В продакшн-использовании. Коммерческие запросы идут через собственный сайт проекта.