Smallest AI und TrueFoundry AI Gateway

Die Text-zu-Sprache- und Sprache-zu-Text-Modelle von Smallest AI integrieren sich über natives Passthrough in das TrueFoundry AI Gateway. Anfragen fließen zu den REST-Endpunkten von Smallest AI für Batch-Synthese und -Transkription sowie zu den entsprechenden Server-Sent-Event-Streams und WebSocket-Endpunkten für segmentierte Audioausgabe und Live-Transkription. Das Gateway ersetzt den Smallest AI Bearer Token aus seinem Anmeldeinformationsspeicher, wendet Zugriffskontrolle an und sendet OpenTelemetry-Spans aus, bevor es die Anfrage weiterleitet oder den WebSocket aktualisiert.

Dieser Beitrag behandelt die Smallest AI API-Oberfläche der TTS- und STT-Familien. Er behandelt auch, wie die Gateway-Ebene den nativen Passthrough-Pfad für nicht OpenAI-kompatible Sprach-Endpunkte handhabt.

Was Smallest AI bereitstellt

Smallest AI bietet zwei Modellfamilien an. Lightning ist die Text-zu-Sprache-Familie. Pulse ist die Sprache-zu-Text-Familie. Beide laufen als REST-Endpunkte für die Batch-Nutzung und als WebSocket-Endpunkte für die Streaming-Nutzung.

Lightning v3.1 ist ein 44-kHz-TTS-Modell mit einer veröffentlichten Zeit bis zum ersten Audio unter 100 ms. Es unterstützt 15 Sprachen mit starker indischer Abdeckung, darunter Hindi, Tamil, Telugu, Malayalam, Kannada, Marathi und Gujarati, sowie Englisch, Spanisch, Französisch, Deutsch, Italienisch, Portugiesisch, Schwedisch und Niederländisch. Das Modell verwendet eine nicht-autoregressive Architektur, die ganze Sprachsegmente parallel generiert, anstatt Token für Token. Dies ist es, was das Latenzprofil erzeugt und was es dem Modell ermöglicht, mit weniger als 1 GB VRAM zu laufen, was den On-Premise-Einsatz in regulierten Umgebungen praktikabel macht.

Das Modell wird über drei Endpunktformen bereitgestellt.

1. POST https://waves/v1/lightning-v3.1/get_speech. 
   
   1. Dies ist ein synchroner Batch-Endpunkt, der die vollständige Audiodatei im Antworttext zurückgibt. Er akzeptiert MP3-, PCM-, WAV-, Mulaw- oder Alaw-Ausgabeformate und unterstützt Abtastraten von 8000 Hz bis 44100 Hz. 
   2. Er akzeptiert einen voice_id-Parameter und einen Geschwindigkeitsparameter zwischen 0,5x und 2x sowie ein optionales pronunciation_dicts-Array für benutzerdefinierte Lexikon-Überschreibungen. 
   3. Es unterstützt auch session_id- und request_id-Korrelationsidentifikatoren, die in den Antwort-Headern als X-External-Session-Id und X-External-Request-Id zurückgegeben werden. Diese werden unverändert durch das Gateway geleitet, was für die End-to-End-Trace-Korrelation nützlich ist.
2. POST https://waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Dies ist der Server-Sent-Events-Stream, der Audio-Chunks progressiv ausgibt, während das Modell sie generiert.
3. WSS /waves/v1/lightning-v3.1/get_speech/stream. 
   
   1. Dies ist die persistente WebSocket-Verbindung, die Audio-Chunks liefert, sobald sie erzeugt werden. 
   2. Die Verbindung ist über mehrere TTS-Anfragen hinweg wiederverwendbar, sodass die Kosten für den Verbindungsaufbau amortisiert werden. 

Pulse ist das STT-Gegenstück. Es läuft in zwei Formen. POST /waves/v1/pulse/get_text verarbeitet vorab aufgezeichnetes Audio im Batch-Verfahren. WSS /waves/v1/pulse/get_text verarbeitet Live-Streaming-Transkription. Der Streaming-Endpunkt akzeptiert Audio-Frames mit 8000, 16000, 22050, 24000, 44100 oder 48000 Hz, wobei linear16 die Standardkodierung ist. Es unterstützt 36 Sprachen mit Code-Switching, das über language=multi aktiviert wird.

Die interessanten Aspekte des Pulse-Streaming-Protokolls für eine Integration hinter einem Gateway sind die Inline-Inhaltskontrollen. redact_pii=true entfernt personenbezogene Daten aus finalisierten Transkripten, bevor sie Smallest AI verlassen. redact_pci=true entfernt Zahlungsinformationen wie Kartennummern, CVV-Codes, Postleitzahlen und Kontonummern. diarize=true ermöglicht die Sprechererkennung (Diarisierung). keywords akzeptiert eine kommagetrennte Liste von Phrasen mit optionalen Intensivierungswerten, um die Erkennung domänenspezifischer Terminologie wie Produkt- oder Medikamentennamen zu verbessern. itn_normalize=true aktiviert die Inverse Textnormalisierung, die gesprochene Zahlen, Daten und Währungen in finalisierten Transkripten in ihre schriftliche Form umwandelt. Die Redaktionsparameter sind wichtig, da sie die Durchsetzung des Datenschutzes in die Modellebene verlagern, anstatt eine nachgeschaltete Schutzfunktion zu erfordern, die das Transkript nachträglich bereinigt.

Parallelitätsmodell. Smallest AI bietet eine ungewöhnliche Parallelitätsoberfläche, die es wert ist, verstanden zu werden, bevor man darauf aufbaut. Eine Parallelitätseinheit entspricht einer aktiven TTS-Anfrage, die zu einem bestimmten Zeitpunkt verarbeitet werden kann. Pro Parallelitätseinheit können bis zu drei WebSocket-Verbindungen für TTS hergestellt werden. Ein Mandant mit drei Parallelitätseinheiten kann also neun WebSocket-Verbindungen offen halten, aber nur drei davon können gleichzeitig eine aktive Generierung in Bearbeitung haben. Zusätzliche Anfragen, die über eine beliebige Verbindung gesendet werden, während das Parallelitätslimit erreicht ist, werden mit einem Fehler abgewiesen, anstatt in die Warteschlange gestellt zu werden. Dies unterscheidet sich vom typischen Token-pro-Minute- oder Anfrage-pro-Minute-Modell und hat Auswirkungen darauf, wie der Ratenbegrenzer des Gateways konfiguriert werden sollte. Für STT ist eine Parallelitätseinheit eine WebSocket-Verbindung.

Natives Passthrough über die Gateway-Ebene

Das TrueFoundry AI Gateway basiert auf dem Hono-Framework und läuft als Flotte zustandsloser Pods. Ein einzelner Pod mit 1 vCPU und 1 GB RAM verarbeitet über 250 RPS mit einer zusätzlichen Latenz von etwa 3 ms. Die Steuerungsebene verwaltet die Konfiguration in PostgreSQL und ClickHouse und verbreitet Updates über NATS an die Gateway-Pods. Gateway-Pods cachen diese Konfiguration im Speicher, sodass der Anforderungspfad keine externen Aufrufe für Authentifizierung, Autorisierung oder Routing-Entscheidungen tätigt.

Für OpenAI-kompatible Anbieter übersetzt das Gateway das eingehende OpenAI-Format und das native Format des Anbieters innerhalb eines Adapters. Smallest AI passt nicht zu dieser Übersetzung, da die OpenAI Audio API keine Entsprechung für die Parameter voice_id, pronunciation_dicts und session_id von Smallest AI hat und auch keine Entsprechung für das WebSocket-Streaming-Protokoll, das die segmentierte Audioausgabe von Lightning liefert. Das Gateway stellt Smallest AI daher über natives Passthrough bereit.

Wenn eine Smallest AI-Anfrage einen Gateway-Pod erreicht, führt die Vorwärtsleitung dieselben Prüfungen durch, die auch für Chat-Vervollständigungen ausgeführt werden. Das in der Anfrage präsentierte JWT wird anhand von gecachten öffentlichen IdP-Schlüsseln validiert, ohne einen externen Authentifizierungsaufruf zu tätigen. Die Autorisierung wird anhand der In-Memory-Zuordnung von Benutzern zu Modellen überprüft. Der Modell-Identifikator (lightning-v3.1 oder pulse) wird dem konfigurierten Smallest AI-Konto zugeordnet. Der eingehende Authorization-Header wird entfernt und durch das aus dem Anmeldeinformationsspeicher abgerufene Bearer-Token ersetzt. Die weitergeleitete URL wird zu https://api.smallest.ai/... wobei der passende Pfad und die Methode beibehalten werden. Der Body wird unverändert durchgestreamt. Für die WebSocket-Endpunkte führt das Gateway einen HTTP-Upgrade-Handshake mit der Smallest AI WebSocket-URL durch. Nach erfolgreichem Upgrade hält das Gateway zwei WebSocket-Verbindungen (eine mit dem Client und eine mit Smallest AI) und leitet Frames in beide Richtungen weiter, ohne die Payloads zu interpretieren. Die Echo-Header X-External-Session-Id und X-External-Request-Id werden unverändert an den Aufrufer weitergeleitet.

Nach Abschluss der Anfrage veröffentlicht das Gateway einen Span an NATS, der Dauer, Status, den aufgelösten Modellnamen und die Kostenmetadaten enthält. Der OTEL-Exporter liest vom asynchronen Pfad und leitet den Span über gRPC oder HTTP an das konfigurierte Backend weiter. Der Aggregator-Dienst fasst Kostendaten pro Benutzer, pro Team und pro Modell zusammen.

Die Integrationsschnittstelle

Das Hinzufügen von Smallest AI zum TrueFoundry AI Gateway erfolgt in drei Schritten im Dashboard. Navigieren Sie zu AI Gateway, dann zu Modelle und wählen Sie Smallest AI aus. Fügen Sie ein Konto hinzu, indem Sie einen eindeutigen Kontonamen und das Smallest AI Bearer-Token eingeben. Das Token wird verschlüsselt in der Steuerungsebene gespeichert und niemals direkt den Gateway-Pods zugänglich gemacht. Fügen Sie optional Kollaboratoren hinzu, um zu steuern, welche Benutzer und Teams über dieses Konto routen können. Registrieren Sie dann ein oder mehrere Modelle, indem Sie auf Modell hinzufügen klicken und den Anzeigenamen, die Modell-ID und den Modelltyp angeben. Die Modell-ID muss exakt mit dem Smallest AI Modell-Identifikator übereinstimmen (lightning-v3.1 oder lightning-v2 oder pulse).

Die Inferenz verwendet das Smallest AI Python SDK oder einen beliebigen HTTP-Client, wobei die Gateway-URL als Basis-URL eingesetzt wird. Ein Python-Client sieht wie folgt aus.

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)

Dieselbe Form funktioniert für den SSE-Endpunkt, indem der Pfad geändert und die Antwort als Stream gelesen wird. Der WebSocket-Endpunkt funktioniert über jeden Standard-WebSocket-Client, indem er auf die Gateway-URL mit dem wss-Schema zeigt. Das von TrueFoundry ausgestellte JWT ersetzt das Smallest AI Bearer-Token im Authorization-Header. Der Smallest AI-Client sieht dieselbe Antwort-Payload und dieselben Header, die er auch bei direkter Kommunikation mit Smallest AI sehen würde, da das Gateway die URL-Pfade und die Antwortstrukturen, einschließlich der Korrelations-Header X-External-Session-Id und X-External-Request-Id, beibehält.

Architekturzusammenfassung

Der End-to-End-Datenfluss ist unkompliziert. Ein Client öffnet eine HTTP-Anfrage oder einen WebSocket gegen die Gateway-URL, entweder mit dem Smallest AI Python SDK oder einem generischen HTTP- und WebSocket-Client. Der Gateway-Pod authentifiziert das JWT anhand von gecachten öffentlichen IdP-Schlüsseln und ordnet den Modell-Identifikator dem konfigurierten Smallest AI-Konto zu. Er entfernt den eingehenden Authentifizierungs-Header und ersetzt ihn durch das Bearer-Token aus dem Anmeldeinformationsspeicher. Er leitet die Anfrage an https://api.smallest.ai weiter oder aktualisiert den WebSocket auf die entsprechende wss://-URL. Für WebSocket-Sitzungen überbrückt er Frames in beide Richtungen, bis eine der beiden Seiten die Verbindung schließt. Nach Abschluss veröffentlicht das Gateway einen Span an NATS, der den OTEL-Exporter und den Kostenaggregator speist.

Was nicht benötigt wird, ist bemerkenswert. Es gibt keinen Fork des Smallest AI SDK. Es gibt keine Übersetzungsschicht zwischen dem OpenAI Audio-Format und den Parametern voice_id und pronunciation_dicts von Smallest AI, die an der Schnittstelle Informationen verlieren würde. Es gibt keine separate Shadow-Tracing-Pipeline für Sprachverkehr, die von der Chat-Verkehrs-Pipeline getrennt ist. Es gibt kein pro Dienst verteiltes Bearer-Token im Anwendungscode oder in Kubernetes-Secrets. Es gibt keinen separaten WebSocket-Terminator, der neben dem Gateway bereitgestellt werden muss, um die Zugriffskontrolle auf die Streaming-Endpunkte anzuwenden. Die Pulse PII- und PCI-Redaktionsparameter durchlaufen das Gateway unberührt, wodurch die Durchsetzung des Datenschutzes auf der Modellebene verbleibt, wo die Redaktionspipeline von Smallest AI läuft, anstatt sie über eine nachgeschaltete Schutzfunktion zu fragmentieren.

Das architektonische Prinzip ist die Trennung zwischen Protokollsemantik und Governance-Semantik. Lightnings segmentiertes Audio-Streaming und Pulses Streaming-Transkription mit Inline-Redaktion tragen eine Sprachdomänenbedeutung, die nicht auf andere Anbieter verallgemeinerbar ist. Die Governance-Schicht (Authentifizierung, Autorisierung, Credential-Injektion, Observability, Kostenkonsolidierung und Ratenbegrenzung an der Teamgrenze) ist anbieterunabhängig und läuft vor jedem HTTP- oder WebSocket-Ursprung, ohne Payloads zu inspizieren. Natives Passthrough bewahrt Ersteres, während es Letzteres anwendet. Das Ergebnis ist, dass die gesamte Funktionspalette von Smallest AI (Lightnings Abdeckung von 15 Sprachen und die indischen Stimmen sowie Pulses PCI-Redaktion und das explizite Parallelitätsmodell) den Clients zur Verfügung steht, während die operativen Garantien, die der Rest des AI Gateways für Chat-Verkehr bietet, auch für Sprachverkehr auf denselben Gateway-Pods mit derselben Steuerungsebene und denselben Trace- und Kosten-Backends gelten.