Azure LLM Speech 09-2026：新增 25 种语言，多语言呼叫管线转录提速 2 倍

服务器技术 2026-11-02 14:48:54 5

最近折腾 Azure LLM Speech 的多语言呼叫转录，顺手把 09-2026 版本和现有管线对了一遍，踩到的坑主要不在接口，而在端点检测、语言候选范围和本地采音这几个环节。这篇把新版能力、实际延迟收益和选型边界说清楚。

微软于 2026 年 10 月 26 日发布 Azure LLM Speech 09-2026。这次更新让 Fast Transcription 端点通过 enhanced mode 接入的旗舰 LLM（Large Language Model，大型语言模型）模型新增了 25 种语言，其中包括 11 种印度语言：阿萨姆语、孟加拉语、古吉拉特语、卡纳达语、马拉雅拉姆语、马拉地语、奥里亚语、旁遮普语、泰米尔语、泰卢固语和乌尔都语，另外还加入加泰罗尼亚语、马来语和威尔士语。

目前模型的覆盖范围已经达到 50 种语言、60 多个区域设置。内部测试数据显示，相比上一版 2607，在高并发场景下处理 5 至 10 秒的短音频，速度最高可提升 2 倍；在 GigaSpeech、VoxPopuli 等基准上，Token Error Rate（词元错误率）最高改善 25%，Entity Error Rate（实体错误率）最高改善 37%，提升尤其明显的是财报领域的专有名词。

Waveforms

先澄清一点：它不是流式模型。Fast Transcription 走的是同步文件链路，你通过 POST（应用程序接口的 HTTP 提交方式）发送音频文件或音频 URL，服务端完成识别后返回可直接展示的转录文本，而且速度可以快于实时音频时长。enhanced mode 会把请求路由到 Azure LLM Speech，模型版本由服务托管，客户端不需要也不能固定某个版本字符串，服务端会自动完成版本切换和发布。

Fast Transcription 接口

公告示例使用的 REST（Representational State Transfer，表述性状态转移）端点如下，api-version 为 2025-10-15：

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" }'

对接近实时的呼叫管线来说，有几个配置点值得留意：

enhancedMode.enabled: true 会选择 LLM Speech 链路，也可以把 task 改成翻译。
locales 是可选配置。模型本身支持多语言，省略时会尝试自动检测；如果业务场景已经知道候选语言，例如面试或客服电话，可以传一个短列表来缩小检测范围。
短语列表可以偏向特定领域术语，不需要训练完整的自定义模型。
接口支持说话人分离，返回的每个短语都带有说话人索引。
云端链路的文件限制比较宽松，Fast Transcription 文档给出的上限是 5 小时、500 MB。支持 WAV、MP3、OPUS/OGG、FLAC 等容器，单声道 16 位 PCM、48 kHz 仍然是最省事、最稳定的选择。

Lattice wave

响应是 JSON（JavaScript Object Notation，JavaScript 对象表示法）格式，包含 combinedPhrases，每个短语还提供 text、offsetMilliseconds、durationMilliseconds、声道和说话人信息。展示格式已经包含标点与大小写，适合直接交给下一步的 LLM，因为它更期待可读文本，而不是一串词元。

短音频为什么值得追求 2 倍提速

现在很多所谓“实时” STT（Speech-to-Text，语音转文本）方案，底层仍然假设持续音频流。实际工程里，常见模式是先缓存 3 至 15 秒音频，再发一次请求更新界面或给推理模型喂数据。Fast Transcription 针对的就是这种模式：它处理的是一段已经完整的语句，因此延迟更稳定，也不会像流式识别那样不断修改部分结果。

在 Windows 上，采音通常才是延迟预算里最贵的部分。WASAPI（Windows Audio Session API，Windows 音频会话 API）独占模式、低周期共享模式，以及通过 loopback client 捕获系统声音，都有各自的缓冲开销。如果进程光是收集一段干净音频就要花 80 至 120 毫秒，重采样或混合声道又需要 20 至 40 毫秒，那么原来处理 7 秒音频需要 800 毫秒的云端往返，现在缩短到约 400 毫秒，用户对悬浮字幕的感受会明显不同。

模型变快不会修复采音链路，它只是让网络与推理这一段不再占据主要耗时。

取舍依然很直接：

云端链路需要网络、密钥管理，并意味着音频会离开本机。对于 BYOK（Bring Your Own Key，自带密钥）模式的应用，密钥不进入安装包，由用户自行提供，再通过 DPAPI（Data Protection API，数据保护 API）或同类机制保存。
本地模型仍然有自己的优势。Whisper.cpp、faster-whisper，以及体积控制在几 GB 以内的小型 Nemotron/Parakeet 级检查点，在必须离线处理，或者需要低于 200 毫秒的部分结果且不想承担网络往返时更合适。代价是它们在长尾语言和特定行业词汇的实体准确率上通常较弱，而这恰好是 Azure LLM Speech 这次重点改进的部分。
流式模型适合说话人还没说完就要持续输出结果的场景，例如微软自家的 MAI-Transcribe-2-Streaming、OpenAI 的实时 Whisper 变体等。Fast Transcription 则适合等待一句话结束，或者处理已经录制好的音频片段。

一套实用的 Windows 管线

下面这个最小 Python（编程语言）客户端会提交一段短 WAV 音频，并打印合并后的文本：

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": "task": "transcribe"}, "locales": ["en-US", "hi-IN"], "phraseList": {"phrases": ["Talkaside", "WASAPI", "endpointing"]}, "diarization": {"enabled": "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"])

采音部分仍然要自己负责，常见做法有：

使用 WASAPI loopback 捕获系统声音，同时录制麦克风，并保存为双轨，方便后续分离说话人，或者把远端客户和本地用户直接分开。
按固定长度切块，或者通过 VAD（Voice Activity Detection，语音活动检测）触发切块。可以使用 Silero VAD，也可以采用简单的能量门限。音频先写入环形缓冲区，再导出为临时 WAV，或者以内存流发送。
POST 之前重采样为 16 kHz 或 48 kHz 单声道。服务端本身也能重采样，但在本地使用高质量重采样器，例如 libsoxr、r8brain 或 FFmpeg（Fast Forward and Reverse Forward，自称多媒体框架工具）内置的 resampler，通常能让云端处理更快、更稳定。

真正难搞的仍然是端点检测。即使模型快了 2 倍，一个不靠谱的静音检测器如果从句子中间截断，或者在最后一个音素之后还要等待 800 毫秒，体验依然会显得迟钝。Azure 这次更新提升的是音频到达后的识别质量，不会自动替业务方生成更好的 VAD。

什么时候该用，什么时候不该用

以下情况适合通过 Fast Transcription 使用 Azure LLM Speech 09-2026：

业务需要新增的印度语言或其他长尾语言支持。
领域术语的实体准确率很重要，而且一份短语列表就能解决大部分问题。
现有架构本来就会缓存完整语句。
业务能够接受云端往返的延迟和调用成本。

如果端到端延迟预算低于约 300 毫秒，或者音频绝对不能离开设备，优先考虑本地模型或真正的流式接口。

这两套方案并不冲突。一个比较稳的组合是：先在本地用 VAD 和端点检测确定音频块，再根据语言类型和隐私等级选择本地 STT，或者调用 Fast Transcription。

09-2026 本质上是服务端升级。已经设置 enhancedMode.enabled 的客户端不需要改代码就能获得新版能力。用起来确实省事，但也提醒了一件事：模型质量和速度指标并不完全由应用控制，别只盯着发布会数据。最好拿自己的真实呼叫音频持续监控 WER（Word Error Rate，词错误率），再决定是否切换策略。

我正在做 Talkaside，一款面向跨语言求职面试和商务通话的 Windows 应用。这个版本里的选型取舍，很大一部分都来自项目实际代码和运行日志。