Azure LLM Speech 09-2026: 25 New Languages and 2 Faster Fast Transcription for Multilingual Call Pipelines

Microsoft released Azure LLM Speech 09-2026 on 26 October 2026, expanding the LLM-powered enhanced mode of its Fast Transcription endpoint to 25 additional languages, including 11 Indic languages, bringing coverage to 50 languages across 60+ locales. Internal benchmarks show up to 2× faster processing on 5–10 second clips under high concurrency, with up to 25% better Token Error Rate and 37% better Entity Error Rate on GigaSpeech and VoxPopuli, particularly on earnings-domain entities. The service-managed model rolls out automatically with no client-side version pinning, and developers enable it via enhancedMode in the synchronous transcription REST API.

Microsoft announced Azure LLM Speech 09-2026 on 26 October 2026. The update expands the flagship LLM-powered model available through enhanced mode on the Fast Transcription endpoint to 25 additional languages—including 11 Indic languages Assamese, Bengali, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Tamil, Telugu, Urdu —plus Catalan, Malay, and Welsh. Coverage now sits at 50 languages across 60+ locales. Internal numbers show up to 2× faster processing than the prior 2607 release on short clips 5–10 s under high concurrency, with up to 25 % better Token Error Rate and 37 % better Entity Error Rate on benchmarks such as GigaSpeech and VoxPopuli, especially on earnings-domain entities. This is not a streaming model. Fast Transcription is the synchronous file path: you POST an audio file or URL and get a display-form transcript back faster than real-time. Enhanced mode routes the request to Azure LLM Speech. The model is service-managed; you do not pin a version string in the client. The release rolls out automatically on the service side. The REST endpoint looks like this api-version 2025-10-15 in the announcement examples : curl --location 'https://<YourResourceName .cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15' \ --header 'Content-Type: multipart/form-data' \ --header 'Ocp-Apim-Subscription-Key: <YourSpeechResourceKey ' \ --form 'audio=@"YourAudioFile.wav"' \ --form 'definition={ "enhancedMode": { "enabled": true, "task": "transcribe" }, "diarization": { "maxSpeakers": 2, "enabled": true }, "phraseList": { "phrases": "Kenichi Kumatani", "John McDonough" }, "locales": "en-in", "gu-in", "en-us" , "profanityFilterMode": "Masked" }' Key points that matter for a live-adjacent pipeline: enhancedMode.enabled: true selects the LLM Speech path. You can also request translation as the task. locales is optional. The model is multilingual and will attempt detection when omitted. Supplying a short list helps when you already know the candidate languages common in interview or support calls . The response is JSON with combinedPhrases , per-phrase text , offsetMilliseconds , durationMilliseconds , channel, and speaker. Display form includes punctuation and capitalization—useful when the next step is an LLM that expects readable text rather than lexical tokens. Most “real-time” STT marketing still assumes continuous streams. In practice a large class of tools buffer 3–15 s of audio, fire a request, and update a UI or feed a reasoning model. That pattern is exactly what Fast Transcription was built for: predictable latency on a complete utterance instead of partial hypotheses that keep mutating. On Windows the capture side is still the expensive part of the budget. WASAPI exclusive mode, shared mode with a low period, or a loopback client for system audio all have their own buffering. If your process is already spending 80–120 ms collecting a clean buffer and another 20–40 ms on resampling or channel mixing , a cloud round-trip that used to take 800 ms on a 7 s clip and now takes ~400 ms changes the feel of the overlay. The model improvement does not fix your capture graph; it just makes the network+inference leg less dominant. Trade-offs remain obvious: A minimal Python client that posts a short WAV and prints the combined text: python import requests url = "https://YOUR RESOURCE.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15" headers = {"Ocp-Apim-Subscription-Key": "YOUR KEY"} definition = { "enhancedMode": {"enabled": True, "task": "transcribe"}, "locales": "en-US", "hi-IN" , "phraseList": {"phrases": "Talkaside", "WASAPI", "endpointing" }, "diarization": {"enabled": True, "maxSpeakers": 2} } files = { "audio": open "clip.wav", "rb" , "definition": None, str definition .replace "'", '"' , "application/json" } r = requests.post url, headers=headers, files=files, timeout=30 r.raise for status print r.json "combinedPhrases" 0 "text" On the capture side you still own the graph. Common patterns: Endpointing remains the hard problem. Even with a 2× faster model, a bad silence detector that cuts mid-sentence or waits 800 ms after the last phoneme still feels laggy. The Azure update improves the recognition quality once the audio arrives; it does not invent a better VAD for you. Use Azure LLM Speech 09-2026 via Fast Transcription when: Prefer a local model or a true streaming endpoint when the latency budget is under ~300 ms end-to-end or when the audio must never leave the device. The two approaches compose cleanly: local VAD + local endpointing to decide the chunk, then either a local STT or a Fast Transcription POST depending on language and privacy mode. The 09-2026 release is a service-side bump. Existing clients that already set enhancedMode.enabled pick it up without a code change. That is both convenient and a reminder that quality and speed numbers are not under your control—monitor your own WER on representative call audio rather than trusting the press numbers alone. I'm building Talkaside https://talkaside.com/ , a Windows app for job interviews and calls in another language. Drafted with AI assistance from this project's code and logs.