Kokoro-82M auf SageMaker: So startet die Sprachausgabe früher

Der AWS-Ansatz lässt Kokoro-82M bereits abgeschlossene Sätze vertonen, während ein KI-Agent noch an seiner Antwort arbeitet. Dafür sendet der Agent jeden vollständigen Satz einzeln an einen bidirektionalen Amazon-SageMaker-AI-Endpunkt. Die Sprachsynthese der einzelnen Nachrichten läuft nacheinander, aber sie muss nicht warten, bis der gesamte Antworttext vorliegt.

Voraussetzungen und Aufbau

Das Beispiel verbindet einen eigenen Kokoro-82M-Container auf einem SageMaker-AI-Echtzeitendpunkt mit einem Strands-Agenten in Amazon Bedrock AgentCore. Der Endpunkt nutzt in der beschriebenen Konfiguration eine ml.g5.xlarge-GPU-Instanz. Für den Pfad zum Agenten sieht AWS außerdem eine Verbindung zu Amazon Bedrock vor.

Für die Einrichtung nennt AWS ein AWS-Konto mit den nötigen Berechtigungen, ein initialisiertes AWS CDK v2, Python 3.12 oder neuer, uv, Docker und eine kompatible Boto3-Version. Der Container braucht die Kennzeichnung für bidirektionales Streaming. Kenntnisse zu WebSockets und Starlette beziehungsweise ASGI helfen bei der Implementierung.

Der Beispielcontainer stellt drei Routen bereit: GET /ping für den Gesundheitscheck, POST /invocations für einen Antwortstream und WS /invocations-bidirectional-stream für eine dauerhafte WebSocket-Verbindung in beide Richtungen.

In dieser Reihenfolge setzt du den Sprachpfad um

1. Richte zuerst den SageMaker-Endpunkt ein. Der Kokoro-Endpunkt muss bereitstehen, bevor der Agent ihn für die Sprachsynthese aufruft. AWS’ Beispiel setzt dafür den eigenen Container mit Kokoro-82M auf dem Echtzeitendpunkt ein.
2. Verarbeite WebSocket-Nachrichten als Binärdaten. SageMaker übergibt Nachrichten des bidirektionalen Clients laut AWS als binäre WebSocket-Frames. Ein Starlette-Handler, der ausschließlich receive_text() aufruft, kann deshalb KeyError('text') auslösen, obwohl der Endpunkt den Status InService meldet. Der Handler sollte Text- und Byte-Nachrichten annehmen und Byte-Inhalte bei Bedarf als UTF-8 dekodieren.
3. Halte dieselbe Sitzung für weitere Sätze offen. Nach einer Synthese muss die Verbindung nicht neu aufgebaut werden: Über dieselbe Sitzung können weitere Textnachrichten laufen. Schließe sie erst, wenn der Client eine ausdrückliche Schließnachricht sendet. AWS’ Protokoll verwendet dabei Steuerframes für synthesis_start und synthesis_complete sowie binäre Frames für das rohe PCM-Audio.
4. Starte den Strands-Agenten in Bedrock AgentCore. Der Agent bezieht Text aus der laufenden Antwortgenerierung und gibt fertige Sätze an den SageMaker-Endpunkt weiter. Die Satzaufteilung kann vollständige Sätze aus den eintreffenden Textfragmenten ausgeben; am Ende muss sie auch den verbleibenden Text übergeben, selbst wenn dieser keinen vollständigen Satzabschluss enthält.
5. Prüfe den Ablauf mit mehreren Nachrichten. Teste neben der Verarbeitung binärer Frames auch, ob eine Sitzung mehrere Syntheseaufrufe trägt und erst nach der ausdrücklichen Schließnachricht endet. Ein funktionierender Durchlauf enthält die Steuerframes für den Synthesestart und den Abschluss sowie die Audioframes dazwischen.

Audiotransport für den Browser wählen

Wenn eine bestehende Browseranwendung bereits Server-Sent Events (SSE) nutzt, kann Audio als Base64-kodierter Inhalt über diesen Pfad laufen. Base64 vergrößert die Nutzdaten in den AWS-Messungen um ungefähr ein Drittel. Außerdem können Übertragungsblöcke mitten in einem Audioframe enden. Der Empfänger muss solche Teile puffern und wieder zusammensetzen, statt jeden einzelnen Block als vollständigen Frame zu behandeln.

Auf dem bidirektionalen Weg zum Kokoro-Endpunkt kann AWS dagegen rohe Audiodaten und JSON-Steuerframes über dieselbe Sitzung übertragen. Ein Frame ist dabei nur dann ein Steuerframe, wenn sich der gesamte Inhalt als JSON-Objekt lesen lässt. Der Browserpfad über AgentCore nutzt weiterhin Base64, weil die Laufzeit dort JSON-serialisierbare Daten weitergibt.

AWS maß die Datenmengen in einem Test mit 24 Audioclips:

Die Tabelle zeigt den Größenunterschied der getesteten Formate. Sie ersetzt nicht die nötige Pufferung und Zusammensetzung der Audioframes im SSE-Empfänger.

Was die Latenzmessungen von AWS aussagen

In einem isolierten Test mit einem 267 Zeichen langen Text aus vier Sätzen maß AWS bei fünf Durchläufen pro Modus eine mittlere Zeit bis zum ersten Audiobyte von 329,3 ms im Batch-Modus und 156,7 ms, wenn zunächst nur der erste Satz gesendet wurde. AWS bezifferte die relative Verringerung für diesen Test auf 52,4 Prozent.

Für den vollständigen Agentenvergleich berichtete AWS, dass bidirektionales Streaming die Zeit bis zum ersten Audio lokal um den Faktor 2,4 und in einer bereitgestellten AgentCore-Laufzeit um den Faktor 3,5 gegenüber dem Batch-Modus verkürzte. Diese Werte stammen aus den jeweiligen AWS-Vergleichen; der Beitrag nennt für den Ende-zu-Ende-Test keine Zahl der Wiederholungen. Sie beschreiben nicht automatisch die Latenz anderer Prompts oder Konfigurationen.

Kokoro lässt sich auch mit anderen Hosting-Ansätzen einsetzen. Trelis Research zeigte Kokoro-ONNX für lokale Inferenz auf einer CPU sowie einen separaten Kokoro-FastAPI-Server auf einer H100-Instanz bei Runpod. Für den Serverbetrieb berichtete Trelis Research unter gleichzeitiger Verarbeitung eine Rate von etwa 55 bis 78 Audiostunden pro Echtzeitstunde. Das ist ein eigener Durchsatzwert für dieses Setup und keine Latenzmessung des SageMaker-Agenten.

Sicherheits- und Aufräumarbeiten

AWS weist darauf hin, dass der Beispielcontainer eine ältere PyTorch-Version festlegt, die mit dem Hinweis PYSEC-2026-2286 verbunden ist. Laut AWS ist der Hinweis in PyTorch 2.10.0 behoben; vor einem Einsatz über einen Machbarkeitsnachweis hinaus sollte die festgelegte Version geprüft werden.

Beim Aufräumen entfernt AWS’ Ablauf die AgentCore-Laufzeit und den SageMaker-Endpunkt. Der S3-Bucket mit dem Modellcache und das ECR-Repository mit dem Container-Image bleiben dabei bestehen und können weiterhin Speicherkosten verursachen, bis sie separat gelöscht werden.