Smallest AI et TrueFoundry AI Gateway

Les modèles de synthèse vocale et de reconnaissance vocale de Smallest AI s'intègrent à TrueFoundry AI Gateway via un passthrough natif. Les requêtes sont acheminées vers les points de terminaison REST de Smallest AI pour la synthèse et la transcription par lots, ainsi que vers les flux d'événements envoyés par le serveur et les points de terminaison WebSocket correspondants pour la sortie audio par blocs et la transcription en direct. La passerelle substitue le jeton Bearer de Smallest AI depuis son magasin d'informations d'identification, applique le contrôle d'accès et émet des spans OpenTelemetry avant de proxifier la requête ou de mettre à niveau le WebSocket.

Cet article couvre la surface d'API de Smallest AI pour les familles TTS et STT. Il explique également comment le plan de la passerelle gère le chemin de passthrough natif pour les points de terminaison vocaux non compatibles OpenAI.

Ce que Smallest AI expose

Smallest AI propose deux familles de modèles. Lightning est la famille de modèles de synthèse vocale. Pulse est la famille de modèles de reconnaissance vocale. Les deux fonctionnent comme des points de terminaison REST pour une utilisation par lots et comme des points de terminaison WebSocket pour une utilisation en streaming.

Lightning v3.1 est un modèle TTS de 44 kHz avec un temps de première audio publié inférieur à 100 ms. Il prend en charge 15 langues avec une forte couverture des langues indiennes, notamment l'hindi, le tamoul, le télougou, le malayalam, le kannada, le marathi et le gujarati, ainsi que l'anglais, l'espagnol, le français, l'allemand, l'italien, le portugais, le suédois et le néerlandais. Le modèle utilise une architecture non autorégressive qui génère des segments de parole entiers en parallèle plutôt que jeton par jeton. C'est ce qui produit le profil de latence et ce qui permet au modèle de fonctionner avec moins de 1 Go de VRAM, rendant le déploiement sur site pratique pour les environnements réglementés.

Le modèle est exposé via trois formes de points de terminaison.

1. POST https://waves/v1/lightning-v3.1/get_speech. 
   
   1. Il s'agit d'un point de terminaison synchrone par lots qui renvoie le fichier audio complet dans le corps de la réponse. Il accepte les formats de sortie MP3, PCM, WAV, mulaw ou alaw et prend en charge des fréquences d'échantillonnage de 8000 Hz à 44100 Hz. 
   2. Il accepte un paramètre voice_id et un paramètre speed entre 0,5x et 2x, ainsi qu'un tableau optionnel pronunciation_dicts pour les remplacements de lexique personnalisés. 
   3. Il prend également en charge les identifiants de corrélation session_id et request_id qui sont renvoyés dans les en-têtes de réponse sous la forme de X-External-Session-Id et X-External-Request-Id. Ceux-ci transitent par la passerelle sans modification, ce qui est utile pour la corrélation de traces de bout en bout.
2. POST https://waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Il s'agit du flux d'événements envoyés par le serveur qui émet des blocs audio progressivement à mesure que le modèle les génère.
3. WSS /waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Il s'agit de la connexion WebSocket persistante qui délivre les blocs audio au fur et à mesure de leur production. 
   2. La connexion est réutilisable pour plusieurs requêtes TTS, de sorte que le coût d'établissement de la connexion est amorti. 

Pulse est l'équivalent STT. Il fonctionne sous deux formes. POST /waves/v1/pulse/get_text gère l'audio préenregistré par lots. WSS /waves/v1/pulse/get_text gère la transcription en streaming en direct. Le point de terminaison de streaming accepte les trames audio à 8000, 16000, 22050, 24000, 44100 ou 48000 Hz avec linear16 comme encodage par défaut. Il prend en charge 36 langues avec la commutation de code activée via language=multi.

Les aspects intéressants du protocole de streaming Pulse pour une intégration située derrière une passerelle sont les contrôles de contenu intégrés. redact_pii=true supprime les informations personnellement identifiables des transcriptions finalisées avant qu'elles ne quittent Smallest AI. redact_pci=true supprime les informations de carte de paiement, y compris les numéros de carte, les codes CVV, les codes postaux et les numéros de compte. diarize=true active la diarisation des locuteurs. keywords accepte une liste de phrases séparées par des virgules avec des valeurs d'intensification optionnelles pour améliorer la reconnaissance de la terminologie spécifique au domaine, comme les noms de produits ou de médicaments. itn_normalize=true active la normalisation inverse du texte qui convertit les chiffres, dates et devises prononcés en leur forme écrite dans les transcriptions finalisées. Les paramètres de rédaction sont importants car ils intègrent l'application de la confidentialité dans la couche du modèle plutôt que de nécessiter une protection en aval pour nettoyer la transcription après coup.

Modèle de concurrence. Smallest AI présente une surface de concurrence inhabituelle qu'il est utile de comprendre avant de l'utiliser. Une unité de concurrence correspond à une requête TTS active qui peut être traitée à un moment donné. Jusqu'à trois connexions WebSocket peuvent être établies par unité de concurrence pour le TTS. Ainsi, un locataire avec trois unités de concurrence peut maintenir neuf connexions WebSocket ouvertes, mais seulement trois d'entre elles peuvent avoir une génération active en cours simultanément. Les requêtes supplémentaires envoyées via une connexion alors que la limite de concurrence est atteinte sont rejetées avec une erreur plutôt que mises en file d'attente. Ceci est différent du modèle typique de jeton par minute ou de requête par minute et a des implications sur la manière dont le limiteur de débit de la passerelle doit être configuré. Pour le STT, une unité de concurrence correspond à une connexion WebSocket.

Passthrough natif via le plan de la passerelle

La passerelle TrueFoundry AI est construite sur le framework Hono et fonctionne comme une flotte de pods sans état. Un seul pod avec 1 vCPU et 1 Go de RAM gère plus de 250 RPS avec environ 3 ms de latence ajoutée. Le plan de contrôle gère la configuration dans PostgreSQL et ClickHouse et propage les mises à jour aux pods de la passerelle via NATS. Les pods de la passerelle mettent en cache cette configuration en mémoire, de sorte que le chemin de la requête n'effectue aucun appel externe pour l'authentification, l'autorisation ou les décisions de routage.

Pour les fournisseurs compatibles OpenAI, la passerelle traduit entre le format OpenAI entrant et le format natif du fournisseur à l'intérieur d'un adaptateur. Smallest AI ne correspond pas à cette traduction car l'API audio OpenAI n'a pas d'équivalent pour les paramètres voice_id, pronunciation_dicts et session_id de Smallest AI, et aucun équivalent pour le protocole de streaming WebSocket qui fournit la sortie audio chunkée de Lightning. La passerelle expose donc Smallest AI via un passthrough natif.

Lorsqu'une requête Smallest AI atteint un pod de passerelle, le pipeline de pré-acheminement exécute les mêmes vérifications que celles effectuées pour les complétions de chat. Le JWT présenté sur la requête 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 aux modèles. L'identifiant du modèle (lightning-v3.1 ou pulse) est résolu vers le compte Smallest AI configuré. L'en-tête d'autorisation entrant est supprimé et remplacé par le jeton Bearer récupéré du magasin de justificatifs. L'URL transmise devient https://api.smallest.ai/... avec le chemin et la méthode correspondants préservés. Le corps est transmis en streaming sans modification. Pour les points de terminaison WebSocket, la passerelle effectue un handshake HTTP Upgrade contre l'URL WebSocket de Smallest AI. Une fois la mise à niveau réussie, la passerelle maintient deux connexions WebSocket (une avec le client et une avec Smallest AI) et proxyfie les trames dans les deux directions sans interpréter les charges utiles. Les en-têtes d'écho X-External-Session-Id et X-External-Request-Id sont transmis intacts à l'appelant.

Une fois la requête terminée, la passerelle publie une trace (span) sur NATS contenant la durée, le statut, le nom du modèle résolu et les métadonnées de coût. L'exportateur OTEL lit depuis le chemin asynchrone et transmet la trace au backend configuré via gRPC ou HTTP. Le service d'agrégation regroupe les données de coût par utilisateur, par équipe et par modèle.

La surface d'intégration

L'ajout de Smallest AI à la passerelle TrueFoundry AI se fait en trois étapes dans le tableau de bord. Accédez à AI Gateway, puis à Modèles et sélectionnez Smallest AI. Ajoutez un compte en saisissant un nom de compte unique et le jeton Bearer de Smallest AI. Le jeton est stocké de manière chiffrée dans le plan de contrôle et n'est jamais exposé directement aux pods de la passerelle. Ajoutez éventuellement des collaborateurs, ce qui contrôle quels utilisateurs et équipes peuvent router via ce compte. Ensuite, enregistrez un ou plusieurs modèles en cliquant sur Ajouter un modèle et en fournissant le nom d'affichage, l'ID du modèle et le type de modèle. L'ID du modèle doit correspondre exactement à l'identifiant du modèle Smallest AI (lightning-v3.1 ou lightning-v2 ou pulse).

L'inférence utilise le SDK Python de Smallest AI ou tout client HTTP avec l'URL de la passerelle substituée comme URL de base. Un client Python se présente comme suit.

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 même forme fonctionne pour le point de terminaison SSE en modifiant le chemin et en lisant la réponse comme un flux. Le point de terminaison WebSocket fonctionne via n'importe quel client WebSocket standard en pointant vers l'URL de la passerelle avec le schéma wss. Le JWT émis par TrueFoundry remplace le jeton Bearer de Smallest AI dans l'en-tête d'autorisation. Le client Smallest AI voit la même charge utile de réponse et les mêmes en-têtes qu'il verrait en parlant directement à Smallest AI, car la passerelle préserve les chemins d'URL et les formes de réponse, y compris les en-têtes de corrélation X-External-Session-Id et X-External-Request-Id.

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 vers l'URL de la passerelle en utilisant soit le SDK Python de Smallest AI, soit un client HTTP et WebSocket générique. Le pod de la passerelle authentifie le JWT par rapport aux clés publiques IdP mises en cache et résout l'identifiant du modèle vers le compte Smallest AI configuré. Il supprime l'en-tête d'authentification entrant et substitue le jeton Bearer du magasin de justificatifs. Il transmet la requête à https://api.smallest.ai ou met à niveau le WebSocket vers l'URL wss:// correspondante. Pour les sessions WebSocket, il relie les trames dans les deux directions jusqu'à ce que l'une ou l'autre partie ferme la connexion. Après achèvement, la passerelle publie une trace (span) sur NATS qui alimente l'exportateur OTEL et l'agrégateur de coûts.

Ce qui n'est pas requis est notable. Il n'y a pas de fork du SDK Smallest AI. Il n'y a pas de couche de traduction entre la forme audio OpenAI et les paramètres voice_id et pronunciation_dicts de Smallest AI qui entraînerait une perte d'informations à la limite. Il n'y a pas de pipeline de traçage fantôme pour le trafic vocal séparé du pipeline de trafic de chat. Il n'y a pas de jeton Bearer par service distribué dans le code de l'application ou les secrets Kubernetes. Il n'y a pas de terminateur WebSocket séparé qui doit être déployé à côté de la passerelle pour appliquer le contrôle d'accès aux points de terminaison de streaming. Les paramètres de rédaction PII et PCI de Pulse traversent la passerelle sans être modifiés, ce qui maintient l'application de la confidentialité au niveau de la couche du modèle où s'exécute le pipeline de rédaction de Smallest AI, plutôt que de la fragmenter à travers une protection en aval.

Le principe architectural est la séparation entre la sémantique du protocole et la sémantique de la gouvernance. Le streaming audio chunké de Lightning et la transcription en streaming de Pulse avec rédaction intégrée portent une signification de domaine vocal qui ne se généralise pas à d'autres fournisseurs. La couche de gouvernance (authentification, autorisation, injection de justificatifs, observabilité, agrégation des coûts et limitation de débit à la limite de l'équipe) est agnostique vis-à-vis du fournisseur et s'exécute devant toute origine HTTP ou WebSocket sans inspecter les charges utiles. Le passthrough natif préserve le premier tout en appliquant le second. Le résultat est que la surface fonctionnelle complète de Smallest AI (la couverture de 15 langues de Lightning, les voix indiennes, la rédaction PCI de Pulse et le modèle de concurrence explicite) est disponible pour les clients, tandis que les garanties opérationnelles que le reste de la passerelle AI fournit pour le trafic de chat 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.