Как мы сделали наш API для синтеза речи бесплатным: Инженерные решения по инференсу S2.1 Pro

TL;DR

• Fish Audio S2.1 Pro теперь доступен как бесплатный API для синтеза речи: 83 языка, отсутствие жестких лимитов на использование, идентификатор модели s2.1-pro-free. Бесплатный доступ предоставляется на начальный период; о любых изменениях мы сообщим заранее. Подробности можно найти здесь.
• Сквозная оптимизация инференса позволила в 4 раза снизить нагрузку на GPU: тот же объем работы, для которого раньше требовалось четыре H200, теперь выполняется на одном.
• Ключевые факторы: кастомные CUDA-ядра (ускорение в 2.1–4.3 раза по сравнению с cuBLAS при декодировании), непрерывный батчинг (масштабирование пропускной способности в 52 раза при c=1→64), повышение утилизации GPU с ~50% до ~90%+.
• Тот же стек используется в нашем API для клонирования голоса — те же веса модели, та же инфраструктура, включен бесплатный уровень. S2.1 Pro базируется на Fish Speech, нашей базовой модели с открытыми весами.
• Основная библиотека ядер fish-scales-ops доступна в open source.

Узнайте, почему разработчики переходят с других платформ → Начните разработку бесплатно

Июль 2026 | Fish Audio перестроила стек инференса и сделала S2.1 Pro бесплатным для всех разработчиков

Настоящая причина, почему голосовой ИИ стоит дорого

Инференс голосового ИИ имеет структурную проблему, которую не объясняют на страницах с ценами: авторегрессионное декодирование по умолчанию враждебно к утилизации GPU.

Каждый вызов API TTS запускает цикл декодирования, который генерирует аудио-токены шаг за шагом. Каждый шаг — это небольшое перемножение матриц (на практике M ≤ 128), за которым следует чтение из памяти KV-кеша для этой последовательности. CUDA-ядра большую часть времени простаивают, пока подсистема памяти догоняет их. Используя H200 стоимостью 30 000 долларов, вы платите за вычисления, которые сгорают в ожидании данных из памяти.

При низкой конкурентности ситуация ухудшается. Цикл декодирования одного запроса занимает GPU всплесками по 10–20 мкс, разделенными накладными расходами на планирование. Утилизация GPU на синтезе речи при c=1 может быть ниже 10%. Оборудование есть, но работы недостаточно, чтобы его загрузить.

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

Вот что для этого потребовалось.

Сквозная оптимизация: полный стек

Ни одно отдельное изменение не дает 4-кратного улучшения эффективности. Успех пришел от одновременной оптимизации каждого слоя:

• Кастомные CUDA-ядра — устранение потерь вычислительных ресурсов на каждом токене.
• FP8-квантование — снижение нагрузки на пропускную способность памяти вдвое.
• Непрерывный батчинг (Continuous batching) — заполнение GPU за счет параллельных запросов.
• Планирование GPU — устранение неиспользуемых мощностей между задачами.
• Собственная сеть и хранилище — исключение наценок облачной инфраструктуры.

Каждый слой описан ниже. Итоговые показатели пропускной способности и стоимости — это результат их совместной работы.

Кастомные CUDA-ядра: fish-scales-ops

Почему cuBLAS было недостаточно

Формы (shapes) декодирования при обслуживании TTS (M ≤ 128) — это не те формы, под которые оптимизированы cuBLAS, GEMM-ядра PyTorch или даже torch.compile. Эти библиотеки ориентированы на обучение и предзаполнение большими батчами (prefill), где M исчисляется тысячами. При малых M они не используют всю пропускную способность памяти и упускают возможности слияния (fusion), которые существуют только при батчах декодирования.

Конкретный пример: для прямого прохода SwiGLU MLP при M=1 (декодирование одного запроса) cuBLAS scaled_mm выполняет три отдельных запуска ядра — активация, умножение затвора (gate multiply), обратная проекция. Промежуточные результаты записываются в HBM и считываются обратно между каждым шагом. При M=1 именно эта пересылка данных становится узким местом, а не сами вычисления.

Мы создали fish-scales-ops, чтобы закрыть этот пробел: это библиотека FP8 GEMM и FlashAttention промышленного уровня, ориентированная на архитектуры NVIDIA Hopper (H200, sm_90a) и Blackwell (sm_120a), с открытым исходным кодом.

Стратегия FP8-квантования

Мы реализовали две схемы квантования для разных поколений оборудования:

bsgemm (блочно-масштабируемый FP8 128×128) для H200/Hopper. Блочное масштабирование с детализацией 128×128 обеспечивает хорошую числовую стабильность без риска потери точности, характерного для квантования по целым тензорам.

mxfp8 (1×32, формат OCP UE8M0) для Blackwell (RTX 5090, RTX 6000 PRO). Микромасштабирование с общими экспонентами для 32 элементов — стандарт OCP MX — обеспечивает более тонкую числовую точность на масштабах, критичных для генерации аудио-токенов.

Один неочевидный баг в пути mxfp8 потребовал серьезной отладки: quantize_blockscale.py создавал тензоры weight_scale с использованием .contiguous() для совместимости с safetensors, но linear_mxfp8_raw считывает масштабы с шагом (stride) K-major (1, N). Загрузка row-major тензора [N, K/128] приводила к тому, что каждый GEMM выдавал некорректные логиты на полной скорости ядра — итоговое сэмплирование схлопывалось в один повторяющийся семантический токен. Это выглядело как проблема качества модели, но на деле было багом разметки памяти. Исправлением стало изменение шага (re-striding) в MXFP8LinearMethod.process_weights_after_loading. После исправления жадное декодирование по первым пяти аудио-кадрам попиксельно совпадает с bf16.

Результаты тестирования ядер

На формах декодирования (M ≤ 128), согласно внутренним тестам на идентичном оборудовании (полная методология в репозитории fish-scales-ops):

• Путь MXFP8 превосходит torch.nn.functional.scaled_mm на 8 из 10 квадратных форм от 1024³ до 16384³, до +21%.
• Прямой проход Qwen3-4B SwiGLU MLP: в 1.7–6.2 раза быстрее обычного cuBLAS scaled_mm на всех значениях M от 1 до 4096.
• В сравнении с cuBLAS через torch.compile: в 2.1–4.3 раза быстрее.
• MXFP8 FlashAttention на sm_120a: в 7–19 раз быстрее PyTorch SDPA decode, в 1.2–2.7 раза быстрее FlashInfer BF16.

Два комбинированных ядра обеспечивают основную часть прироста: одно объединяет квантование активации и упаковку масштабов UE8M0 в один запуск; другое встраивает пролог SwiGLU непосредственно в квантование активации для down-GEMM, устраняя промежуточную запись и чтение в формате BF16.

Архитектура пакетного инференса: баланс задержки и пропускной способности

Непрерывный батчинг для авторегрессионного TTS

Эффективность ядер снижает стоимость одного токена. Батчинг же превращает эту эффективность в утилизацию GPU при потоке запросов.

Статический батчинг (дополнение всех последовательностей до одной длины) тратит ресурсы на пустые вычисления и блокирует новые запросы до завершения самой длинной последовательности. Для TTS с переменной длиной вывода это критично сказывается на задержке.

Мы используем непрерывный батчинг (continuous batching), адаптированный из sglang: новые запросы добавляются в активный батч декодирования по мере освобождения слотов, не дожидаясь границ батча. Цикл декодирования GPU никогда не простаивает из-за одного длинного запроса.

DualAR: специфические ограничения батчинга для S2

Архитектура DualAR в S2.1 Pro генерирует аудио-токены в два этапа — грубые кодовые книги, затем тонкие — со скользящим окном previous_tokens. Это создает ограничение корректности, которого нет у обычных LLM: ядро prev_tokens_shift_inplace требует строгого соответствия типов и форм (prev int32 [bs, W, cw], next_tokens int32 [bs, cw]). Любые манипуляции с формами на уровне вызывающей стороны — .unsqueeze(), неявное приведение типов — портят окно и приводят к деградации аудио, которую трудно отличить от регрессии качества модели.

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

Результаты пропускной способности

H200, bsgemm FP8, тест конкурентности:

Пропускная способность масштабируется ~52 раза при переходе от c=1 к c=64, в то время как время до первого байта (TTFB) увеличивается всего на 36.6 мс — с 73 до 110 мс. GPU выполняет в 52 раза больше работы при задержке, которая практически незаметна в большинстве реальных задач.

При c=64 одна H200 выдает 8,006 ток/с. Это число и есть прямой механизм, позволяющий сделать API бесплатным: больше пропускной способности на один GPU означает меньшую стоимость каждого запроса.

Эти показатели стоят за каждым бесплатным вызовом API. Начать разработку →

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

Для голосовых агентов и интерактивных приложений мы предоставляем отдельную конечную точку реального времени, оптимизированную под «время до первого аудио», а не под общую пропускную способность.

Ключевое архитектурное решение: prefill (предзаполнение) происходит в момент открытия соединения, полностью вне критического пути задержки. Отсчет времени стриминга начинается с момента отправки первого фрагмента аудио, а не с момента установления соединения. Это значит, что стоимость prefill, которая растет вместе с длиной промпта, вообще не влияет на показатель TTFA (Time to First Audio).

На уровне планировщика используется дизайн «пинг-понг»: декодирование и предзаполнение запускаются в разных потоках без барьера синхронизации хоста на каждом цикле. Устранение этого барьера — основное улучшение TTFA при c≥4: в наивной реализации синхронизация хоста после каждого шага декодирования выстраивает в очередь то, что должно выполняться параллельно. Конвейерный цикл декодирования и закрепленная (pinned) H2D память решают проблемы TTFB и джиттера при высокой конкурентности.

Полное описание дизайна и анализ задержек приведены в arXiv:2603.08823.

Проверка качества: как мы убедились, что оптимизация не испортила звук

Квантование и батчинг могут вызывать регрессии качества, которые трудно заметить только по тестам пропускной способности — GPU может работать на полной скорости, выдавая неверный результат.

Мы столкнулись с этим при разработке mxfp8: баг с разметкой весов давал относительную ошибку логитов ~53%, при этом задержка ядра была в норме. Регрессия проявилась только при анализе выходных токенов.

Наш пайплайн проверки имеет два этапа:

Контроль корректности: Жадное декодирование после квантования должно попиксельно совпадать с токенами bf16 на первых пяти аудио-кадрах для фиксированного эталонного входа. Это позволяет выявить системное повреждение логитов — если квантованная модель выдает другие распределения вероятностей, она немедленно отклонится от bf16 на детерминированных входных данных.

Контроль производительности: Показатель decode_tps для каждого запроса должен оставаться в пределах 5% от базовых значений на всех точках конкурентности (c=1, c=16, c=64). Любое изменение, снижающее пропускную способность более чем на 5%, требует обоснования. Это защищает от «исправлений» корректности, которые скрыто добавляют синхронизацию в цикл декодирования.

Обе проверки запускаются при каждом изменении стека инференса. В итоге: веса модели S2.1 Pro Free идентичны весам платной версии, а путь квантованного обслуживания проверяется на соответствие неквантованному эталону при каждом развертывании.

Клонирование голоса в масштабе: почему эффективность инференса имеет значение

Клонирование голоса в Fish Audio всегда было бесплатным — и оно остается, по нашей оценке и отзывам разработчиков, лучшим в своем классе. Стабильность голоса на 83 языках, естественная просодия и стабильная работа с акцентами — это не функции платного тарифа. Это стандарт. S2.1 Pro построен на базе Fish Speech S2 Pro, нашей модели с открытыми весами, выпущенной ранее в этом году.

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

Три типа оптимизации особенно важны для клонирования голоса:

FP8 сохраняет кондиционирование спикера. Проверка корректности на уровне токенов подтверждает, что квантование не ослабляет сигнал эмбеддинга спикера. Консистентность голоса в клонированном выводе соответствует уровню bf16.

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

52-кратное масштабирование делает массовую генерацию доступной. При 8,006 ток/с на одной H200 создание огромных библиотек клонированных голосов — аудиокниг, диалогов для игр, локализованного контента — становится экономически оправданным в рамках бесплатного тарифа.

Бесплатный уровень включает клонирование голоса не потому, что мы просто решили на нем сэкономить. Мы включили его, потому что это всегда было частью продукта, а описанные здесь инженерные решения позволяют нам выполнять это обещание по мере роста нагрузки. О том, как интегрировать клонирование голоса в рабочие процессы агентов, читайте в нашей статье о поддержке MCP и навыков агентов.

Клонируйте голос менее чем за 60 секунд → Попробовать бесплатно

Инфраструктура GPU: владение всем стеком

Оборудование и закупки

Наш кластер GPU насчитывает около 500 карт в нескольких дата-центрах. Топология с несколькими ДЦ была решением по закупкам еще до того, как стала решением по надежности: доступность и цены на GPU волатильны, а зависимость от одного вендора означает прямое принятие этой волатильности. Закупка у разных поставщиков и в разных ДЦ хеджирует ценовые риски и дефицит поставок ценой операционной сложности.

Для инференса мы используем смешанный парк. H200 SXM5 обрабатывает высококонкурентные задачи, где доминирует общая пропускная способность bsgemm FP8. RTX 5090 и RTX 6000 PRO (sm_120a) обслуживают периферийные узлы — при c=64 модель 5090 с mxfp8 достигает 5,869 ток/с, что составляет примерно 71% от пропускной способности H200 bsgemm при существенно меньшей стоимости оборудования.

Для развертывания на sm_120a потребовалось одно неочевидное исправление: изначальное ограничение cuda_graph_max_bs = 24 для GPU с 32 ГБ памяти вызывало резкое падение пропускной способности при высокой конкурентности — на c=32 она падала до ~31 ток/с на запрос, на c=64 до ~35 ток/с. Увеличение лимита до min(max_running_requests, 64) восстановило график пропускной способности. Причина: захват CUDA-графа при bs=24 оставлял GPU недогруженным на размерах батча, которые реально возникают при c=32+.

Планирование GPU: устранение простоев

Базовая утилизация GPU в кластере, предназначенном только для инференса, составляет около 50%. Трафик инференса по своей природе скачкообразен: GPU простаивает в непиковые часы, между запусками обучения и во время загрузки датасетов.

Мы используем две параллельные системы планирования — Kubernetes для инференса и Slurm для обучения — с общим принципом: задачи по очистке и предобработке данных запускаются как эластичные фоновые работы с самым низким приоритетом в обоих кластерах. Эти задачи занимают свободные мощности GPU, когда инференс или обучение их не используют. Они поддерживают контрольные точки и мгновенно прерываются, поэтому исчезают без потерь, как только появляется реальная нагрузка.

Порядок приоритетов: инференс > очистка в K8s-кластере; обучение > очистка в Slurm. Автоскейлер на стороне инференса использует сигналы реального трафика, а не временные эвристики, поэтому фоновые задачи вытесняются мгновенно при росте нагрузки.

Результат: повышение утилизации GPU с ~50% до ~90%+. В масштабах кластера эта разница почти вдвое снижает эффективную стоимость каждого запроса инференса — бюджет на оборудование фиксирован, но на нем обслуживается в два раза больше запросов.

Сетевая инфраструктура

Мы управляем собственной сетью: прямая закупка полосы у провайдеров, собственная ASN, каналы 300 Гбит/с и пиринг с Cloudflare. Для TTS это дает два важных преимущества.

Исходящий трафик (egress) в масштабах TTS — весомая статья расходов. Цены на трафик у облачных провайдеров структурно завышены; владение сетевым уровнем полностью убирает эту наценку.

Вторая причина — задержка. Каждая миллисекунда сетевого пути отражается на пользовательском TTFB. Пиринг с Cloudflare приближает узлы Fish Audio к пользователям, чей трафик идет через сеть Cloudflare (а это огромная часть глобального API-трафика). Развертывание в нескольких ДЦ означает, что большинство запросов достигает ближайшего узла инференса, не проходя через весь интернет.

Хранилище: многоуровневая архитектура

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

• Hot (NVMe flash): активные данные для обучения, веса моделей для обслуживания.
• Warm (смесь flash/HDD): недавние чекпоинты, предобработанные датасеты.
• Cold (собственный HDD-кластер Ceph): исторические данные, долгосрочное хранение.

Холодный уровень заменил сторонние объектные хранилища для больших объемов данных. Локальный слой кеширования перед холодным хранилищем означает, что повторные чтения (частые при обучении) обслуживаются с NVMe, а не с медленных HDD.

Результат: что дает этот стек

На всех уровнях:

• Кастомные FP8-ядра: в 2.1–4.3 раза быстрее стандартного cuBLAS на формах декодирования.
• Непрерывный батчинг: масштабирование пропускной способности в 52 раза при переходе от c=1 к c=64 при росте задержки всего на 37 мс.
• Планирование GPU: утилизация ~50% → ~90%+, что почти вдвое снижает стоимость запроса.
• Собственная инфраструктура: устранена облачная наценка на вычисления, сеть и хранение.

В совокупности тот объем запросов, который раньше требовал четырех H200, теперь выполняется на одном. 4-кратное повышение эффективности — вот что делает бесплатный тариф экономически оправданным. Это не субсидия, а структурное снижение затрат. Период бесплатного доступа подтверждает работоспособность этой юнит-экономики; актуальную информацию о доступности см. в разделе Цены.

Как стек инференса Fish Audio соотносится с другими

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

Тенденция очевидна: Fish Audio — единственный крупный поставщик TTS, который публично задокументировал архитектуру инференса, открыл библиотеку ядер и опубликовал конкретные цифры производительности. «Не раскрывается» — это не критика, а констатация того, что невозможно проверить. Для независимой оценки качества голоса ознакомьтесь с нашим слепым сравнением TTS-провайдеров.

Что доступно в Open Source

Библиотека fish-scales-ops доступна уже сейчас: FP8 GEMM и FlashAttention для Hopper и Blackwell, готовые к продакшену и безопасные для захвата CUDA-графов.

Если вы строите инфраструктуру инференса для авторегрессионных моделей на H200 или RTX 5090/6000 PRO, разрыв в производительности со стандартными библиотеками на малых батчах реален, и эти ядра помогут его закрыть.

Что внутри библиотеки:

• FP8 GEMM: bsgemm (1×128 act × 128×128 wgt) для Hopper; MXFP8 1×32 (OCP UE8M0) для Blackwell.
• MXFP8 FlashAttention для sm_120a: непрерывное предзаполнение, послойное предзаполнение (extend), послойное декодирование с нативной поддержкой GQA через stride-0 K/V трансляцию.
• Полная совместимость с CUDA Graph.

Что дальше

Поддержка B300 уже в планах. Нативные тензорные ядра FP8 и пропускная способность NVLink 5 в архитектуре Blackwell позволят еще сильнее поднять планку пропускной способности.

Оптимизация инференса продолжается. Текущие показатели тестов для нас — это лишь уровень, который нельзя снижать, а не предел мечтаний. Каждая точка на графике — это вызов.

Больше компонентов стека обслуживания станут кандидатами для open source по мере стабилизации — модификации sglang_lite, логика батчинга для DualAR, обработка CUDA-графов для sm_120a. Инфраструктура, которая делает бесплатный тариф устойчивым, — это та самая база, на которой мы хотим видеть развитие всего сообщества.

Как начать работу с бесплатным API TTS

Идентификатор модели: s2.1-pro-free. Всего одно изменение в заголовке любого существующего вызова API Fish Audio.

python

import httpx

body = {
    "text": "Привет, мир!",
    "reference_id": "your_model_id",
    "format": "mp3",
}

with httpx.Client() as client:
    res = client.post(
        "https://api.fish.audio/v1/tts",
        headers={
            "Authorization": "Bearer <YOUR_API_KEY>",
            "Content-Type": "application/json",
            "model": "s2.1-pro-free",
        },
        json=body,
    )

res.raise_for_status()

with open("output.mp3", "wb") as f:
    f.write(res.content)

JavaScript

import { writeFile } from "fs/promises";

const body = {
  text: "Привет, мир!",
  reference_id: "your_model_id",
  format: "mp3",
};

const res = await fetch("https://api.fish.audio/v1/tts", {
  method: "POST",
  headers: {
    Authorization: "Bearer <YOUR_API_KEY>",
    "Content-Type": "application/json",
    model: "s2.1-pro-free",
  },
  body: JSON.stringify(body),
});

if (!res.ok) {
  throw new Error(`TTS request failed: ${res.status} ${await res.text()}`);
}

const buffer = Buffer.from(await res.arrayBuffer());
await writeFile("output.mp3", buffer);

83 языка. Без жестких лимитов. Без привязки карты. Клонирование голоса включено.

Все остальные современные TTS API берут плату с самого первого токена. S2.1 Pro — нет.

Клонируйте голос менее чем за 60 секунд →

Полная документация API →