„Echtzeit“ in der Sprach-KI: Was 80 Millisekunden wirklich bedeuten

Darum geht es

Wer Live-Untertitel in einer Videokonferenz einschaltet, kennt das Bild: Ein Wort erscheint, springt eine Sekunde später um, der halbe Satz wird neu geschrieben. Dahinter steckt eine Abwägung, die jede Streaming-Spracherkennung treffen muss. Streaming-ASR („Automatic Speech Recognition“) ist Spracherkennung, die schon mitschreibt, während noch gesprochen wird. Sie kann früh raten und später korrigieren, oder sie wartet, bis sie sicher ist, und bleibt dann bei ihrer Entscheidung.

Ins Gespräch kommt das Thema gerade durch Confucius4-R2T2 von NetEase Youdao. Das offene Modell erschien im September auf Hugging Face, das ausführliche Paper ist jetzt auf arXiv erschienen. Es verspricht, dass einmal ausgegebene Wörter nie mehr umgeschrieben werden. Gleichzeitig werben ElevenLabs, Nvidia, Mistral und OpenAI mit „Echtzeit“ und Millisekunden-Angaben. Diese Zahlen messen aber sehr unterschiedliche Dinge. Wir erklären, was dahintersteckt, und rechnen nach, wie viel Genauigkeit jede eingesparte Zehntelsekunde kostet, auch auf Deutsch.

Warum Wörter überhaupt umspringen

Eine Streaming-Erkennung bekommt das Audio in kleinen Stücken, den Chunks (Datenblöcken von z. B. 80 oder 160 Millisekunden). Am Ende eines Chunks weiß das Modell oft noch nicht, wie ein Wort ausgeht. „Wahl“ kann zu „Wahlkampf“ werden, „vier“ zu „vierzig“.

Viele Systeme lösen das mit vorläufigen Hypothesen: Sie zeigen ihre beste Vermutung sofort an und überschreiben sie, sobald mehr Audio da ist. Das bekannte Projekt whisper_streaming der Prager Karlsuniversität macht aus dem eigentlich nicht streamingfähigen Whisper ein Live-System, mit einer Regel namens Local Agreement. Whisper rechnet den wachsenden Audiopuffer immer wieder neu durch. Als bestätigt gilt nur, was zwei aufeinanderfolgende Durchläufe übereinstimmend erkennen. Der Preis dafür: Im Paper von 2023 liegt die Verzögerung bei rund 3,3 Sekunden auf Englisch und 4,1 bis 4,4 Sekunden auf Deutsch. Die Genauigkeit liegt dafür fast auf Offline-Niveau (Deutsch: 9,5 statt 9,2 Prozent Wortfehlerrate). Das Repository gilt inzwischen als veraltet und verweist auf den Nachfolger SimulStreaming.

Qwen3-ASR von Alibaba arbeitet ähnlich. Laut technischem Bericht nutzt der Streaming-Modus 2-Sekunden-Chunks und rechnet das bisherige Audio bei jedem Schritt neu. Die letzten fünf Tokens (Wortbausteine) werden dabei jedes Mal neu erzeugt und können sich ändern. Genau das sind die springenden Wörter.

Dass das Flackern stört, ist belegt. In einer Google-Studie von 2023 bewerteten 123 Teilnehmende Untertitel zu 20 YouTube-Clips. Stabilisierte Untertitel wurden bei fünf von sechs Aussagen besser bewertet: weniger Ablenkung, weniger Ermüdung, angenehmer zu lesen. Die Forschenden schreiben:

„Textinstabilität bei Live-Untertiteln beeinträchtigt das Leseerlebnis der Nutzer erheblich.“

Für Sprachagenten und Dolmetsch-Pipelines wiegt das Problem noch schwerer. Das R2T2-Paper bringt es auf den Punkt: Ein ausgegebenes Token sei eine Aktion, denn nachgelagerte Komponenten fangen sofort an, damit zu arbeiten. Wird es später korrigiert, war die Übersetzung umsonst oder der Agent hat womöglich schon das falsche Werkzeug aufgerufen.

Drei Bauweisen, die nicht zurückspringen

Cache-aware Encoder (Nvidia Nemotron): Nemotron Speech ASR (nur Englisch) und Nemotron 3.5 ASR (40 Sprachvarianten, darunter Deutsch) haben je 600 Millionen Parameter. Der Encoder, also der Teil, der das Audio in Merkmale übersetzt, merkt sich in einem Zwischenspeicher (Cache) seine bisherigen Zustände. So wird jedes Audio-Stück laut Modellkarte genau einmal verarbeitet, ohne Überlappung. Die Chunk-Größe ergibt sich aus einem 80-ms-Rahmen plus Look-ahead: Das Modell darf 0, 1, 3, 6 oder 13 Rahmen in die Zukunft hören, bevor es entscheidet. So entstehen die Stufen 80 ms, 160 ms, 320 ms, 560 ms und 1,12 s. Welche Stufe gilt, legst du beim Start fest, ohne neues Training. Der Decoder ist ein RNN-Transducer, der Text Stück für Stück anhängt.

Verzögerte Ströme (Mistral Voxtral Realtime): Das 4,4-Milliarden-Modell macht pro 80-ms-Rahmen einen Schritt und gibt entweder ein Text-Token oder einen Platzhalter („warten“) aus. Ein Wort darf frühestens dann erscheinen, wenn es akustisch abgeschlossen ist und die eingestellte Verzögerung verstrichen ist. Diese Verzögerung lässt sich in 80-ms-Schritten bis 2,4 s wählen. Empfohlen werden 480 ms.

Stable Prefix (NetEase Confucius4-R2T2): Hier wird ein LLM-basiertes Modell, Qwen3-ASR-1.7B, nachtrainiert, das ursprünglich umschreibt. Grundlage sind 1.500 Stunden chinesisches und englisches Audio. Nur der Sprach-Decoder lernt dazu, Audio-Encoder und Architektur bleiben unverändert. Das Modell lernt den längsten stabilen Präfix: den Textanfang, der sich auch mit mehr Audio nicht mehr ändern wird. Dazu kommt eine ausdrückliche „Wait“-Aktion für den Fall, dass es mehr Audio braucht. Ein Parameter U legt fest, wie viele vorläufige Tokens intern zurückgehalten werden. Bei U=1 wird ein Token zurückgehalten, das bringt mehr Qualität. Bei U=0 wird nichts zurückgehalten, das senkt die Verzögerung. Ausgegeben wird in beiden Fällen nur fester Text.

Im R2T2-Paper sind übrigens auch Nemotron 3.5 und Voxtral Realtime als Systeme ohne umschreibbare Zwischenstände gelistet. Umgeschrieben haben in der Tabelle das Qwen3-Basismodell, WhisperRT und die drei kommerziellen APIs (AssemblyAI und zwei ungenannte). Feste Ausgabe ist also nicht neu. Neu ist, dass sie mit einem großen LLM-Decoder bei 160 ms funktioniert.

Vier Zahlen, die alle „Latenz“ heißen

Am meisten Missverständnisse produzieren die 24 ms von Nvidia. Im Blog von Daily, das die Zahl gemessen hat, wird die Finalisierung erst durch 200 ms Stille ausgelöst. Der Server hängt zusätzlich 120 ms künstliche Stille an, weil das Modell 320 ms nachlaufendes Audio braucht, um die letzten Wörter festzuschreiben. Ob diese Zeiten in den 24 ms stecken, sagt der Artikel nicht. Die serverseitigen Werte lauten auf einer RTX 5090 19 ms (Median) und 23 ms (P90). Für den ganzen Sprachagenten, also Sprechende hört auf bis Bot fängt an, nennt Daily serverseitig 508 ms. Im Browser kommen typischerweise 250 ms hinzu, am Telefon weitere 300 bis 600 ms.

Bei ElevenLabs ist nicht nachvollziehbar, was die „unter 150 ms“ von Scribe v2 Realtime messen. Die Dokumentation unterscheidet vorläufige „partial“- und feste „committed“-Transkripte. Festgeschrieben wird automatisch nach einer Stillephase oder per manuellem Befehl, etwa alle 20 bis 30 Sekunden. Laut Dokumentation beginnt die Verarbeitung erst, nachdem die ersten zwei Sekunden Audio gesendet wurden. OpenAI nennt für das neue GPT-Live-Transcribe gar keine Latenzzahl. Laut einem Entwicklerleitfaden können die gestreamten Text-Deltas frühere Wörter wieder ändern.

Unsere Einschätzung: Die Zahlen der offenen Modelle sind zumindest definiert. Sie messen aber reine Modellzeit auf der Audio-Zeitachse. Was beim Nutzer ankommt, ist immer langsamer.

Was jede Zehntelsekunde kostet, auch auf Deutsch

Für Deutsch gibt es vergleichbare Werte auf dem Testdatensatz FLEURS. Angegeben ist die Wortfehlerrate (WER), also der Anteil falscher, fehlender oder überzähliger Wörter. Alle Werte sind Herstellerangaben, und die Textnormalisierung kann sich zwischen den Tabellen unterscheiden.

Nachgerechnet ergibt sich ein klares Muster. Nemotron verliert wenig: Von 1,12 s auf 80 ms steigt die Fehlerrate nur um 1,5 Punkte, aber der Wert sinkt nie unter etwa 8 Prozent. Voxtral zahlt kurze Verzögerungen teuer: Zwischen 480 und 160 ms kommen 3,3 Punkte hinzu, gut ein Punkt pro eingesparter Zehntelsekunde. Ab knapp einer Sekunde ist Voxtral dafür auf Deutsch deutlich genauer als Nemotron. R2T2 liegt bei 160 ms laut NetEase vorn, obwohl Deutsch gar nicht in seinen Trainingsdaten war. Mit U=0 steigt der Wert laut unserer Lesart der Anhangstabelle auf 12,35 Prozent. Die Spaltenzuordnung ist in der Textfassung des Papers allerdings nicht eindeutig. Auf dem zweiten deutschen Test, MLS, kommt R2T2 auf 9,52 Prozent. NetEase selbst schreibt, das Modell sei auf Chinesisch und Englisch optimiert.

Eine unabhängige Studie (arXiv 2604.14493) bestätigt den Trend für Englisch auf der CPU. Nemotron schneidet gestreamt am besten ab, Qwen3-ASR-1.7B dagegen fällt in Blöcken zerlegt von 5,90 auf 9,69 bis 10,45 Prozent. Das Fazit der Autoren: Die Offline-Fehlerrate sagt die Streaming-Qualität schlecht voraus.

Was der Sprung von 21 auf 5,8 Prozent wirklich zeigt

NetEase hebt hervor, dass die Fehlerrate bei 160 ms von 21,01 Prozent (Basismodell) auf 5,76 Prozent (R2T2) sinkt. Das stimmt, ist aber ein ungleicher Vergleich, denn das Basismodell ist für 2-Sekunden-Chunks gebaut. In seiner vorgesehenen Einstellung (2 s, fünf umschreibbare Tokens) erreicht es laut derselben Tabelle 5,25 Prozent, offline 5,15 Prozent. Der eigentliche Fortschritt ist also: ein Zwölftel der Chunk-Größe, kein Umschreiben mehr, und das für rund einen halben Prozentpunkt mehr Fehler.

Gegen Nemotron 3.5 (Mittelwert 14,21) und Voxtral Realtime (19,35) liegt R2T2 im Paper klar vorn. Diese Mittelwerte enthalten aber chinesische Testsätze, und welche Verzögerung bei Voxtral eingestellt war, ist aus der Tabelle nicht sicher abzulesen. Kommerzielle Dienste liegen dicht dahinter (6,01 und 6,23), schreiben laut Paper aber um bzw. legen ihren Text später fest. Werte für den Emission Lag nennt NetEase nur in Grafiken. Im Text heißt es lediglich, der mittlere Lag liege bei 80-ms-Chunks und U=0 unter einer halben Sekunde. Wie oft andere Systeme flackern, hat das Paper ausdrücklich nicht gemessen.

Was du zum Ausprobieren brauchst

Die R2T2-Demo läuft im Browser. Lokal braucht R2T2 (rund 2 Milliarden Parameter, BF16) eine Nvidia-GPU mit vLLM. Es gibt GGUF-Dateien für llama.cpp und eine MLX-Fassung für Apple-Rechner. Ein Nutzer im openHAB-Forum betreibt es auf einer 8-GB-vGPU. Der Code steht unter Apache 2.0, die Gewichte unter einer eigenen NetEase-Modelllizenz. Nemotron 3.5 ist mit 600 Millionen Parametern am genügsamsten. Laut der unabhängigen Studie läuft eine int4-Fassung (0,67 GB) auch auf der CPU. Voxtral Realtime braucht laut Mistral eine GPU mit mindestens 16 GB und steht unter Apache 2.0. Einen eigenen Test mit deutschem Audio haben wir für diesen Artikel nicht durchgeführt.

Einordnung

Für Live-Untertitel zählt vor allem, dass der Text ruhig steht. Eine halbe Sekunde Verzögerung stört weniger als Flackern. Für Dolmetsch-Pipelines gilt das noch mehr, weil jede Korrektur eine Neuübersetzung auslöst. Bei Sprachagenten entscheidet dagegen die Zeit nach dem Satzende, und die hängt stärker an Pausenerkennung und Netzwerk als am Modell.

Unsere Einschätzung: „80 Millisekunden“ heißt fast immer nur, dass das Modell in 80-ms-Schritten arbeitet. Es heißt nicht, dass ein Wort 80 ms nach dem Aussprechen fest auf dem Bildschirm steht. Auf Deutsch kosten die kürzesten Einstellungen grob 1,5 bis 5 Prozentpunkte Fehlerrate gegenüber einer Sekunde Wartezeit, je nach Modell. Die größte Lücke ist die Messung selbst. Weder die Modellkarten noch das Open ASR Leaderboard erfassen bisher, wie oft angezeigter Text umspringt. Der Vorschlag für eine Streaming-Rangliste in einem Fork des Leaderboards (Stand 1. November) sieht Streaming-WER und eine p95-Finalisierungslatenz ab VAD-erkanntem Sprechende vor, Netzwerk bei APIs eingerechnet. Eine Flacker-Kennzahl ist darin noch nicht definiert. Solange das so bleibt, lohnt es sich, bei jeder Echtzeit-Angabe zu fragen: gemessen ab wann, bis wann, und darf der Text danach noch umspringen?