Cartesia und TrueFoundry AI Gateway: Natives Passthrough für Sprachinferenz

Cartesias Sonic-3 Text-to-Speech-Modell und Ink-Whisper Streaming Speech-to-Text-Modell integrieren sich über eine native Passthrough-Schnittstelle in das TrueFoundry AI Gateway. Anfragen fließen an Cartesias /tts/bytes HTTP-Endpunkt, den /tts/sse Server-Sent-Events-Stream, den /tts/websocket bidirektionalen WebSocket und den Ink Streaming WebSocket, wobei ihre ursprüngliche Protokollsemantik intakt bleibt. Das Gateway fügt den Cartesia API-Schlüssel aus seinem zentralen Anmeldeinformationsspeicher ein, führt die Zugriffskontrolle durch und sendet OpenTelemetry-Spans, bevor es die Verbindung weiterleitet.

Dieser Beitrag erklärt, warum Spracherkennungsanbieter nicht dasselbe OpenAI-kompatible Übersetzungsmuster verwenden können, das das Gateway für Chat-Completion-Anbieter anwendet. Er behandelt, wie die Gateway-Ebene natives Passthrough innerhalb der bestehenden Hono-Anfrage-Pipeline handhabt. Er beschreibt die API-Oberfläche von Cartesia für TTS und STT. Er behandelt die Konfigurationsstruktur und den End-to-End-Datenfluss.

‍

Warum Sprachanbieter den OpenAI-Übersetzungspfad nicht nutzen

Die meisten TrueFoundry AI Gateway-Integrationen basieren auf einem Übersetzungsprinzip. Eine Anfrage trifft im OpenAI-kompatiblen Format unter /chat/completions oder /embeddings oder /responses ein. Das Gateway löst den Modell-Identifikator zu einem Anbieter-Endpunkt auf und übersetzt die Anfrage über einen Adapter in das native Format dieses Anbieters. Anthropic wird in die Messages API übersetzt. Google Vertex wird in die Generative Language API übersetzt. Cohere wird in sein natives Chat-Schema übersetzt. Die Antwort kommt zurück und wird umgekehrt übersetzt, sodass der Aufrufer eine einheitliche OpenAI-Struktur sieht, unabhängig davon, welcher physische Anbieter die Anfrage bearbeitet hat.

Dieses Muster funktioniert, weil die Semantik der Chat-Vervollständigung über die Anbieter hinweg weitgehend äquivalent ist. Es gibt eine Liste von Nachrichten, einen Modell-Identifikator, Sampling-Parameter, ein Streaming-Flag und eine Antwort mit Tool-Aufrufen und Abschlussgründen. Die Unterschiede sind real, aber gering und können innerhalb eines Adapters ausgeglichen werden.

Spracherkennung passt nicht in dieses Schema. Cartesias TTS-API verfügt über Parameter, die in der OpenAI Audio API keine Entsprechung haben. Das Feld „voice“ akzeptiert eine Cartesia-Stimmen-ID oder ein Stimmen-Embedding. Der Block „output_format“ spezifiziert Container, Kodierung und Abtastrate als strukturiertes Objekt. Das Feld „language“ wählt zwischen 42 unterstützten Sprachen. Der Block „__experimental_controls“ enthält Geschwindigkeits- und Emotionsparameter, die den Ausdruckssteuerungen von Sonic-3 zugeordnet sind. Das WebSocket-Protokoll führt multiplexierte Kontexte, flush_id-Grenzen und Fortsetzungssemantik für das Streaming von Texteingaben von einem vorgelagerten LLM ein. Nichts davon existiert in der OpenAI /v1/audio/speech-Struktur.

Der Ink-Whisper STT-Pfad ist ähnlich. Das Streaming-WebSocket-Protokoll übermittelt Audio-Frames in Echtzeit und gibt Zwischen- und Endtranskripte aus, während das Modell dynamisches Chunking an semantisch sinnvollen Grenzen durchführt. Der OpenAI /v1/audio/transcriptions-Endpunkt ist ein Request-Response-Datei-Upload ohne Streaming-Gegenstück in der offiziellen Spezifikation.

Eine Übersetzung dieser Oberfläche würde entweder Funktionen verlieren oder verlustbehaftete Zuordnungen einführen. Das Gateway stellt Cartesia daher über natives Passthrough bereit. Der Aufrufer verwendet weiterhin das offizielle Cartesia Python SDK oder einen anderen Cartesia-Client mit seinem vollen Funktionsumfang. Das Gateway fungiert im Pfad als Grenze für Anmeldeinformationen, Richtlinien und Beobachtbarkeit und nicht als Protokollübersetzer.

Wie natives Passthrough innerhalb der Gateway-Ebene funktioniert

Das TrueFoundry AI Gateway basiert auf dem Hono-Framework. Ein einzelner Gateway-Pod mit 1 vCPU und 1 GB RAM verarbeitet über 250 RPS mit einer zusätzlichen Latenz von etwa 3 ms. Pods sind zustandslos und CPU-gebunden und skalieren horizontal auf Zehntausende von RPS. Die Gateway-Ebene und die Steuerungsebene sind getrennt. Die Steuerungsebene verwaltet die Konfiguration in PostgreSQL und ClickHouse und verbreitet Updates über NATS. Gateway-Pods cachen diese Konfiguration im Speicher.

Wenn eine Cartesia-Anfrage einen Gateway-Pod erreicht, läuft dieselbe Vorwärtsleitungs-Pipeline ab, die auch für Chat-Completions läuft. Das in der Anfrage präsentierte JWT wird gegen zwischengespeicherte öffentliche IdP-Schlüssel validiert, ohne externen Authentifizierungsaufruf. Die Autorisierung wird gegen die im Speicher befindliche Zuordnung von Benutzern zu Modellen geprüft, die NATS synchronisiert hält. Die Routing-Schicht löst den Modell-Identifikator (wie sonic-3 oder ink-whisper) zum für dieses Modell konfigurierten Anbieter-Endpunkt und zu den in der Steuerungsebene gespeicherten Cartesia-Kontozugangsdaten auf. Der Anfragetext sowie Pfad- und Abfrageparameter werden nicht umgeschrieben. Lediglich die Header Authorization und X-API-Key werden aus der eingehenden Anfrage entfernt und durch den Cartesia API-Schlüssel aus dem sicheren Anmeldeinformationsspeicher ersetzt. Die weitergeleitete URL wird zum Cartesia-Ursprung (https://api.cartesia.ai/...) mit beibehaltenem passendem Pfad und Methode. Der Body wird unverändert durchgestreamt.

Für die WebSocket-Endpunkte (wss://api.cartesia.ai/tts/websocket und den Ink Streaming-Endpunkt) führt das Gateway einen HTTP-Upgrade-Handshake durch. Nach erfolgreichem Upgrade hält das Gateway zwei WebSocket-Verbindungen (eine mit dem Client und eine mit Cartesia) und leitet Frames in beide Richtungen weiter. Das von Cartesia bereitgestellte multiplexierte Kontextmodell bleibt erhalten, da das Gateway die Frame-Payloads nicht interpretiert. Ein Client, der einen einzelnen WebSocket öffnet und Dutzende gleichzeitiger Generierungen mit verschiedenen context_id-Werten ausführt, sieht über das Gateway dasselbe Verhalten, als würde er direkt mit Cartesia kommunizieren.

Der asynchrone Trace-Veröffentlichungspfad, den das Gateway für Chat-Completions verwendet, läuft auch für Cartesia-Traffic. Das Gateway sendet Spans für den eingehenden HTTP-Handler, die Anmeldeinformationsauflösung und den ausgehenden Anbieteraufruf (oder die WebSocket-Sitzung). Für TTS-Anfragen enthalten diese Spans Dauer und Status, den aufgelösten Modellnamen und einen Hash des Transkripts. Für STT-Sitzungen erfasst der Span die Verbindungslebensdauer und die Nachrichtenanzahl. Spans werden nach Abschluss der Anfrage asynchron an NATS veröffentlicht. Der OpenTelemetry-Exporter liest vom asynchronen Pfad und leitet Traces an das konfigurierte Backend (gRPC oder HTTP) weiter. Der Export ist additiv und ändert den eigenen Trace-Speicher des Gateways nicht. Das Gateway schlägt eine Cartesia-Anfrage niemals fehl, selbst wenn der externe OTEL-Endpunkt unerreichbar ist.

Die Kostenverfolgungspipeline läuft ebenfalls im Passthrough-Modus. Cartesia rechnet nach Credits ab, die sich in synthetisierte Zeichen für TTS und transkribierte Sekunden für STT umrechnen lassen. Das Gateway zeichnet die Metadaten zur Anforderungsgröße und Antwortdauer auf und veröffentlicht diese im selben NATS-Event-Bus, der Chat-Completion-Kostendaten aggregiert. Der Aggregator-Dienst berechnet Rollups pro Benutzer, pro Team und pro Modell, die in der einheitlichen Analyseansicht neben dem Chat-Traffic angezeigt werden.

Was Cartesia bereitstellt

Cartesia entwickelt Sprachmodelle auf einer State-Space-Modellarchitektur. Die TTS-Familie heißt Sonic, und das aktuelle Produktionsmodell ist Sonic-3. Die STT-Familie heißt Ink, und das aktuelle Produktionsmodell ist Ink-Whisper.

‍Sonic-3 ist ein Streaming-TTS-Modell mit einer veröffentlichten Zeit bis zum ersten Audio von etwa 90 ms. Es unterstützt 42 Sprachen. Es bietet feingranulare Steuerungsmöglichkeiten für Lautstärke, Geschwindigkeit und Emotionen über API-Parameter und SSML-Tags. Es unterstützt Lachen durch [laughter] Inline-Tags. Das Modell wird über drei Endpunkt-Formen bereitgestellt, die für verschiedene Anwendungsfälle geeignet sind.

Der erste ist POST /tts/bytes. Dies ist ein synchroner Batch-Endpunkt, der die gesamte Audiodatei im Antworttext zurückgibt. Er akzeptiert MP3-, WAV- oder rohe PCM-Ausgabeformate und eignet sich zur Vorabgenerierung von Audio-Assets, bei denen die volle Latenzzeit bis zur vollständigen Ausgabe akzeptabel ist.

Der zweite ist POST /tts/sse. Dies ist ein Server-Sent-Events-Stream. Das Modell gibt Audio-Chunks progressiv aus, während sie generiert werden. Dies eignet sich für Anwendungen, die Audio progressiv abspielen und den Vorteil der schnellen ersten Byte-Übertragung benötigen, aber keinen Eingabetext in das Modell streamen müssen.

Der dritte ist WSS /tts/websocket. Dies ist der empfohlene Endpunkt für Echtzeit-Sprachagenten. Die Verbindung ist bidirektional und unterstützt multiplexierte Generierungen über das Feld context_id. Ein einzelner offener WebSocket kann Dutzende gleichzeitiger Generierungen verarbeiten. Die context_id ermöglicht die Fortsetzungsgenerierung, bei der zusätzliche Textsegmente in einen bestehenden Kontext eingefügt werden können, um die Prosodie über die Übergänge hinweg aufrechtzuerhalten. Dies ist wichtig, wenn die vorgelagerte Textquelle ein LLM ist, das Token für Token streamt, und die TTS der Kadenz der Textgenerierung folgen muss. Das WebSocket-Protokoll unterstützt auch manuelles Flushing über flush_id-Marker, die diskrete Audiogrenzen innerhalb eines einzelnen Kontexts erzeugen.

Ink-Whisper ist ein Streaming-STT-Modell, das von whisper-large-v3-turbo abgeleitet und für den Echtzeit-Konversationsgebrauch neu entwickelt wurde. Die entscheidende Metrik ist die Zeit bis zur vollständigen Transkription, die misst, wie schnell die endgültige, genaue Transkription nach Beendigung des Sprechens durch den Benutzer verfügbar ist. Ink-Whisper erreicht dies durch dynamisches Chunking. Standard-Whisper funktioniert am besten mit festen 30-Sekunden-Audio-Puffern und führt daher eine grundlegende Latenzschwelle ein, die für Live-Gespräche ungeeignet ist. Ink-Whisper analysiert den Audiostream auf semantisch bedeutsame Bruchpunkte wie Pausen und Atemzüge und verarbeitet kürzere Chunks, sobald sie sich bilden. Der Endpunkt ist ein Streaming-WebSocket, das PCM-Audioframes mit 16 kHz akzeptiert und Zwischen- sowie endgültige Transkripte ausgibt, sobald das Modell diese festlegt. Die Standard-Audio-Kodierung ist pcm_s16le bei 16000 Hz.

Cartesia trennt WebSocket-Verbindungen nach 3 Minuten Inaktivität. Das Timeout wird mit jedem in beide Richtungen gesendeten Frame zurückgesetzt. Clients verwenden typischerweise auf Stille basierende Keepalives, um die Verbindung über Sprechpausen hinweg offen zu halten.

Die Integrationsschnittstelle

Das Hinzufügen von Cartesia zum TrueFoundry AI Gateway erfolgt in drei Schritten im Dashboard. Navigieren Sie zu AI Gateway, dann zu Modelle und wählen Sie Cartesia aus. Fügen Sie ein Cartesia-Konto hinzu, indem Sie einen eindeutigen Kontonamen und den Cartesia API-Schlüssel eingeben. Der Schlüssel wird verschlüsselt in der Steuerungsebene gespeichert und niemals direkt den Gateway-Pods zugänglich gemacht. Fügen Sie optional Kollaboratoren hinzu, die steuern, welche Benutzer und Teams Traffic über dieses Konto leiten können. Registrieren Sie dann ein oder mehrere Modelle, indem Sie auf Modell hinzufügen klicken und einen Anzeigenamen, eine Modell-ID und einen Modelltyp angeben. Für Cartesia müssen die Modell-ID und der Anzeigename identisch sein und exakt mit dem Cartesia-Modellbezeichner übereinstimmen (sonic-3 und sonic-3-2026-01-12 und ink-whisper und so weiter).

Die Konfigurationsoberfläche für ein Cartesia-Konto ist einfach.

Die Inferenz verwendet das native Cartesia SDK, wobei die Gateway-URL als Basis-URL eingesetzt wird. Ein Python-Client sieht wie folgt aus.

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},
)

Dieselbe SDK-Aufrufe funktionieren für den WebSocket-Endpunkt und für den Ink-Whisper STT WebSocket. Das von TrueFoundry ausgestellte JWT ersetzt den Cartesia API-Schlüssel in der SDK-Konfiguration. Das SDK geht davon aus, direkt mit Cartesia zu kommunizieren, da das Gateway die URL-Pfade und die Antwortstrukturen beibehält. Kosten, Zugriffskontrolle und Tracing erfolgen alle unsichtbar im Anforderungspfad.

Architekturübersicht

Der End-to-End-Datenfluss ist unkompliziert. Ein Client öffnet eine HTTP-Anfrage oder einen WebSocket gegen die Gateway-URL unter Verwendung des Cartesia SDK. Der Gateway-Pod authentifiziert das JWT anhand zwischengespeicherter öffentlicher IdP-Schlüssel und löst den Modellbezeichner in das konfigurierte Cartesia-Konto auf. Er entfernt den eingehenden Authentifizierungs-Header und ersetzt ihn durch den Cartesia API-Schlüssel aus dem Anmeldeinformationsspeicher. Er leitet die Anfrage weiter oder aktualisiert den WebSocket auf https://api.cartesia.ai. Für WebSocket-Sitzungen überbrückt er Frames in beide Richtungen, bis eine der beiden Seiten die Verbindung schließt. Nach Abschluss der Anfrage 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 Cartesia SDK-Fork. Es gibt keine Schatten-Übersetzungsschicht, die TTS-Parameter in das OpenAI-Audioformat umwandelt und dabei die Sprach-ID und das Streaming-Kontextmodell verliert. Es gibt keine separate Trace-Pipeline für Sprachverkehr und eine andere für Chat-Verkehr. Es gibt keinen pro Dienst verteilten API-Schlüssel im Anwendungscode. Es gibt keinen clientseitigen WebSocket-Terminator, der separat bereitgestellt werden muss, um die Zugriffskontrolle auf die Streaming-Endpunkte anzuwenden.

Das architektonische Prinzip, das dies ermöglicht, ist die Trennung zwischen Protokollsemantik und Governance-Semantik. Das Cartesia-Protokoll trägt eine Sprachdomänenbedeutung, die sich nicht sauber auf andere Anbieter verallgemeinern lässt. Die Governance-Schicht (Authentifizierung und Autorisierung sowie Anmeldeinformationsinjektion und Beobachtbarkeit und Kostenverfolgung) ist anbieterunabhängig und kann vor jedem HTTP- oder WebSocket-Ursprung ausgeführt werden, ohne die Nutzlast zu inspizieren. Natives Passthrough bewahrt das Erste, während es das Zweite anwendet. Das Ergebnis ist, dass die gesamte Funktionsvielfalt von Cartesia (Sonic-3s Kontexte und Fortsetzungen und Emotionskontrollen und Ink-Whispers Streaming-Transkriptionsfluss) 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.