做过语音 Agent 的人大多踩过同一个坑：用户一句话还没说完，系统只能干等，等到判定「说完了」才开始转写、再把文本交给大模型，一来一回几百毫秒甚至几秒就没了。客服场景里用户最怕的就是「我说完了你怎么还没反应」，实时字幕场景里观众最怕的是「字幕比讲话慢半拍」。问题不在大模型推理慢，而在转写这一环的交互模式：非流式转写必须拿到完整音频才开工，延迟是结构性的，优化空间很小。微软在 2026 年 10 月 1 日发布的 MAI-Transcribe-2-Streaming，就是冲着这个结构性问题来的------转写在讲话进行的同时持续输出，最终转录延迟压到 0.13 秒，词错误率 2.50%，在 Artificial Analysis 的流式语音转文字榜单上力压 28 个模型登顶。这篇文章拆开看它到底改了什么、工程上怎么用、值不值得接。
先说清楚：流式转写到底解决了什么
传统语音转写是「录音-上传-等待-拿结果」的批处理模式。你把一段音频文件交给服务，它处理完之后一次性返回全文。这个模式对会议记录、临床文书、播客转写这类离线任务很合适，但对实时对话是灾难：系统必须先用端点检测判断用户说完了，再启动转写，转写完才能进入意图理解和推理。整条链路里最浪费的不是计算时间，而是「等」的时间。
流式转写把这个模式倒过来：音频边进边出文字。模型每收到一小段音频就吐出一版「部分结果」，随着上下文增多不断修正，等一句话真正结束时，最终文本几乎在同一瞬间提交。这意味着下游的大模型不用等用户说完就可以开始理解意图、预加载工具调用，客服智能体甚至可以在来电者话说到一半时就开始检索答案。所谓「所说即所见」的实时字幕，靠的也是这个机制。
MAI-Transcribe-2-Streaming 是什么
这是微软第一个实时流式语音转写模型，定位是 MAI-Transcribe-2 的流式版本。此前微软已经发布过非流式的 MAI-Transcribe-2，在 Azure Speech 公共预览阶段以每小时 0.10 美元的价格提供，60 语种平均词错误率 5.2%。这次的 Streaming 版把交互模式从批处理改成了持续流，同时把精度又往上推了一大截：在 Artificial Analysis 于 9 月 28 日公布的流式语音转文字排行榜中，它的最终词错误率为 2.50%，最终转录延迟 0.13 秒，在 28 个参评模型中排第一。
语言覆盖方面，它支持 60 种语言，并且具备自动、连续的语言检测能力。这一点对出海产品很关键：用户不需要在会话开始前手动指定语言，系统可以根据语音内容识别语言变化，中途切换语言也能跟上。接入渠道有三个：Microsoft Foundry、MAI Playground 和 OpenRouter，目前处于优惠阶段，每小时 0.54 美元，约合每 1000 分钟 9 美元。
延迟解剖：0.13 秒是怎么量出来的
流式转写的延迟不是一个数字，而是三个。第一个是「首部分延迟」：从收到音频到吐出第一版部分文本，MAI-Transcribe-2-Streaming 在 100 多毫秒内就能给出。第二个是「可见延迟」：微软自己的实时评估里，文字最快在语音出现后约 320 毫秒显示在屏幕上。第三个是「最终延迟」：一句话结束后多久提交稳定的最终文本，Artificial Analysis 测出来是 0.13 秒。
这三个数字对应工程上三种不同的用法。首部分延迟决定你的下游系统能多早开工------拿到第一个词就可以开始做意图预判。可见延迟决定用户体验------字幕跟不跟嘴。最终延迟决定整条链路的尾延迟------最终文本提交后，大模型才能拿到可靠输入做正式推理。微软强调该模型在「最终转录」和「首次部分转录」两个指标上均排名第一，也就是说它不是只在某一个口径上刷榜，而是整条流式链路都快。
值得展开的是「持续修正」这个机制。流式模型给出的部分结果不是定稿，随着更多音频进来，前面已经输出的词可能被改写------比如先听到「我要订一张」时猜不出宾语，听到后半句才把「bai 京」修正为「北京」。这个特性决定了下游消费部分结果时必须允许覆写，UI 上字幕要支持局部替换，Agent 侧的预判逻辑也要设计成「可作废」的：基于部分文本启动的检索，在最终文本提交后要有一次对齐校验，避免拿被修正掉的旧词去触发动作。很多团队第一次接流式转写时忽略这一点，结果用户看到字幕来回跳、Agent 拿着错误意图提前调了工具，体验反而更差。
榜单横向对比：2.50% 的含金量
词错误率每降一个百分点，在真实业务里意味着明显的体验差异。下面这张表整理了三甲模型的关键指标：
| 模型 | 最终词错误率 | 最终转录延迟 | 备注 |
|---|---|---|---|
| MAI-Transcribe-2-Streaming | 2.50% | 0.13 秒 | 双指标第一，60 语种 |
| Grok Voice Transcribe 2.0 Streaming | 2.73% | 略高于第一名 | xAI 出品 |
| ElevenLabs Scribe v2 Realtime | 3.59% | 中等 | 语音克隆厂商跨界 |
从 2.73% 到 2.50% 看着只差 0.23 个百分点，但放在每小时上万通电话的客服系统里，就是每小时少出几十处转写错误，每一处错误都可能让下游大模型理解偏意图。更值得注意的是对比它自己的非流式版本：MAI-Transcribe-2 的 60 语种平均词错误率是 5.2%，流式版直接砍到 2.50%，说明流式化并没有以精度为代价，反而借更强的建模把精度翻了倍。
流式还是非流式：工程上怎么选
两个版本不是替代关系，而是分工关系。选择逻辑可以用一句话概括：用户是否在等结果。如果链路里有人在实时等待------语音助手对话、实时字幕、同声传译、客服座席辅助------流式是唯一答案，因为延迟是体验的硬约束。如果任务是处理已有音频------会议录像转写、医疗文书、合规质检、内容审核------非流式更合适，它价格更低（0.10 美元对 0.54 美元每小时），一次性返回全文也更省事。
还有一个混合策略值得考虑：用流式版跑实时交互，拿到最终文本后落库；对精度要求极高的场景（比如医疗），后台再用非流式批处理复核一遍。两条链路互补，成本和体验都不牺牲。
成本敏感型业务还有一层账要算。非流式版每小时 0.10 美元，流式版每小时 0.54 美元，差出五倍多。如果你的产品是异步场景硬套了流式接口，等于为不需要的实时性付了五倍溢价；反过来，如果是实时对话场景为了省钱用了非流式，用户流失造成的损失远不止这点差价。选型的第一性问题永远是「链路上有没有人在实时等」，而不是哪个单价便宜。
上手：一个最小流式转写客户端
流式接入的核心是把音频切成小 chunks 持续推送，同时异步接收部分结果和最终结果。下面的伪代码展示了典型骨架，实际接入时替换为 Microsoft Foundry 或 OpenRouter 的鉴权和端点即可：
python
import asyncio, websockets, json
async def stream_transcribe(audio_chunks, ws_url, api_key):
async with websockets.connect(
ws_url, extra_headers={"Authorization": f"Bearer {api_key}"}
) as ws:
await ws.send(json.dumps({
"language": "auto", # 自动语言检测，免手动指定
"partial_results": True # 打开部分结果推送
}))
async def send_audio():
async for chunk in audio_chunks: # 每 20~40ms 一个 chunk
await ws.send(chunk)
await ws.send(json.dumps({"event": "end_of_speech"}))
async def recv_text():
async for msg in ws:
data = json.loads(msg)
if data["type"] == "partial":
yield ("partial", data["text"]) # 可做意图预判
elif data["type"] == "final":
yield ("final", data["text"]) # 0.13s 内提交
sender = asyncio.create_task(send_audio())
async for kind, text in recv_text():
handle(kind, text) # partial 喂预判，final 喂正式推理
await sender关键设计有两点。一是 partial 结果不要扔：它是下游系统抢跑的信号，客服 Agent 可以拿它提前检索知识库。二是 final 结果才是权威：涉及写库、触发工具调用这类有副作用的操作，只认 final。
价格、边界与落地建议
成本上，优惠期每小时 0.54 美元约合 3.6 元人民币，每 1000 分钟约 60.5 元。对一个日均一万分钟通话的客服中心，月成本大约 1.8 万元，换来的是平均几秒级的响应提速和 2.50% 的词错误率，在多数 B 端场景里这笔账是划算的。个人开发者可以先用 MAI Playground 免费体验验证效果，再决定接哪个渠道。
边界也要看清。一是榜单成绩基于 Artificial Analysis 的标准测试集，真实场景里的口音、噪声、专业术语仍然需要自己的评测集兜底------建议拿业务里最近一个月的真实录音抽两三百条，人耳标注后算一遍词错误率，这个数字比任何公开榜单都更接近你的上线效果。二是自动语言检测虽方便，但在中英混杂极其频繁的会话里建议实测后再决定是否关掉手动指定，混合语种的切分点仍是业界难点。三是优惠期定价之后大概率回调，预算规划时别把现价当永久价，把回调到非流式与非流式之间常规差价的情景也跑一遍测算。
落地节奏上，建议分三步走：先在测试环境用录好的真实音频跑通流式链路，验证部分结果的修正频率是否在你的 UI 和 Agent 逻辑可承受范围内；再小流量灰度到真实用户，盯首部分延迟和最终延迟的实际分布而不是平均值；最后才全量切换并下线旧的批处理链路。每一步都留好回退开关，流式链路对网络抖动比批处理敏感得多，弱网环境下的表现必须在灰度阶段暴露出来。
回到开头那个问题：语音 Agent 的「等你说完」税，本质是转写架构的税。MAI-Transcribe-2-Streaming 这类模型把转写从批处理变成流，等于把整条语音链路的最大瓶颈松开了。接下来语音应用的竞争点，会从上层的 prompt 和编排，下沉到「谁能把首词延迟、最终延迟、错误率这三个数字同时压到最低」。这一轮，微软先交卷了。