Локальные модели синтеза речи: критерии выбора для офлайн-задач

Зато становятся явными ограничения, которые облачный API обычно скрывает: задержка первого аудиофрагмента, потребление RAM и VRAM, скорость генерации на конкретном процессоре, доступность нужного голоса и лицензия весов.

Для офлайн-задач нет универсального победителя. Piper рассчитан на слабое железо и CPU-сценарии. NeuTTS Air сочетает квантованные веса с генерацией на процессоре. Kokoro-82M занимает промежуточную позицию по размеру модели. XTTS v2 и OmniVoice дают более широкий набор возможностей, но предъявляют другие требования к инфраструктуре и проверке языковых чекпоинтов.

Сначала измерьте задачу, а не модель

Главный показатель скорости генерации — RTF, или Real-Time Factor. Он сопоставляет длительность синтезированного аудио со временем, которое занял инференс. При RTF ниже 1 модель генерирует быстрее реального времени. Значение, полученное на серверной видеокарте, нельзя переносить на CPU ноутбука или одноплатный компьютер: это характеристика связки модели и оборудования.

Для интерактивного приложения одного RTF недостаточно. Пользователь слышит задержку до первого аудиофрагмента, а не только итоговое время генерации всей реплики. Поэтому отдельно измеряют latency первого чанка и скорость последующих чанков. Для пакетной озвучки длинных текстов критичнее суммарное время обработки и стабильность пайплайна.

Перед выбором локальной модели зафиксируйте рабочую нагрузку:

• длину типичного текста и частоту запросов;
• допустимую задержку до начала воспроизведения;
• целевое оборудование: CPU, GPU, объем VRAM и RAM;
• требуемые языки, голоса и режим клонирования;
• формат входа и выхода, требования к потоковой передаче;
• ограничения лицензии для коммерческого или внутреннего использования.

Сравнивать модели корректно на одном устройстве, с одинаковыми настройками и сопоставимым текстом. Нужно учитывать время загрузки весов, прогрев инференса, нормализацию текста и работу вокодера. Иначе замер будет описывать не модель, а случайные различия тестового пайплайна.

RTF показывает пропускную способность. Для диалогового интерфейса критична задержка первого аудиофрагмента.

В сводных сравнениях быстрых моделей встречаются значения RTF порядка 0,008–0,025. Их нельзя считать гарантией для локального запуска: результат зависит от GPU, точности вычислений, длины текста и реализации. Для OmniVoice, например, приводится RTF от 0,025 на NVIDIA H100. Это серверная точка измерения, а не обещание такой же скорости на пользовательской видеокарте.

CPU-класс: Piper и NeuTTS Air

Если GPU нет, выбор начинается с моделей, рассчитанных на CPU или пригодных для квантованного запуска. Piper использует ONNX-модели на базе VITS и ориентирован на CPU, в том числе на устройства класса Raspberry Pi 4. Размер отдельных моделей обычно указывается ниже 100–110 МБ. В фактуре для Piper также отмечено требование менее 3 ГБ VRAM, но для CPU-сценария важнее замерить RAM, скорость и нагрузку на конкретное устройство.

Компактный файл не означает мгновенный старт. На устройстве с медленным накопителем время загрузки может заметно влиять на первый запрос. При постоянной работе модель разумно держать в памяти. Для приложения с редкими запросами нужно отдельно проверить стоимость выгрузки и повторной инициализации.

NeuTTS Air устроена иначе. Модель содержит 748 млн параметров, но квантованные сборки GGUF в форматах Q4/Q8 занимают менее 200 МБ. Она предназначена для CPU-инференса в реальном времени и поддерживает клонирование голоса по короткому образцу, около трех секунд. Такая длительность снижает порог подготовки референса, но не отменяет требований к чистоте записи. Шум, реверберация и посторонняя речь ухудшают кондиционирование.

У Piper практическое преимущество — компактный ONNX-пайплайн и ориентация на CPU. Для встраиваемых устройств это снижает сложность развертывания. Ограничение — качество и набор голосов зависят от конкретного чекпоинта. Наличие модели не гарантирует нужный язык или приемлемое произношение имен, аббревиатур и чисел.

NeuTTS Air интересна, когда требуется сочетание CPU-запуска и клонирования. Показатель размера после квантования нужно трактовать как размер весов, а не как полную оценку потребления памяти процесса. К этому добавляются runtime, буферы аудио и текстовая обработка. Поэтому модель на диске меньше 200 МБ не означает, что системе достаточно такого же объема RAM.

Средний и тяжелый класс: качество, языки, GPU

Kokoro-82M содержит 82 млн параметров, распространяется по Apache 2.0 и имеет опубликованную оценку естественности MOS 4,2. Это компактная модель с более доступным весовым профилем, чем крупные трансформерные решения. Но сам MOS не заменяет проверку на целевом языке. Методика, состав слушателей, тестовые тексты и версия чекпоинта влияют на результат.

Для XTTS v2 заявлены 17 языков и потоковая передача с задержкой менее 200 мс. Для комфортного запуска на GPU требуется от 8 ГБ VRAM. Это уже отдельный класс инфраструктуры: под нагрузкой нужно учитывать память модели, активации, аудиобуферы и одновременность запросов. Увеличение размера батча может улучшить пропускную способность, но повысить задержку отдельного запроса.

OmniVoice поддерживает синтез более чем на 600 языках и zero-shot клонирование по аудио длительностью 3–10 секунд. Для этой модели приводится RTF от 0,025 на NVIDIA H100. Масштаб языковой поддержки полезен для мультиязычного пайплайна, однако число языков само по себе не описывает качество каждого из них. Перед интеграцией проверяют нужный язык, наличие подходящего голосового режима и корректность чтения целевых текстов.

При выборе между этими моделями полезно разделять три характеристики:

• Естественность речи. MOS и субъективное прослушивание помогают оценить просодию, но сравнение имеет смысл только при сопоставимой методике.
• Управляемость голоса. Zero-shot клонирование зависит от длительности и качества референса, а также от того, насколько модель сохраняет тембр на длинной реплике.
• Цена инференса. VRAM, скорость на целевой GPU, время первого чанка и устойчивость при параллельных запросах определяют эксплуатационный бюджет.

Заявленная поддержка языка не равна наличию готового голоса, который подходит продукту. В частности, нельзя автоматически считать, что любая из перечисленных моделей качественно синтезирует русский из коробки. Нужны конкретный чекпоинт, русскоязычные тесты и проверка фонетики. Тестовый набор должен включать даты, числа, сокращения, фамилии, англоязычные термины и длинные синтаксические конструкции.

Для клонирования отдельно оценивают стабильность тембра. Короткий чистый образец может дать рабочее сходство на одной фразе, но результат меняется на длинных предложениях и при иной интонации. В продуктовой оценке нужны несколько фрагментов разной длины. Также нужно заранее проверить права на голосовые данные и условия распространения модели.

Потоковая генерация и интеграция с LLM

Связка LLM и TTS часто задерживается до момента, когда языковая модель закончит весь ответ. Для голосового интерфейса это лишнее ожидание. Потоковый пайплайн передает текст в синтез по мере готовности, а аудио воспроизводит чанками.

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

В интеграции нужно контролировать несколько точек:

1. Нормализация текста. Числа, даты, символы валют и аббревиатуры переводятся в форму, которую модель произносит предсказуемо.

2. Буферизация. Система не должна отправлять в синтез обрывок, который LLM может продолжить синтаксически или смыслово.

3. Согласование темпа. Если LLM генерирует текст медленнее, чем TTS озвучивает, аудиопоток будет прерываться. Если быстрее, растет буфер.

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

5. Поведение при сбое. Нужно определить, что происходит при ошибке вокодера, нехватке памяти или разрыве внутреннего соединения между компонентами.

Для офлайн-сценария «без интернета» недостаточно один раз скачать веса. В изолированную среду переносят runtime, зависимости, токенизаторы или текстовые нормализаторы, конфигурации, голосовые файлы и сами чекпоинты. Затем тестируют чистый запуск без сетевого доступа. Некоторые приложения при старте пытаются проверить обновления или загрузить недостающие артефакты; такой вызов должен быть выявлен до развертывания.

Русскоязычные чекпоинты и эксплуатационная проверка

Локальные библиотеки синтеза речи дают контроль над данными и позволяют работать без обращения к облачному API. Но локальное размещение не решает автоматически вопросы качества. Для русского языка критичны ударения, редукция гласных, произношение заимствований и чтение числовых последовательностей. Эти ошибки часто не видны на короткой демонстрационной фразе.

Соберите небольшой регрессионный корпус из реальных текстов продукта. Включите в него фразы с именами, датами, адресами, обозначениями моделей и словами, где ударение зависит от контекста. Для каждого релиза сохраняйте аудиовыход и параметры инференса. При обновлении весов сравнивайте не только субъективное впечатление, но и длину пауз, обрезание концов фраз, артефакты вокодера и изменение тембра.

У локального запуска есть и эксплуатационная цена. Команда отвечает за обновление библиотек, хранение и версионирование весов, мониторинг расхода памяти и обработку перегрузки. В многопользовательском сервисе один экземпляр модели может обслуживать запросы последовательно или параллельно; фактическая пропускная способность зависит от реализации и оборудования. Показатель RTF одиночного теста не описывает поведение очереди под нагрузкой.

Выбор сводится к профилю ограничения. Для слабого CPU и предсказуемой озвучки подходит Piper. Для CPU-сценария с квантованием и коротким референсом стоит оценивать NeuTTS Air. Kokoro-82M дает компактный вариант с опубликованным MOS, а XTTS v2 и OmniVoice требуют более тщательной проверки GPU-ресурсов, чекпоинта и языкового качества.

Перед внедрением нужен замер на целевой машине. В него входят задержка первого чанка, RTF, RAM/VRAM, скорость при параллельных запросах и прослушивание русскоязычного тестового корпуса. Без этих данных выбор архитектуры остается предположением.