Средний

9 мин

9

Продолжаю писать о разработке собственного TTS-сервиса, основанный на шишках, набитых в targetai. В первой статье я описал критерии оценки и методологию бенчмарка. В этой статье речь пойдет о том, как мы с командой применили эти критерии на практике.

Дисклеймеры: Всё описанное ниже не претендует на объективную истину. Выводы и трактовки основаны исключительно на моем личном опыте и опыте моей команды в работе с конкретными решениями в конкретном продакшен-контексте. Уровень технических деталей в тексте намеренно упрощен — этот текст ориентирован в первую очередь на технических менеджеров и CTO, принимающих архитектурные решения.

В предыдущей статье я описывал систему критериев оценки TTS-движков для ИИ-агента в голосе (телефония + WebRTC). Если кратко, то вот основные моменты :

Must-have (Приоритет 1): человекоподобность голоса, фонетическое качество на русском языке, поддержка онлайн-режима с предсказуемой задержкой.

Важно, но итерируемо (Приоритет 2): корректность ударений, лёгкость добавления нового голоса, quality voice cloning.

Для тех, кто хочет более широкий взгляд на open source TTS-ландшафт — рекомендую обзор коллег из Raft, там хороший срез по метрикам и архитектурам с точки зрения технической команды. Мы же с коллегами в targetai смотрели на вещи с точки зрения прикладной задачи: что из этого реально работает для русскоязычного голосового агента "в проде".

Отдельная методологическая оговорка, важная для интерпретации дальнейшего: поскольку инференс части моделей неидемпотентен (один и тот же текст на одном референсном аудио может каждый раз звучать чуть иначе), каждую реплику бенчмарк-датасета мы синтезировали минимум 3 раза. Это особенно критично для русского языка: ошибка в ударении может проявляться нестабильно — и один «чистый» прогон не означает, что модель справилась.

Ну что ж, напомнил, о чем была речь ранее, теперь переходим к конкретным моделям.

F5-TTS

Коротко: E2E-модель на flow matching и Diffusion Transformer. Нет авторегрессии, нет отдельного duration predictor, не нужен явный выравниватель (aligner) текста и речи.

Архитектура

Вместо классического каскада «текстовый энкодер → предсказание длительностей → акустическая модель → вокодер» F5-TTS работает принципиально иначе. Текст приводится к длине речевого представления через специальные токены-заполнители, после чего модель «восстанавливает» звук как задачу постепенного деноизинга. Из практически важных деталей: на этапе инференса используется Sway Sampling — стратегия, ускоряющая генерацию без переобучения. Вокодер — Vocos или BigVGAN.

Важная экосистемная деталь для нашей задачи: вокруг F5-TTS существуют русскоязычные чекпойнты с поддержкой явной разметки ударений. Это не свойство исходной базовой модели, но ценный практический бонус.

Что показало тестирование

F5-TTS произвела хорошее впечатление в части voice cloning — перенос тембра, интонаций и экспрессивности на уровне, который мы не ожидали от полностью неавторегрессионной архитектуры. Просодия естественная, модель звучит живо.

Проблема, с которой мы столкнулись — плавающие фонетические отклонения. Конкретный пример: слово «кэшбэк» в части прогонов произносилось как «кэшбок». После дообучения частоту таких ошибок удалось снизить примерно до 3 случаев на 100 сэмплов. Звучит терпимо — но не в телефонии. Одна фонетическая ошибка в ключевом слове в разговоре с клиентом заметнее, чем общий высокий средний балл качества.

Второй принципиальный ограничитель — отсутствие нормального потокового (streaming) режима. Модель генерирует весь результат одной «транзакцией», и разбить этот процесс на чанки с гранулярностью 100–200 мс штатными средствами нельзя. Для offline-сценария это несущественно. Для голосового агента в реальном диалоге — проблема.

Итог по F5-TTS

XTTS v2

Коротко: авторегрессионная multilingual zero-shot TTS от Coqui. Выросла из идей Tortoise, но оптимизирована под cross-language voice cloning и streaming inference.

Архитектура — в двух словах

XTTS v2 предсказывает аудио-токены авторегрессионно — то есть токен за токеном, как языковая модель предсказывает слова. Это принципиально важно: именно авторегрессионная природа делает возможным нативный стриминг — генерацию и отдачу аудио чанками по мере готовности, не дожидаясь конца всей фразы. Для conditioning по голосу используется Perceiver resampler: он «читает» mel-spectrogram референсного аудио и формирует представление голоса, которое подаётся на вход GPT-декодеру. В документации Coqui заявлена задержка первого чанка менее 200 мс в типовой GPU-конфигурации.

Что показало тестирование

XTTS v2 оказалась самой практичной точкой входа для нашей задачи с точки зрения скорости прохождения пути «поднял → дообучил → встроил в онлайн-сценарий». Модель, CLI, API, streaming и fine-tuning уже собраны в одном репозитории.

Отзывчивость к дообучению — хорошая. На датасете менее 100 часов удалось получить достаточное следование разметке ударений. Это важно: не нужно сразу собирать сотни часов доменного русского аудио, чтобы начать управляемо улучшать произношение.

Главная проблема, которую мы фиксировали чаще, чем у других моделей — аудиоартефакты: локальные искажения, клиппинг. Они не всегда критичны в «студийном» прослушивании, но в телефонном канале кодек может их усилить — и тогда они становятся заметны пользователю.

Важная организационная оговорка: оригинальный репозиторий Coqui фактически не поддерживается с прежней активностью. Существует популярный форк с активной поддержкой, и в реальности работа идёт именно с ним — но это нужно учитывать при оценке долгосрочных рисков.

Итог по XTTS v2

ChatterBox

Коротко: семейство open source TTS-моделей от Resemble AI, архитектурно близкое к XTTS. С MIT-лицензией, встроенным watermarking и управлением экспрессивностью.

Архитектура — в двух словах

ChatterBox — каскад из двух основных блоков. Первый (T3) авторегрессионно генерирует речевые токены по текстовым. Второй (S3Gen) переводит эти токены в аудио через flow matching. Финальный вокодер работает на 24 kHz. Есть Turbo-версия (350M параметров) с ускоренным декодером — она требует меньше GPU-памяти и считается быстрее.

Отдельный плюс для коммерческого применения — MIT-лицензия и встроенный watermarking.

Что показало тестирование

По качеству voice cloning ChatterBox показал сильные результаты — перенос тембра и интонаций хороший. Но для нашего сценария модель не прошла практический фильтр из-за выраженного акцента при синтезе на русском языке. Субъективно он воспринимался как «азиатский» и проявлялся достаточно стабильно, чтобы портить пользовательское впечатление в диалоге.

Попытки снизить выраженность проблемы через дообучение не дали результата в достаточной степени.

Важная техническая деталь, которая помогает частично объяснить акцент: в документации прямо указано, что при несовпадении языка референсного аудио и целевого языка синтеза модель может переносить акцент из референса. Частичная митигация через снижение параметра cfg_weight — есть, но это именно митигация, не решение.

Для нас это означало: интересная архитектура, удобная лицензия, но не для русского телефонного продакшена в текущем виде.

Итог по ChatterBox

CosyVoice3

Коротко: multilingual streaming TTS от FunAudioLLM. Ключевая особенность — streaming и non-streaming синтез в одной архитектуре без потери качества в потоковом режиме.

Архитектура — в двух словах

В основе — языковая модель (Qwen2.5-0.5B), которая авторегрессионно генерирует речевые токены по тексту. Затем токены переводятся в аудио через chunk-aware causal flow matching — то есть flow-модель специально устроена так, чтобы одинаково хорошо работать и в batch-режиме, и в потоке. Это не «нарезка» offline-результата на чанки, а нативная потоковая генерация. В материалах проекта заявляется задержка первого пакета до 150 мс.

Инфраструктура вокруг модели — одна из наиболее зрелых среди рассмотренных: поддерживается vLLM, TensorRT-LLM, Triton, gRPC. Лицензия — Apache 2.0.

Что показало тестирование

CosyVoice3 — наш выбор для онлайн-сценария. Native streaming, хорошее качество русского языка в базовой модели, сильная production-инфраструктура — это именно то, что нужно для телефонии.

Но есть один существенный нюанс, который мы обнаружили в процессе дообучения. При работе на относительно небольшом датасете — просодийное качество деградирует заметнее, чем хотелось бы. Модель начинала лучше следовать нужной фонетической разметке, но при этом теряла часть естественности, интонационной пластики, «живости» голоса. Это компромисс, с которым нам пришлось работать.

Важная оговорка для тех, кто будет повторять: наличие русского языка в списке поддерживаемых не гарантирует корректные ударения и отсутствие акцента в телефонном контексте. Это нужно проверять отдельно на своём домене.

Итог по CosyVoice

OmniVoice

Коротко: massively multilingual zero-shot TTS от k2-fsa. 600+ языков, voice cloning и voice design через diffusion language model-style архитектуру на базе Qwen3.

Архитектура — в двух словах

Нестандартная комбинация: backbone — bidirectional Transformer, инициализированный весами Qwen3-0.6B, но генерация устроена не как авторегрессия токен за токеном, а как итеративный unmasking — постепенное «проявление» аудио-токенов за несколько шагов (типично 32, есть 16-step режим). Технически это ближе к masked diffusion, чем к классическому авторегрессионному декодеру. Результат — относительно быстрый offline/batch инференс при высоком качестве. В материалах проекта заявлен RTF порядка 0.025–0.032 на современном GPU.

Модель появилась позже остальных — весна 2026 — что само по себе является оговоркой: меньше накопленного production-опыта.

Что показало тестирование

По двум ключевым качественным критериям OmniVoice показал лучшие результаты среди всех рассмотренных вариантов.

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

И — принципиально важная деталь — при дообучении на датасете до 100 часов для обучения следованию разметке ударений мы не зафиксировали деградации просодийного качества. Именно это отличает OmniVoice от CosyVoice в нашем опыте.

Единственный, но принципиальный минус для телефонии — отсутствие нативного streaming inference. Штатный сильный сценарий модели — быстрый offline и batch. Компенсировать это можно на уровне продуктовой логики: предварительная генерация типовых фраз, нарезка реплик, speculative generation. Но это инженерная компенсация на уровне сервиса, а не свойство самой модели.

Итог по OmniVoice

Сводная таблица

Выбор сделан: комбинируем ресурсы двух моделей

После тестирования и экспериментов с дообучением мы не нашли универсальной модели, которая одновременно закрывала бы все наши требования. Если модель отлично клонирует голос и звучит живо — она может не поддерживать стриминг. Если хорошо стримит и быстро дообучается — у неё могут проявляться аудиоартефакты или деградировать просодия. Если архитектурно идеальна для онлайна — дообучение на небольшом датасете может «выбить» из неё естественность.

При наших ресурсных ограничениях гнаться за одной универсальной моделью оказалось нецелесообразным. Мы остановились на двух рабочих направлениях:

CosyVoice3 — для сценариев, где критичны стриминг, предсказуемая задержка и хороший real-time factor. Нативный потоковый режим, зрелая production-инфраструктура (vLLM, TensorRT-LLM, Triton, gRPC), хорошее базовое качество русского языка. Компромисс: при дообучении на небольшом датасете нужно тщательно контролировать деградацию просодии.

OmniVoice — для сценариев, где важнее максимальное качество voice cloning, просодии и естественности, а отсутствие нативного стриминга можно компенсировать архитектурными решениями на уровне сервиса. Лучший результат по quality-критериям среди всех рассмотренных, и — что для нас особенно ценно — дообучение под русские ударения не ломает просодию.

Для голосового ИИ-агента качество TTS — это не один общий score, а набор балансов между фонетикой, задержкой, стабильностью, стоимостью инференса и скоростью адаптации голоса под конкретный бренд или сценарий.

Продолжение следует

Надеюсь, наш опыт будет вам полезен. Оставляйте комментарии, я все читаю и на все отвечаю. Пока план на следующую статью - поделиться информацией про нашу инфраструктурную часть: как организовали продакшен-сервис вокруг выбранных моделей, что сделали с latency на уровне системы, и как управляем качеством на стыке TTS и диалогового агента.