FireRedTTS3 — мультиязычный TTS (24 языка, вкл. украинский)

Локальный сервис синтеза речи на FireRedTTS3 с HTTP-API и MCP-сервером. Третий в ряду рядом с ukrainian-tts (StyleTTS2, :8000) и HolosTTS (:8010); этот — на :8020.

Модель вышла 13.08.2026, лицензия Apache 2.0, веса публичные.

Чем отличается от соседей

Три вещи, которые стоит понимать, прежде чем начать:

1. Пресетных голосов нет. Пустая библиотека = синтезировать нечем. Сначала заводишь голос из любой записи речи (add_firered_voice), дальше используешь его по имени. Модель клонирует zero-shot прямо во время синтеза.

2. Нужен транскрипт референса. Модели мало самого аудио — нужен ещё текст того, что в нём звучит. Не передашь — распознаём Whisper'ом, но свой текст всегда точнее.

3. Ударений нет. Ни словаря, ни ByT5-фолбека, ни ручного Му+дрого, как у соседей. Ударения модель ставит сама из контекста, и на омографах (за́мок/замо́к) она их путает. Это принципиальное ограничение мультиязычной модели — если ударения критичны, HolosTTS до сих пор лучший выбор для чистого украинского.

Related MCP server: STT2TTS MCP

Установка

cd /Users/admin/Projects/firered-tts
./setup.sh                    # venv + залежності + апстрім + патч + ваги

setup.sh делает четыре вещи:

1. .venv с Python 3.11, torch 2.8.0 под MPS/CPU

2. клонирует апстрим в vendor/FireRedTTS3 на зафиксированном коммите 00570ad

3. патчит его под Apple Silicon — см. ниже

4. тянет веса base+redae (~11.4 ГБ) в pretrained_models/

Веса отдельно (долго — лучше detached):

nohup ./download-weights.sh base > data/download.log 2>&1 &
./download-weights.sh instruct   # +7.9 ГБ, для дизайну голосу й редагування

Зачем патч

Апстрим написан исключительно под NVIDIA и на Mac не запускается вообще:

flash_attn — CUDA-only, на Metal не собирается в принципе; sdpa работает везде, в т.ч. на NVIDIA, так что патч ничего не ломает.

Десятое место в патче стоит отдельно: base.py:317 — это не портативность, а производительность (кеш кодирования референса, см. «Скорость» ниже).

src/patch_upstream.py идемпотентный и падает, если замена не попала — если апстрим изменился, ты узнаешь об этом сразу, а не CUDA-ошибкой на первом синтезе.

Запуск

./run.sh                      # http://localhost:8020

Отдельно запускать не обязательно — MCP-сервер поднимет бекенд сам. Бекенд выключается после 1800с простоя (IDLE_SHUTDOWN_SECONDS) и освобождает память.

run.sh берёт лок на порт (data/.start-<порт>.lock): второй запуск при живом сервисе просто выйдет с кодом 0. Это намеренно — autostart дёргают несколько клиентов сразу, а /health молчит все ~90с загрузки.

HTTP API

# 1) завести голос
curl -X POST localhost:8020/clone_voice -H 'Content-Type: application/json' -d '{
  "audio": "prompts/зразок.wav", "name": "Богдан",
  "prompt_text": "Це зразок мого голосу для клонування.",
  "language": "Ukrainian", "gender": "male"}'

# 2) озвучити
curl -X POST localhost:8020/tts -H 'Content-Type: application/json' -d '{
  "text": "Сьогодні чудова погода, ходімо гуляти в парк.",
  "voice": "Богдан", "format": "mp3"}' -o out.mp3

# Або one-shot — без реєстрації голосу: передай reference_audio замість voice,
# транскрипт зробить Whisper (перший виклик +~30с, далі кешується)
curl -X POST localhost:8020/tts -H 'Content-Type: application/json' -d '{
  "text": "Сьогодні чудова погода.", "reference_audio": "prompts/зразок.mp3",
  "format": "mp3"}' -o out.mp3

MCP

См. mcp_server/README.md. Кратко:

claude mcp add firered-tts -- /Users/admin/Projects/firered-tts/.venv/bin/python \
  /Users/admin/Projects/firered-tts/mcp_server/server.py

Инструменты: firered_backend_status, list_firered_voices, add_firered_voice, delete_firered_voice, synthesize_firered_speech, design_firered_voice, edit_firered_speech.

Память и скорость

Mac mini M4, 16 ГБ. На диске base (7.9) + redae (3.5) = 11.4 ГБ, но в память идёт ~7.7 ГБ: LLM-бекбон грузится в fp16 (4.2 вместо 8.4 — см. оптимизацию 2 ниже), остальное остаётся fp32.

Веса — не вся картина. Измерено на живом процессе после синтеза:

phys_footprint:      13 ГБ
phys_footprint_peak: 14 ГБ

Разница между 7.7 и 13 — кеш MPS-аллокатора, KV-кеш и активации генерации. На 16 ГБ это впритык даже одним процессом, и ps/RSS тут врёт (показывает десятые гигабайта: MPS-буферы в unified memory в RSS не попадают). Меряй footprint, не ps.

Последствия, заложенные в код:

• в памяти живёт ровно одна модель — base или instruct; переключение = полная перезагрузка (минуты, громко логируется);

• синтез сериализован глобальным локом — два параллельных запроса на 16 ГБ дают OOM, а не ускорение;

• run.sh берёт лок на порт — иначе несколько клиентов, делающих autostart одновременно, поднимают по копии бекенда каждый (реальный случай: семь процессов на 16 ГБ);

• автоостановка по простою 1800с — дольше, чем у соседей, намеренно: рестарт стоит ~40с компиляции шейдеров, так что держать процесс живым выгоднее;

• Whisper для автотранскрипта — int8 на CPU, выгружается сразу после распознавания.

Скорость и четыре оптимизации

Наивный запуск апстрима на M4 давал ×189 реального времени — 3 секунды украинского считались 9.5 минуты. Три исправления дали ×4.0, то есть в 48 раз быстрее; четвёртое довело до ×2.7. Что именно было не так (замерено tools/profile_steps.py и инструментацией):

1. Autocast на шаге AR-цикла — главная беда. Апстрим вешает @torch.autocast декоратором на _backbone_one_step, то есть регион autocast открывается и закрывается на КАЖДОМ шаге авторегрессии. Кеш перекастов весов в torch живёт ровно внутри региона, так что 1.7B параметров fp32 перегонялись в half на каждом шагу. Шаг бекбона: 19000 мс → 2710 мс. Теперь autocast выключен по умолчанию, а каст делается явно на границе бекбона.

2. Бекбон в fp32. Веса сохранены в float32 (3.0B параметров = 11.4 ГБ), что на 16 ГБ означает своп. Переводим в half лишь LLM-бекбон (4.2 ГБ вместо 8.4), а redae и flow-декодер оставляем fp32 — апстрим там намеренно работает в полной точности, и half ломает MPS-matmul. Шаг: 2710 → 1387 мс.

3. Компиляция Metal-шейдеров. Самая большая часть «медленности» оказалась разовой: Metal компилирует ядра при первом выполнении. Поштучные замеры шага бекбона: 9873, 2104, 120, 93, 96, 97… мс. Поэтому сервис делает прогрев на старте (FIRERED_WARMUP=1) и имеет долгий таймаут простоя — рестарт стоит ~40 секунд компиляции.

4. Кеш кодирования референса. generate() вызывается на КАЖДОЕ предложение, и каждый вызов заново прогонял redae-энкодер по референсной записи — 5.58с каждый раз, независимо от длины текста. Ключ кеша — содержимое аудио, а не id тензора, так что подменить голос кеш не может. На прогоне 6.6 мин аудио (14 чанков): 30 попаданий против 2 промахов ≈ 150с, то есть ~11% времени.

Минута аудио считается ~2.7 минуты (Mac mini M4 / 16 ГБ, прогретая модель, тёплый кеш референса; лучший из 5 чередующихся раундов на 3.0с украинского, медиана даёт ×2.9). Real-time нет, но это уже рабочий инструмент, а не «запусти на ночь».

Профиль прогретой генерации: flow-декодер 57%, бекбон 18%, redae 11%.

n_timesteps — шаги ODE в flow-декодере, самой дорогой части. Параметр доступен в /tts, MCP и FIRERED_N_TIMESTEPS, но дефолт 10, как в апстриме: апстрим его не документирует и нигде не предлагает крутить, а ниже 4 качество заметно грубеет. По тому же замеру: 10 → ×2.7, 6 → ×1.9, 4 → ×1.3, 2 → ×1.0. Снижай только под конкретную задачу и со сверкой на слух.

Text normalization

Встроенный TN (wetext) знает лишь китайский и английский, так что для украинского он бесполезен, и мы его не ставим. 19:30, 250 грн, 2026 р. модель озвучит как получится.

Два выхода:

1. писать текст сразу словами;

2. включить LLM-TN — FIRERED_TN_API_URL / _API_KEY / _MODEL в .env. Подойдёт любой OpenAI-совместимый эндпоинт, включая локальный (llama.cpp / vLLM / Ollama) — тогда всё остаётся офлайн.

Лицензия

Код и веса — Apache 2.0. В README апстрима отдельно написано, что zero-shot клонирование «solely for academic research purposes» — это противоречит Apache 2.0, и на коммерческое использование клонированных голосов смотри осторожно. Для домашнего использования вопрос не стоит.