Єдиний голос для всіх мов: як ми будуємо мультимовний TTS
Ваш сервіс виходить на 10 нових ринків, але кожна мова звучить по-новому — втрачається голосовий бренд. Клієнти помічають: 30% користувачів втрачають довіру при зміні диктора. А code-switching (наприклад, «наш product manager запропонував») перетворює мовлення на какофонію. Ми вирішуємо цю проблему, проектуючи єдину TTS-систему, яка зберігає тембр на всіх цільових мовах з latency p99 менше 200 мс.
Наш стек — cross-lingual synthesis на базі TTS (XTTS v2, ElevenLabs Multilingual v2). Головне — не просто підставити аудіо, а вибудувати архітектуру детекції мови та маршрутизації, що забезпечує стабільну затримку. Як зазначено в репозиторії XTTS v2, модель підтримує 17 мов з одним референсним записом.
Чому XTTS v2 краще окремих моделей?
Окремі моделі для кожної мови дають кращу якість на конкретній мові, але голос різниться. XTTS v2 з cross-lingual synthesis дозволяє використовувати один референсний голос для 17 мов. Економія на ліцензіях та простота підтримки: одна модель замість N.
| Характеристика | Окремі моделі | XTTS v2 / ElevenLabs Multilingual |
|---|---|---|
| Єдиний голос | Ні | Так |
| Якість | Максимальна | Висока, поступається лише на рідкісних мовах |
| Обслуговування | N моделей | 1-2 моделі |
| Затримка | Залежить від маршрутизації | Низька (єдиний інференс) |
| Вартість ліцензій | Вища (на кожну мову) | Фіксована на модель |
Як зберегти голос при перемиканні мов?
Ключова проблема — prosody та вимова. Ми використовуємо speaker embedding з референсного аудіо та передаємо його в модель разом з кодом мови. У XTTS v2 це вирішується параметром speaker_wav:
from TTS.api import TTS tts = TTS("tts_models/multilingual/multi-dataset/xtts_v2").to("cuda") def speak_multilingual(text: str, lang: str, reference_voice: str) -> np.ndarray: return tts.tts( text=text, speaker_wav=reference_voice, language=lang ) Для ElevenLabs — передаємо voice_id та language_code. Результат — єдиний тембр на всіх мовах. При цьому pitch та швидкість залишаються стабільними (відхилення не більше 5% за тестами з носіями).
Що таке code-switching і як його обробляти?
Реальні тексти часто містять суміш мов. Наш пайплайн детектує мову на рівні речень або слів. Для сегментації використовуємо fastText і простий токенізатор:
def split_by_language(text: str) -> list[tuple[str, str]]: """Розбиває текст на сегменти за мовою""" import re segments = [] parts = re.split(r'(\b[A-Za-z][a-zA-Z\s-]*\b)', text) for part in parts: if re.match(r'[A-Za-z]', part): segments.append(("en", part)) elif part.strip(): segments.append(("ru", part)) return segments Кожен сегмент синтезується відповідним двигуном з єдиним голосом. Цей підхід дає природне звучання навіть для текстів з частими перемиканнями.
Що входить в роботу
- Аудит поточних аудіо-ассетів та вимог до голосу
- Вибір архітектури (хмарний API vs self-hosted) з розрахунком costs per 1M characters
- Конфігурація XTTS v2 або ElevenLabs, створення референсних аудіо (рекомендована тривалість — від 30 секунд)
- Розробка пайплайну детекції мови та code-switching
- Інтеграція з вашим бекендом (REST API, gRPC)
- Тестування на 50+ сценаріях (чистий текст, змішаний, акценти, технічні терміни)
- Документація та навчання команди
- Супровід після деплою
Типові помилки при впровадженні
- Ігнорування code-switching — текст з іншомовними вставками звучить неприродно.
- Вибір непідходящого кодека — збільшує latency (p99 може перевищити 500 мс) та витрати на трафік.
- Відсутність fallback-плану при недоступності хмарного API.
- Використання надто короткого референсного аудіо (< 30 секунд) — падає якість клонування.
Порівняння latency для різних архітектур
| Архітектура | Середній latency (p50) | P99 latency |
|---|---|---|
| Хмарний API (ElevenLabs) | 150 мс | 400 мс |
| Self-hosted XTTS v2 (GPU A10) | 80 мс | 200 мс |
| Кастомна модель (донавчена) | 120 мс | 350 мс |
Процес роботи
- Аналітика — аудит аудіо-ассетів, збір сценаріїв використання, заміри поточної latency
- Проектування — вибір стеку, архітектури, прототипування (наприклад, на ElevenLabs Multilingual v2)
- Реалізація — налаштування моделі, розробка інтеграції, обгортка в Docker
- Тестування — A/B тести з носіями мови (не менше 20 респондентів), метрики MOS (Mean Opinion Score) та WER (Word Error Rate) на еталонних фразах
- Деплой — контейнеризація, моніторинг (latency, utilization GPU), CI/CD
Терміни орієнтовно
- Хмарна інтеграція (Azure, ElevenLabs) — від 3 до 5 днів
- Self-hosted рішення з XTTS v2 — від 1 до 2 тижнів
- Кастомна модель з донавчанням — від 4 тижнів
Вартість розраховується індивідуально. Ми гарантуємо фіксовану ціну на кожному етапі.
Досвід компанії: 5 років на ринку AI-рішень, 30+ завершених проектів з TTS та ASR. Маємо сертифікати з аудіообробки.
Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію з вибору архітектури мультимовного TTS.







