Wie wir Live-Übersetzung unter 700 ms gebracht haben

Das Budget ist die eigentliche Schwierigkeit, nicht das Modell

Alle gehen davon aus, dass die Latenz bei Sprachübersetzung ein Modellproblem ist: eine schnellere Erkennungs-Engine, ein schnelleres Übersetzungsmodell, eine schnellere Stimme, und die Zahl sinkt. Bei FluenSync, unserem Echtzeit-Sprach-zu-Sprach-Übersetzungsprodukt für Web, iOS und Android, spielten Modellwechsel eine kleinere Rolle als erwartet. Was uns tatsächlich unter 700 Millisekunden über 14 oder mehr Sprachen brachte, war die Pipeline-Architektur rund um die Modelle.

Sprache in Stücken verarbeiten, bevor sie zu Ende ist

Der naive Ansatz wartet auf eine Pause, schickt die vollständige Äußerung zur Erkennung, dann zur Übersetzung, dann zur Sprachsynthese. Jede Stufe wartet, bis die vorherige fertig ist, und allein die Pausen fressen das Budget auf, bevor ein einziges Wort verarbeitet wurde. Wir streamen stattdessen Audio in festen Blöcken zur Erkennung, sobald sie eintreffen, und lassen sie fortlaufend Teiltranskripte ausgeben. Die Übersetzung beginnt auf stabilen Segmenten, die die Erkennung nicht mehr revidiert, ohne auf ein finales Transkript zu warten. Der Großteil des Budgets wird hier zurückgewonnen, nicht durch ein schnelleres Einzelmodell.

Wo die Verbindung liegt

Alle drei Stufen laufen über eine einzige WebSocket-Verbindung pro Sitzung statt über drei getrennte Aufrufe. Ein WebSocket spart die Aufbaukosten einer neuen Verbindung pro Block und erlaubt uns, Teilresultate an den Client zu senden, sobald sie vorliegen, statt auf Abfragen des Clients zu warten. Auf dem Mobilgerät trägt dieselbe Verbindung Audio hinauf und synthetisierte Sprache zurück, sodass nur eine Hin- und Rückstrecke ins Budget eingeht, nicht mehrere.

Das Budget, das wir tatsächlich messen

• Erfassung und Aufteilung auf dem Gerät: ein kleiner fester Abschnitt, nicht die gesamte Äußerung.
• Netzwerk aufwärts: ein WebSocket-Frame, nicht eine neue Verbindung pro Block.
• Erkennung auf einem stabilen Segment: Rückgabe, sobald es nicht mehr revidiert wird.
• Übersetzung dieses Segments: Eingabe klein genug, um die Modelllatenz vorhersehbar zu halten.
• Sprachsynthese: Audio für ein Segment beginnt, bevor das nächste fertig übersetzt ist.
• Netzwerk abwärts und Wiedergabe: gestreamt, nicht als eine Datei am Ende geliefert.

Jede Stufe hat ihr eigenes Millisekundenziel, und wir messen sie getrennt statt nur die Gesamtzahl, denn eine langsame Stufe verschwindet im Durchschnitt, bleibt für die wartende Person aber deutlich spürbar.

Das Netzwerk behandeln, nicht nur die Pipeline

Eine Pipeline, die auf einer stabilen Verbindung schnell ist, versagt im Feld trotzdem, wenn sie davon ausgeht, dass das Netz nie stockt. Mobilverbindungen verlieren Frames, vertauschen Pakete und stocken mitten im Satz. Wir betreiben einen kleinen Jitter-Puffer auf dem Client, um kurze Lücken ohne Wiedergabeaussetzer auszugleichen, und codieren Audio mit einem Codec für niedrige Bandbreite statt einem, der auf Dateigröße optimiert ist. Bricht die WebSocket-Verbindung während einer Sitzung ab, verbindet sich der Client neu und setzt fort, statt von vorn zu beginnen, sodass eine kurze Unterbrechung nur ein Stocken kostet, keinen Neustart aus der Stille. Nichts davon zeigt sich in einer Latenzzahl, die im Labornetz gemessen wird, aber es entscheidet, ob das 700-Millisekunden-Budget auf einem Telefon im fahrenden Zug hält.

Was wir bewusst nicht gemacht haben

Wir haben nicht isoliert das schnellste Modell gejagt, denn ein minimal schnelleres Modell, das auf die vollständige Äußerung wartet, verliert gegen ein etwas langsameres, das auf einem Teilsegment starten kann. Wir haben auch nicht versucht, mit geratenen Fortsetzungen vorauszueilen, denn eine falsche Vermutung kostet mehr Korrekturaufwand im laufenden Gespräch, als die gesparte Latenz wert wäre. Der Gewinn kam aus dem Wegfall von Leerlaufzeit zwischen den Stufen, nicht aus der Beschleunigung einer einzelnen Stufe.

Was wir einem Team raten würden, das so etwas baut

Profilieren Sie die Pipeline Stufe für Stufe, bevor Sie ein einzelnes Modell optimieren. Streamen Sie alles, was sich streamen lässt. Behandeln Sie die Verbindung selbst als Teil des Latenzbudgets, nicht nur die Modelle dahinter. Bei einem Echtzeit-Sprachprodukt bemerken Nutzer nicht die Geschwindigkeit einer einzelnen Stufe. Sie bemerken die Summe aller Punkte, an denen eine Stufe warten musste, bis die andere vollständig fertig war.