Cartesia e TrueFoundry AI Gateway: Passthrough Nativo para Inferência de Voz

O modelo de texto para fala Sonic-3 da Cartesia e o modelo de fala para texto por streaming Ink-Whisper integram-se com o TrueFoundry AI Gateway através de uma superfície de passagem nativa. As requisições fluem para o endpoint HTTP /tts/bytes da Cartesia, para o fluxo de eventos enviados pelo servidor /tts/sse, para o WebSocket bidirecional /tts/websocket e para o WebSocket de streaming Ink com a semântica original do protocolo intacta. O gateway injeta a chave de API da Cartesia de seu repositório central de credenciais, executa o controle de acesso e emite spans do OpenTelemetry antes de encaminhar a conexão.

Esta publicação explica por que os provedores de inferência de voz não podem usar o mesmo padrão de tradução compatível com OpenAI que o gateway aplica aos provedores de conclusão de chat. Ela aborda como o plano do gateway lida com a passagem nativa dentro do pipeline de requisições Hono existente. Ela cobre a superfície da API da Cartesia para TTS e STT. Ela aborda o formato da configuração e o fluxo de dados de ponta a ponta.

‍

Por que os provedores de voz não usam o caminho de tradução OpenAI

A maioria das integrações do TrueFoundry AI Gateway opera com base em um princípio de tradução. Uma requisição chega em formato compatível com OpenAI em /chat/completions ou /embeddings ou /responses. O gateway resolve o identificador do modelo para um endpoint de provedor e traduz a requisição para o formato nativo desse provedor por meio de um adaptador. Anthropic é traduzido para a API de Mensagens. Google Vertex é traduzido para a API de Linguagem Generativa. Cohere é traduzido para seu esquema de chat nativo. A resposta retorna e é traduzida inversamente para que o chamador veja um formato OpenAI uniforme, independentemente de qual provedor físico atendeu à requisição.

Este padrão funciona porque a semântica de conclusão de chat é aproximadamente equivalente entre os provedores. Há uma lista de mensagens, um identificador de modelo, parâmetros de amostragem, um sinalizador de streaming e uma resposta com chamadas de ferramentas e motivos de conclusão. As diferenças são reais, mas estreitas e podem ser conciliadas dentro de um adaptador.

A inferência de voz não se encaixa nesse molde. A API TTS da Cartesia possui parâmetros que não têm equivalente na API de Áudio da OpenAI. O campo 'voice' aceita um ID de voz da Cartesia ou um embedding de voz. O bloco 'output_format' especifica o contêiner, a codificação e a taxa de amostragem como um objeto estruturado. O campo 'language' seleciona entre 42 idiomas suportados. O bloco '__experimental_controls' contém parâmetros de velocidade e emoção que mapeiam para os controles expressivos do Sonic-3. O protocolo WebSocket introduz contextos multiplexados, limites de flush_id e semântica de continuação para entrada de texto por streaming de um LLM upstream. Nada disso existe no formato /v1/audio/speech da OpenAI.

O caminho STT do Ink-Whisper é semelhante. O protocolo WebSocket de streaming passa quadros de áudio em tempo real e emite transcrições provisórias e transcrições finais à medida que o modelo realiza o agrupamento dinâmico em limites semanticamente significativos. O endpoint /v1/audio/transcriptions da OpenAI é um upload de arquivo de requisição-resposta sem uma contraparte de streaming na especificação oficial.

Traduzir esta superfície resultaria na perda de capacidade ou na introdução de mapeamentos com perdas. O gateway, portanto, expõe a Cartesia através de passagem nativa. O chamador continua a usar o SDK Python oficial da Cartesia ou qualquer outro cliente Cartesia com seu conjunto completo de recursos. O gateway atua no caminho como um limite de credencial, política e observabilidade, em vez de um tradutor de protocolo.

Como funciona a passagem nativa dentro do plano do gateway

O TrueFoundry AI Gateway é construído sobre o framework Hono. Um único pod de gateway com 1 vCPU e 1 GB de RAM lida com mais de 250 RPS com aproximadamente 3 ms de latência adicionada. Os pods são sem estado e limitados pela CPU, e escalam horizontalmente para dezenas de milhares de RPS. O plano do gateway e o plano de controle são separados. O plano de controle gerencia a configuração em PostgreSQL e ClickHouse e propaga atualizações via NATS. Os pods do gateway armazenam essa configuração em cache na memória.

Quando uma requisição da Cartesia atinge um pod do gateway, o mesmo pipeline de pré-encaminhamento é executado, o mesmo que é executado para conclusões de chat. O JWT apresentado na requisição é validado contra chaves públicas IdP em cache, sem chamada de autenticação externa. A autorização é verificada contra o mapa em memória de usuários para modelos que o NATS mantém sincronizado. A camada de roteamento resolve o identificador do modelo (como sonic-3 ou ink-whisper) para o endpoint do provedor configurado para esse modelo e para as credenciais da conta Cartesia armazenadas no plano de controle. O corpo da requisição, o caminho e os parâmetros de consulta não são reescritos. Apenas os cabeçalhos Authorization e X-API-Key são removidos da requisição de entrada e substituídos pela chave de API da Cartesia do repositório seguro de credenciais. A URL encaminhada torna-se a origem da Cartesia (https://api.cartesia.ai/...) com o caminho e o método correspondentes preservados. O corpo é transmitido sem alterações.

Para os endpoints WebSocket (wss://api.cartesia.ai/tts/websocket e o endpoint de streaming Ink), o gateway realiza um handshake de HTTP Upgrade. Após o sucesso da atualização, o gateway mantém duas conexões WebSocket (uma com o cliente e outra com a Cartesia) e atua como proxy para os frames em ambas as direções. O modelo de contexto multiplexado que a Cartesia expõe é preservado porque o gateway não interpreta os payloads dos frames. Um cliente que abre um único WebSocket e executa dezenas de gerações concorrentes com diferentes valores de context_id vê o mesmo comportamento através do gateway como se estivesse se comunicando diretamente com a Cartesia.

O caminho de publicação de rastreamento assíncrono que o gateway usa para conclusões de chat também é executado para o tráfego da Cartesia. O gateway emite spans para o manipulador HTTP de entrada, a resolução de credenciais e a chamada do provedor de saída (ou sessão WebSocket). Para requisições TTS, esses spans contêm duração e status, o nome do modelo resolvido e um hash da transcrição. Para sessões STT, o span captura o tempo de vida da conexão e a contagem de mensagens. Os spans são publicados assincronamente no NATS após a conclusão da requisição. O exportador OpenTelemetry lê do caminho assíncrono e encaminha os rastreamentos para o backend configurado (gRPC ou HTTP). A exportação é aditiva e não altera o próprio armazenamento de rastreamentos do gateway. O gateway nunca falha uma requisição da Cartesia, mesmo que o endpoint OTEL externo esteja inacessível.

O pipeline de rastreamento de custos também é executado em modo de passagem. A Cartesia cobra por créditos que se traduzem em caracteres sintetizados para TTS e segundos transcritos para STT. O gateway registra o tamanho da requisição e os metadados de duração da resposta e os publica no mesmo barramento de eventos NATS que agrega os dados de custo de conclusão de chat. O serviço agregador calcula resumos por usuário, por equipe e por modelo que aparecem na visualização unificada de análises, juntamente com o tráfego de chat.

O que a Cartesia expõe

A Cartesia constrói modelos de voz com base em uma arquitetura de modelo de espaço de estados. A família TTS é chamada Sonic e o modelo de produção atual é o Sonic-3. A família STT é chamada Ink e o modelo de produção atual é o Ink-Whisper.

‍Sonic-3 é um modelo TTS de streaming com um tempo publicado para o primeiro áudio de aproximadamente 90 ms. Ele suporta 42 idiomas. Ele expõe controles granulares de volume, velocidade e emoção através de parâmetros de API e tags SSML. Ele suporta risadas através de tags inline [laughter]. O modelo é exposto através de três formatos de endpoint que se adequam a diferentes casos de uso.

O primeiro é POST /tts/bytes. Este é um endpoint de lote síncrono que retorna o arquivo de áudio completo no corpo da resposta. Ele aceita formatos de saída MP3, WAV ou PCM bruto e é adequado para pré-gerar ativos de áudio onde a latência total de espera pela saída completa é aceitável.

O segundo é POST /tts/sse. Este é um fluxo de eventos enviados pelo servidor (SSE). O modelo emite blocos de áudio progressivamente à medida que são gerados. Isso é adequado para aplicações que reproduzem áudio progressivamente e precisam da vantagem do "tempo para o primeiro byte", mas não precisam transmitir texto de entrada para o modelo.

O terceiro é WSS /tts/websocket. Este é o endpoint recomendado para agentes de voz em tempo real. A conexão é bidirecional e suporta gerações multiplexadas através do campo context_id. Um único WebSocket aberto pode suportar dezenas de gerações simultâneas. O context_id permite a geração de continuação, onde segmentos de texto adicionais podem ser inseridos em um contexto existente para manter a prosódia nas junções. Isso é importante quando a fonte de texto upstream é um LLM que transmite token por token e o TTS precisa seguir a cadência da geração de texto. O protocolo WebSocket também suporta descarga manual através de marcadores flush_id, que criam limites de áudio discretos dentro de um único contexto.

Ink-Whisper é um modelo STT de streaming derivado do whisper-large-v3-turbo e reengenheirado para uso conversacional em tempo real. A métrica definidora é o "tempo para transcrição completa", que mede a rapidez com que a transcrição final precisa está pronta após o usuário parar de falar. O Ink-Whisper consegue isso através de segmentação dinâmica. O Whisper padrão tem o melhor desempenho em buffers de áudio fixos de 30 segundos e, portanto, introduz um limite de latência fundamental inadequado para conversas ao vivo. O Ink-Whisper analisa o fluxo de áudio em busca de pontos de interrupção semanticamente significativos, como pausas e respirações, e processa blocos mais curtos à medida que se formam. O endpoint é um WebSocket de streaming que aceita quadros de áudio PCM a 16 kHz e emite transcrições provisórias e finais à medida que o modelo as confirma. A codificação de áudio padrão é pcm_s16le a 16000 Hz.

A Cartesia desconecta as conexões WebSocket após 3 minutos de inatividade. O tempo limite é redefinido a cada quadro enviado em qualquer direção. Os clientes geralmente executam keepalives baseados em silêncio para manter a conexão aberta durante as lacunas de fala.

A superfície de integração

Adicionar a Cartesia ao TrueFoundry AI Gateway envolve três etapas no painel. Navegue até AI Gateway, depois para Modelos e selecione Cartesia. Adicione uma conta Cartesia inserindo um nome de conta exclusivo e a chave de API da Cartesia. A chave é armazenada criptografada no plano de controle e nunca é exposta diretamente aos pods do gateway. Opcionalmente, adicione colaboradores, o que controla quais usuários e equipes podem rotear tráfego através desta conta. Em seguida, registre um ou mais modelos clicando em Adicionar Modelo e fornecendo um Nome de exibição, um ID de Modelo e um Tipo de Modelo. Para a Cartesia, o ID do Modelo e o Nome de exibição devem ser idênticos e devem corresponder exatamente ao identificador do modelo Cartesia (sonic-3 e sonic-3-2026-01-12 e ink-whisper e assim por diante).

A superfície de configuração para uma conta Cartesia é simples.

A inferência usa o SDK nativo da Cartesia com a URL do gateway substituída como a URL base. Um cliente Python se parece com o seguinte.

import os
from cartesia import Cartesia

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

response = client.tts.bytes(
    model_id="sonic-3",
    transcript="The road goes ever on and on.",
    voice={"mode": "id", "id": "6ccbfb76-1fc6-48f7-b71d-91ac6298247b"},
    output_format={"container": "wav", "encoding": "pcm_f32le", "sample_rate": 44100},
)

As mesmas chamadas do SDK funcionam para o endpoint WebSocket e para o WebSocket STT Ink-Whisper. O JWT emitido pela TrueFoundry substitui a chave de API da Cartesia na configuração do SDK. O SDK acredita estar se comunicando diretamente com a Cartesia porque o gateway preserva os caminhos da URL e os formatos de resposta. Custo, controle de acesso e rastreamento ocorrem invisivelmente no caminho da requisição.

Resumo da arquitetura

O fluxo de dados de ponta a ponta é direto. Um cliente abre uma requisição HTTP ou um WebSocket contra a URL do gateway usando o SDK da Cartesia. O pod do gateway autentica o JWT contra chaves públicas IdP em cache e resolve o identificador do modelo para a conta Cartesia configurada. Ele remove o cabeçalho de autenticação de entrada e substitui pela chave de API da Cartesia do armazenamento de credenciais. Ele encaminha a requisição ou atualiza o WebSocket para https://api.cartesia.ai. Para sessões WebSocket, ele faz a ponte dos quadros em ambas as direções até que um dos lados feche a conexão. Após a conclusão da requisição, o gateway publica um span no NATS, que alimenta o exportador OTEL e o agregador de custos.

O que não é necessário é notável. Não há um fork do SDK da Cartesia. Não há uma camada de tradução oculta que achata os parâmetros TTS para o formato de Áudio OpenAI e perde o ID de voz e o modelo de contexto de streaming no processo. Não há um pipeline de rastreamento separado para tráfego de voz e outro para tráfego de chat. Não há uma chave de API por serviço distribuída pelo código da aplicação. Não há um terminador WebSocket do lado do cliente que precise ser implantado separadamente para aplicar controle de acesso aos endpoints de streaming.

O princípio arquitetônico que faz isso funcionar é a separação entre a semântica do protocolo e a semântica da governança. O protocolo Cartesia carrega um significado de domínio de voz que não se generaliza facilmente para outros provedores. A camada de governança (autenticação, autorização, injeção de credenciais, observabilidade e rastreamento de custos) é agnóstica ao provedor e pode ser executada na frente de qualquer origem HTTP ou WebSocket sem inspecionar o payload. O passthrough nativo preserva o primeiro enquanto aplica o segundo. O resultado é que a superfície completa de recursos da Cartesia (contextos e continuações do Sonic-3, controles de emoção e o fluxo de transcrição de streaming do Ink-Whisper) está disponível para os clientes, enquanto as garantias operacionais que o restante do AI Gateway oferece para o tráfego de chat se aplicam ao tráfego de voz nos mesmos pods de gateway, com o mesmo plano de controle e os mesmos backends de rastreamento e custo.