Потоковое распознавание речи (Streaming STT) в реальном времени

Мы сталкивались с задачей: call-центр на 50 операторов, нужно субтитры в реальном времени для супервайзера. Batch STT давал задержку 5 секунд — пропускал важные моменты диалога. На живых субтитрах конференции задержка в 2 секунды уже неприемлема, а в голосовом ассистенте каждый лишний миллисекунд ухудшает UX. Решение — streaming STT с частичными результатами через WebSocket. За 5 лет мы выстроили архитектуру, которая держит latency 100-500 мс при любых нагрузках.

Какие проблемы решает streaming STT?

• Задержка: Без частичных результатов пользователь ждёт окончания фразы. Streaming выдаёт предварительную транскрипцию каждые 200-400 мс. Для call-центра это означает возможность мгновенной реакции — супервайзер видит текст через 200 мс после произнесения.
• Паузы и наложения: VAD + endpointing корректно обрабатывают тишину и overlapping speech. Настройка aggressiveness=2 отсекает 90% пауз без потери смысла.
• Точность в реальном времени: Модели с низкой latency (Deepgram Nova-2) показывают WER <5% даже при 200 мс. Стоимость Deepgram Nova-2 составляет $0.0043/мин, что на 40% дешевле Google STT.

Как мы строим streaming pipeline?

Типичная архитектура, которую мы запускали в production:

Microphone → WebSocket (WSS) → FastAPI → STT Engine → NLP → Response

Ключевые компоненты реализованы на Python с асинхронными сокетами.

WebSocket сервер на FastAPI

from fastapi import FastAPI, WebSocket
from faster_whisper import WhisperModel
import numpy as np
import asyncio

app = FastAPI()
model = WhisperModel("medium", device="cuda", compute_type="float16")

@app.websocket("/stream")
async def stream_stt(websocket: WebSocket):
    await websocket.accept()
    audio_buffer = bytearray()
    try:
        while True:
            chunk = await websocket.receive_bytes()
            audio_buffer.extend(chunk)
            if len(audio_buffer) >= 32000 * 2:  # 2 sec @ 16kHz 16-bit
                audio_array = np.frombuffer(audio_buffer, dtype=np.int16).astype(np.float32) / 32768.0
                segments, _ = model.transcribe(audio_array, language="ru")
                partial_text = " ".join([s.text for s in segments])
                await websocket.send_json({"type": "partial", "text": partial_text})
                audio_buffer = bytearray()
    except Exception:
        await websocket.close()

VAD (Voice Activity Detection)

VAD подключаем до накопления буфера: отсекаем тишину, уменьшая количество транскрипций.

import webrtcvad

vad = webrtcvad.Vad(2)
def is_speech(audio_chunk: bytes, sample_rate: int = 16000) -> bool:
    return vad.is_speech(audio_chunk, sample_rate)

Для endpointing держим скользящее окно тишины 500-800 мс.

Клиентская часть

const socket = new WebSocket('wss://api.example.com/stream');
const mediaStream = await navigator.mediaDevices.getUserMedia({ audio: true });
const recorder = new MediaRecorder(mediaStream, { mimeType: 'audio/webm;codecs=opus' });
recorder.ondataavailable = (event) => {
    if (socket.readyState === WebSocket.OPEN) socket.send(event.data);
};
recorder.start(250); // 250ms chunks

Почему VAD критичен для streaming?

Без VAD движок обрабатывает весь аудиопоток, включая тишину. Это увеличивает токенную стоимость и задержку. На практике мы видели рост latency p99 на 30% при отсутствии предварительного VAD.

Как выбрать STT движок?

Выбор между облаком и self-hosted зависит от нагрузки, требований к конфиденциальности и бюджета. Согласно официальной документации Deepgram, Nova-2 имеет latency 180 мс при p95.

Self-hosted решения экономят до 80% при объёмах >1000 часов в месяц. Например, faster-whisper на GPU обходится около $0.001/мин. Для мультиязычных проектов Google и Azure предпочтительнее из-за широты покрытия.

Как обеспечить latency p99 < 400 мс?

Ключевые факторы: выбор движка с низкой latency, оптимизация VAD и настройка буферизации. Для self-hosted используем faster-whisper с CUDA и INT8-квантизацию — это снижает latency на 30% без потери точности. Плюс предварительная сегментация аудио через VAD, чтобы не транскрибировать тишину.

Какие метрики мониторить?

• p99 latency — не более 400 мс для self-hosted, 300 мс для облачных решений.
• CPU/GPU utilization — чтобы избежать перегрузки под пиковой нагрузкой.
• WER (Word Error Rate) — отслеживаем на семпловой выборке.
• Количество активных сессий — важно для auto-scaling.

Процесс реализации под ключ

1. Анализ: Определяем язык, количество спикеров, ожидаемый RPS, требования к endpointing.
2. Проектирование: Строим диаграмму потоков, выбираем движок, VAD и метод диспетчеризации.
3. Разработка: Кодим WebSocket сервер, интегрируем STT, настраиваем auto-scaling.
4. Тестирование: Генерируем синтетические RTP потоки, измеряем latency p99, утечки памяти.
5. Деплой: Разворачиваем в k8s с помощью Helm, подключаем мониторинг (Prometheus + Grafana).
6. Передача: Документация, обучение команды, кодовая база с комментариями.

Что входит в работу

• Архитектурная схема и обоснование выбора
• Репозиторий с Docker-контейнерами и Helm-чартом
• API документация (OpenAPI)
• Интеграция с клиентскими SDK (Web, iOS, Android — опционально)
• План тестирования под нагрузкой
• Поддержка 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально под задачу. Получите оценку проекта — напишите нам.

Наш опыт

Мы внедрили streaming STT для 10+ проектов: от call-центров до живых субтитров. Наш опыт включает интеграцию с глубоким фреймворком диалогов и настройку под высокую нагрузку (до 1000 одновременных сессий). Гарантируем latency p99 < 400 мс для self-hosted решений на базе NVIDIA A10G. Сертифицированы по CUDA (NVIDIA).

Готовы реализовать streaming STT под ключ. Свяжитесь для консультации — обсудим вашу задачу и подберём оптимальную архитектуру.

Распознавание и синтез речи: ASR, TTS, клонирование голоса

Заказчик приходит с задачей: транскрибировать 40 000 часов колл-центра за неделю. Штатный облачный ASR (Google Speech-to-Text) выдаёт WER 28% на отраслевой лексике и стоит ощутимо дорого при таких объёмах. Задача — снизить WER ниже 10% и перейти на self-hosted инференс.

Типовые проблемы, с которыми приходят

WER не сходится к нужной метрике. Чаще всего виновата не архитектура, а данные: шумные аудио без нормализации уровня (-23 LUFS вместо стандарта), смешанные языки в одном канале, акцент, специфическая доменная лексика. Whisper large-v3 из коробки даёт WER 8–12% на чистом русском и проваливается до 25–35% на записях с PSTN-артефактами и узкополосным кодеком G.711.

Диаризация ломается при больше двух спикеров. pyannote/speaker-diarization-3.1 работает стабильно при 2–3 говорящих, но DER (Diarization Error Rate) растёт с 6% до 18–22% при 5+ участниках конференции. Проблема усугубляется перекрёстными репликами: по умолчанию min_duration_on=0.1 срезает короткие вставки.

Клонирование голоса — латентность или качество. XTTS v2 (Coqui) даёт натуральный голос, но при потоковой генерации stream_chunk_size=20 первый аудиочанк прилетает через 1.4–2.0 с — неприемлемо для интерактивных сценариев. StyleTTS2 и Kokoro быстрее, но требуют точной подготовки референсного аудио.

Как это решается на практике

Базовый стек для production-пайплайна:

• ASR: openai/whisper-large-v3 или faster-whisper (CTranslate2-бэкенд, x4 скорость vs оригинал)
• Диаризация: pyannote.audio 3.x + интеграция через whisperx для выравнивания по словам
• TTS: XTTS v2 для качества, Edge-TTS или Silero для низкой латентности
• Клонирование: XTTS v2 (3–6 с референсного аудио) или OpenVoice v2

Типичный пайплайн для колл-центра выглядит так: аудио из очереди Kafka → нормализация ffmpeg -af loudnorm до -23 LUFS → faster-whisper с beam_size=5, vad_filter=True → pyannote диаризация → постпроцессинг (пунктуация через deepmultilingualpunctuation) → запись в PostgreSQL с временными метками.

Кейс из практики. Финтех-компания с 12 000 звонков/день. Исходный WER на русском с банковской лексикой — 22% (Google STT). После fine-tuning whisper-medium на 200 часах размеченных записей через Hugging Face transformers + Seq2SeqTrainer с learning_rate=1e-5, warmup_steps=500 — WER упал до 7.3%. Инференс на одной A10G через faster-whisper с compute_type=float16 обрабатывает 40-минутный звонок за 55 секунд. Итоговая стоимость инференса — $0.0008/мин против $0.016/мин у облачного провайдера.

Дообучение Whisper на доменных данных

Когда общая модель не справляется, fine-tuning — первый инструмент. Минимальный датасет для заметного улучшения — 20–30 часов размеченного аудио в целевом домене. Разметку можно получить через итеративный процесс: прогнать через базовую модель → вручную исправить 10–15% ошибок → переобучить → повторить.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

Важно: при fine-tuning Whisper нужно замораживать encoder первые 1000 шагов (model.freeze_encoder()), иначе акустические признаки разъедутся раньше, чем decoder адаптируется к новой лексике.

Синтез речи: выбор под задачу

Для интерактивных ботов с требованием TTFB < 300 мс — Silero или Kokoro. Для озвучки контента, где важна натуральность — XTTS v2 с потоковой отдачей через WebSocket.

Процесс работы

Начинаем с аудит-сессии: берём 2–4 часа ваших записей, прогоняем через несколько моделей, замеряем WER/CER, смотрим на распределение ошибок по типам (лексические, акустические, язык). Это занимает 1–2 дня и сразу показывает, нужен ли fine-tuning или достаточно пост-обработки.

Далее — выбор архитектуры под ваш throughput: один GPU для 1000 мин/день или кластер с балансировщиком для 100 000+ мин/день. Деплой через Docker-контейнер с FastAPI или Triton Inference Server для батчированного инференса.

Сроки зависят от сложности: базовая интеграция готовой модели — 1–2 недели. Fine-tuning с подготовкой данных и валидацией — 4–8 недель. Полная разработка голосового пайплайна (ASR + диаризация + TTS + мониторинг) — 2–4 месяца.