Cómo hicimos que nuestra API de texto a voz sea gratuita: la ingeniería de inferencia detrás de S2.1 Pro

Resumen (TL;DR)

• Fish Audio S2.1 Pro ya está disponible como una API de texto a voz gratuita: 83 idiomas, sin límite de uso estricto, cadena de modelo s2.1-pro-free. El acceso gratuito está disponible por un periodo inicial; comunicaremos cualquier cambio con aviso previo. Para más información, consulte aquí.
• La optimización de inferencia de extremo a extremo redujo la capacidad de solicitudes por GPU en 4 veces: la misma carga de trabajo que antes requería cuatro H200 ahora se ejecuta en una sola.
• Palancas clave: kernels de CUDA personalizados (2.1–4.3 veces más rápidos que cuBLAS en formas de decodificación), procesamiento por lotes continuo (escalamiento de rendimiento de 52 veces c=1→64), utilización de la GPU elevada de ~50% a ~90%+.
• El mismo stack impulsa nuestra API de clonación de voz — mismos pesos de modelo, misma infraestructura, nivel gratuito incluido. S2.1 Pro se basa en Fish Speech, nuestro modelo fundacional de pesos abiertos.
• La biblioteca de kernels principal fish-scales-ops es de código abierto.

Vea por qué los desarrolladores están cambiando desde otras plataformas → Comience a construir gratis

Julio 2026 | Fish Audio reconstruyó el stack de inferencia y puso S2.1 Pro a disposición de todos los desarrolladores de forma gratuita.

La verdadera razón por la que la IA de voz cuesta dinero

La inferencia de IA de voz tiene un problema estructural que las páginas de precios no explican: la decodificación autorregresiva es hostil para la utilización de la GPU por defecto.

Cada llamada a la API de TTS impulsa un bucle de decodificación que genera tokens de audio paso a paso. Cada paso es una pequeña multiplicación de matrices — M ≤ 128 en la práctica — seguida de una lectura de memoria de la caché KV para esa secuencia. Los núcleos CUDA permanecen mayormente inactivos mientras el subsistema de memoria se pone al día. En una H200 de $30,000, estás pagando por cómputo y desperdiciándolo en paradas de memoria (stalls).

A baja concurrencia, esto empeora. Un bucle de decodificación de una sola solicitud ocupa la GPU en ráfagas de 10–20μs separadas por la sobrecarga de programación. La utilización de la GPU en un punto final de TTS servido de forma ingenua con c=1 puede estar por debajo del 10%. El hardware está presente; el trabajo no lo está llenando.

La respuesta de la industria ha sido trasladar el costo a los desarrolladores a través de precios por carácter. Nuestra respuesta fue solucionar el problema de utilización en la capa de infraestructura. Cuando una sola GPU puede hacer el trabajo que antes requería cuatro, la economía de un nivel gratuito se vuelve viable.

Esto es lo que eso requirió.

Optimización de extremo a extremo: El stack completo

Ningún cambio individual permite alcanzar una mejora de eficiencia de 4 veces. Las ganancias provinieron de optimizar cada capa simultáneamente y permitir que se potenciaran entre sí:

• Kernels de CUDA personalizados — eliminando el desperdicio de cómputo por token.
• Cuantización FP8 — reduciendo a la mitad la presión del ancho de banda de memoria.
• Procesamiento por lotes continuo — llenando la GPU a través de solicitudes concurrentes.
• Programación de GPU — eliminando la capacidad inactiva entre cargas de trabajo.
• Red y almacenamiento propios — eliminando el margen de beneficio de la infraestructura en la nube.

Cada capa se describe a continuación. Las cifras de rendimiento y costo al final son el producto de todas ellas juntas.

Kernels de CUDA personalizados: fish-scales-ops

Por qué cuBLAS no era suficiente

Las formas de decodificación en el servicio de TTS (M ≤ 128) no son las formas para las que están optimizados cuBLAS, los kernels GEMM de PyTorch o incluso torch.compile. Esas bibliotecas apuntan al entrenamiento y al prellenado (prefill) de lotes grandes (M en los miles). Con una M pequeña, desaprovechan el ancho de banda de memoria y pierden oportunidades de fusión que solo existen en tamaños de lote de decodificación.

La brecha específica: para un paso adelante (forward) de MLP SwiGLU con M=1 (decodificación de una sola solicitud), cuBLAS scaled_mm emite tres lanzamientos de kernel separados — activación, multiplicación de compuerta (gate) y proyección descendente — con resultados intermedios escritos y leídos de nuevo desde la HBM entre cada uno. Con M=1, ese viaje de ida y vuelta es el cuello de botella, no el cómputo.

Construimos fish-scales-ops para cerrar esta brecha: una biblioteca de GEMM FP8 y FlashAttention de grado de producción dirigida a las arquitecturas NVIDIA Hopper (H200, sm_90a) y Blackwell (sm_120a), de código abierto.

Estrategia de cuantización FP8

Implementamos dos esquemas de cuantización para diferentes generaciones de hardware:

bsgemm (FP8 con escala de bloques de 128×128) para H200/Hopper. El escalado por bloques con una granularidad de 128×128 proporciona una buena estabilidad numérica sin el riesgo de precisión de la cuantización por tensor.

mxfp8 (1×32, formato OCP UE8M0) para Blackwell (RTX 5090, RTX 6000 PRO). El microescalado con exponentes compartidos de 32 elementos —el estándar OCP MX— proporciona una fidelidad numérica más detallada en las escalas que importan para la generación de tokens de audio.

Un error no obvio en la ruta mxfp8 requirió una depuración significativa: quantize_blockscale.py materializaba tensores weight_scale con .contiguous() para la compatibilidad con safetensors, pero linear_mxfp8_raw lee escalas con zancada (stride) K-mayor (1, N). Cargar un [N, K/128] contiguo de fila mayor hacía que cada GEMM produjera logits incorrectos a toda la velocidad del kernel; el modo de muestreo descendente colapsaba a un único token semántico repetitivo, lo que parece un problema de calidad del modelo pero es en realidad un error de diseño de memoria. La solución fue reajustar las zancadas en MXFP8LinearMethod.process_weights_after_loading. Tras la corrección, la decodificación codiciosa (greedy decode) coincide exactamente con los tokens de bf16 en los primeros cinco fotogramas de audio.

Resultados de benchmark del kernel

En formas de decodificación (M ≤ 128), los benchmarks internos en hardware equivalente — metodología completa en el repositorio fish-scales-ops:

• La ruta MXFP8 supera a torch.nn.functional.scaled_mm en 8 de 10 formas cuadradas desde 1024³ hasta 16384³, hasta un +21%.
• Forward de MLP SwiGLU Qwen3-4B de extremo a extremo: 1.7–6.2 veces sobre cuBLAS scaled_mm puro en cada M de 1 a 4096.
• Contra cuBLAS fusionado con torch.compile en formas de decodificación: 2.1–4.3 veces más rápido.
• MXFP8 FlashAttention en sm_120a: 7–19 veces sobre la decodificación SDPA de PyTorch, 1.2–2.7 veces sobre FlashInfer BF16.

Los dos kernels fusionados que impulsan la mayor parte de la ganancia: uno fusiona la cuantización de activación + el empaquetado de escala UE8M0 en un solo lanzamiento; el otro fusiona el prólogo de SwiGLU directamente en la cuantización de activación de la GEMM descendente, eliminando una escritura y lectura intermedia BF16 completa que de otro modo PyTorch materializaría entre las dos operaciones.

Arquitectura de inferencia por lotes: El compromiso entre latencia y rendimiento

Procesamiento por lotes continuo para TTS autorregresivo

La eficiencia del kernel mejora el costo por token. El procesamiento por lotes es lo que convierte la eficiencia por token en utilización de la GPU a través del flujo de solicitudes.

El procesamiento por lotes estático —rellenar todas las secuencias a la misma longitud, ejecutar como un lote fijo— desperdicia cómputo en el relleno (padding) y bloquea nuevas solicitudes hasta que la secuencia más lenta del lote termina. Para TTS con longitudes de salida variables, la penalización de la latencia de cola es significativa.

Utilizamos procesamiento por lotes continuo (continuous batching) adaptado de sglang: las nuevas solicitudes se unen al lote de decodificación activo a medida que se liberan ranuras, sin esperar a un límite de lote. El bucle de decodificación de la GPU nunca se detiene por una solicitud atípica lenta.

DualAR: Restricciones de procesamiento por lotes específicas de S2

La arquitectura DualAR de S2.1 Pro genera tokens de audio en dos etapas —libros de códigos (codebooks) gruesos seguidos de libros de códigos finos— con una ventana deslizante de previous_tokens que condiciona cada paso. Esto crea una restricción de corrección que el procesamiento por lotes estándar de LLM no tiene: el kernel prev_tokens_shift_inplace requiere un contrato estricto de forma/tipo de datos (prev int32 [bs, W, cw], next_tokens int32 [bs, cw]). Cualquier manipulación de la forma en el llamador —.unsqueeze(), promoción implícita de tipo de datos— corrompe la ventana y produce audio degradado que es difícil de distinguir de una regresión en la calidad del modelo.

Para las cargas de trabajo de clonación de voz, esta restricción es especialmente importante: el acondicionamiento del locutor fluye a través de la misma ruta de decodificación, y la corrupción de la ventana se manifiesta como una deriva de la identidad del locutor en salidas largas en lugar de artefactos de audio obvios.

Resultados de rendimiento (throughput)

H200, bsgemm FP8, barrido de concurrencia:

El rendimiento escala ~52 veces de c=1 a c=64, mientras que el TTFB aumenta en 36.6ms —de 73ms a 110ms. La GPU realiza 52 veces más trabajo por una penalización de latencia que es imperceptible en la mayoría de las cargas de trabajo de producción.

A c=64, una sola H200 mantiene 8,006 tok/s. Esa cifra es el mecanismo directo detrás del nivel gratuito: más rendimiento por GPU significa menor costo por solicitud.

Estas son las cifras que se ejecutan detrás de cada llamada a la API gratuita. Comience a construir →

Modo de tiempo real: Enfoque arquitectónico para cargas de trabajo de baja latencia

Para agentes de voz y aplicaciones de toma de turnos, exponemos un punto final de tiempo real separado optimizado para el tiempo hasta el primer audio (TTFA) en lugar del rendimiento agregado.

La decisión arquitectónica principal: el prellenado (prefill) ocurre al abrir la conexión, fuera de la ruta crítica de latencia. El reloj para la latencia de transmisión comienza al enviar el primer fragmento de audio, no al establecer la conexión. Esto significa que el costo de prefill, que escala con la longitud del prompt, no aparece en absoluto en la cifra de TTFA.

A nivel del programador, un diseño de ping-pong ejecuta la decodificación y el prefill en hilos separados sin barrera de host por ciclo. La eliminación de la barrera es la principal mejora del TTFA a c≥4: en una implementación ingenua, la sincronización del lado del host después de cada paso de decodificación serializa lo que debería ser trabajo concurrente. El bucle de decodificación segmentado (pipelined) y las transferencias de memoria H2D ancladas (pinned) abordan el TTFB y el jitter en alta concurrencia.

El diseño completo y el desglose de la latencia están en arXiv:2603.08823.

Validación de calidad: Cómo verificamos que la optimización no degradó el audio

La cuantización y el procesamiento por lotes pueden introducir regresiones de calidad que son difíciles de detectar solo con benchmarks de rendimiento: la GPU se ejecuta a toda velocidad produciendo resultados incorrectos.

Detectamos un caso de esto durante el desarrollo de mxfp8: el error de diseño de pesos descrito anteriormente produjo un error de logit relativo del ~53% mientras que la latencia del kernel era completamente normal. La regresión solo apareció en el análisis de tokens de salida, no en ninguna métrica de rendimiento.

Nuestra canalización de validación tiene dos puertas:

Puerta de corrección: La decodificación codiciosa posterior a la cuantización debe coincidir exactamente con los tokens de bf16 en los primeros cinco fotogramas de audio para una entrada de referencia fija. La coincidencia exacta de tokens en los primeros fotogramas detecta la corrupción sistemática de logits; si el modelo cuantizado produce distribuciones de probabilidad diferentes, divergerá de bf16 inmediatamente en entradas deterministas.

Puerta de regresión de rendimiento: El decode_tps por solicitud debe mantenerse dentro del 5% de las cifras de referencia congeladas en cada punto de concurrencia. Cualquier cambio que degrade el rendimiento más allá del 5% en cualquier concurrencia —c=1, c=16, c=64— requiere una justificación explícita antes de la fusión. Esta puerta protege contra correcciones de precisión que agregan silenciosamente sincronización al bucle de decodificación.

Ambas puertas se ejecutan en cada cambio en el stack de inferencia. El resultado: los pesos del modelo S2.1 Pro Free son idénticos a los del nivel de pago, y la ruta de servicio cuantizada se valida contra la línea de base no cuantizada en cada despliegue.

Clonación de voz a escala: Por qué importa la eficiencia de la inferencia

La clonación de voz de Fish Audio siempre ha sido gratuita y sigue siendo, según nuestra propia evaluación y los comentarios de los desarrolladores, la mejor en su clase. La consistencia del locutor en 83 idiomas, la prosodia natural y el rendimiento estable en diferentes acentos no son características que hayamos añadido a un nivel de pago. Son la base. S2.1 Pro se basa en Fish Speech S2 Pro, nuestro modelo fundacional de pesos abiertos lanzado a principios de este año.

Lo que cambia la optimización de la inferencia es la economía de mantener ese compromiso a escala. Las cargas de trabajo de clonación de voz conllevan un costo por solicitud más alto que el TTS estándar: cada llamada debe acondicionarse en una incrustación (embedding) de locutor de referencia, mantener la identidad del locutor en salidas de longitud variable y hacer ambas cosas de manera consistente en todos los idiomas. Sin las ganancias de eficiencia descritas en esta publicación, la clonación de voz gratuita a escala de producción requeriría subvencionar una carga de trabajo estructuralmente costosa. Con ellas, no es necesario.

Tres optimizaciones son especialmente importantes para la clonación de voz:

FP8 preserva el acondicionamiento del locutor. La validación de corrección exacta de tokens —que detecta la corrupción a nivel de logit— valida directamente que la cuantización no degrada la señal de incrustación del locutor. La consistencia del locutor en las salidas clonadas coincide con la línea de base de bf16.

El procesamiento por lotes continuo maneja tipos de solicitudes mixtos. El tráfico de clonación de voz de producción mezcla solicitudes acondicionadas por referencia y no acondicionadas, longitudes de salida variables e idiomas variados. El procesamiento por lotes continuo llena el lote de decodificación independientemente del tipo de solicitud; no hay penalización por la heterogeneidad de la carga de trabajo.

El escalamiento del rendimiento de 52 veces hace viable la generación masiva. Con 8,006 tok/s en una sola H200, la generación de grandes bibliotecas de audio con voz clonada —audiolibros, diálogos de juegos, contenido localizado a escala— es económicamente viable dentro del nivel gratuito.

El nivel gratuito no incluye la clonación de voz porque hayamos optimizado nuestro camino para poder permitirlo. Lo incluimos porque ese siempre ha sido el producto, y el trabajo de ingeniería descrito aquí es lo que nos permite mantener esa promesa a medida que el uso escala. Para integrar la clonación de voz en flujos de trabajo de agentes, consulte nuestro soporte para habilidades de agentes y MCP.

Clone una voz en menos de 60 segundos → Pruébelo gratis

Infraestructura de GPU: Ser dueños del stack

Hardware y adquisición

Nuestro clúster de GPU cuenta con aproximadamente 500 tarjetas en múltiples centros de datos (DC). La topología multi-DC fue una decisión de adquisición antes que de fiabilidad: el suministro y los precios de las GPU son volátiles, y el bloqueo con un solo proveedor significa absorber esa volatilidad directamente. El abastecimiento multi-proveedor y multi-DC mitiga el riesgo de precio y las restricciones de suministro simultáneamente, a costa de la complejidad operativa.

Para la inferencia, operamos una flota mixta. Las H200 SXM5 manejan el servicio de producción de alta concurrencia donde domina el rendimiento agregado de bsgemm FP8. Las RTX 5090 y RTX 6000 PRO (sm_120a) sirven puntos finales de borde (edge); a c=64, la 5090 mxfp8 logra 5,869 tok/s, aproximadamente el 71% del rendimiento de la H200 bsgemm a un costo de hardware por tarjeta sustancialmente menor.

El despliegue de sm_120a requirió una corrección no obvia: el límite original de cuda_graph_max_bs = 24 para GPU de 32GB producía una caída drástica de rendimiento en alta concurrencia —c=32 caía a ~31 tok/s/req, c=64 a ~35 tok/s/req. Elevar el límite a min(max_running_requests, 64) recuperó la curva completa de rendimiento. El problema subyacente: la captura del grafo de CUDA en bs=24 dejaba la GPU subutilizada en los tamaños de lote de decodificación que realmente aparecen en c=32+.

Programación de GPU: Eliminando la capacidad ociosa

La utilización base de la GPU en un clúster solo de inferencia es de aproximadamente el 50%. El tráfico de inferencia es inherentemente intermitente; la GPU permanece inactiva durante las horas de menor actividad, entre ejecuciones de entrenamiento y durante las fases de carga de conjuntos de datos.

Ejecutamos dos sistemas de programación paralelos —Kubernetes para la inferencia, Slurm para el entrenamiento— con un principio compartido: los trabajos de limpieza y preprocesamiento de datos se ejecutan como trabajo de relleno elástico en el nivel de prioridad más bajo en ambos clústeres. Los trabajos de limpieza ocupan la capacidad ociosa de la GPU siempre que la inferencia o el entrenamiento no la estén utilizando. Son puntos de control e inmediatamente interrumpibles (preemptible), por lo que desaparecen sin costo de corrección cuando llega trabajo real.

Orden de prioridad: inferencia > limpieza en el clúster K8s; entrenamiento > limpieza en Slurm. El escalador automático en el lado de la inferencia utiliza señales de tráfico real —no heurísticas basadas en el tiempo— por lo que los trabajos de limpieza se desalojan tan pronto como la carga aumenta.

Resultado: utilización de la GPU de ~50% a ~90%+. A escala de clúster, ese diferencial reduce aproximadamente a la mitad el costo efectivo por solicitud de inferencia; el presupuesto de hardware es fijo, pero se atienden el doble de solicitudes con él.

Infraestructura de red

Operamos nuestra propia red: adquisición directa de ancho de banda de ISP, ASN, conectividad de 300Gbps y peering con Cloudflare. Dos implicaciones de costo específicas para TTS.

La salida (egress) a escala de TTS no es trivial. Los precios de salida de los proveedores de la nube son estructuralmente de alto margen; ser dueños de la capa de red elimina ese margen por completo.

La latencia es la segunda razón. Cada milisegundo de viaje de ida y vuelta de la red aparece en el TTFB percibido por el usuario. El peering con Cloudflare coloca los puntos finales de Fish Audio cerca de los usuarios enrutados a través de la red de Cloudflare, una fracción sustancial del tráfico global de API. El despliegue multi-DC significa que la mayoría de las solicitudes llegan a un nodo de inferencia cercano sin atravesar la totalidad del internet público.

Almacenamiento: Arquitectura por niveles

Los datos de entrenamiento, los puntos de control del modelo y la caché de inferencia tienen diferentes patrones de acceso y requisitos de costo. Utilizamos una arquitectura de tres niveles:

• Activo (NVMe flash): datos de entrenamiento activos, pesos de modelo para el servicio.
• Templado (mezcla flash/HDD): puntos de control recientes, conjuntos de datos preprocesados.
• Frío (clúster HDD Ceph autohospedado): datos de entrenamiento históricos, almacenamiento a largo plazo.

El nivel frío reemplazó al almacenamiento de objetos de terceros para datos masivos. Una capa de caché local frente al almacenamiento frío significa que las lecturas repetidas —comunes en las canalizaciones de datos de entrenamiento— se sirven desde NVMe en lugar de HDD frío.

El resultado: Lo que produce el stack

A través de todas las capas:

• Kernels FP8 personalizados: 2.1–4.3 veces más rápidos que cuBLAS estándar en formas de decodificación.
• Procesamiento por lotes continuo: escalamiento de rendimiento de 52 veces de c=1 a c=64, aumento de latencia de 37ms.
• Programación de GPU: utilización ~50% → ~90%+, reduciendo aproximadamente a la mitad el costo por solicitud.
• Infraestructura propia: margen de beneficio de la nube eliminado del cómputo, la red y el almacenamiento.

En conjunto, el mismo volumen de solicitudes que antes requería cuatro H200 ahora se ejecuta en una. La mejora de eficiencia de 4 veces es lo que hace que el nivel gratuito sea económicamente viable; no es un subsidio, sino una reducción de costos estructural. El período de acceso gratuito refleja que la economía unitaria funciona; vea Precios para la disponibilidad actual.

Cómo se compara el stack de inferencia de Fish Audio

Datos de infraestructura basados en documentación pública, repositorios de GitHub y blogs de ingeniería a fecha de junio de 2026.

El patrón es consistente: Fish Audio es el único proveedor importante de TTS que ha documentado públicamente su arquitectura de inferencia, ha liberado su biblioteca de kernels como código abierto y ha publicado cifras de rendimiento concretas. "No revelado" no es una crítica, es una observación sobre lo que es verificable. Para una evaluación independiente de la calidad de voz entre proveedores, vea nuestra comparativa ciega de proveedores de TTS.

Qué hay en código abierto

fish-scales-ops ya está disponible: GEMM FP8 y FlashAttention para Hopper y Blackwell, de grado de producción, seguro para la captura de grafos de CUDA.

Si está construyendo infraestructura de inferencia para modelos autorregresivos en H200 o RTX 5090/6000 PRO, la brecha de rendimiento en formas de decodificación frente a las bibliotecas estándar es real y los kernels están ahí para cerrarla.

Qué hay en la biblioteca:

• FP8 GEMM: bsgemm (activación 1×128 × peso 128×128) para Hopper; MXFP8 1×32 (OCP UE8M0) para Blackwell.
• MXFP8 FlashAttention para sm_120a: prefill contiguo, prefill paginado (extend), decodificación paginada con GQA nativo mediante difusión K/V con zancada 0.
• Seguro para la captura de grafos de CUDA en todo momento.

Qué sigue

Soporte para B300 está en la hoja de ruta. Los núcleos tensores FP8 nativos y el ancho de banda de NVLink 5 en Blackwell impulsarán aún más la curva de rendimiento.

La optimización de la inferencia continúa. Las cifras de los benchmarks congelados son una puerta de regresión, no un objetivo. Cada punto de concurrencia es algo a superar.

Más partes del stack de servicio son candidatos para el código abierto a medida que se estabilicen: las modificaciones de sglang_lite, la lógica de procesamiento por lotes específica de DualAR, el manejo de grafos de CUDA de sm_120a. La infraestructura que hace que el nivel gratuito sea sostenible es la misma infraestructura sobre la que querríamos que la comunidad construyera.

Primeros pasos con la API de TTS gratuita

Cadena de modelo: s2.1-pro-free. Un solo cambio de encabezado respecto a cualquier llamada a la API de Fish Audio existente.

python

import httpx

body = {
    "text": "Hello, world!",
    "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: "Hello, world!",
  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 idiomas. Sin límite de uso estricto. Sin tarjeta de crédito. Clonación de voz incluida.

Todas las demás API de TTS de última generación cobran desde el primer token. S2.1 Pro no lo hace.

Clone una voz en menos de 60 segundos →

Documentación completa de la API →