Audio-Streaming verstehen | ElevenLabs Documentation

Wenn Sie ein Video streamen, laden Sie eine Datei herunter. Der Server sendet Bytes, die Ihr Player puffert, bis genug für die Wiedergabe angekommen sind. Beim Streaming der Audiogenerierung ist das grundlegend anders. Das Audio existiert noch nicht, wenn das Streaming beginnt. Das Modell synthetisiert es in Echtzeit, und die gestreamten Bytes sind die Live-Ausgabe dieses Syntheseprozesses.

Dieser Unterschied ist wichtig, weil er verändert, wie Sie über Latenz, Pufferung und Fehlermodi nachdenken.

Was passiert beim Aufruf des Streaming-Endpunkts?

Wenn Sie den Streaming-TTS-Endpunkt von ElevenLabs aufrufen, passiert Folgendes:

Ihre Anfrage trifft auf dem Server ein.
Das Modell beginnt mit der Sprachsynthese.
Während Audio erzeugt wird, sendet der Server es schrittweise, typischerweise in Blöcken von wenigen Kilobyte.
Ihr Client empfängt jeden Block und spielt ihn ab, sobald er eintrifft.

Entscheidend ist Schritt 3: Der Server wartet nicht, bis die gesamte Audiodatei fertig ist, bevor er sie sendet. Das unterscheidet Streaming grundlegend vom Standard-Endpunkt, der wartet, bis die Synthese abgeschlossen ist, bevor er überhaupt Audio zurückgibt.

Warum Streaming die Zeit bis zum ersten Audio reduziert

Beim Standard-Endpunkt entspricht die Zeit bis zum ersten Audio der Zeit, die für die Synthese des gesamten Texts benötigt wird. Bei einem kurzen Satz können das 500 ms sein, bei einem Absatz mehrere Sekunden.

Beim Streaming entspricht die Zeit bis zum ersten Audio ungefähr der Zeit, die für die Synthese des ersten Audioblocks erforderlich ist. Typischerweise die ersten paar hundert Millisekunden Sprache. Alles danach wird abgespielt, während weitere Blöcke parallel erzeugt werden.

Deshalb ist Streaming für Echtzeitanwendungen unverzichtbar: Nutzende hören innerhalb eines Sekundenbruchteils Ton, selbst wenn die vollständige Generierung länger dauert.

Die zwei Streaming-Protokolle

ElevenLabs unterstützt zwei Streaming-Ansätze für unterschiedliche Anwendungsfälle.

HTTP-Streaming (Server-Sent Events) ist der einfachere Ansatz. Sie senden vorab einen vollständigen Text, und der Server streamt Audio zurück, während es erzeugt wird. Das funktioniert gut, wenn der gesamte Text vor dem Start verfügbar ist. Zum Beispiel ein vorab geschriebenes Skript oder eine vollständige LLM-Antwort, die Sie sofort abspielen möchten.

WebSocket-Streaming ermöglicht bidirektionale Kommunikation. Sie können Text schrittweise senden, Wort für Wort oder Satz für Satz, und das Modell beginnt mit der Generierung, bevor die vollständige Eingabe verfügbar ist. Dadurch werden durchgängig latenzarme Sprach-Pipelines möglich: Ein LLM generiert Tokens, Sie leiten diese beim Eintreffen an den TTS-WebSocket weiter, und die Audiowiedergabe beginnt, bevor das LLM seine Antwort abgeschlossen hat.

Der WebSocket-Ansatz ist komplexer. Das Modell muss entscheiden, wann es die Audiogenerierung verbindlich startet: Zu früh kann es an Phrasengrenzen unnatürliche Prosodie erzeugen, zu spät leidet die Latenz. Gesteuert wird dies über Blockpläne und die Einstellung auto_mode, die diesen Kompromiss für die meisten Anwendungsfälle automatisch verwaltet.

Warum die Blockgröße sowohl Latenz als auch Natürlichkeit beeinflusst

Bei der Audio-Streaming-Generierung besteht ein grundlegender Zielkonflikt zwischen Blockgröße und Natürlichkeit der Sprache.

Sprachsynthesemodelle profitieren von Kontext. Zu wissen, was vor und nach einem bestimmten Wort kommt, hilft dem Modell, natürliche Prosodie zu erzeugen. Ein Modell, das Audio aus „Die Wirtschaft“ generiert, muss die Prosodie sehr unterschiedlich gestalten, je nachdem, ob der Satz mit „erholt sich“ oder „bricht ein“ endet.

Wenn Audio zu früh festgelegt wird, bevor das Modell genug Text gesehen hat, kann die Sprache an Phrasengrenzen unnatürlich klingen. Technisch korrekt, aber leicht roboterhaft. Auf mehr Kontext zu warten verbessert die Natürlichkeit, erhöht aber die Latenz.

ElevenLabs’ auto_mode versucht, durch Analyse des eingehenden Texts automatisch eine gute Balance zu finden. Für die meisten Anwendungen liefert dies gute Ergebnisse. Wenn Sie feinere Kontrolle benötigen, etwa bei einem Sprachagenten, bei dem Sie für geringere Latenz etwas weniger natürliche Prosodie akzeptieren, können Sie den Blockplan direkt konfigurieren.

Streaming-Latenz vs. Generierungslatenz

Diese beiden Werte werden leicht verwechselt, sind aber unterschiedlich.

Generierungslatenz gibt an, wie lange das Modell für die Audioerzeugung benötigt. Die veröffentlichten Modelllatenzwerte messen dies serverseitig: die Zeit, die ElevenLabs benötigt, um das erste Audio zurückzugeben, ohne Netzwerk-Roundtrips und Anwendungs-Overhead.

Zeit bis zum ersten Audio ist die verstrichene Zeit vom Start einer Anfrage durch Ihre Anwendung bis das erste Audio-Sample tatsächlich für den Endnutzer abgespielt wird. Sie umfasst Netzwerklatenz, Serververarbeitungszeit und jede Pufferung durch Ihren Audioplayer.

In der Praxis wird die Zeit bis zum ersten Audio deutlich höher sein als die reine Modelllatenz. Netzwerk-Roundtrips fügen je nach geografischer Entfernung 50–200 ms hinzu. Der Puffer Ihres Audioplayers kommt noch dazu. Dieses Verständnis hilft Ihnen, realistische Erwartungen zu setzen und Leistungsprobleme zu diagnostizieren: Ist die Zeit bis zum ersten Audio hoch, liegt der Engpass meist am Netzwerk oder an der Pufferung in der Anwendung, nicht an der Modellleistung.

Häufige Missverständnisse

„Der Streaming-Endpunkt ist langsamer, weil er Daten schrittweise sendet.“ Nein, für Ihre Nutzenden ist er schneller, weil sie das Audio früher hören. Die gesamte Generierungszeit ist ähnlich; nur der Zeitpunkt, zu dem Daten eintreffen, ändert sich.

„Ich brauche WebSockets für Streaming.“ Nicht unbedingt. Der HTTP-Streaming-Endpunkt eignet sich gut für die meisten Anwendungsfälle. WebSockets sind besonders wertvoll, wenn Sie Text und Audio gleichzeitig generieren. Zum Beispiel wenn ein LLM Text erzeugt, der direkt in die Audiogenerierung fließt.

„Höherwertige Audioformate erhöhen die Streaming-Latenz deutlich.“ Das wird meist überschätzt. Die Hauptfaktoren für Latenz sind Modell-Inferenzzeit und Netzwerk-Roundtrip. Ein Ausgabeformat mit höherer Bitrate verursacht nur geringen zusätzlichen Aufwand, der selten vor den größeren Faktoren optimiert werden sollte.