微软于10月1日宣布推出MAI-Transcribe-2-Streaming。用户说话时，模型会接收音频，并在最终转录稿生成前不断返回变化中的文本。对于要在语音应用中加入实时字幕或语音输入的开发者，关键问题是这些更新如何传给应用，以及何时可以将文本视为定稿。

本文根据文档说明面向正在评估公开预览版的开发者，解释如何集成模型。目标是判断是否要制作原型，并找出应用为显示实时文本和保存最终文本所需完成的客户端工作。微软提供了接口说明和示例代码；BIG CHANGE没有部署模型、运行示例，也没有测量其准确率或延迟。

重大变化

  • 微软推出了一款流式模型，会随着音频到达返回临时文本，随后确认各段转录内容。另有一条MAI-Transcribe-2文件转录流程，面向录制好的音频，并提供另一套有文档说明的选项。
  • 使用Realtime API的应用必须发送格式正确的音频，处理临时文本末尾部分的修订，并决定何时请求完整转录稿。这些选择决定了用户能看到什么，以及下游应用逻辑何时可以依赖最终文本。
  • 该流式模型目前处于公开预览阶段，没有服务等级协议（SLA）。微软不建议将其用于生产工作负载。微软公布的速度和准确率数据属于发布方声明和基准测试结果，并非本文实测。

选择连接方式

微软的Foundry模型目录 列出MAI-Transcribe-2-Streaming，版本为 2026-08-06，并将其列为支持音频输入和文本输出的预览模型。微软的10月1日概述 介绍了两种集成方式：采用类似OpenAI Realtime的WebSocket协议的Realtime API，或Azure Speech SDK。两种方式都会返回中间识别结果和最终识别结果。SDK负责管理连接和音频流；Realtime方式则直接向应用暴露事件。

对于Realtime API，微软要求用户拥有Azure订阅、位于支持区域的Microsoft Foundry资源，以及一个流式模型部署。连接到wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription，并使用Microsoft Entra持有者令牌或API密钥进行身份验证。文档建议使用Entra身份验证。在session.created之后，发送session.update，其中要指定部署名称并设置输入格式。首次追加音频后，即使提交了一个音频片段，也不能再更改此设置。

文档规定的输入是原始、有符号、小端序、单声道PCM16音频，采样率为16或24 kHz，以base64编码的音频块形式发送到input_audio_buffer.append消息中。音频数据不带WAV文件头。微软建议使用较小的音频块，例如10至20毫秒，以降低延迟，同时指出较大的音频块可以减少网络开销。微软的Python示例以100毫秒为单位读取麦克风音频；网页给出的短音频块建议和示例中的块大小是不同选择，并非BIG CHANGE实测结果。

微软的Speech SDK方式 要求使用SDK v1.52.0，并拥有Azure订阅以及Foundry或Speech资源。微软的Python示例将speech_config.model设为MAI-Transcribe-2-Streaming，通过推送流提供16 kHz、16位、单声道音频，并监听recognizing和recognized事件。示例使用一个已有的audio.pcm文件来演示推送流；实际应用需要提供自己的音频来源。这些内容是文档说明的接口和预期事件类型，并非本刊对账户级兼容性的测试。

将临时文本与确认文本分开处理

Realtime事件的含义会影响实时界面。一条conversation.item.input_audio_transcription.delta事件包含刚刚定稿的文本，客户端应用应在不改变空格的情况下将它追加到已确认文本缓冲区；而intermediate事件包含当前临时文本后缀的完整内容；每次收到新的后缀，都要替换上一个后缀。界面可以显示已确认文本缓冲区加上当前后缀；如果把每次中间事件都另存为一行，模型修订文本时就会重复显示词语。

客户端会发送input_audio_buffer.commit，在检测到停顿时或录音结束时。微软称，这会请求尽快生成最终转录稿；input_audio_buffer.committed会确认已提交，随后conversation.item.input_audio_transcription.completed会提供自上一次提交以来这段音频的完整最终文本。Realtime指南指出，此模型的会话配置不支持服务器端轮次检测和自动提交。因此，如果语音应用希望自动完成一个个语音片段，就需要自行确定停顿或轮次边界。文档说明了事件约定，但没有规定哪种边界检测器适用于所有场景。

微软的指南将每个Realtime会话时长限制为一小时。指南还指出，单条音频追加没有单独的确认响应，后续可能产生零个或多个转录事件。开发者评估原型时，应区分音频消息已送达和最终文本已生成，并决定应用如何处理会话断开。微软公开指南中的Python示例包含麦克风队列和错误处理代码，但BIG CHANGE没有运行该示例来验证实际故障表现。

访问、区域与价格

微软称，该模型可在全球范围内访问，Azure会将请求路由到提供服务的区域。10月1日发布的两篇集成指南列出了不同的可用区域：Realtime指南列出瑞典中部、美国中部和印度南部；Speech SDK指南列出瑞典中部、美国中部和东南亚。两者都将美国东部2列为即将推出。请针对计划使用的集成方式，核对当前部署和区域选项；这两篇页面没有提供一份完全一致的区域列表。全球可访问不代表处理一定会在某个特定地点进行。

公告给出的优惠价格为每小时音频0.54美元，优惠持续至2026年底。按算术换算，相当于每1,000分钟音频9美元；应用使用的其他服务或基础设施费用需另计。微软在相应指南中分别链接到Foundry Models和Speech服务的定价页面。查阅的资料没有提供优惠期结束后的费率或实际账单，因此制定部署预算时需要查询当时的价格。

微软称，该流式模型支持60种语言，并可持续自动检测语言。微软还称，接收音频后稍早于100毫秒便会出现首个部分结果，并引用Artificial Analysis的说法，称该模型在准确率排名中领先。Artificial Analysis的流式基准测试以约8小时、按权重组合的数据集测量词错误率，并按照检测到的语音结束时间来计算部分结果和最终结果的延迟。这是针对特定音频及计时规则的基准测试，并不能保证某个应用在100毫秒内显示的词语就是正确的。我们未能在为本文检索到的公开基准测试文本中找到针对该模型的具体结果行，因此没有独立核实微软所称的精确排名。

另一份Azure Speech中的MAI-Transcribe-2指南介绍文件输入，以及说话人分离、词级时间戳、关键词偏置和清洁或逐字记录风格等选项。不要假设MAI-Transcribe-2-Streaming也支持这些控制项：流式集成指南没有说明这些功能。如果产品需要这类输出，请评估文件转录模型，或先通过最新文档和实际测试确认流式版本是否支持，再据此构建。

资料与延伸阅读

  • 微软AI公告，2026年10月1日：产品发布、语言、速度及优惠价格声明。正文已将微软自己的准确率和内部速度声明标明为厂商说法。
  • Microsoft Foundry模型目录，于10月2日查阅：模型版本、预览阶段、输入和输出类型；目录信息不是性能测试。
  • 流式模型概述、Realtime API指南和Speech SDK指南，更新于10月1日：两种有文档说明的集成方式、预览条款、事件行为、示例和区域表。BIG CHANGE没有运行这些示例。
  • Azure Speech中的MAI-Transcribe-2，于10月2日查阅：单独的文件转录流程及其文档所列控制项。该功能列表不能证明流式模型也支持这些功能。
  • Artificial Analysis流式基准测试和方法说明，于10月2日查阅：独立基准测试的设计和计时定义。检索到的公开文本未列出该模型的具体结果，因此无法独立确认其排名。