Cartesia y TrueFoundry AI Gateway: acceso nativo para la inferencia de voz

El modelo de conversión de texto a voz Sonic-3 de Cartesia y el modelo de transmisión de voz a texto de Ink-Whisper se integran con TrueFoundry AI Gateway a través de una superficie de acceso nativa. Las solicitudes llegan a las de Cartesia /tts/bytes Punto final HTTP y /tts/es flujo de eventos enviados por el servidor y /tts/websocket WebSocket bidireccional y WebSocket de transmisión de tinta con su semántica de protocolo original intacta. La pasarela inyecta la clave API de Cartesia desde su almacén central de credenciales, ejecuta el control de acceso y emite intervalos de OpenTelemetry antes de reenviar la conexión.

Esta publicación explica por qué los proveedores de inferencia de voz no pueden usar el mismo patrón de traducción compatible con OpenAI que la puerta de enlace aplica a los proveedores de finalización de chat. En él se explica cómo el plano de pasarela gestiona la transferencia nativa dentro de la canalización de solicitudes de Hono existente. Cubre la superficie de la API de Cartesia tanto en TTS como en STT. Abarca la forma de la configuración y el flujo de datos de principio a fin.

Por qué los proveedores de voz no utilizan la ruta de traducción de OpenAI

La mayoría de las integraciones de TrueFoundry AI Gateway funcionan según un principio de traducción. Llega una solicitud en un formato compatible con OpenAI el /chat/finalizaciones o /incrustaciones o /respuestas. La puerta de enlace resuelve el identificador del modelo en un punto final del proveedor y traduce la solicitud a la forma nativa de ese proveedor mediante un adaptador. Anthropic se traduce a la API de mensajes. Google Vertex se traduce a la API de lenguaje generativo. Cohere se traduce a su esquema de chat nativo. La respuesta vuelve y se traduce al revés para que la persona que llama vea una forma uniforme de OpenAI, independientemente del proveedor físico que haya atendido la solicitud.

Este patrón funciona porque la semántica de finalización del chat es aproximadamente equivalente en todos los proveedores. Hay una lista de mensajes y un identificador de modelo y parámetros de muestreo, así como un indicador de streaming y una respuesta con las llamadas a las herramientas y los motivos de finalización. Las diferencias son reales pero limitadas y se pueden conciliar dentro de un adaptador.

La inferencia de voz no se ajusta a ese molde. La API TTS de Cartesia tiene parámetros que no tienen equivalentes en la API de audio de OpenAI. El voz El campo acepta un identificador de voz de Cartesia o una incrustación de voz. El formato_de_salida block especifica el contenedor y la codificación y la frecuencia de muestreo como un objeto estructurado. El lengua El campo selecciona entre 42 idiomas compatibles. El Controles __experimentales block contiene parámetros de velocidad y emoción que se corresponden con los controles expresivos de Sonic-3. El protocolo WebSocket introduce contextos multiplexados y flush_id límites y semántica de continuación para la transmisión de entradas de texto desde un LLM ascendente. Nada de esto existe en el OpenAI /v1/audio/voz forma.

La ruta STT de Ink-Whisper es similar. El protocolo WebSocket de streaming transfiere los fotogramas de audio en tiempo real y emite transcripciones provisionales y finales a medida que el modelo realiza la fragmentación dinámica dentro de límites semánticamente significativos. El OpenAI /v1/audio/transcripciones endpoint es un archivo de respuesta a una solicitud que se carga sin una contraparte de streaming en la especificación oficial.

La traducción de esta superficie eliminaría la capacidad o introduciría mapeos con pérdidas. Por lo tanto, la puerta de enlace expone a Cartesia a través de una ruta nativa. La persona que llama continúa usando el SDK oficial de Python de Cartesia o cualquier otro cliente de Cartesia con su conjunto completo de funciones. La puerta de enlace se interpone en la ruta como límite de credenciales, políticas y observabilidad, más que como traductor de protocolos.

Cómo funciona el acceso directo nativo dentro del plano de puerta de enlace

El TrueFoundry AI Gateway se basa en el marco Hono. Un único módulo de puerta de enlace con 1 vCPU y 1 GB de RAM gestiona más de 250 RPS con una latencia adicional de aproximadamente 3 ms. Los pods no tienen estado y están vinculados a la CPU, y se escalan horizontalmente hasta alcanzar decenas de miles de RPS. El plano de puerta de enlace y el plano de control están divididos. El plano de control administra la configuración en PostgreSQL y ClickHouse y propaga las actualizaciones a través de NATS. Los pods de puerta de enlace almacenan en caché esa configuración en la memoria.

Cuando una solicitud de Cartesia llega a un pod de gateway, se ejecuta la misma canalización previa al reenvío que se ejecuta para completar el chat. El JWT presentado en la solicitud se valida con las claves públicas del IdP almacenadas en caché sin ninguna llamada de autenticación externa. La autorización se comprueba comparándola con el mapa almacenado en la memoria entre los usuarios y los modelos que NATS mantiene sincronizados. La capa de enrutamiento resuelve el identificador del modelo (como sónico-3 o susurro de tinta) al punto final del proveedor configurado para ese modelo y a las credenciales de la cuenta de Cartesia almacenadas en el plano de control. El cuerpo de la solicitud y los parámetros de ruta y consulta no se reescriben. Solo el Autorización y Clave X-API los encabezados se eliminan de la solicitud entrante y se sustituyen por la clave API de Cartesia del almacén de credenciales seguro. La URL reenviada pasa a ser el origen de Cartesia (https://api.cartesia.ai/...) conservando la ruta y el método coincidentes. El cuerpo se transmite sin cambios.

Para los puntos finales de WebSocket (ws: //api.cartesia.ai/tts/websocket y el punto final de transmisión de tinta), la puerta de enlace realiza un protocolo de enlace de actualización HTTP. Una vez que la actualización se realiza correctamente, la puerta de enlace contiene dos conexiones WebSocket (una con el cliente y otra con Cartesia) y envía marcos proxy en ambas direcciones. El modelo de contexto multiplexado que expone Cartesia se conserva porque la puerta de enlace no interpreta las cargas útiles de los marcos. Un cliente que abre un único WebSocket y ejecuta docenas de generaciones simultáneas en diferentes identidad_contexto values ve el mismo comportamiento a través de la pasarela que si hablara directamente con Cartesia.

La ruta de publicación de rastreo asincrónico que la puerta de enlace utiliza para completar el chat también se ejecuta para el tráfico de Cartesia. La puerta de enlace emite intervalos para el controlador HTTP entrante, la resolución de credenciales y la llamada saliente al proveedor (o sesión de WebSocket). En el caso de las solicitudes de TTS, estos intervalos incluyen la duración y el estado, así como el nombre del modelo resuelto y un hash de la transcripción. En el caso de las sesiones STT, el intervalo captura la duración de la conexión y el recuento de mensajes. Los intervalos se publican de forma asincrónica en NATS una vez finalizada la solicitud. El exportador de OpenTelemetry lee la ruta asíncrona y reenvía los rastros al backend configurado (gRPC o HTTP). La exportación es aditiva y no cambia el almacenamiento de trazas propio de la puerta de enlace. La puerta de enlace nunca falla en una solicitud de Cartesia, incluso si no se puede acceder al punto final externo de OTEL.

El proceso de seguimiento de costos también se ejecuta en modo de transferencia. Cartesia factura con créditos que se traducen en caracteres sintetizados para TTS y segundos transcritos para STT. La pasarela registra los metadatos del tamaño de la solicitud y la duración de la respuesta y los publica en el mismo bus de eventos NATS que agrega los datos sobre los costos de finalización del chat. El servicio de agregación calcula por usuario y por equipo y por modelo los paquetes acumulados que aparecen en la vista analítica unificada junto con el tráfico de chat.

Lo que expone Cartesia

Cartesia construye modelos de voz sobre una arquitectura modelo de espacio de estados. La familia TTS se llama Sonic y el modelo de producción actual es Sonic-3. La familia STT se llama Ink y el modelo de producción actual es Ink-Whisper.

Sonic 3 es un modelo de transmisión TTS con un tiempo publicado hasta el primer audio de aproximadamente 90 ms. Es compatible con 42 idiomas. Expone controles detallados sobre el volumen, la velocidad y la emoción a través de parámetros de API y etiquetas SSML. Apoya la risa a través de [risas] etiquetas en línea. El modelo se expone a través de tres formas de punto final que se adaptan a diferentes casos de uso.

La primera es POST /tts/bytes. Se trata de un punto final de lote sincrónico que devuelve el archivo de audio completo en el cuerpo de la respuesta. Acepta los formatos de salida MP3, WAV o PCM sin procesar y es adecuado para pregenerar recursos de audio en los que la latencia total de espera para obtener la salida completa es aceptable.

La segunda es PUBLICACIÓN /tts/sse. Este es un flujo de eventos enviado por el servidor. El modelo emite fragmentos de audio progresivamente a medida que se generan. Esto se adapta a las aplicaciones que reproducen audio de forma progresiva y necesitan aprovechar el tiempo necesario para llegar al primer byte, pero no necesitan transmitir el texto de entrada al modelo.

El tercero es WSS /tts/websocket. Este es el punto final recomendado para los agentes de voz en tiempo real. La conexión es bidireccional y admite generaciones multiplexadas a través del identidad_contexto campo. Un único WebSocket abierto puede almacenar docenas de generaciones simultáneas. El identidad_contexto permite la generación de continuaciones donde se pueden insertar segmentos de texto adicionales en un contexto existente para mantener la prosodia en todas las uniones. Esto es importante cuando la fuente de texto ascendente es un LLM que transmite token por token y el TTS debe seguir la cadencia de la generación del texto. El protocolo WebSocket también admite la limpieza manual flush_id marcadores que crean límites de audio discretos dentro de un único contexto.

Susurro de tinta es un modelo STT de streaming derivado de turbo v3 supergrande y rediseñado para un uso conversacional en tiempo real. La métrica que la define es el tiempo necesario para completar la transcripción, que mide la rapidez con la que está lista la transcripción final precisa una vez que el usuario deja de hablar. Ink-Whisper logra esto mediante la fragmentación dinámica. El Whisper estándar funciona mejor con búferes de audio fijos de 30 segundos, por lo que introduce un nivel de latencia fundamental que no es adecuado para una conversación en directo. Ink-Whisper analiza la transmisión de audio en busca de puntos de interrupción semánticamente significativos, como pausas y respiraciones, y procesa los fragmentos más cortos a medida que se forman. El punto final es un WebSocket de streaming que acepta fotogramas de audio PCM a 16 kHz y emite transcripciones provisionales y finales a medida que el modelo se compromete a utilizarlas. La codificación de audio predeterminada es pcm_s16le a 16000 Hz.

Cartesia desconecta las conexiones de WebSocket después de 3 minutos de inactividad. El tiempo de espera se restablece con cada fotograma enviado en cualquier dirección. Los clientes suelen utilizar Keepalives basados en el silencio para mantener la conexión abierta a pesar de los espacios entre palabras.

La superficie de integración

Añadir Cartesia a TrueFoundry AI Gateway consta de tres pasos en el panel de control. Diríjase a AI Gateway y, a continuación, a Models y seleccione Cartesia. Añade una cuenta de Cartesia introduciendo un nombre de cuenta único y la clave de API de Cartesia. La clave se almacena cifrada en el plano de control y nunca se expone directamente a los pods de la puerta de enlace. Si lo desea, añada colaboradores para controlar qué usuarios y equipos pueden dirigir el tráfico a través de esta cuenta. A continuación, registre uno o más modelos haciendo clic en Agregar modelo y proporcionando un nombre para mostrar, un ID de modelo y un tipo de modelo. En el caso de Cartesia, el identificador del modelo y el nombre para mostrar deben ser idénticos y deben coincidir exactamente con el identificador del modelo de Cartesia (sónico-3 y sonic-3-2026-01-12 y susurro de tinta y así sucesivamente).

La superficie de configuración de una cuenta de Cartesia es pequeña.

FieldValueAccount NameIdentificador único que abarca la clave de la API de Workspace/la clave de API de Cartesia del panel de control de Cartesia. Colaboradores. Usuarios y equipos que pueden enrutar a través de esta cuenta.

La superficie de configuración de un modelo de Cartesia es igualmente pequeña.

FieldValueDisplay NameDebe ser igual al ID del modelo (ID del modelo), al identificador del modelo Cartesia (por ejemplo). sónico-3 o susurro de tinta) Tipo de modeloSeleccionado entre los tipos de modelos de voz compatibles

Inference usa el SDK nativo de Cartesia con la URL de la puerta de enlace sustituida como URL base. Un cliente de Python tiene el siguiente aspecto.

sistema operativo de importación
de cartesia importar Cartesia

cliente = Cartesia (
api_key=os.environ ["TFY_API_KEY"],
<your-gateway-host>base_url="https:///cartesia «,
)

respuesta = client.tts.bytes (
model_id = «sonic-3",
transcript="El camino sigue y sigue. «,
voice= {"mode»: «id», «id»: «6ccbfb76-1fc6-48f7-b71d-91ac6298247b"},
output_format= {"contenedor»: «wav», «codificación»: «pcm_f32le», «sample_rate»: 44100},
)


Las mismas llamadas al SDK funcionan para el punto final de WebSocket y para el WebSocket STT de Ink-Whisper. El JWT emitido por TrueFoundry reemplaza la clave de la API de Cartesia en la configuración del SDK. El SDK cree que está comunicándose directamente con Cartesia porque la puerta de enlace conserva las rutas URL y las formas de respuesta. El control de los costos y el acceso y el rastreo se realizan de forma invisible en la ruta de la solicitud.

Resumen de la arquitectura

El flujo de datos de principio a fin es sencillo. Un cliente abre una solicitud HTTP o un WebSocket en la URL de la puerta de enlace mediante el SDK de Cartesia. El pod de gateway autentica el JWT con las claves públicas del IdP almacenadas en caché y resuelve el identificador del modelo en la cuenta de Cartesia configurada. Elimina el encabezado de autenticación entrante y sustituye la clave de la API de Cartesia del almacén de credenciales. Reenvía la solicitud o actualiza el WebSocket a https://api.cartesia.ai. Para las sesiones de WebSocket, une los marcos en ambas direcciones hasta que cualquiera de los lados cierra la conexión. Una vez completada la solicitud, la pasarela publica un intervalo en NATS que indica al exportador OTEL y al agregador de costos.

Lo que no se requiere es importante. No hay ninguna bifurcación del SDK de Cartesia. No hay ninguna capa de traducción de sombras que aplane los parámetros del TTS para convertirlos en OpenAI Audio y, en el proceso, pierda el identificador de voz y el modelo de contexto de streaming. No hay un canal de seguimiento independiente para el tráfico de voz y otro diferente para el tráfico de chat. No hay ninguna clave de API por servicio distribuida en el código de la aplicación. No hay ningún terminador WebSocket del lado del cliente que deba implementarse por separado para aplicar el control de acceso a los puntos finales de streaming.

El principio arquitectónico que hace que esto funcione es la separación entre la semántica del protocolo y la semántica de la gobernanza. El protocolo Cartesia contiene un significado de dominio de voz que no se generaliza claramente a otros proveedores. La capa de gobierno (autenticación y autorización, inyección de credenciales, observabilidad y seguimiento de costos) no depende del proveedor y puede ejecutarse en cualquier origen HTTP o WebSocket sin inspeccionar la carga útil. La autenticación nativa conserva la primera mientras se aplica la segunda. El resultado es que las funciones completas de Cartesia (los controles de contexto, continuaciones y emociones de Sonic-3 y el flujo de transcripciones de streaming de Ink-Whisper) están disponibles para los clientes, mientras que las garantías operativas de que el resto de la pasarela de IA que proporciona el tráfico de chat se aplica al tráfico de voz en los mismos módulos de puerta de enlace, con el mismo plano de control y los mismos backends de rastreo y costo.

‍