Integration von Resemble AI-Sprachmodellen mit TrueFoundry

Wir freuen uns, die Integration von Resemble AI in das TrueFoundry AI Gateway bekannt zu geben. Damit stehen Sprachklonierung, synchrone Text-to-Speech-Funktionen sowie Streaming-TTS über denselben Gateway-Pfad zur Verfügung, den Teams bereits für LLMs, Embeddings und Agenten-Traffic nutzen.

Teams, die ihren KI-Traffic über das AI Gateway von TrueFoundry leiten, können Resemble AI nun als erstklassigen Text-to-Speech-Anbieter über das native SDK-Pass-Through des Gateways anbinden. Anfragen an die /synthesize- und /stream-Endpunkte von Resemble fließen durch den Gateway-Pfad, inklusive zentraler Authentifizierung, team-spezifischer Zugriffskontrolle, einheitlicher Kostenverfolgung und vollständigem Request-Tracing. Es sind keine Änderungen am Client-Code erforderlich, außer die Resemble-Basis-URL auf das Gateway umzustellen und sich mit einem TrueFoundry-Token zu authentifizieren.

Dieser Beitrag erläutert die Architektur der Integration. Er erklärt, wie das TrueFoundry AI Gateway TTS-Anbieter bereitstellt, wie die native API-Oberfläche von Resemble durch die Pass-Through-Schicht erhalten bleibt und wie Failover-Mechanismen über mehrere TTS-Anbieter mittels virtueller Modelle funktionieren.

Warum Teams ein Gateway vor Sprachanwendungen schalten

TrueFoundry bietet die Steuerungsebene für KI-Systeme in der Produktion. Über das AI Gateway zentralisieren Teams das Modell-Routing, die Schlüsselverwaltung, Zugriffskontrolle, Observability und Kostenverfolgung für LLMs, Embeddings sowie Bild- und Audioanbieter. Jeder Request durchläuft eine einzige Proxy-Schicht, in der die Identität verifiziert, Ratenbegrenzungen durchgesetzt und Traces erfasst werden.

TTS-Traffic in der Produktion ähnelt in dreierlei Hinsicht dem LLM-Traffic. Meist sind mehrere Anbieter im Einsatz, da kein einzelner TTS-Anbieter in jeder Hinsicht überzeugt. Latenz ist entscheidend, da Sprachagenten Audio in Echtzeit an Benutzer streamen. Die Kosten summieren sich schnell auf Zeichen- oder Sekundenebene und profitieren von denselben Kostenstellen- und Budgetkontrollen, die Teams bereits für Chat-Completions anwenden. Die Argumente für ein Gateway vor LLM-Anbietern lassen sich direkt übertragen.

Resemble AI ist eine umfassende Plattform für generative KI-Sicherheit zur Erstellung, Verifizierung und Erkennung synthetischer Medien in den Bereichen Audio, Video und Bild. Resemble entwickelt zudem eigene Basismodelle für Generierung und Erkennung, was einen entscheidenden Vorteil bei der Identifizierung von KI-generierten Inhalten bietet. Für die Spracherzeugung ist das Kernmodell Chatterbox, Chatterbox Multilingual, mit einer Chatterbox Turbo-Variante für geringere Latenz und Unterstützung paralinguistischer Tags. Alle von Resemble entwickelten TTS-Modelle werden standardmäßig mit Watermarking ausgeliefert. Die Plattform unterstützt außerdem Voice Cloning, Voice Design, Audiobearbeitung, SSML, HD-Synthese und Streaming-Ausgabe. Zusammen bieten die beiden Plattformen Teams einen zentralen Ort, um die Spracherzeugung gemeinsam mit dem restlichen KI-Stack zu steuern und nachzuverfolgen. TrueFoundry übernimmt das Deployment, das Routing und die operative Kontrolle. Resemble übernimmt die eigentliche Synthese. Die Integration nutzt das native SDK-Pass-Through von TrueFoundry, wodurch die vollständige API-Oberfläche von Resemble erhalten bleibt, ohne sie in ein OpenAI-kompatibles Format zwingen zu müssen.

Die Resemble API-Oberfläche

Der synchrone Text-to-Speech-Endpunkt von Resemble benötigt nur wenige Felder und liefert Audio zusammen mit Timing-Metadaten zurück. Der synthesize-Endpunkt akzeptiert eine voice_uuid zur Auswahl der trainierten oder vordefinierten Stimme sowie ein Datenfeld mit Text oder SSML bis zu 3000 Zeichen. Optionale Felder steuern die Modellauswahl über model (z. B. chatterbox-turbo), die Audiopräzision über precision (MULAW, PCM_16, PCM_24 oder PCM_32), das Ausgabeformat über output_format (wav oder mp3), die Abtastrate, den HD-Modus über use_hd sowie die Handhabung benutzerdefinierter Aussprachen über apply_custom_pronunciations.

Die Antwort-Payload enthält eine Erfolgsmeldung und ein base64-kodiertes audio_content-Feld mit den synthetisierten Audio-Bytes. Timing-Metadaten werden in audio_timestamps mit Graphem-Zeichen, Graphem-Zeiten, Phonem-Zeichen und Phonem-Zeiten für nachgelagerte Anwendungsfälle wie Lippensynchronisation und Untertitelung bereitgestellt. Die Antwort meldet zudem duration (die Audiolänge in Sekunden), synth_duration (die reine Synthesezeit), output_format, sample_rate sowie eventuelle Probleme, die der Synthesizer während der Generierung gemeldet hat.

Ein zweiter Endpunkt unter /stream unterstützt Streaming-Synthese über HTTP für Sprachagenten-Anwendungsfälle, bei denen die Zeit bis zum ersten Audio-Chunk entscheidend ist. Die Request-Struktur ist identisch. Die Antwort ist ein Stream von Audio-Frames anstelle einer einzelnen base64-Payload. Die Authentifizierung für beide Endpunkte erfolgt über ein Bearer-Token, das über die Resemble-Account-Konsole ausgestellt wird.

Wie das Gateway TTS-Anbieter handhabt

Das TrueFoundry AI Gateway basiert auf dem Hono-Framework; ein einzelner Gateway-Pod verarbeitet über 250 Anfragen pro Sekunde bei 1 vCPU und 1 GB RAM mit einer zusätzlichen Latenz von etwa 3 ms. Gateway-Pods sind zustandslos, CPU-gebunden und skalieren horizontal durch zusätzliche Pods auf zehntausende Anfragen pro Sekunde. Die Control Plane und die Gateway Plane sind getrennt. Die Anbieterkonfiguration, einschließlich Anmeldedaten, Routing-Regeln und Ratenbegrenzungen, liegt in der Control Plane und wird über NATS mit den Gateway-Pods synchronisiert. Der eigentliche Request-Pfad bleibt im Arbeitsspeicher, ohne externe Aufrufe außer dem Anbieteraufruf selbst.

Für TTS bietet das Gateway zwei Integrationsmuster.

Das erste ist das OpenAI-kompatible API -Muster an der Basis-URL des Gateways. Anbieter, die das OpenAI-/audio/speech-Format unterstützen (OpenAI, Azure OpenAI, Azure AI Foundry und Groq), werden hier eingebunden. Clients verwenden das Standard-OpenAI-SDK, und das Gateway übersetzt die Anfrage über eine Adapterschicht in das native Format des Anbieters.

Das zweite ist das native SDK-Pass-Through -Muster unter {GATEWAY_BASE_URL}/tts/{providerAccountName}. Anbieter mit umfangreichen nativen APIs, die sich nicht direkt auf das OpenAI-Format abbilden lassen, werden hier eingebunden. Das vollständige Format der Anfrage und Antwort des Anbieters bleibt erhalten. Das Gateway übernimmt Authentifizierung, Zugriffskontrolle, Tracing und Routing, schreibt die Nutzlast jedoch nicht um. Dies ist das Muster, das Resemble verwendet, da der Resemble-Anfragekörper mit voice_uuid, audio_timestamps, Präzisionsstufen und dem chatterbox-turbo-Modellselektor kein Äquivalent im OpenAI-TTS-Vertrag hat.

Wenn eine Anfrage einen Gateway-Pod erreicht, sieht der Pfad wie folgt aus: Das TrueFoundry-Token im Authorization-Header wird gegen zwischengespeicherte öffentliche IdP-Schlüssel validiert. Die Team-Identität wird über eine In-Memory-Map aufgelöst und die Berechtigung für das Resemble-Anbieterkonto geprüft. Der Anfragekörper wird an den Resemble-Synthesize- oder Stream-Endpunkt weitergeleitet, wobei das Resemble-Bearer-Token serverseitig angehängt wird. Die Antwort wird an den Client gestreamt. Die gesamte Interaktion wird in einem Trace-Span erfasst, inklusive Modellname, Anbieterkonto, Anzahl der Eingabezeichen, Antwortdauer, Synthesedauer und Latenz. Es gibt keine zusätzlichen Roundtrips über den eigentlichen Anbieteraufruf hinaus.

Die Integrationsschnittstelle

Resemble ist in der TrueFoundry-Steuerungsebene als Anbieterkonto registriert, wobei das Resemble-Bearer-Token als Secret gespeichert ist. Sobald das Konto hinzugefügt wurde, stellt das Gateway zwei TTS-Routen dafür bereit. Die native SDK-Route unter {GATEWAY_BASE_URL}/tts/{providerAccountName}/synthesize leitet an den synchronen Endpunkt weiter. Die Streaming-Route unter {GATEWAY_BASE_URL}/tts/{providerAccountName}/stream leitet an den Streaming-Endpunkt weiter. Beide Routen behalten das Format der Resemble-Anfrage und -Antwort exakt bei.

Ein minimaler Client-Aufruf sieht wie im folgenden Code-Schnipsel aus. Beachten Sie, dass die einzige Änderung gegenüber einem direkten Resemble-Aufruf die Basis-URL und der Authentifizierungs-Header sind.

curl -X POST {GATEWAY_BASE_URL}/tts/resemble-prod/synthesize \  -H "Authorization: Bearer ${TFY_API_KEY}" \  -H "Content-Type: application/json" \  -d '{    "voice_uuid": "55592656",    "data": "Hello from the gateway.",    "model": "chatterbox-turbo",    "output_format": "mp3",    "use_hd": false  }'

Bestehender Anwendungscode, der direkt auf Resemble zugreift, kann durch Austausch der Basis-URL und des Bearer-Tokens migriert werden. Voice-UUIDs, SSML-Nutzlasten, Präzisionseinstellungen und der HD-Modus bleiben unverändert erhalten. Die offiziellen Client-Bibliotheken von Resemble können auf die gleiche Weise konfiguriert werden, indem ihre Basis-URL überschrieben wird.

Routing und Failover zwischen TTS-Anbietern

Voice-Agent-Stacks betreiben in der Produktion oft mehr als einen TTS-Anbieter aus Kosten- und Latenzgründen. Die Virtual-Model-Abstraktion des Gateways lässt sich auf TTS-Anbieter genauso anwenden wie auf LLM-Anbieter. Ein virtueller Modellbezeichner wird auf eine oder mehrere physische TTS-Bereitstellungen mit Routing-Regeln abgebildet. Gewichtungsbasiertes Routing verteilt den Datenverkehr prozentual auf die Anbieter. Prioritätsbasiertes Routing versucht es beim ersten Anbieter und führt bei einem 5xx-Fehler, einem Timeout oder einer Ratenbegrenzung ein Failover durch. Latenzbasiertes Routing sendet den Datenverkehr an den Anbieter mit der niedrigsten p50-Latenz im gleitenden Zeitfenster.

Das Failover für TTS funktioniert nach denselben Prinzipien wie das LLM-Failover. Fehler, die nicht wiederholt werden können, lösen sofort einen erneuten Versuch beim nächsten Anbieter mit der nächsthöheren Priorität aus. Fehlerspitzen führen dazu, dass ein Anbieter für 5 Minuten in eine Abkühlphase versetzt wird, während Testanfragen die Wiederherstellung prüfen. Ein Team, das Resemble Chatterbox Turbo als primären Pfad für niedrige Latenz nutzt, kann auf Cartesia oder ElevenLabs ausweichen, ohne den Client-Code zu ändern. Das virtuelle Modell übernimmt die Auswahl.

Die Kostenverfolgung erfasst die TTS-Nutzung mit derselben Granularität wie die LLM-Nutzung. Das Gateway protokolliert für jede Anfrage die Anzahl der Eingabezeichen, die Synthesedauer, das Modell, das Team und den Benutzer. Der Aggregator-Dienst berechnet die Ausgaben pro Team und Benutzer und speist dieselben Dashboards und Budget-Durchsetzungsmechanismen, die bereits für Chat-Completions und Embeddings existieren. Ratenbegrenzungen werden über den Sliding-Window-Token-Bucket-Algorithmus mit pro-Minute-Fenstern angewendet, die auf Benutzer-, Team- oder Modellebene definiert sind. Bei TTS ist die Einheit Zeichen oder Anfragen statt Token, aber der Algorithmus bleibt identisch.

Observability und Traces

Jede TTS-Anfrage erzeugt einen Trace-Span. Die Span-Attribute umfassen das Anbieterkonto, die Modellkennung (zum Beispiel resemble-prod/chatterbox-turbo), die Anzahl der Eingabezeichen, die Antwortdauer in Sekunden, die reine Synthesezeit, das Ausgabeformat, die Abtastrate sowie die Latenz auf Gateway-Seite. Traces werden asynchron über NATS ausgegeben und via OTEL an das vom Team konfigurierte Observability-Backend (Arize, Langfuse, LangSmith oder ein anderes unterstütztes Ziel) exportiert. Der Schalter „Anfragedaten ausschließen“ funktioniert analog zu Chat-Vervollständigungen, um den Eingabetext aus exportierten Traces fernzuhalten, wenn dies aus Datenschutzgründen erforderlich ist.

Dies bedeutet, dass TTS-Aufrufe in derselben Trace-Timeline erscheinen wie der vorgelagerte LLM-Aufruf, der den Text erzeugt hat, und die nachgelagerte Agentenaktion, die das Audio verarbeitet hat. Für das Debugging von Voice-Agenten ist diese Konsolidierung entscheidend. Ein fehlerhafter Durchlauf lässt sich von der LLM-Vervollständigung, die die Antwort ausgewählt hat, über die TTS-Synthese, die sie ausgegeben hat, bis hin zur darauffolgenden Aktion des Agenten nachverfolgen.

Architekturübersicht

Der End-to-End-Anfragefluss sieht wie folgt aus: Ein Client sendet eine TTS-Anfrage an das Gateway unter {GATEWAY_BASE_URL}/tts/{providerAccountName}/synthesize oder das entsprechende Streaming-Pendant mit einem TrueFoundry-Bearer-Token. Das Gateway authentifiziert den Aufrufer anhand zwischengespeicherter IdP-Schlüssel, löst das Anbieterkonto auf und prüft die Team- und Benutzerautorisierung im Arbeitsspeicher. Wenn ein virtuelles Modell verwendet wird, wählt die Routing-Logik einen physischen Anbieter basierend auf Gewichtung, Priorität oder Latenz aus. Der Anfragekörper wird mit dem serverseitigen Resemble-Bearer-Token an Resemble weitergeleitet. Die Antwort wird an den Client zurückgestreamt, wobei die vollständige Resemble-Payload-Struktur einschließlich Audioinhalt, Zeitstempeln und Metadaten zur Dauer erhalten bleibt. Jeder Schritt wird in einem Trace-Span erfasst, asynchron an NATS gesendet und via OTEL exportiert.

An der Anwendung selbst muss nichts geändert werden. Es ist kein Umschreiben des SDKs erforderlich, es gibt keine anbieterspezifische Authentifizierungsverwaltung auf Client-Seite und keine separate Observability-Pipeline für Voice-Traffic. Das Gateway befindet sich bereits im Anfragepfad für den Rest des KI-Stacks, und Resemble bindet sich über natives Pass-Through an diesen Pfad an. Bestehender Resemble-Client-Code funktioniert nach einem Austausch der Basis-URL weiterhin einwandfrei.

Das Architekturprinzip, das dies so sauber macht, ist das Dual-Integration-Pattern. Anbieter, die das OpenAI-Protokoll unterstützen, werden über den OpenAI-kompatiblen Adapter eingebunden und nutzen dieselben Client-SDKs. Anbieter mit umfangreichen nativen APIs werden über die Pass-Through-Route angebunden, wodurch die vollständige Funktionalität des Anbieters erhalten bleibt, ohne eine Übersetzung zu erzwingen. Bei TTS ist dies wichtig, da die Unterschiede zwischen den Anbietern nicht nur kosmetischer Natur sind. Voice-UUIDs, Audio-Zeitstempelformate, Präzisionsstufen und Streaming-Frame-Strukturen variieren auf eine Weise, die ein Adapter im OpenAI-Stil einebnen müsste. Das Pass-Through-Muster hält die Modellauswahl von Resembles Chatterbox sowie die Audio-Zeitstempel und Präzisionssteuerungen intakt, während das Gateway die übergreifenden Aspekte wie Authentifizierung, Routing, Observability und Kostenverfolgung übernimmt.

Erste Schritte

Erfahren Sie mehr über dieTrueFoundry AI Gateway und die Resemble AI-Plattform. Fügen Sie Resemble als Anbieterkonto in der Gateway-Control-Plane hinzu und rufen Sie den Synthesize- oder Stream-Endpunkt über die Route /tts/{providerAccountName} aus Ihrem bestehenden Anwendungscode auf.