Библиотеки синтеза речи для Python: сравнение скорости и ресурсов

XTTS v2 и Bark требуют видеопамяти и не рассчитаны на генерацию в реальном времени на процессоре. Сравнивать их по одному числу бессмысленно: у библиотек разная точность измерений, разные модели и разные условия запуска.

Базовая метрика — RTF, коэффициент реального времени. Значение ниже 1 означает, что синтез занимает меньше времени, чем звучание готовой речи. Например, при RTF 0,5 одна минута аудио генерируется примерно за 30 секунд. Но RTF не описывает задержку до первого фрагмента речи, загрузку модели и поведение при параллельных запросах. Для голосового ассистента эти параметры могут быть важнее скорости обработки длинного текста.

Архитектура определяет профиль нагрузки

В простейшем варианте Python-код передает текст системному речевому движку. Так устроена pyttsx3: в Windows она использует SAPI5, в Linux — espeak, в macOS — NSSpeechSynthesizer. Нейросетевые веса не загружаются, GPU не требуется. Цена такого режима — роботизированное звучание и зависимость от установленного в системе движка.

Нейросетевые TTS-модели синтезируют аудио с помощью обученных весов и вокодера. Авторегрессионные архитектуры формируют результат последовательно, токен за токеном. Это увеличивает вычислительную нагрузку и затрудняет быстрый вывод на CPU. XTTS v2 и Bark относятся к тяжелым моделям этого класса: для них нужны GPU и как минимум 4 ГБ и 8 ГБ VRAM соответственно.

Неавторегрессионный подход позволяет обрабатывать части синтеза параллельно. Он лучше подходит для CPU-инференса и устройств с ограниченными ресурсами. Piper использует ONNX Runtime и ориентирован в том числе на ARM-платформы. Kokoro-82M — компактная модель на 82 млн параметров, для которой доступны квантованные ONNX-веса.

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

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

Silero, Piper и Kokoro: локальный инференс на CPU

Для Silero TTS v5 приводится RTF около 0,04 на CPU. Это соответствует генерации примерно в 24 раза быстрее реального времени. Модель поддерживает ударения и 29 русских голосов. Для локального сервиса такая конфигурация снижает зависимость от внешней сети и снимает требование к GPU. При этом опубликованный RTF сам по себе не гарантирует ту же скорость на любом процессоре: частота, число ядер, версия библиотек и размер входного текста влияют на результат.

Piper построен вокруг ONNX Runtime и рассчитан на устройства с ограниченными ресурсами, включая ARM и Raspberry Pi 4. Для него заявлена скорость более трехкратного реального времени на CPU; средний размер файла голосовой модели составляет около 63 МБ. Это делает Piper практичным кандидатом для встраиваемого локального синтеза. Размер файла голоса, однако, не равен полной потребности процесса в памяти: во время исполнения добавляются веса, буферы и накладные расходы среды.

Kokoro-82M занимает промежуточное место по профилю. Модель содержит 82 млн параметров. Квантованный вариант int8 в ONNX весит около 86–92 МБ. Для 32-ядерного CPU указан медианный RTF около 0,640. По определению метрики это быстрее реального времени, но существенно медленнее заявленного результата Silero. Сравнивать эти значения без сведений о тестовой системе и одинаковых входных данных следует осторожно.

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

• Режим исполнения. Если проект обязан работать без сети, облачные gTTS и edge-tts не подходят.
• Доступное железо. Для Silero и Piper описан CPU-сценарий; XTTS v2 и Bark требуют GPU с указанным минимумом VRAM.
• Требования к голосу. Число голосов и поддержка ударений влияют на применимость модели, но не заменяют прослушивание результата на целевых текстах.
• Размер артефактов. Размер модели влияет на доставку и хранение, но не показывает весь расход оперативной памяти при инференсе.
• Задержка приложения. Итоговое время включает подготовку текста, загрузку модели, генерацию и передачу аудио клиенту.

Когда требуется GPU

XTTS v2 и Bark не стоит выбирать для CPU-инференса в реальном времени. Для XTTS v2 указан минимум 4 ГБ VRAM, для Bark — 8 ГБ VRAM. Это ориентиры по минимальному объему видеопамяти, а не гарантия заданной скорости или стабильной работы при нескольких параллельных запросах.

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

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

Облачные API и стоимость сетевого этапа

gTTS и edge-tts обращаются к облачным API, связанным соответственно с Google Translate и Microsoft Edge TTS. Они не являются офлайн-библиотеками. Локально не требуется запускать тяжелую нейросетевую модель, поэтому снижается нагрузка на CPU и GPU. Вместо нее появляется сетевой этап: запрос может задержаться из-за соединения, ответа сервиса или передачи аудио.

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

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

Как измерять скорость в своем пайплайне

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

Минимальный набор метрик для практического сравнения:

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

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

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

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

5. Качество на собственных текстах. Короткие фразы, числа, аббревиатуры и сложные ударения выявляют разные ошибки синтеза.

В протоколе замеров стоит записывать версию модели, библиотек, ONNX Runtime или другого исполнительного слоя, устройство и число потоков CPU. Без этого цифры трудно воспроизвести. Результат одного процессора нельзя переносить на другой как свойство библиотеки.

Практический выбор сводится к профилю нагрузки. Для автономной озвучки на CPU разумно начинать с Silero или Piper. Kokoro подходит для проверки компактной неавторегрессионной модели при наличии сопоставимого тестового окружения. Для системного голоса без нейросетевой нагрузки есть pyttsx3, если качество его движка приемлемо. gTTS и edge-tts подходят только там, где допустима сеть. XTTS v2 и Bark требуют GPU-ресурса и отдельного тестирования задержки.

В итоговом сравнении важны условия замера, а не максимальное число из таблицы. Для CPU-озвучки опубликованные показатели Silero и Piper выглядят пригодными для задач быстрее реального времени; Kokoro также укладывается в этот критерий на указанной конфигурации. Для ассистента нужно измерять TTFB и нагрузку под очередью. Это и определяет пригодность библиотеки в конкретном Python-пайплайне.