Голосовой AI без компромиссов — почему большинство решений всё ещё тормозят
Голосовые ассистенты — это боль. Либо они платные и гонят ваш голос в чужое облако, либо локальные, но отвечают с задержкой в 5–10 секунд — как будто вы разговариваете со спутником на Марсе. А что, если я скажу, что можно собрать полностью открытый пайплайн, который отвечает быстрее, чем вы успеваете моргнуть? И для этого не нужен GPU за $30 000. Нужны Gemma 4, Cerebras и Qwen TTS. Три кита, которые превращают «речь-мысль-речь» из лабораторного эксперимента в реально работающую систему на вашем железе или в облаке.
Давайте разберем архитектуру по косточкам. Почему именно этот стек? Потому что он модульный, open-source и реально быстрый. Каждый компонент можно заменить, но в связке они дают субсекундную задержку. Спойлер: секрет не только в моделях, но и в том, как они общаются друг с другом.
Классическая проблема: конвейер, который тормозит сам себя
Любой speech-to-speech пайплайн состоит из четырёх этапов: VAD (обнаружение голоса) → ASR (распознавание речи) → LLM (генерация ответа) → TTS (синтез речи). В наивной реализации они работают последовательно: пока один этап не закончится, следующий не начнётся. Это убивает real-time. Каждый этап — минимум 200–500 мс на хорошем GPU. Умножаем на четыре — получаем 2 секунды, а если где-то CPU или квантование — все 5–6.
Выход — каскад с параллельными потоками и буферами. Мы уже обсуждали это в статье про проблемы аудиопаплайна для Gemma 4. Там мы выяснили, что главный враг — не модели, а бутылочное горлышко передачи данных между процессами. Решение — перевести каждый компонент в отдельный процесс (или поток) и обмениваться данными через очереди (Redis, ZeroMQ или просто asyncio.Queue). Но это полдела. Нужны модели, которые сами по себе быстрые.
Компонент №1: VAD + ASR — почему Parakeet, а не Whisper
Для VAD можно взять Silero или NVIDIA NeMo, но в нашем пайплайне мы используем Parakeet-TDT 1.1 от NVIDIA. Он объединяет детекцию голоса и распознавание в одной модели — меньше накладных расходов. Parakeet-TDT работает на ONNX Runtime, что даёт inference за 50–100 мс даже на CPU. Для ASR этого достаточно, ведь мы не транскрибируем всю речь сразу, а работаем с сегментами. Задержка на выходе ASR — менее 200 мс.
Важный нюанс: Parakeet поддерживает streaming. Он выдаёт частичные результаты по мере того, как пользователь говорит. Это позволяет LLM начать обрабатывать текст ещё до того, как пользователь закончил фразу. Так мы выигрываем ещё 300–500 мс.
💡 Совет: Если вам не нужен streaming, можно использовать быстрый non-streaming VAD + ASR. Но для real-time критично именно частичное распознавание. Без него вы теряете преимущество параллельной обработки.
Компонент №2: LLM — Gemma 4 на Cerebras. Почему это меняет правила
А вот здесь главная фишка. Gemma 4 от Google — мультимодальная модель, которая умеет принимать аудио напрямую. В статье «Gemma 4 ловит звук» мы разобрали, как архитектура проекции аудиоволн в эмбеддинги позволяет модели понимать не только слова, но и интонации, паузы, фоновый шум. Это снимает необходимость отдельного энкодера — задержка падает.
Но одного этого мало. Gemma 4 14B или 27B на обычном GPU (даже A100) выдаёт 20–30 токенов в секунду. Для короткого ответа из 30 токенов это 1–1.5 секунды. Можно квантовать, но это потеря качества. Cerebras решает задачу кардинально: их WSE-3 (Wafer-Scale Engine) умещает модель целиком на одном кристалле, устраняя узкое место передачи данных между GPU и памятью. Inference Gemma 4 на Cerebras занимает 50–100 мс — то есть в 10–20 раз быстрее, чем на топовом GPU.
Cerebras не поддерживает все LLM, но Gemma 4 (и её родственники от Google) — да. Cerebras предоставляет облачный API, а также обещает on-prem решения в 2026 году. Для доступа к API Cerebras можно использовать единый шлюз, например AITunnel, который проксирует запросы к разным моделям и упрощает разворачивание. Да, это не совсем open-source, но даёт доступ к инфраструктуре без покупки собственного WSE.
⚠️ Важно: Cerebras пока доступен как облачный сервис (Cerebras Cloud). Это добавляет сетевую задержку (RTT ~5-20 мс в хорошем дата-центре). Но даже с учётом этого, общая задержка остаётся в пределах 300–500 мс — недостижимо для локального GPU при тех же моделях.
Компонент №3: TTS — Qwen3TTS и его бешеное ускорение
За синтез речи отвечает Qwen3TTS. Это открытая модель от Alibaba, которая генерирует голос с эмоциями и настраиваемым тембром. Её главное преимущество — скорость. В статье «Qwen3-TTS.cpp: ускорение TTS в 4 раза» мы показали, как за счёт квантования и оптимизации C++ бэкенда удаётся синтезировать 10 секунд речи за 1 секунду на CPU. В нашем пайплайне Qwen3TTS работает на GPU (например, RTX 4090) — это даёт real-time фактор 0.3–0.5x (то есть 3–5 секунд речи синтезируются за 1.5–2.5 секунды).
Но мы не ждём весь ответ LLM целиком. Qwen3TTS поддерживает streaming: можно начать синтезировать первые слова, как только LLM выдала 2–3 токена. Это маскирует задержку TTS — пользователь слышит начало ответа до того, как генерация завершена.
| Компонент | Типичная задержка (GPU) | С Cerebras/оптимизациями | Режим работы |
|---|---|---|---|
| VAD + ASR (Parakeet) | 100–200 мс | 50–100 мс | Streaming |
| LLM (Gemma 4 14B) | 1000–1500 мс | 50–100 мс | Streaming токенов |
| TTS (Qwen3TTS) | 1500–2500 мс | 500–1000 мс (с streaming) | Chunked streaming |
| Общая ощущаемая задержка | 4–6 секунд | 200–400 мс | Параллельно |
Архитектура пайплайна: как соединить всё без лагов
Теперь о том, как эти компоненты общаются. Забудьте про последовательные вызовы в одном потоке. Правильная архитектура — это несколько асинхронных процессов, обменивающихся данными через очереди.
- VAD/ASR процесс — забирает аудио с микрофона, определяет речь, транскрибирует и кладёт частичные (или полные) тексты в очередь ASR→LLM.
- LLM процесс — читает из очереди, отправляет запрос в Cerebras Cloud (через HTTP/gRPC), получает стриминг токенов и сразу кладёт каждый чанк текста в очередь LLM→TTS.
- TTS процесс — берёт текстовый чанк, синтезирует аудио и отправляет в аудиовыход. Если чанк маленький (2–3 слова), TTS может его склеивать с предыдущим для плавности.
Ключевой момент: очереди должны быть быстрыми и неблокирующими. Для локальной системы подойдёт asyncio.Queue с буфером ограниченного размера. Для распределённой — Redis Streams или NATS. Если буфер переполняется, VAD должен притормаживать (backpressure). Иначе вы получите растущую задержку, как описано в нашем разборе AI-автосекретаря с субсекундной задержкой.
Типичные ошибки и как их не совершить
На практике этот пайплайн ломается в трёх местах:
- Синхронная отправка всего текста в LLM. Если ждать полного ответа от ASR, вы теряете преимущество streaming. Решение — отправлять частичные транскрипции, даже если они неполные. Gemma 4 умеет работать с неполным контекстом.
- Блокирующий TTS. Если TTS не поддерживает streaming, он будет ждать весь текст. Тогда задержка суммируется с LLM. Используйте Qwen3TTS с чанковым режимом или CosyVoice с аналогичным API.
- Отсутствие backpressure. Если VAD работает быстрее, чем LLM обрабатывает, очередь растёт. Через 10 секунд у вас лаг в минуту. Настройте ограничение размера очереди и паузу в VAD при заполнении.
Ещё одна распространённая ошибка — пытаться запустить Cerebras напрямую без шлюза. Cerebras Cloud требует специфической аутентификации и форматов запросов. Используйте единый API-шлюз вроде AITunnel — он абстрагирует различия между провайдерами и даёт единый endpoint для Gemma 4 и других моделей. Это особенно полезно на этапе прототипирования.
А что насчёт железа? Можно ли всё запустить локально?
Если у вас нет Cerebras, но есть мощный GPU (RTX 4090 / A100), можно заменить Cerebras на локальный inference Gemma 4 с использованием llama.cpp или vLLM. Задержка вырастет до 300–500 мс на LLM, но общий пайплайн всё равно будет укладываться в 1–1.5 секунды. Это приемлемо для разговорного AI, но не для real-time соревнований.
Для совсем скромного железа (8 ГБ RAM, без GPU) существует альтернатива — запустить каскад на ARM, как мы делали в гайде для Reachy Mini. Там задержка 3–5 секунд, но это всё ещё usable, особенно для роботов.
💡 Прогноз на 2026–2027: Cerebras будет расширять поддержку моделей и предлагать on-prem «коробки» по цене high-end сервера. Когда это случится, open-source пайплайны с субсекундной задержкой станут стандартом для голосовых ассистентов, и мы перестанем терпеть лаги Siri и Алисы. Хотите быть впереди — собирайте свой стек уже сейчас.
Хотите знать, почему ваш голосовой ассистент до сих пор тупит? Потому что вы используете последовательную архитектуру с монолитными моделями. Соберите пайплайн, как я описал — модульно, параллельно, с Cerebras для LLM и Qwen3TTS в стриминге — и вы поймёте, что реальное время — это не про тактовую частоту, а про то, как компоненты обмениваются данными. И да, теперь вы знаете, как это сделать правильно.
