Azure AI Speech LLM 09-2026 Adds 25 Languages: Faster Multilingual Transcription

What's new in LLM Speech 09-2026​

Azure LLM Speech is built for quality, contextual understanding, multilingual support and prompt tuning. It is reached through the shared fast transcription endpoint, not a separate API. The 09-2026 release is a model update on top of that.

Microsoft's announcement lists these changes:

• Language coverage: The new Indic locales are Assamese, Bengali, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Tamil, Telugu and Urdu. Catalan, Malay and Welsh are also new. Microsoft puts the full list at 50 languages across 60+ locales.
• Accuracy: Microsoft cites internal evaluations showing up to a 25% improvement in Token Error Rate and 37% in Entity Error Rate. It says these were measured on internal and public benchmarks, including GigaSpeech and VoxPopuli, with the strongest gains on earnings-domain entities in financial scenarios.
• Speed: The release is up to 2x faster than 2607. Microsoft says the gain is most visible on short clips of 5 to 10 seconds at high concurrency.
• Silence handling: Microsoft says it has reduced hallucinated text on silent or empty audio.
• Rollout: The announcement says no customer action is required. The update deploys automatically on the service side.

How this fits the 2607 release​

The previous release was LLM Speech 2607. It improved multilingual recognition and mixed-language audio, and added an enhanced phrase list feature. That release claimed latency up to 3x faster than the earlier 2605 release. The speed claims therefore compare each release with its immediate predecessor. They don't compound into a single benchmark you can rely on.

Language detection and locale hints​

Microsoft's documentation describes LLM Speech as multilingual. It detects the languages in your audio automatically when you omit the locales field. If you know the locale, naming a supported one such as en-US might improve quality.

This matches the announcement's advice. Leave locale hints out for mixed-language recordings. Use a hint only for audio that is genuinely single-language.

Microsoft's current docs also list the new locale codes: as-IN, bn-IN, gu-IN, kn-IN, ml-IN, mr-IN, or-IN, pa-IN, ta-IN, te-IN, ur-IN, ca-ES, ms-MY and cy-GB. The same table has regional English variants such as en-IN, en-GB and en-US. The Learn page I could retrieve was mid-update. Its "current release" note still said 07 2026, so check the live locale table before you build on a specific code.

A related Learn page gives a caution. Fast Transcription's multilingual model supports a separate set of locales. If your audio's locale isn't supported by that model, provide a fixed supported locale instead. Check the locale table before you drop the hints.

Calling the API​

The request is a multipart/form-data POST to the fast transcription endpoint:

1. Send it to https://<resource>.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15.
2. Attach the audio file as the audio form field.
3. Add a JSON definition field with enhancedMode enabled and the task set to transcribe.
4. Authenticate with the Ocp-Apim-Subscription-Key header. Microsoft's docs recommend keyless Microsoft Entra ID authentication, using a bearer token, for production.

You can combine extra options such as diarization, phraseList, locales, profanityFilterMode and channels. The announcement says the phrase list supports up to 2,000 phrases. I couldn't confirm that limit in the documentation, so verify it before you depend on it.

One correction to the announcement's sample: its locales array is written as [en-in, gu-in, en-us], with unquoted values. Valid JSON needs quoted strings, such as ["en-IN", "gu-IN", "en-US"]. The simplest multilingual request leaves locales out entirely.

Practical impact​

• Contact centers and captioning teams: Languages that once needed a separate workflow can now go through the same call. This matters most for Indian-language recordings.
• Voice agents: The short-clip speed gain is aimed at you. Clips of 5 to 10 seconds at high concurrency are typical of conversational turns.
• Teams in regulated sectors: The announcement's clinical example, with Arabic, Hindi and Indian English in one consultation, is only an illustration. It is not evidence of clinical validity.

Caveats​

• Microsoft doesn't publish per-language results, test sets or methodology for the 25% and 37% figures. The percentages are the best case, since both are stated as "up to".
• The speed claim is a comparison with 2607 under particular conditions. Longer files or low concurrency may not see 2x.
• LLM Speech depends on region availability. Microsoft's docs say you need a Speech resource in a supported region. I could not confirm region details for 09-2026 in the sources I found.
• The model updates automatically, so output can change under you. The docs say the release name isn't a selectable API model identifier. Rerun your regression tests, especially if you compare transcripts or rely on entity extraction.

What to do now​

1. Pull a representative sample of your recordings, including accents, noise and terminology.
2. Test the new locales with and without locale hints.
3. Add a phrase list for product names and acronyms.
4. Compare error rates and latency before and after the update.
5. Try it in the Foundry playground under Azure Speech, Speech to Text, using the new Foundry portal.

Microsoft's headline numbers are plausible. The only way to know whether they hold for your workload is to run your own audio through it.