RustSTT

Задача

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

Система

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

Моя роль

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

Найскладніше

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

Архітектурні рішення

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

Поточний стан

У продакшн-використанні. Комерційні запити йдуть через власний сайт проєкту.