Cartesia et TrueFoundry AI Gateway : passerelle native pour l'inférence vocale

Le modèle de synthèse vocale Sonic-3 de Cartesia et le modèle de diffusion de voix en texte Ink-Whisper s'intègrent à TrueFoundry AI Gateway via une surface de transmission native. Les demandes sont transmises à Cartesia /tts/octets point de terminaison HTTP et /tts/se flux d'événements envoyés par le serveur et /tts/websocket WebSocket bidirectionnel et le WebSocket de streaming Ink avec la sémantique de leur protocole d'origine intacte. La passerelle injecte la clé API Cartesia depuis son magasin d'informations d'identification central, gère le contrôle d'accès et émet des spans OpenTelemetry avant de transférer la connexion.

Cet article explique pourquoi les fournisseurs d'inférence vocale ne peuvent pas utiliser le même modèle de traduction compatible avec OpenAI que celui que la passerelle applique aux fournisseurs de complétion de chat. Il explique comment le plan de passerelle gère le relais natif dans le pipeline de requêtes Hono existant. Il couvre la surface API de Cartesia à la fois en TTS et en STT. Il couvre la forme de configuration et le flux de données de bout en bout.

Pourquoi les fournisseurs de services vocaux n'utilisent pas le chemin de traduction OpenAI

La plupart des intégrations de TrueFoundry AI Gateway fonctionnent selon le principe de la traduction. Une demande arrive au format compatible OpenAI le /chat/complétions ou /intégrations ou /réponses. La passerelle transmet l'identifiant du modèle à un point de terminaison du fournisseur et traduit la demande dans la forme native de ce fournisseur via un adaptateur. Anthropic est traduit vers l'API Messages. Google Vertex est traduit vers l'API Generative Language. Cohere est traduit dans son schéma de chat natif. La réponse revient et est traduite en sens inverse, de sorte que l'appelant voit une forme OpenAI uniforme, quel que soit le fournisseur physique qui a traité la demande.

Ce modèle fonctionne car la sémantique de complétion des discussions est à peu près équivalente d'un fournisseur à l'autre. Il existe une liste de messages, un identifiant de modèle et des paramètres d'échantillonnage, un indicateur de diffusion et une réponse avec les appels à l'outil et les raisons de fin. Les différences sont réelles mais limitées et peuvent être conciliées à l'aide d'un adaptateur.

L'inférence vocale ne correspond pas à ce modèle. L'API TTS de Cartesia possède des paramètres qui n'ont pas d'équivalent dans l'API OpenAI Audio. Le voix Ce champ accepte un identifiant vocal Cartesia ou une intégration vocale. Le format_de sortie block spécifie le conteneur, le codage et la fréquence d'échantillonnage en tant qu'objet structuré. Le langue Ce champ permet de sélectionner l'une des 42 langues prises en charge. Le __contrôles_expérimentaux Le bloc contient des paramètres de vitesse et d'émotion qui correspondent aux commandes expressives de Sonic-3. Le protocole WebSocket introduit des contextes multiplexés et identifiant Flush limites et sémantique de continuation pour la diffusion en continu de texte saisi à partir d'un LLM en amont. Rien de tout cela n'existe dans OpenAI /v1/audio/discours forme.

Le chemin Ink-Whisper STT est similaire. Le protocole WebSocket de streaming transmet des trames audio en temps réel et émet des transcriptions intermédiaires et des transcriptions finales lorsque le modèle effectue un découpage dynamique sur des limites sémantiquement significatives. L'OpenAI /v1/audio/transcriptions endpoint est un téléchargement de fichier de réponse à une demande sans équivalent en streaming dans la spécification officielle.

La traduction de cette surface réduirait la capacité ou introduirait des mappages avec perte. La passerelle expose donc Cartesia via un relais natif. L'appelant continue d'utiliser le SDK Python officiel de Cartesia ou tout autre client Cartesia doté de ses fonctionnalités complètes. La passerelle se trouve sur le chemin en tant que limite d'identification, de politique et d'observabilité plutôt que comme un traducteur de protocole.

Comment fonctionne le passthrough natif à l'intérieur du plan de la passerelle

La passerelle TrueFoundry AI est basée sur le framework Hono. Un seul module de passerelle sur 1 processeur virtuel et 1 Go de RAM gère plus de 250 RPS avec une latence supplémentaire d'environ 3 ms. Les pods sont sans état, liés au processeur et s'adaptent horizontalement à des dizaines de milliers de RPS. Le plan de passerelle et le plan de contrôle sont séparés. Le plan de contrôle gère la configuration dans PostgreSQL et ClickHouse et propage les mises à jour via NATS. Les modules Gateway mettent cette configuration en cache en mémoire.

Lorsqu'une requête Cartesia atteint un module de passerelle, le même pipeline de pré-transfert s'exécute que celui qui s'exécute pour terminer le chat. Le JWT présenté sur la demande est validé par rapport aux clés publiques IdP mises en cache sans appel d'authentification externe. L'autorisation est vérifiée par rapport à la carte en mémoire des utilisateurs par rapport aux modèles que le NATS maintient synchronisés. La couche de routage résout l'identifiant du modèle (tel que sonic-3 ou chuchotement d'encre) au terminal du fournisseur configuré pour ce modèle et aux informations d'identification du compte Cartesia stockées dans le plan de contrôle. Le corps de la demande, le chemin et les paramètres de requête ne sont pas réécrits. Seul le Autorisation et Clé X-API les en-têtes sont supprimés de la demande entrante et remplacés par la clé API Cartesia provenant du magasin d'informations d'identification sécurisé. L'URL transférée devient l'origine de Cartesia (https://api.cartesia.ai/...) avec le chemin et la méthode correspondants préservés. Le corps est traversé inchangé.

Pour les points de terminaison WebSocket (ws : //api.cartesia.ai/tts/websocket et le point de terminaison Ink Streaming), la passerelle effectue une poignée de main HTTP Upgrade. Une fois la mise à niveau réussie, la passerelle contient deux connexions WebSocket (une avec le client et une avec Cartesia) et des trames proxy dans les deux sens. Le modèle de contexte multiplexé exposé par Cartesia est préservé car la passerelle n'interprète pas les charges utiles des trames. Un client qui ouvre un seul WebSocket et exécute des dizaines de générations simultanées sur différents identifiant_contexte values voit le même comportement via la passerelle qu'il s'adresserait directement à Cartesia.

Le chemin de publication de traces asynchrone que la passerelle utilise pour terminer les discussions s'exécute également pour le trafic Cartesia. La passerelle émet des spans pour le gestionnaire HTTP entrant, la résolution des informations d'identification et l'appel au fournisseur sortant (ou session WebSocket). Pour les requêtes TTS, ces intervalles comportent la durée et le statut, ainsi que le nom du modèle résolu et un hachage de la transcription. Pour les sessions STT, le span capture la durée de vie de la connexion et le nombre de messages. Les spans sont publiées de manière asynchrone sur NATS une fois la demande terminée. L'exportateur OpenTelemetry lit le chemin asynchrone et transmet les traces au backend configuré (gRPC ou HTTP). L'exportation est additive et ne modifie pas le stockage des traces de la passerelle. La passerelle ne fait jamais échouer une requête Cartesia, même si le point de terminaison externe de l'OTEL est inaccessible.

Le pipeline de suivi des coûts fonctionne également en mode relais. Cartesia facture des crédits qui se traduisent par des caractères synthétisés pour TTS et des secondes transcrites pour STT. La passerelle enregistre les métadonnées relatives à la taille de la demande et à la durée de réponse et les publie sur le même bus d'événements NATS qui regroupe les données sur les coûts d'achèvement du chat. Le service d'agrégation calcule les cumuls par utilisateur, par équipe et par modèle qui apparaissent dans la vue analytique unifiée à côté du trafic de discussion.

Ce que Cartesia expose

Cartesia construit des modèles vocaux sur une architecture de modèle spatial d'états. La famille TTS s'appelle Sonic et le modèle de production actuel est Sonic-3. La famille STT s'appelle Ink et le modèle de production actuel est Ink-Whisper.

Sonic 3 est un modèle TTS en streaming dont le temps publié jusqu'au premier son est d'environ 90 ms. Il prend en charge 42 langues. Il propose des contrôles précis du volume, de la vitesse et des émotions grâce à des paramètres d'API et à des balises SSML. Il favorise le rire grâce à [Rires] balises en ligne. Le modèle est présenté à travers trois formes d'extrémité adaptées à différents cas d'utilisation.

Le premier est POST /tts/octets. Il s'agit d'un point de terminaison de lot synchrone qui renvoie l'intégralité du fichier audio dans le corps de la réponse. Il accepte les formats de sortie MP3, WAV ou PCM bruts et convient à la pré-génération de ressources audio lorsque la latence totale liée à l'attente de la sortie complète est acceptable.

Le second est POST/tts/sse. Il s'agit d'un flux d'événements envoyé par le serveur. Le modèle émet des segments audio au fur et à mesure de leur génération. Cela convient aux applications qui diffusent le son de manière progressive et qui ont besoin de l'avantage du temps nécessaire pour atteindre le premier octet, mais qui n'ont pas besoin de diffuser le texte d'entrée dans le modèle.

Le troisième est WSS /tts/websocket. Il s'agit du point de terminaison recommandé pour les agents vocaux en temps réel. La connexion est bidirectionnelle et prend en charge les générations multiplexées via identifiant_contexte champ. Un seul WebSocket ouvert peut contenir des dizaines de générations simultanées. Le identifiant_contexte permet la génération de suites où des segments de texte supplémentaires peuvent être insérés dans un contexte existant afin de maintenir la prosodie entre les jointures. Cela est important lorsque la source de texte en amont est un flux LLM jeton par jeton et que le TTS doit suivre la cadence de génération du texte. Le protocole WebSocket prend également en charge le vidage manuel identifiant Flush des marqueurs qui créent des limites audio discrètes au sein d'un même contexte.

Ink-Whisper est un modèle STT de streaming dérivé de Whisper-Large-V3-Turbo et repensé pour une utilisation conversationnelle en temps réel. La métrique déterminante est le temps nécessaire pour terminer la transcription, qui mesure la rapidité avec laquelle la transcription précise finale est prête une fois que l'utilisateur a cessé de parler. Ink-Whisper y parvient grâce au découpage dynamique. Le Whisper standard fonctionne mieux sur des buffers audio fixes de 30 secondes et introduit ainsi un plancher de latence fondamental qui n'est pas adapté aux conversations en direct. Ink-Whisper analyse le flux audio à la recherche de points de rupture sémantiquement significatifs, tels que les pauses et les respirations, et traite les segments plus courts au fur et à mesure de leur formation. Le point de terminaison est un WebSocket de streaming qui accepte les trames audio PCM à 16 kHz et émet des transcriptions intermédiaires et finales au fur et à mesure que le modèle les accepte. L'encodage audio par défaut est pcm_s16le à 16 000 Hz.

Cartesia déconnecte les connexions WebSocket après 3 minutes d'inactivité. Le délai d'attente est réinitialisé à chaque fois que chaque trame est envoyée dans les deux sens. Les clients utilisent généralement des méthodes de mémorisation basées sur le silence pour maintenir la connexion ouverte malgré les interstices d'énonciation.

La surface d'intégration

L'ajout de Cartesia à TrueFoundry AI Gateway se fait en trois étapes sur le tableau de bord. Accédez à AI Gateway, puis à Modèles et sélectionnez Cartesia. Ajoutez un compte Cartesia en saisissant un nom de compte unique et la clé API Cartesia. La clé est stockée de manière cryptée dans le plan de contrôle et n'est jamais exposée directement aux modules de la passerelle. Ajoutez éventuellement des collaborateurs qui contrôlent quels utilisateurs et quelles équipes peuvent acheminer le trafic via ce compte. Enregistrez ensuite un ou plusieurs modèles en cliquant sur Ajouter un modèle et en fournissant un nom d'affichage, un ID de modèle et un type de modèle. Pour Cartesia, l'ID du modèle et le nom d'affichage doivent être identiques et doivent correspondre exactement à l'identifiant du modèle Cartesia (sonic-3 et sonic-3-2026-01-12 et chuchotement d'encre et ainsi de suite).

La surface de configuration d'un compte Cartesia est petite.

FieldValueAccount NameIdentifiant unique limité à la clé d'API WorkspaceClé d'API Cartesia issue du Cartesia DashboardCollaborators/Utilisateurs et équipes autorisés à effectuer un routage via ce compte

La surface de configuration d'un modèle Cartesia est tout aussi petite.

FieldValueDisplay NameDoit être égal à Model ID/Model ID/Identifiant du modèle Cartesia (par exemple) sonic-3 ou chuchotement d'encre) Type de modèleSélectionné parmi les types de modèles vocaux pris en charge

L'inférence utilise le SDK natif Cartesia avec l'URL de la passerelle remplacée comme URL de base. Un client Python ressemble à ce qui suit.

système d'importation
de cartesia import Cartesia

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

réponse = client.tts.bytes (
model_id="sonic-3",
Transcript="La route continue encore et encore. «,
voice= {"mode » : « identifiant », « identifiant » : « 6ccbfb76-1fc6-48f7-b71d-91ac6298247b"},
output_format= {"container » : « wav », « encoding » : « pcm_f32le », « sample_rate » : 44100},
)


Les mêmes appels au SDK fonctionnent pour le point de terminaison WebSocket et pour le WebSocket Ink-Whisper STT. Le JWT publié par TrueFoundry remplace la clé API Cartesia dans la configuration du SDK. Le SDK pense qu'il communique directement avec Cartesia car la passerelle préserve les chemins d'URL et les formes de réponse. Le contrôle des coûts et des accès et le traçage se font tous de manière invisible dans le chemin de la demande.

Résumé de l'architecture

Le flux de données de bout en bout est simple. Un client ouvre une requête HTTP ou un WebSocket sur l'URL de la passerelle à l'aide du SDK Cartesia. Le pod de passerelle authentifie le JWT par rapport aux clés publiques IdP mises en cache et résout l'identifiant du modèle en fonction du compte Cartesia configuré. Il supprime l'en-tête d'authentification entrant et remplace la clé API Cartesia du magasin d'informations d'identification. Il transmet la demande ou met à niveau le WebSocket vers https://api.cartesia.ai. Pour les sessions WebSocket, il relie les trames dans les deux sens jusqu'à ce que l'un des côtés ferme la connexion. Une fois la demande terminée, la passerelle publie un span dans NATS qui alimente l'exportateur OTEL et l'agrégateur de coûts.

Ce qui n'est pas obligatoire est significatif. Il n'existe pas de fork du SDK Cartesia. Aucune couche de traduction fictive n'aplatit les paramètres TTS dans la forme d'OpenAI Audio et perd l'identifiant vocal et le modèle de contexte de streaming au cours du processus. Il n'existe pas de pipeline de traçage distinct pour le trafic vocal et un autre pour le trafic de chat. Aucune clé d'API par service n'est distribuée dans le code de l'application. Aucun terminateur WebSocket côté client ne doit être déployé séparément pour appliquer le contrôle d'accès aux points de terminaison de streaming.

Le principe architectural qui sous-tend ce travail est la séparation entre la sémantique des protocoles et la sémantique de la gouvernance. Le protocole Cartesia comporte une signification de domaine vocal qui ne se généralise pas clairement aux autres fournisseurs. La couche de gouvernance (authentification et autorisation, injection d'informations d'identification, observabilité et suivi des coûts) est indépendante du fournisseur et peut s'exécuter devant n'importe quelle origine HTTP ou WebSocket sans inspecter la charge utile. Le passthrough natif préserve le premier lors de l'application du second. Le résultat est que la surface fonctionnelle complète de Cartesia (les contextes, les continuations et les contrôles des émotions de Sonic-3 et le flux de transcription en continu d'Ink-Whisper) est disponible pour les clients tandis que les garanties opérationnelles que le reste de la passerelle AI fournit pour le trafic de discussion s'appliquent au trafic vocal sur les mêmes pods de passerelle avec le même plan de contrôle et les mêmes backends de trace et de coût.

‍