Microsoft kündigte MAI-Transcribe-2-Streaming am 1. Oktober an. Das Modell verarbeitet Audio während des Sprechens und liefert wechselnden Text, bevor ein endgültiges Transkript vorliegt. Für Entwickler, die einer Sprach-App Live-Untertitel oder Spracheingabe hinzufügen, ist entscheidend, wie die Aktualisierungen die App erreichen und wann sie als endgültig gelten können.

Dies ist ein dokumentationsbasierter Integrationsleitfaden für Entwickler, die die öffentliche Preview prüfen. Sie sollen entscheiden können, ob sie das Modell prototypisch testen und welche Client-Logik nötig ist, um Live-Text anzuzeigen und den endgültigen Text zu übernehmen. Microsoft dokumentiert den Verbindungsweg und Beispielcode; BIG CHANGE hat das Modell weder eingesetzt noch die Beispiele ausgeführt oder Genauigkeit und Latenz gemessen.

Die große Änderung

  • Microsoft hat ein Streaming-Modell eingeführt, das vorläufigen Text liefert, sobald Audio eingeht, und anschließend Transkriptabschnitte bestätigt. Der separate Dateitranskriptionsweg MAI-Transcribe-2 verarbeitet aufgezeichnetes Audio und dokumentiert andere Optionen.
  • Eine App, die die Realtime API nutzt, muss korrekt formatiertes Audio senden, Änderungen am vorläufigen Textende verarbeiten und entscheiden, wann sie ein vollständiges Transkript anfordert. Davon hängt ab, was Nutzer sehen und ab wann sich nachgelagerte App-Logik auf den endgültigen Text verlassen kann.
  • Das Streaming-Modell ist eine öffentliche Preview ohne Service Level Agreement. Microsoft empfiehlt es nicht für den Produktionseinsatz. Die genannten Angaben zu Geschwindigkeit und Genauigkeit stammen aus der Produkteinführung und aus Benchmarks; sie wurden in diesem Leitfaden nicht gemessen.

Wählen Sie einen Verbindungsweg

Der Microsoft-Foundry-Modellkatalog führt das Modell MAI-Transcribe-2-Streaming, Version 2026-08-06, als Preview-Modell mit Audioeingabe und Textausgabe auf. Microsofts Übersicht vom 1. Oktober beschreibt zwei Integrationswege: eine Realtime API mit einem WebSocket-Protokoll ähnlich der OpenAI Realtime API oder das Azure Speech SDK. Beide liefern vorläufige und endgültige Erkennungsergebnisse. Das SDK verwaltet Verbindung und Audiostream; bei der Realtime API verarbeitet die App die Ereignisse direkt.

Für die Realtime API verlangt Microsoft ein Azure-Abonnement, eine Microsoft-Foundry-Ressource in einer unterstützten Region und ein Deployment des Streaming-Modells. Stellen Sie die Verbindung wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription mit einem Microsoft-Entra-Bearer-Token oder API-Schlüssel her. Die Dokumentation empfiehlt die Entra-Authentifizierung. Sobald session.created eingegangen ist, senden Sie session.update mit dem Deploymentnamen und dem Eingabeformat. Nach dem ersten Audioanhängen lässt sich das Format nicht mehr ändern, auch nicht nach einem Commit.

Als Eingabe dient laut Dokumentation rohes, vorzeichenbehaftetes PCM16-Audio im Little-Endian-Format, mono und mit 16 oder 24 kHz, das als Base64-Blöcke in input_audio_buffer.append-Nachrichten übertragen wird. Die PCM-Daten enthalten keinen WAV-Header. Microsoft empfiehlt kleine Blöcke von etwa 10 bis 20 Millisekunden, um die Latenz zu verringern, weist aber darauf hin, dass größere Blöcke den Netzwerkaufwand senken. Das Python-Beispiel liest Mikrofon-Audio in 100-ms-Blöcken ein. Der Rat zu kleinen Blöcken auf der Dokumentationsseite und die Blockgröße im Beispiel sind unterschiedliche Optionen und kein Messergebnis von BIG CHANGE.

Der Weg über das Speech SDK erfordert SDK v1.52.0, ein Azure-Abonnement sowie eine Foundry- oder Speech-Ressource. Im Python-Beispiel von Microsoft wird speech_config.model auf MAI-Transcribe-2-Streaming gesetzt. Es stellt 16-kHz-Mono-Audio mit 16 Bit über einen Push-Stream bereit und wartet auf recognizing sowie recognized Ereignisse. Das Beispiel verwendet eine vorhandene audio.pcm-Datei, um den Push-Stream zu veranschaulichen; eine App muss ihre eigene Audioquelle bereitstellen. Das sind dokumentierte Schnittstellen und erwartete Ereignistypen, kein Kompatibilitätstest mit einem echten Konto durch diese Redaktion.

Vorläufigen und bestätigten Text getrennt behandeln

Die Bedeutung der Realtime-Ereignisse ist für eine Live-Oberfläche entscheidend. Ein conversation.item.input_audio_transcription.delta-Ereignis enthält neu endgültig erkannten Text, den der Client an den bestätigten Textpuffer anhängt, ohne die Abstände zu verändern. Ein intermediate-Ereignis enthält den gesamten aktuellen vorläufigen Textzusatz. Jeder neue Zusatz ersetzt den vorherigen. Auf dem Bildschirm können der bestätigte Textpuffer und dieser aktuelle Zusatz gemeinsam erscheinen. Werden alle Zwischenereignisse als neue Zeile gespeichert, wiederholen sich Wörter, wenn das Modell seine Erkennung korrigiert.

Der Client sendet input_audio_buffer.commit bei einer erkannten Sprechpause oder am Ende einer Aufnahme. Laut Microsoft fordert dies so bald wie möglich ein endgültiges Transkript an; input_audio_buffer.committed bestätigt den Commit und conversation.item.input_audio_transcription.completed liefert den vollständigen endgültigen Text für die Audioeingabe seit dem vorherigen Commit. Der Leitfaden zur Realtime API weist darauf hin, dass die Erkennung von Sprecherwechseln auf dem Server und automatische Commits für die Sitzungskonfiguration dieses Modells nicht verfügbar sind. Eine Sprach-App braucht daher selbst eine Pausen- oder Sprecherwechselerkennung, wenn sie Abschnitte automatisch abschließen soll. Die Dokumentation beschreibt den Ereignisvertrag, schreibt aber keine für alle Fälle geeignete Erkennungsmethode vor.

Der Leitfaden von Microsoft begrenzt jede Realtime-Sitzung auf eine Stunde. Ein angehängter Audioblock erhält demnach keine eigene Bestätigung und kann null, ein oder mehrere Transkriptionsereignisse auslösen. Wer einen Prototyp prüft, sollte unterscheiden, ob eine Audio-Nachricht eingegangen ist oder ob endgültiger Text vorliegt, und festlegen, wie die App mit einer unterbrochenen Sitzung umgeht. Das öffentlich verfügbare Python-Beispiel enthält eine Mikrofon-Warteschlange und Fehlerbehandlung; BIG CHANGE hat es nicht ausgeführt und daher auch kein tatsächliches Fehlerverhalten ermittelt.

Zugang, Regionen und Preis

Microsoft zufolge ist das Modell weltweit verfügbar; Azure leitet Anfragen an Regionen mit Modellbereitstellung weiter. Die beiden Integrationsleitfäden vom 1. Oktober nennen unterschiedliche verfügbare Regionen: Der Realtime-Leitfaden führt Sweden Central, Central US und South India auf; der Speech-SDK-Leitfaden nennt Sweden Central, Central US und Southeast Asia. Beide listen East US 2 als demnächst verfügbar. Prüfen Sie die aktuellen Deployment- und Regionsoptionen für den gewünschten Verbindungsweg; die Seiten bieten keine einheitliche Liste. Die weltweite Verfügbarkeit garantiert keinen bestimmten Verarbeitungsstandort.

In der Ankündigung wird ein Einführungspreis von 0,54 US-Dollar pro Audiostunde bis Ende 2026 genannt. Rechnerisch entspricht das 9 US-Dollar pro 1.000 Audiominuten, ohne weitere Dienste oder Infrastruktur, die eine App nutzt. Microsoft verlinkt in den Anleitungen auf Foundry-Models- und Speech-Service-Preisseiten für die jeweiligen Wege. Die geprüften Quellen nennen weder einen Preis nach dem Einführungszeitraum noch eine tatsächlich abgerechnete Summe. Für die Budgetplanung einer Bereitstellung müssen Sie daher die aktuellen Preise prüfen.

Laut Microsoft unterstützt das Streaming-Modell 60 Sprachen mit fortlaufender automatischer Erkennung. Das erste vorläufige Ergebnis erscheine etwas mehr als 100 ms nach Eingang des Audios; außerdem beruft sich Microsoft für die Genauigkeit auf Artificial Analysis. Der Streaming-Benchmark von Artificial Analysis misst die Wortfehlerrate anhand gewichteter Datensätze mit insgesamt etwa acht Stunden Audiomaterial. Außerdem erfasst er die Zeit bis zu vorläufigen und endgültigen Ergebnissen, gemessen ab dem erkannten Ende der Spracheingabe. Das Ergebnis gilt für festgelegte Audiodaten und Zeitmessregeln. Es garantiert nicht, dass eine bestimmte App innerhalb von 100 ms korrekte Wörter anzeigt. Den konkreten Rang, den Microsoft für das Modell angibt, konnten wir anhand der öffentlich abgerufenen Benchmark-Daten nicht unabhängig überprüfen, da dort keine modellbezogene Ergebniszeile sichtbar war.

Der separate Azure-Speech-Leitfaden für MAI-Transcribe-2 dokumentiert Datei-Eingabe und Optionen wie Sprecherzuordnung, Zeitstempel auf Wortebene, Schlüsselwortgewichtung sowie bereinigte oder wortgetreue Transkription. Gehen Sie nicht davon aus, dass diese Funktionen mit MAI-Transcribe-2-Streaming verfügbar sind: Die Streaming-Anleitungen dokumentieren sie nicht. Wenn ein Produkt diese Ausgaben benötigt, prüfen Sie das Dateimodell oder bestätigen Sie die Streaming-Unterstützung anhand aktueller Dokumentation und eines Tests, bevor Sie die weitere Entwicklung davon abhängig machen.

Quellen und weiterführende Informationen

  • Microsoft-KI-Ankündigung, 1. Oktober 2026: Veröffentlichung, Sprachen, Geschwindigkeits- und Einführungspreisangaben. Die Aussagen von Microsoft zu Genauigkeit und interner Geschwindigkeit sind oben als Herstellerangaben gekennzeichnet.
  • Microsoft-Foundry-Modellkatalog, geprüft am 2. Oktober: Modellversion, Preview-Status, Ein- und Ausgabeformate; der Katalog enthält keinen Leistungstest.
  • Streaming-Übersicht, Leitfaden zur Realtime API und Leitfaden zum Speech SDK, aktualisiert am 1. Oktober: die beiden dokumentierten Integrationswege, Preview-Bedingungen, Ereignisverhalten, Beispiele und Regionstabellen. BIG CHANGE hat die Beispiele nicht ausgeführt.
  • MAI-Transcribe-2 in Azure Speech, geprüft am 2. Oktober: der separate Dateitranskriptionsweg und seine dokumentierten Optionen. Die Funktionsliste belegt keine Funktionsgleichheit mit dem Streaming-Modell.
  • Streaming-Benchmark von Artificial Analysis und Methodik, geprüft am 2. Oktober: unabhängiger Benchmark-Aufbau und Definitionen der Zeitmessung. Im abgerufenen öffentlichen Text war kein genaues, modellbezogenes Ergebnis für eine unabhängige Rangbestätigung zu sehen.