Smallest AI y TrueFoundry AI Gateway

Los modelos de texto a voz y voz a texto de Smallest AI se integran con TrueFoundry AI Gateway a través de un paso nativo. Las solicitudes fluyen a los puntos finales REST de Smallest AI para la síntesis y transcripción por lotes, y a los flujos de eventos enviados por el servidor y los puntos finales WebSocket correspondientes para la salida de audio en fragmentos y la transcripción en vivo. La pasarela sustituye el token Bearer de Smallest AI de su almacén de credenciales, aplica el control de acceso y emite tramos de OpenTelemetry antes de actuar como proxy de la solicitud o de actualizar el WebSocket.

Esta publicación cubre la superficie de la API de Smallest AI en las familias TTS y STT. También cubre cómo el plano de la pasarela maneja la ruta de paso nativo para los puntos finales de voz no compatibles con OpenAI.

Lo que Smallest AI expone

Smallest AI ofrece dos familias de modelos. Lightning es la familia de texto a voz. Pulse es la familia de voz a texto. Ambos funcionan como puntos finales REST para uso por lotes y como puntos finales WebSocket para uso en streaming.

Lightning v3.1 es un modelo TTS de 44 kHz con un tiempo publicado hasta el primer audio inferior a 100 ms. Admite 15 idiomas con una fuerte cobertura de idiomas índicos, incluyendo hindi, tamil, telugu, malayalam, kannada, marathi y gujarati, junto con inglés, español, francés, alemán, italiano, portugués, sueco y neerlandés. El modelo utiliza una arquitectura no autorregresiva que genera segmentos de voz completos en paralelo en lugar de token por token. Esto es lo que produce el perfil de latencia y lo que permite que el modelo se ejecute con menos de 1 GB de VRAM, lo que hace que la implementación local sea práctica para entornos regulados.

El modelo se expone a través de tres formas de punto final.

1. POST https://waves/v1/lightning-v3.1/get_speech. 
   
   1. Este es un punto final síncrono por lotes que devuelve el archivo de audio completo en el cuerpo de la respuesta. Acepta formatos de salida MP3, PCM, WAV, mulaw o alaw y admite frecuencias de muestreo de 8000 Hz a 44100 Hz. 
   2. Acepta un parámetro voice_id y un parámetro speed entre 0.5x y 2x, y una matriz opcional pronunciation_dicts para anulaciones de léxico personalizadas. 
   3. También admite identificadores de correlación session_id y request_id que se devuelven en los encabezados de la respuesta como X-External-Session-Id y X-External-Request-Id. Estos pasan por la pasarela sin cambios, lo cual es útil para la correlación de trazas de extremo a extremo.
2. POST https://waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Este es el flujo de eventos enviados por el servidor que emite fragmentos de audio progresivamente a medida que el modelo los genera.
3. WSS /waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Esta es la conexión WebSocket persistente que entrega fragmentos de audio a medida que se producen. 
   2. La conexión es reutilizable en múltiples solicitudes TTS, por lo que el costo de establecimiento de la conexión se amortiza. 

Pulse es la contraparte STT. Funciona de dos formas. POST /waves/v1/pulse/get_text maneja audio pregrabado por lotes. WSS /waves/v1/pulse/get_text maneja la transcripción en vivo por streaming. El punto final de streaming acepta fotogramas de audio a 8000, 16000, 22050, 24000, 44100 o 48000 Hz con linear16 como codificación predeterminada. Admite 36 idiomas con cambio de código habilitado a través de language=multi.

Las partes interesantes del protocolo de streaming Pulse para una integración detrás de una pasarela son los controles de contenido en línea. redact_pii=true elimina la información de identificación personal de las transcripciones finalizadas antes de que salgan de Smallest AI. redact_pci=true elimina la información de tarjetas de pago, incluyendo números de tarjeta, códigos CVV, códigos postales y números de cuenta. diarize=true habilita la diarización de hablantes. keywords acepta una lista de frases separadas por comas con valores intensificadores opcionales para mejorar el reconocimiento de terminología específica del dominio, como nombres de productos o nombres de medicamentos. itn_normalize=true habilita la Normalización Inversa de Texto, que convierte los números, fechas y monedas hablados a su forma escrita en las transcripciones finalizadas. Los parámetros de redacción son importantes porque trasladan la aplicación de la privacidad a la capa del modelo, en lugar de requerir una barrera de seguridad posterior para limpiar la transcripción a posteriori.

Modelo de concurrencia. Smallest AI expone una superficie de concurrencia inusual que vale la pena entender antes de construir sobre ella. Una unidad de concurrencia corresponde a una solicitud TTS activa que puede procesarse en un momento dado. Se pueden establecer hasta tres conexiones WebSocket por unidad de concurrencia para TTS. Así, un inquilino con tres unidades de concurrencia puede mantener abiertas nueve conexiones WebSocket, pero solo tres de ellas pueden tener una generación activa en curso simultáneamente. Las solicitudes adicionales enviadas a través de cualquier conexión mientras se alcanza el límite de concurrencia son rechazadas con un error en lugar de ser puestas en cola. Esto difiere del modelo típico de tokens por minuto o solicitudes por minuto y tiene implicaciones sobre cómo debe configurarse el limitador de velocidad de la pasarela. Para STT, una unidad de concurrencia es una conexión WebSocket.

Paso nativo a través del plano de la pasarela

La pasarela de IA de TrueFoundry está construida sobre el framework Hono y funciona como una flota de pods sin estado. Un solo pod con 1 vCPU y 1 GB de RAM maneja más de 250 RPS con aproximadamente 3 ms de latencia adicional. El plano de control gestiona la configuración en PostgreSQL y ClickHouse y propaga las actualizaciones a los pods de la pasarela a través de NATS. Los pods de la pasarela almacenan esa configuración en memoria, por lo que la ruta de la solicitud no realiza llamadas externas para autenticación, autorización o decisiones de enrutamiento.

Para los proveedores compatibles con OpenAI, la pasarela traduce entre el formato de entrada de OpenAI y el formato nativo del proveedor dentro de un adaptador. Smallest AI no encaja en esa traducción porque la API de audio de OpenAI no tiene un equivalente para los parámetros voice_id, pronunciation_dicts y session_id de Smallest AI, ni para el protocolo de streaming WebSocket que entrega la salida de audio en fragmentos de Lightning. Por lo tanto, la pasarela expone Smallest AI a través de un paso nativo.

Cuando una solicitud de Smallest AI llega a un pod de la pasarela, la tubería de pre-reenvío ejecuta las mismas comprobaciones que se ejecutan para las finalizaciones de chat. El JWT presentado en la solicitud se valida contra las claves públicas IdP en caché sin ninguna llamada de autenticación externa. La autorización se verifica contra el mapa en memoria de usuarios a modelos. El identificador del modelo (lightning-v3.1 o pulse) se resuelve a la cuenta de Smallest AI configurada. El encabezado de autorización de entrada se elimina y se reemplaza con el token Bearer recuperado del almacén de credenciales. La URL reenviada se convierte en https://api.smallest.ai/... con la ruta y el método coincidentes preservados. El cuerpo se transmite sin cambios. Para los puntos finales de WebSocket, la pasarela realiza un handshake de actualización HTTP contra la URL de WebSocket de Smallest AI. Una vez que la actualización tiene éxito, la pasarela mantiene dos conexiones WebSocket (una con el cliente y otra con Smallest AI) y proxy los frames en ambas direcciones sin interpretar las cargas útiles. Los encabezados de eco X-External-Session-Id y X-External-Request-Id pasan al llamador intactos.

Una vez completada la solicitud, la pasarela publica un span en NATS que contiene la duración, el estado, el nombre del modelo resuelto y los metadatos de coste. El exportador OTEL lee de la ruta asíncrona y reenvía el span al backend configurado a través de gRPC o HTTP. El servicio agregador consolida los datos de costes por usuario, por equipo y por modelo.

La superficie de integración

Añadir Smallest AI a TrueFoundry AI Gateway se realiza en tres pasos desde el panel de control. Navegue a AI Gateway, luego a Modelos y seleccione Smallest AI. Añada una cuenta introduciendo un nombre de cuenta único y el token Bearer de Smallest AI. El token se almacena cifrado en el plano de control y nunca se expone directamente a los pods de la pasarela. Opcionalmente, añada colaboradores para controlar qué usuarios y equipos pueden enrutar a través de esta cuenta. Luego, registre uno o más modelos haciendo clic en Añadir Modelo y proporcionando el Nombre de visualización, el ID del modelo y el Tipo de modelo. El ID del modelo debe coincidir exactamente con el identificador del modelo de Smallest AI (lightning-v3.1 o lightning-v2 o pulse).

La inferencia utiliza el SDK de Python de Smallest AI o cualquier cliente HTTP con la URL de la pasarela sustituida como URL base. Un cliente Python se ve así.

import requests

response = requests.post(
    "https://<your-gateway-host>/smallest/waves/v1/lightning-v3.1/get_speech",
    headers={
        "Accept": "audio/wav",
        "Authorization": f"Bearer {TFY_API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "text": "Welcome to the support line. Please describe your issue.",
        "voice_id": "daniel",
        "sample_rate": 24000,
        "speed": 1.0,
        "output_format": "wav",
        "language": "en",
    },
)

with open("response.wav", "wb") as f:
    f.write(response.content)

La misma estructura funciona para el punto final SSE cambiando la ruta y leyendo la respuesta como un flujo. El punto final WebSocket funciona a través de cualquier cliente WebSocket estándar apuntando a la URL de la pasarela con el esquema wss. El JWT emitido por TrueFoundry reemplaza el token Bearer de Smallest AI en el encabezado de autorización. El cliente de Smallest AI ve la misma carga útil de respuesta y los mismos encabezados que vería al comunicarse directamente con Smallest AI, porque la pasarela conserva las rutas URL y las formas de respuesta, incluyendo los encabezados de correlación X-External-Session-Id y X-External-Request-Id.

Resumen de la arquitectura

El flujo de datos de extremo a extremo es sencillo. Un cliente abre una solicitud HTTP o un WebSocket contra la URL de la pasarela utilizando el SDK de Python de Smallest AI o un cliente HTTP y WebSocket genérico. El pod de la pasarela autentica el JWT contra las claves públicas IdP en caché y resuelve el identificador del modelo a la cuenta de Smallest AI configurada. Elimina el encabezado de autenticación de entrada y sustituye el token Bearer del almacén de credenciales. Reenvía la solicitud a https://api.smallest.ai o actualiza el WebSocket a la URL wss:// correspondiente. Para las sesiones WebSocket, puentea los frames en ambas direcciones hasta que cualquiera de las partes cierra la conexión. Una vez completado, la pasarela publica un span en NATS que alimenta el exportador OTEL y el agregador de costes.

Lo que no se requiere es significativo. No hay una bifurcación del SDK de Smallest AI. No hay una capa de traducción entre el formato de audio de OpenAI y los parámetros voice_id y pronunciation_dicts de Smallest AI que perdería información en el límite. No hay una tubería de rastreo en la sombra para el tráfico de voz separada de la tubería de tráfico de chat. No hay un token Bearer por servicio distribuido a través del código de la aplicación o los secretos de Kubernetes. No hay un terminador WebSocket separado que deba implementarse junto con la pasarela para aplicar el control de acceso a los puntos finales de streaming. Los parámetros de redacción de PII y PCI de Pulse viajan a través de la pasarela sin ser modificados, lo que mantiene la aplicación de la privacidad en la capa del modelo donde se ejecuta la tubería de redacción de Smallest AI, en lugar de fragmentarla a través de una barrera de seguridad posterior.

El principio arquitectónico es la separación entre la semántica del protocolo y la semántica de la gobernanza. El streaming de audio en fragmentos de Lightning y la transcripción en streaming de Pulse con redacción en línea conllevan un significado de dominio de voz que no se generaliza a otros proveedores. La capa de gobernanza (autenticación, autorización, inyección de credenciales, observabilidad, consolidación de costes y limitación de velocidad en el límite del equipo) es agnóstica al proveedor y se ejecuta delante de cualquier origen HTTP o WebSocket sin inspeccionar las cargas útiles. El paso nativo preserva lo primero mientras aplica lo segundo. El resultado es que la superficie completa de características de Smallest AI (la cobertura de 15 idiomas de Lightning, las voces índicas, la redacción PCI de Pulse y el modelo de concurrencia explícito) está disponible para los clientes, mientras que las garantías operativas que el resto de la pasarela de IA proporciona para el tráfico de chat se aplican al tráfico de voz en los mismos pods de pasarela con el mismo plano de control y los mismos backends de rastreo y costes.