Локальный синтез речи: тесты скорости популярных библиотек

Значение 5,3 — минута аудио требует 5 минут 18 секунд.

В сравнении локальных библиотек TTS разрыв существенный. Kokoro-82M показывает RTF около 0,03 на GPU A100. Supertonic 3 достигает 0,20 на 16-поточном CPU. Piper работает на компактных устройствах с моделью размером 22–38 МБ. А XTTS-v2 при запуске на CPU уходит в RTF около 5,3. Это разные классы пайплайнов, несмотря на одинаковый интерфейс text → audio.

Метрики производительности: RTF против задержки

RTF подходит для оценки пакетной генерации. Например, для озвучки каталога роликов, подкастов или большого набора реплик. Для голосового ассистента одной этой метрики недостаточно.

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

• время загрузки весов и инициализации рантайма;
• задержка до первого аудиофрагмента;
• время генерации первого токена или первого акустического блока;
• скорость потоковой выдачи;
• задержка вокодера;
• сетевой или IPC-обмен между компонентами;
• время постобработки и кодирования в PCM, WAV, Opus или другой формат.

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

Для потокового ассистента удобнее разделять два показателя:

1. FTTS, First Token to Speech — время от поступления запроса до первого аудиоканала.

2. VART, Voice Assistant Response Time — полная задержка ответа голосового интерфейса.

Picovoice Orca в опубликованных тестах показывает FTTS до 128 мс и VART около 204 мс. Это уже параметры интерактивного контура, а не просто производительность инференса.

RTF рассчитывается как отношение времени генерации к длительности выходного аудио:

RTF = время генерации / длительность аудио

Чем ниже значение, тем выше пропускная способность. Но сравнивать RTF разных проектов напрямую нельзя без фиксации условий:

• модель и версия весов;
• тип данных: FP32, FP16, INT8;
• CPU или GPU;
• число потоков;
• длина входного текста;
• длина выходной реплики;
• режим warm-up;
• потоковый или пакетный инференс;
• включён ли VAD, нормализация текста и постобработка;
• используется ли аппаратный backend ONNX Runtime, TensorRT или другой компилятор.

Для коротких фраз отдельный вклад даёт запуск пайплайна. Для длинных текстов сильнее проявляется чистая скорость декодирования. Поэтому RTF на 12 символах и RTF на 1712 символах — не одно и то же измерение.

Низкий RTF отвечает на вопрос «как быстро модель генерирует аудио». FTTS отвечает на вопрос «как быстро пользователь услышит начало ответа». Для Voice-AI это разные бюджеты задержки.

Kokoro-82M, Supertonic 3 и Piper: скорость без клонирования

Легковесные модели закрывают основной сценарий локального TTS: фиксированный набор голосов, известный язык, синтез без zero-shot-клонирования. Здесь нет отдельного этапа извлечения speaker embedding и нет необходимости подгонять голос под референсную запись. Архитектура проще. Инференс быстрее.

Kokoro-82M

Kokoro-82M содержит около 82 млн параметров. Версия 1.0 вышла 27 января 2025 года. Размер весов в FP16 — менее 1 ГБ. Это не минимальный embedded-движок, но модель остаётся компактной для рабочего GPU или современного CPU.

На GPU A100 заявлен RTF около 0,03. Генерация 10 секунд речи занимает приблизительно 0,3 секунды. Такой показатель даёт запас для пакетной обработки и потоковой выдачи. На CPU RTF находится в диапазоне 0,12–0,45 в зависимости от конфигурации и реализации backend.

Разброс на CPU шире, чем на GPU. Причины стандартные:

• число физических ядер;
• SIMD-инструкции;
• пропускная способность памяти;
• размер кэша;
• реализация матричных операций;
• выбранный формат весов;
• конкуренция с другими процессами.

Kokoro-82M использует предустановленные голоса. Модель нельзя рассматривать как универсальный движок произвольного клонирования. Это быстрый TTS с контролируемым набором speaker-профилей.

Для локального сервиса с большим количеством коротких реплик Kokoro-82M выглядит рационально. Вес модели не требует отдельного inference-сервера. RTF ниже единицы даже на CPU. Ограничение — голосовой инвентарь и отсутствие полноценного zero-shot режима.

Supertonic 3

Supertonic 3 содержит около 99 млн параметров. На 16-поточном CPU модель показывает RTF около 0,20. Это означает генерацию в пять раз быстрее реального времени. Значение сопоставимо с OmniVoice на GPU RTX 3090, где для модели примерно на 800 млн параметров приводится RTF около 0,196.

Сравнение показательно не само по себе, а по структуре вычислений. Большая модель на дискретном GPU не всегда даёт кратный выигрыш относительно компактной модели на CPU. Накладные расходы инференса, схема декодирования и пропускная способность памяти могут нивелировать разницу в количестве параметров.

Supertonic 3 подходит для серверного CPU-развёртывания, если нет требований к zero-shot-клонированию. Для нескольких параллельных каналов одного RTF недостаточно. При росте concurrency меняются:

• загрузка ядер;
• давление на память;
• очередь запросов;
• время до первого фрагмента;
• стабильность latency p95 и p99.

Одиночный RTF 0,20 не означает, что 10 одновременных сессий будут обслуживаться с тем же качеством. Нужен отдельный тест очереди и потоковой выдачи.

Piper TTS

Piper изначально ориентирован на CPU. Это один из наиболее практичных вариантов для устройств с ограниченной памятью и без GPU. В тестах float16-модель размером около 38 МБ показывает RTF 0,192. Квантованная int8-версия размером около 22 МБ — RTF 0,523.

Снижение размера в 1,7 раза сопровождается падением скорости примерно в 2,7 раза. Это не универсальное правило для всех архитектур. В данном случае оно показывает цену конкретной реализации квантования и CPU-пайплайна.

Piper выигрывает не максимальным качеством голоса и не гибкостью, а операционной простотой. Модель можно разместить в приложении, контейнере или edge-устройстве. Пиковое потребление памяти предсказуемо. Зависимость от внешнего API отсутствует.

Для смартфона, Raspberry Pi, локального шлюза или офлайн-функции в десктопном приложении этот профиль часто полезнее, чем высокая выразительность тяжёлой модели. Но качество зависит от конкретного голоса и языка. Сравнивать Piper с клонирующими моделями по одному критерию некорректно: он решает другую задачу.

Клонирование голоса: Audio8, XTTS-v2 и F5-TTS

Клонирование добавляет в пайплайн несколько операций. Модель должна обработать референс, извлечь характеристики говорящего, сохранить их в embedding или conditioning-состоянии и затем сгенерировать новую речь с нужной просодией. Это увеличивает вычислительную стоимость и требования к памяти.

Audio8 против XTTS-v2

Audio8 имеет масштаб около 0,6 млрд параметров и предназначена для многоязычного клонирования. На CPU её RTF составляет примерно 1,40. Это медленнее реального времени, но заметно быстрее XTTS-v2, для которой приводится RTF около 5,3 на CPU.

Разница — примерно в 3,8 раза. Для пакетной озвучки Audio8 уже может быть применима на CPU при наличии очереди. Для интерактивной речи один поток без оптимизации остаётся пограничным: пользователь слышит ответ с задержкой, а длинная реплика быстро накапливает отставание.

На GPU при использовании оптимизаций уровня SGLang Omni RTF Audio8 снижается до 0,09–0,116. Это переводит модель в другой режим эксплуатации. Генерация становится быстрее реального времени с существенным запасом. Но такой результат нельзя переносить на обычный запуск в PyTorch. Backend, компиляция графа, размер батча и схема KV-кэша меняют итоговые цифры.

XTTS-v2 сохраняет практическую ценность там, где требуется зрелый многоязычный пайплайн и знакомая интеграция. По скорости на CPU это слабый вариант. RTF около 5,3 исключает полноценную интерактивность без GPU или предварительной генерации.

Отдельный фактор — лицензирование. XTTS v2 использует CPML. Это не означает автоматическое разрешение на любой коммерческий сценарий. Лицензию нужно проверять для конкретного продукта, модели распространения и способа использования голосовых данных.

F5-TTS

F5-TTS построена на Flow Matching и архитектуре DiT. Модель поддерживает клонирование по референсу длительностью 5–15 секунд. На GPU заявлен RTF около 0,15 при 16 шагах генерации, или NFE.

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

F5-TTS подходит для сценариев, где требуется управляемое сходство голоса, а не просто выбор из встроенного набора. Референс в 5–15 секунд снижает требования к подготовке датасета. Но это не отменяет контроля входной записи. Шум, реверберация, несколько говорящих и сильная компрессия ухудшают conditioning.

Критичный пункт — лицензия весов. F5-TTS распространяется с некоммерческими весами CC-BY-NC. Использование в коммерческом продукте нельзя считать разрешённым только потому, что код доступен публично. Код, модельные веса, датасеты и аудиореференсы имеют разные правовые контуры.

В клонирующем TTS скорость инференса — только половина задачи. Вторая половина — лицензия весов, права на референс и контроль того, чей голос фактически воспроизводит пайплайн.

ChatTTS

ChatTTS оптимизирована под диалоговые реплики и может работать с дополнительными параметрами выразительности. На GPU приводится RTF около 0,3–0,65. Разброс зависит от класса GPU и конфигурации. Для RTX 4090D указывается значение около 0,65.

Модель демонстрирует нестабильность на длинных фразах. Это ограничивает применение в непрерывной озвучке длинного текста. Для чат-интерфейса с короткими ответами профиль приемлем. Для аудиокниги или длинного подкастного сегмента потребуется разбиение текста, контроль стыков и повторная проверка артефактов.

Разбиение по предложениям не всегда решает проблему. При слишком коротких сегментах появляются:

• скачки интонации;
• разные тембральные состояния;
• лишние паузы;
• нарушение ударений;
• неодинаковая громкость;
• повторная инициализация speaker conditioning.

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

Интерактивные системы: Orca и Pocket TTS

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

Picovoice Orca

Picovoice Orca — локальный коммерческий движок с моделью размером около 7 МБ. Пиковое потребление памяти составляет около 29 МБ. FTTS достигает 128 мс. VART — около 204 мс.

Такой профиль ориентирован на edge-инференс и ассистентов с жёстким latency budget. Малый размер модели снижает стоимость доставки и запуска. Нет зависимости от видеопамяти. Нет сетевого round trip. Проще контролировать персональные данные: аудио и текст могут оставаться на устройстве.

Orca нельзя напрямую сравнивать с Kokoro-82M или F5-TTS по выразительности и гибкости. Это другой инженерный компромисс. Малый runtime и низкая задержка достигаются за счёт фиксированной архитектуры, ограниченного набора функций и коммерческой модели поставки.

Для голосового интерфейса оценка должна включать не только среднее время, но и хвост распределения:

• p50 показывает типичный отклик;
• p95 — задержку для большинства проблемных запросов;
• p99 — поведение системы под нагрузкой и на сложных фразах.

Вызов внешнего API может дать хорошее среднее значение, но нестабильный p95 из-за сети. Локальный движок обычно упрощает контроль хвостов, хотя создаёт нагрузку на CPU устройства.

Pocket TTS

Pocket TTS от Kyutai содержит около 100 млн параметров и оптимизирована под CPU. Модель поддерживает клонирование по пятнадцатисекундному? Нет. В доступных данных указан референс длительностью 5 секунд. Это короткий conditioning-фрагмент.

RTF держится в диапазоне 0,69–0,76 и почти не меняется при длине текста от 12 до 1712 символов. Стабильность на таком диапазоне полезна для серверной очереди. Она показывает, что стоимость инференса не деградирует резко на длинных входах.

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

Pocket TTS интересна как промежуточный вариант между фиксированным голосом и тяжёлым zero-shot TTS:

• CPU-инференс;
• локальное исполнение;
• клонирование по короткому референсу;
• умеренный размер модели;
• RTF около 0,7;
• отсутствие необходимости в дискретном GPU.

Для пакетной генерации она уступает Kokoro-82M и Supertonic 3. Для интерактивного сценария с клонированием может оказаться рациональнее Audio8 на CPU и значительно легче XTTS-v2.

Потребление памяти и размер весов

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

• веса;
• промежуточные активации;
• кэш декодера;
• аудиобуферы;
• runtime;
• tokenizer и нормализатор;
• несколько потоков обработки;
• копии модели при multiprocessing;
• память backend и драйвера.

Для CPU-сервиса с одной моделью это особенно заметно при переходе от одиночного процесса к нескольким worker. Если каждый worker загружает собственную копию весов, потребление памяти растёт почти линейно. Shared memory и server-side batching меняют картину, но требуют другой архитектуры.

Квантование сокращает размер весов. Оно не гарантирует ускорение. INT8 может улучшить пропускную способность на CPU с подходящими инструкциями. На другой архитектуре конвертация может добавить операции распаковки и ухудшить latency. Piper показывает именно такой практический компромисс: FP16-версия на 38 МБ имеет RTF около 0,192, а INT8-версия на 22 МБ — около 0,523.

Kokoro-82M с весами менее 1 ГБ в FP16 легко размещается на GPU среднего класса и рабочих станциях. Audio8 и другие модели порядка 0,6 млрд параметров требуют уже другой оценки VRAM. Важно учитывать не только загрузку модели, но и размер батча, длину последовательности и параллельные сессии.

В edge-сценариях Orca находится в отдельной категории: 7 МБ модели и 29 МБ пиковой памяти. Это параметры для встраиваемого продукта, а не для универсального исследовательского пайплайна.

Как проводить собственный бенчмарк

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

1. Фиксировать железо.

Модель нужно тестировать на конкретном CPU или GPU. Название устройства без числа потоков, версии драйвера и режима питания недостаточно.

2. Прогреть runtime.

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

3. Разделить длины текста.

Нужны короткие реплики для ассистента, средние фразы для озвучки и длинные сегменты для пакетной генерации. Один усреднённый текст скрывает форму latency-кривой.

4. Измерять длительность аудио.

Секунды выходного сигнала должны вычисляться по фактическому числу сэмплов, а не по ожидаемому размеру текста.

5. Записывать RTF и абсолютное время.

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

6. Снимать p50, p95 и p99.

Среднее значение не показывает редкие зависания на длинных фразах или при конкуренции потоков.

7. Проверять потоковый режим.

Непотоковая генерация может иметь хороший итоговый RTF и неприемлемый FTTS.

8. Разделять инференс и постобработку.

Resampling, loudness normalization, кодирование и отправка аудио добавляют задержку. Их нужно измерять отдельно.

9. Повторять тест после квантования.

FP16, FP32 и INT8 дают разные результаты. Выбор формата нельзя делать только по размеру файла.

10. Тестировать ошибочные и сложные входы.

Числа, URL, аббревиатуры, знаки препинания и смешанные языки выявляют проблемы текстового нормализатора быстрее, чем чистый литературный текст.

Бенчмарк для production должен измерять не только одну генерацию, но и очередь запросов. Для многопользовательского сервиса нужны сценарии с concurrency 1, 2, 4 и далее до насыщения CPU или GPU. Фиксируются throughput, latency, доля ошибок, пропуски аудиобуферов и потребление памяти.

Ограничения сравнений

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

Ключевые источники расхождений:

• разные версии PyTorch и ONNX Runtime;
• разные реализации вокодера;
• разные sample rate;
• CUDA-графы и отсутствие CUDA-графов;
• число NFE в Flow Matching;
• streaming chunk size;
• FP16 на GPU и FP32 на CPU;
• NUMA-конфигурация сервера;
• ограничение частоты процессора;
• длина пауз и просодическая разметка;
• отдельный или совместный запуск text frontend.

Особенно осторожно нужно трактовать сравнение CPU и GPU. RTF 0,20 на 16-поточном CPU и RTF 0,196 на RTX 3090 почти совпадают численно, но стоимость эксплуатации, масштабирование и параллельность у этих систем разные. GPU обычно выигрывает на нескольких потоках и больших батчах. CPU проще разместить на edge-устройстве и дешевле использовать при небольшом числе запросов.

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

Мобильные CPU также нельзя оценивать по результатам настольных процессоров. Для большинства моделей нет сопоставимых тестов на ARM-устройствах. Исключение составляют отдельные измерения Piper и локальных коммерческих движков.

Выбор архитектуры для продакшена

Разумный выбор зависит от функции, а не от максимального значения скорости.

Пакетная озвучка большого объёма

Подходят Kokoro-82M и Supertonic 3. У обеих моделей RTF существенно ниже единицы на соответствующих конфигурациях. GPU раскрывает потенциал Kokoro-82M. Supertonic 3 интересна при отсутствии GPU и наличии многопоточного CPU.

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

Edge и офлайн

Piper остаётся практичным вариантом. Размер 22–38 МБ снижает требования к диску и оперативной памяти. Picovoice Orca подходит для сценариев с жёстким FTTS и малым memory budget, если коммерческая лицензия соответствует продукту.

В этом классе критичны время холодного старта и потребление памяти, а не только RTF. Модель, которая быстро генерирует после прогрева, может быть бесполезна, если запуск процесса занимает значительную часть пользовательского сценария.

Клонирование голоса

Audio8 и F5-TTS дают более релевантный функциональный профиль. Audio8 на CPU заметно быстрее XTTS-v2. На GPU с оптимизированным backend её RTF может опускаться до 0,09–0,116. F5-TTS показывает около 0,15 на GPU при 16 NFE.

XTTS-v2 целесообразно рассматривать только после проверки GPU-режима, лицензии и требований к языкам. На CPU значение около 5,3 исключает применение в интерактивном контуре без буферизации.

Короткие диалоговые ответы

ChatTTS и Pocket TTS рассчитаны на другой тип нагрузки, чем классические движки озвучки. ChatTTS показывает RTF около 0,3–0,65 на GPU, но нестабильна на длинных фразах. Pocket TTS работает на CPU с RTF 0,69–0,76 и поддерживает клонирование по 5-секундному референсу.

Для обеих моделей нужен контроль длины ответа. Генерация должна быть привязана к семантическим сегментам. Один длинный ответ увеличивает риск просодических ошибок и задержку до завершения.

Практический итог

В сравнении локальных библиотек TTS по производительности нет единственного победителя. Есть разные профили вычислительной стоимости.

Kokoro-82M — быстрый фиксированный TTS с RTF около 0,03 на A100 и 0,12–0,45 на CPU. Supertonic 3 — компактная модель с RTF около 0,20 на 16-поточном CPU. Piper — вариант для малых устройств, где размер 22–38 МБ важнее выразительности. Audio8 — более быстрый локальный путь к многоязычному клонированию по сравнению с XTTS-v2. F5-TTS требует GPU и контроля NFE. Pocket TTS закрывает CPU-сценарий с клонированием и RTF около 0,7. Orca ориентирована на минимальную задержку и малый memory footprint.

Выбирать библиотеку нужно после фиксации трёх параметров: нужен ли zero-shot voice cloning, допустима ли генерация только на CPU и какой latency budget задан для первого аудиофрагмента. После этого RTF становится рабочей метрикой, а не маркетинговой цифрой.

Для пакетной озвучки приоритетом остаётся throughput. Для ассистента — FTTS, p95 и стабильность потоковой выдачи. Для edge — размер модели и память. Для коммерческого продукта к этим значениям добавляются лицензии весов и права на голосовые данные. Архитектура, которая проходит только один из этих фильтров, продакшен не закрывает.