Como Tornamos Nossa API de Text-to-Speech Gratuita: A Engenharia de Inferência por Trás do S2.1 Pro

TL;DR

• O Fish Audio S2.1 Pro agora está disponível como uma API de text-to-speech gratuita: 83 idiomas, sem limite rígido de uso, string do modelo s2.1-pro-free. O acesso gratuito está disponível por um período inicial; comunicaremos quaisquer mudanças com aviso prévio. Para mais informações, veja aqui.
• A otimização de inferência de ponta a ponta reduziu a capacidade de solicitação por GPU em 4×: a mesma carga de trabalho que antes exigia quatro H200s agora roda em uma.
• Alavancas principais: kernels CUDA personalizados (2,1–4,3× sobre cuBLAS em formatos de decodificação), loteamento contínuo (escalonamento de throughput de 52× c=1→64), utilização de GPU elevada de ~50% para ~90%+.
• O mesmo stack alimenta nossa API de clonagem de voz — mesmos pesos de modelo, mesma infraestrutura, nível gratuito incluído. O S2.1 Pro baseia-se no Fish Speech, nosso modelo fundamental de pesos abertos.
• A biblioteca de kernels principais fish-scales-ops é de código aberto.

Veja por que os desenvolvedores estão mudando de outras plataformas → Comece a construir gratuitamente

Julho de 2026 | Fish Audio reconstruiu o stack de inferência e tornou o S2.1 Pro gratuito para todos os desenvolvedores

A Real Razão Pela Qual a IA de Voz Custa Dinheiro

A inferência de IA de voz tem um problema estrutural que as páginas de preços não explicam: a decodificação autorregressiva é hostil à utilização de GPU por padrão.

Cada chamada de API de TTS aciona um loop de decodificação que gera tokens de áudio um passo de cada vez. Cada passo é uma pequena multiplicação de matriz — M ≤ 128 na prática — seguida por uma leitura de memória do cache KV para aquela sequência. Os núcleos CUDA ficam majoritariamente ociosos enquanto o subsistema de memória tenta acompanhar. Em uma H200 de US$ 30.000, você está pagando por computação e desperdiçando-a em gargalos de memória.

Em baixa concorrência, isso piora. Um loop de decodificação de solicitação única ocupa a GPU em rajadas de 10–20μs separadas por sobrecarga de agendamento. A utilização da GPU em um endpoint de TTS servido de forma ingênua em c=1 pode ficar abaixo de 10%. O hardware está presente; o trabalho não o está preenchendo.

A resposta da indústria tem sido repassar o custo aos desenvolvedores por meio de preços por caractere. Nossa resposta foi corrigir o problema de utilização na camada de infraestrutura. Quando uma única GPU pode fazer o trabalho que antes exigia quatro, a economia de um nível gratuito torna-se viável.

Eis o que isso exigiu.

Otimização de Ponta a Ponta: O Full Stack

Nenhuma mudança isolada proporciona uma melhoria de eficiência de 4×. Os ganhos vieram da otimização de todas as camadas simultaneamente e permitindo que elas se potencializassem:

• Kernels CUDA personalizados — eliminando o desperdício de computação por token
• Quantização FP8 — reduzindo a pressão da largura de banda de memória pela metade
• Loteamento contínuo — preenchendo a GPU em solicitações concorrentes
• Agendamento de GPU — eliminando a capacidade ociosa entre cargas de trabalho
• Rede e armazenamento próprios — removendo a margem de lucro da infraestrutura em nuvem

Cada camada é descrita abaixo. Os números de throughput e custo ao final são o produto de todas elas juntas.

Kernels CUDA Personalizados: fish-scales-ops

Por Que o cuBLAS Não Foi Suficiente

Os formatos de decodificação no serviço de TTS (M ≤ 128) não são os formatos para os quais o cuBLAS, os kernels GEMM do PyTorch ou até mesmo o torch.compile são otimizados. Essas bibliotecas visam o treinamento e o pré-preenchimento (prefill) de grandes lotes — M na casa dos milhares. Com M pequeno, elas subutilizam a largura de banda de memória e perdem oportunidades de fusão que só existem em tamanhos de lote de decodificação.

A lacuna específica: para um forward de MLP SwiGLU em M=1 (decodificação de solicitação única), o scaled_mm do cuBLAS emite três lançamentos de kernel separados — ativação, multiplicação de gate, projeção descendente — com resultados intermediários escritos e lidos de volta da HBM entre cada um. Em M=1, esse ciclo de ida e volta é o gargalo, não a computação.

Construímos a fish-scales-ops para fechar essa lacuna: uma biblioteca de GEMM FP8 e FlashAttention de nível de produção visando as arquiteturas NVIDIA Hopper (H200, sm_90a) e Blackwell (sm_120a), de código aberto.

Estratégia de Quantização FP8

Implementamos dois esquemas de quantização para diferentes gerações de hardware:

bsgemm (FP8 com escala de bloco 128×128) para H200/Hopper. A escala de bloco em granularidade de 128×128 oferece boa estabilidade numérica sem o risco de precisão da quantização por tensor.

mxfp8 (1×32, formato OCP UE8M0) para Blackwell (RTX 5090, RTX 6000 PRO). A micro-escala com expoentes compartilhados de 32 elementos — o padrão OCP MX — oferece fidelidade numérica mais granular nas escalas que importam para a geração de tokens de áudio.

Um bug não óbvio no caminho mxfp8 exigiu depuração significativa: o quantize_blockscale.py materializava tensores weight_scale com .contiguous() para compatibilidade com safetensors, mas o linear_mxfp8_raw lê escalas com stride K-major (1, N). Carregar um [N, K/128] contíguo row-major fazia com que cada GEMM produzisse logits incorretos em velocidade total de kernel — o modo de amostragem posterior colapsava para um único token semântico repetido, o que parece um problema de qualidade do modelo, mas é na verdade um bug de layout de memória. A correção foi o re-striding em MXFP8LinearMethod.process_weights_after_loading. Após a correção, a decodificação gananciosa coincide exatamente com os tokens bf16 nos primeiros cinco frames de áudio.

Resultados de Benchmark de Kernel

Em formatos de decodificação (M ≤ 128), benchmarks internos em hardware equivalente — metodologia completa no repositório fish-scales-ops:

• O caminho MXFP8 supera o torch.nn.functional.scaled_mm em 8 de 10 formatos quadrados de 1024³ a 16384³, até +21%
• Forward de MLP SwiGLU Qwen3-4B de ponta a ponta: 1,7–6,2× sobre cuBLAS puro scaled_mm em cada M de 1 a 4096
• Contra cuBLAS fundido por torch.compile em formatos de decodificação: 2,1–4,3× mais rápido
• MXFP8 FlashAttention em sm_120a: 7–19× sobre a decodificação SDPA do PyTorch, 1,2–2,7× sobre o FlashInfer BF16

Os dois kernels fundidos que geram a maior parte do ganho: um funde a quantização de ativação + pack de escala UE8M0 em um único lançamento; o outro funde o prólogo SwiGLU diretamente na quantização de ativação do down-GEMM, eliminando uma escrita+leitura intermediária BF16 completa que o PyTorch, de outra forma, materializa entre as duas operações.

Arquitetura de Inferência em Lote: O Equilíbrio entre Latência e Throughput

Loteamento Contínuo para TTS Autorregressivo

A eficiência do kernel melhora o custo por token. O loteamento é o que converte a eficiência por token em utilização de GPU em todo o fluxo de solicitações.

Loteamento estático — preencher todas as sequências para o mesmo comprimento, rodando como um lote fixo — desperdiça computação em preenchimento (padding) e bloqueia novas solicitações até que a sequência mais lenta do lote termine. Para TTS com comprimentos de saída variáveis, a penalidade de latência de cauda é significativa.

Usamos loteamento contínuo (continuous batching) adaptado do sglang: novas solicitações entram no lote de decodificação ativo à medida que as vagas são liberadas, sem esperar por uma fronteira de lote. O loop de decodificação da GPU nunca para por uma solicitação lenta atípica.

DualAR: Restrições de Loteamento Específicas do S2

A arquitetura DualAR do S2.1 Pro gera tokens de áudio em dois estágios — codebooks grosseiros seguidos por codebooks finos — com uma janela deslizante de previous_tokens que condiciona cada passo. Isso cria uma restrição de correção que o loteamento de LLM padrão não possui: o kernel prev_tokens_shift_inplace exige um contrato estrito de formato/tipo (prev int32 [bs, W, cw], next_tokens int32 [bs, cw]). Qualquer ajuste de formato no chamador — .unsqueeze(), promoção implícita de dtype — corrompe a janela e produz áudio degradado que é difícil de distinguir de uma regressão de qualidade do modelo.

Para cargas de trabalho de clonagem de voz, essa restrição é especialmente importante: o condicionamento do falante flui pelo mesmo caminho de decodificação, e a corrupção da janela se manifesta como deriva da identidade do falante em saídas longas, em vez de artefatos de áudio óbvios.

Resultados de Throughput

H200, bsgemm FP8, varredura de concorrência:

O throughput escala ~52× de c=1 para c=64, enquanto o TTFB aumenta em 36,6ms — de 73ms para 110ms. A GPU faz 52 vezes o trabalho por uma penalidade de latência que é imperceptível na maioria das cargas de trabalho de produção.

Em c=64, uma única H200 sustenta 8.006 tok/s. Esse número é o mecanismo direto por trás do nível gratuito: mais throughput por GPU significa menor custo por solicitação.

Estes são os números rodando por trás de cada chamada de API gratuita. Comece a construir →

Modo Real-Time: Abordagem Arquitetural para Cargas de Baixa Latência

Para agentes de voz e aplicações de conversação, expomos um endpoint de tempo real separado, otimizado para o tempo até o primeiro áudio (TTFA), em vez do throughput agregado.

A decisão arquitetural central: o pré-preenchimento ocorre na abertura da conexão, totalmente fora do caminho crítico de latência. O cronômetro para a latência de streaming começa no envio do primeiro fragmento de áudio, não no estabelecimento da conexão. Isso significa que o custo do pré-preenchimento, que escala com o comprimento do prompt, não aparece de forma alguma no número de TTFA.

No nível do agendador, um design ping-pong executa a decodificação e o pré-preenchimento em threads separadas sem barreira de host por ciclo. A remoção da barreira é a principal melhoria de TTFA em c≥4: em uma implementação ingênua, a sincronização do lado do host após cada etapa de decodificação serializa o que deveria ser trabalho concorrente. O loop de decodificação em pipeline e as transferências de memória H2D fixas abordam o TTFB e o jitter em alta concorrência.

O design completo e o detalhamento da latência estão em arXiv:2603.08823.

Validação de Qualidade: Como Verificamos se a Otimização Não Degradou o Áudio

A quantização e o loteamento podem introduzir regressões de qualidade difíceis de detectar apenas com benchmarks de throughput — a GPU roda em velocidade total produzindo resultados incorretos.

Detectamos um caso disso durante o desenvolvimento do mxfp8: o bug de layout de peso descrito acima produziu ~53% de erro relativo de logit enquanto a latência do kernel estava completamente normal. A regressão só apareceu na análise de tokens de saída, não em nenhuma métrica de desempenho.

Nosso pipeline de validação possui dois portões:

Portão de correção: A decodificação gananciosa pós-quantização deve coincidir exatamente com os tokens bf16 nos primeiros cinco frames de áudio para uma entrada de referência fixa. A correspondência exata de tokens nos primeiros frames detecta a corrupção sistemática de logits — se o modelo quantizado produzir distribuições de probabilidade diferentes, ele divergirá do bf16 imediatamente em entradas determinísticas.

Portão de regressão de desempenho: O decode_tps por solicitação deve permanecer dentro de 5% dos números de referência congelados em cada ponto de concorrência. Qualquer alteração que degrade o throughput além de 5% em qualquer concorrência — c=1, c=16, c=64 — requer justificativa explícita antes da fusão (merge). Este portão protege contra correções de erro que silenciosamente adicionam sincronização ao loop de decodificação.

Ambos os portões rodam em cada mudança no stack de inferência. O resultado: os pesos do modelo S2.1 Pro Free são idênticos aos do nível pago, e o caminho de serviço quantizado é validado contra a linha de base não quantizada em cada implantação.

Clonagem de Voz em Escala: Por Que a Eficiência de Inferência Importa

A clonagem de voz do Fish Audio sempre foi gratuita — e continua sendo, em nossa própria avaliação e no feedback dos desenvolvedores, a mais forte em sua categoria. A consistência do falante em 83 idiomas, a prosódia natural e o desempenho estável em sotaques não são recursos que adicionamos a um nível pago. Eles são a base. O S2.1 Pro baseia-se no Fish Speech S2 Pro, nosso modelo fundamental de pesos abertos lançado no início deste ano.

O que a otimização de inferência muda é a economia de manter esse compromisso em escala. As cargas de trabalho de clonagem de voz carregam um custo por solicitação mais alto do que o TTS padrão: cada chamada deve se condicionar a um embedding de falante de referência, manter a identidade do falante em saídas de comprimento variável e fazer ambos consistentemente entre idiomas. Sem os ganhos de eficiência descritos neste post, a clonagem de voz gratuita em escala de produção exigiria subsidiar uma carga de trabalho estruturalmente cara. Com eles, não exige.

Três otimizações importam especificamente para a clonagem de voz:

O FP8 preserva o condicionamento do falante. A validação de correção exata de tokens — que detecta corrupção no nível de logit — valida diretamente que a quantização não degrada o sinal de embedding do falante. A consistência do falante em saídas clonadas corresponde à linha de base bf16.

O loteamento contínuo lida com tipos de solicitação mistos. O tráfego de clonagem de voz em produção mistura solicitações condicionadas por referência e não condicionadas, variando comprimentos de saída e idiomas. O loteamento contínuo preenche o lote de decodificação independentemente do tipo de solicitação — não há penalidade pela heterogeneidade da carga de trabalho.

O escalonamento de throughput de 52× torna viável a geração em massa. Com 8.006 tok/s em uma única H200, gerar grandes bibliotecas de áudio com vozes clonadas — audiolivros, diálogos de jogos, conteúdo localizado em escala — é economicamente viável dentro do nível gratuito.

O nível gratuito inclui clonagem de voz porque otimizamos nosso caminho para poder custeá-la. Nós a incluímos porque esse sempre foi o produto — e o trabalho de engenharia descrito aqui é o que nos permite manter essa promessa à medida que o uso escala. Para integrar a clonagem de voz em fluxos de trabalho de agentes, veja nosso suporte a MCP e habilidades de agente.

Clone uma voz em menos de 60 segundos → Teste grátis

Infraestrutura de GPU: Sendo Dono do Stack

Hardware e Aquisição

Nosso cluster de GPU opera aproximadamente 500 placas em vários data centers. A topologia multi-DC foi uma decisão de aquisição antes de ser uma decisão de confiabilidade: o fornecimento e o preço das GPUs são voláteis, e o bloqueio de um único fornecedor significa absorver essa volatilidade diretamente. O fornecimento multi-fornecedor e multi-DC protege contra riscos de preço e restrições de fornecimento simultaneamente, ao custo da complexidade operacional.

Para inferência, operamos uma frota mista. A H200 SXM5 lida com o serviço de produção de alta concorrência, onde o throughput agregado bsgemm FP8 domina. A RTX 5090 e a RTX 6000 PRO (sm_120a) atendem aos endpoints de borda — em c=64, a 5090 mxfp8 atinge 5.869 tok/s, aproximadamente 71% do throughput da H200 bsgemm a um custo de hardware substancialmente menor por placa.

A implantação sm_120a exigiu uma correção não óbvia: o limite original de cuda_graph_max_bs = 24 para GPUs de 32GB produziu uma queda severa de throughput em alta concorrência — c=32 caiu para ~31 tok/s/req, c=64 para ~35 tok/s/req. Elevar o limite para min(max_running_requests, 64) recuperou a curva total de throughput. O problema subjacente: a captura do gráfico CUDA em bs=24 estava deixando a GPU subutilizada nos tamanhos de lote de decodificação que realmente aparecem em c=32+.

Agendamento de GPU: Eliminando a Capacidade Ociosa

A utilização de GPU de referência em um cluster apenas de inferência é de aproximadamente 50%. O tráfego de inferência é inerentemente instável; a GPU fica ociosa durante as horas de folga, entre as execuções de treinamento e durante as fases de carregamento de conjuntos de dados.

Operamos dois sistemas de agendamento paralelos — Kubernetes para inferência, Slurm para treinamento — com um princípio compartilhado: trabalhos de limpeza e pré-processamento de dados funcionam como trabalho de preenchimento elástico no nível de prioridade mais baixo em ambos os clusters. Os trabalhos de limpeza ocupam a capacidade ociosa da GPU sempre que a inferência ou o treinamento não a estão usando. Eles são passíveis de checkpoint e imediatamente preemptíveis, portanto desaparecem sem custo de correção quando o trabalho real chega.

Ordem de prioridade: inferência > limpeza no cluster K8s; treinamento > limpeza no Slurm. O escalonador automático (autoscaler) no lado da inferência usa sinais de tráfego real — e não heurísticas baseadas em tempo — para que os trabalhos de limpeza sejam despejados assim que a carga aumenta.

Resultado: utilização da GPU de ~50% para ~90%+. Na escala do cluster, esse delta reduz aproximadamente pela metade o custo efetivo por solicitação de inferência — o orçamento de hardware é fixo, mas o dobro de solicitações são atendidas com ele.

Infraestrutura de Rede

Operamos nossa própria rede: aquisição direta de largura de banda de ISP, ASN, conectividade de 300Gbps e peering com a Cloudflare. Duas implicações de custo especificamente para TTS.

O egresso na escala de TTS não é trivial. Os preços de egresso dos provedores de nuvem são estruturalmente de alta margem; possuir a camada de rede remove essa margem inteiramente.

A latência é a segunda razão. Cada milissegundo de ida e volta da rede aparece no TTFB percebido pelo usuário. O peering da Cloudflare coloca os endpoints do Fish Audio próximos aos usuários roteados pela rede da Cloudflare — uma fração substancial do tráfego global de API. A implantação multi-DC significa que a maioria das solicitações atinge um nó de inferência próximo sem atravessar toda a internet pública.

Armazenamento: Arquitetura em Camadas

Dados de treinamento, checkpoints de modelo e cache de inferência possuem diferentes padrões de acesso e requisitos de custo. Usamos uma arquitetura de três camadas:

• Hot (NVMe flash): dados de treinamento ativos, pesos de modelo para serviço
• Warm (misto flash/HDD): checkpoints recentes, conjuntos de dados pré-processados
• Cold (cluster HDD Ceph auto-hospedado): dados de treinamento históricos, armazenamento de longo prazo

A camada fria (cold) substituiu o armazenamento de objetos de terceiros para dados em massa. Uma camada de cache local na frente do armazenamento frio significa que as leituras repetidas — comuns em pipelines de dados de treinamento — são atendidas a partir de NVMe em vez de HDD frio.

O Resultado: O Que o Stack Produz

Em todas as camadas:

• Kernels FP8 personalizados: 2,1–4,3× mais rápidos do que o cuBLAS padrão em formatos de decodificação
• Loteamento contínuo: escalonamento de throughput de 52× de c=1 para c=64, aumento de latência de 37ms
• Agendamento de GPU: utilização de ~50% → ~90%+, reduzindo aproximadamente pela metade o custo por solicitação
• Infraestrutura própria: margem de lucro de nuvem removida da computação, rede e armazenamento

Combinado, o mesmo volume de solicitações que antes exigia quatro H200s agora roda em uma. A melhoria de eficiência de 4× é o que torna o nível gratuito economicamente viável — não um subsídio, mas uma redução estrutural de custos. O período de acesso gratuito reflete que a economia unitária funciona; consulte Preços para disponibilidade atual.

Como o Stack de Inferência do Fish Audio se Compara

Dados de infraestrutura baseados em documentação pública, repositórios do GitHub e blogs de engenharia em junho de 2026.

O padrão é consistente: Fish Audio é o único grande provedor de TTS que documentou publicamente sua arquitetura de inferência, abriu o código de sua biblioteca de kernels e publicou números concretos de throughput. "Não divulgado" não é uma crítica — é uma observação sobre o que é verificável. Para uma avaliação independente da qualidade da voz entre provedores, veja nossa comparação cega de provedores de TTS.

O Que é Código Aberto

A fish-scales-ops está disponível agora: GEMM FP8 e FlashAttention para Hopper e Blackwell, nível de produção, segura para captura de Gráfico CUDA.

Se você está construindo infraestrutura de inferência para modelos autorregressivos em H200 ou RTX 5090/6000 PRO, a lacuna de desempenho no formato de decodificação em relação às bibliotecas padrão é real e os kernels estão lá para fechá-la.

O que há na biblioteca:

• GEMM FP8: bsgemm (1×128 act × 128×128 wgt) para Hopper; MXFP8 1×32 (OCP UE8M0) para Blackwell
• MXFP8 FlashAttention para sm_120a: pré-preenchimento contíguo, pré-preenchimento paginado (extend), decodificação paginada com GQA nativo via transmissão K/V stride-0
• Segura para captura de Gráfico CUDA em tudo

O Que Vem a Seguir

O suporte ao B300 está no roteiro. Os núcleos tensores FP8 nativos e a largura de banda NVLink 5 no Blackwell levarão a curva de throughput ainda mais longe.

A otimização da inferência continua. Os números de benchmark congelados são um portão de regressão, não um alvo. Cada ponto de concorrência é algo a ser superado.

Mais partes do stack de serviço são candidatas a código aberto à medida que se estabilizam — as modificações do sglang_lite, a lógica de loteamento específica do DualAR, o manuseio do gráfico CUDA sm_120a. A infraestrutura que torna o nível gratuito sustentável é a mesma infraestrutura sobre a qual gostaríamos que a comunidade construísse.

Introdução à API de TTS Gratuita

String do modelo: s2.1-pro-free. Uma mudança de cabeçalho em relação a qualquer chamada de API do Fish Audio existente.

python

import httpx

body = {
    "text": "Olá, mundo!",
    "reference_id": "seu_id_de_modelo",
    "format": "mp3",
}

with httpx.Client() as client:
    res = client.post(
        "https://api.fish.audio/v1/tts",
        headers={
            "Authorization": "Bearer <SUA_CHAVE_DE_API>",
            "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: "Olá, mundo!",
  reference_id: "seu_id_de_modelo",
  format: "mp3",
};

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

if (!res.ok) {
  throw new Error(`Solicitação de TTS falhou: ${res.status} ${await res.text()}`);
}

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

83 idiomas. Sem limite rígido de uso. Sem cartão de crédito. Clonagem de voz incluída.

Todas as outras APIs de TTS de última geração cobram desde o primeiro token. O S2.1 Pro não.

Clone uma voz em menos de 60 segundos →

Documentação Completa da API →