首页科技媒体TestingCatalog近日披露，微软正在封闭测试一款名为MAI Realtime的原生实时语音模型。从目前曝光的MAI Playground测试界面来看，MAI Realtime可能是微软MAI模型家族中首款面向双向实时语音交互设计的模型。它能够在接收用户音频的同时生成语音回复，并针对用户插话、语言切换和对话端点检测提供专门配置。
不过，截至目前，微软尚未正式发布MAI Realtime，也没有公布模型卡、API文档、价格、延迟或并发限制。现阶段能够确认的信息主要来自TestingCatalog对隐藏测试入口的观察，因此本文所述能力仍应视为早期测试信息，而非最终产品规格。
一. MAI Realtime是什么？
MAI Realtime是一款尚处于封闭测试阶段的实时语音模型。
与微软已经发布的MAI-Voice-2和MAI-Transcribe-1.5不同，MAI Realtime并不是单独完成语音合成或语音识别，而是试图在同一个实时交互系统中完成音频输入理解、回复生成和语音输出。
MAI-Voice-2本质上是一款文本转语音模型，主要负责将文本生成自然语音；MAI-Transcribe-1.5则是一款语音识别模型，负责把音频转换成文本。微软官方已经确认，MAI-Voice-2支持15种语言，而MAI-Transcribe-1.5支持43种语言，但后者的原生流式API仍被列在后续开发计划中。
MAI Realtime的差异在于，它面向的是持续进行的实时对话，而不是一次独立的识别或合成任务。
为什么实时语音模型更适合Voice Agent？
传统Voice Agent通常需要依次经过语音识别、语言模型和语音合成三个环节：
用户说话 → ASR识别文本 → LLM生成回答 → TTS合成语音。
这种级联式架构便于分别替换不同模块，但每增加一个处理环节，都可能引入额外等待时间和上下文损失。
原生实时语音模型则可以持续接收音频流，并在内部协调语音理解、回复生成和语音输出。理论上，这种架构能够缩短用户停止说话到模型开始回应之间的等待时间，也更容易处理语气、停顿、重音和插话等语音信息。
二. 全双工是MAI Realtime的核心方向
TestingCatalog将MAI Realtime描述为一套双向、全双工语音系统，即模型能够同时监听用户输入和生成语音输出。
在传统轮流对话模式中，系统通常需要等待用户说完，才能开始处理并回复。用户讲话和模型回答形成一个相对严格的交替过程。
全双工系统不要求输入和输出完全分离。模型在播放回复时，麦克风通道仍然可以继续接收用户音频，并判断用户是在正常附和、发出背景声音，还是有意打断当前回答。
MAI Realtime测试界面，支持实时语音交互与全双工对话。图片来源：TestingCatalog。
全双工并不等于双方始终同时说话
所谓全双工，重点并不是让用户和模型不断同时发声，而是让系统始终保持双向音频通道。
当模型正在回答时，系统仍需持续完成以下任务：
- 接收麦克风音频；
- 消除扬声器声音产生的回声；
- 识别用户是否开始讲话；
- 判断声音是有效插话还是环境噪声；
- 决定是否停止当前语音输出；
- 根据用户新增内容重新规划回答。
因此，全双工语音交互并不只是模型能力问题，还依赖回声消除、语音活动检测、端点检测、音频传输和播放控制等工程模块协同工作。
三. 两套端点检测机制处理用户插话
从曝光的测试界面来看，MAI Realtime提供了两种可配置的监听或轮次判断方式。
第一种是Switchboard模式，使用名为MAI-Ears的端点检测器，并通过内联控制Token判断用户何时开始或结束一个语音轮次。
第二种则是相对确定性的混合方案，将基于静音的端点检测与Whisper语义端点检测结合使用。
静音检测解决“有没有声音”
静音检测通常基于VAD，也就是语音活动检测。它主要判断当前音频中是否存在人声，以及连续静音持续了多长时间。
这种方式实现简单、响应较快，但无法真正理解用户表达的语义。例如，用户说“我想确认一下……”后短暂停顿，系统可能把这个停顿误认为一句话已经结束，从而过早开始回答。
语义端点检测判断“话有没有说完”
语义端点检测不仅观察静音长度，还会结合上下文判断用户的表达是否完整。
例如，“帮我查询明天从北京到……”即使后面出现短暂停顿，从语义上看也明显没有说完。语义端点检测可以适当延长等待时间，避免系统抢话。
微软现有Voice Live API也已经提供高级轮次结束检测和语义VAD能力。官方将这类能力描述为利用上下文判断用户是真的结束发言，还是仅仅出现自然停顿。
用户打断后，系统需要完成什么？
当用户在模型回答过程中插话，完整的打断流程通常包括：
- 检测用户语音起点；
- 区分真实插话与背景噪声；
- 停止或淡出当前播放音频；
- 取消尚未播放的语音缓存；
- 保留已经说出的对话内容；
- 将用户新增语音加入上下文；
- 重新生成符合最新意图的回答。
TestingCatalog并未披露MAI Realtime执行上述流程的具体时延，因此目前只能确认其测试界面包含打断和端点检测相关配置，不能据此判断其实际打断速度是否已经优于其他实时语音模型。
四. 支持17种语言和自动语言检测
根据TestingCatalog曝光的信息，MAI Realtime当前支持17种语言。
具体包括：英语；德语；西班牙语；法语；意大利语；葡萄牙语；日语；韩语；中文；荷兰语；印地语；印度尼西亚语；阿拉伯语；俄语；土耳其语；越南语；泰语。
开发者或测试用户可以手动指定对话语言，也可以启用自动检测模式。报道还称，模型能够在对话过程中切换语言。
自动语言检测能减少一个前置环节
在传统多语言语音系统中，开发者可能需要先运行语言识别模型，判断用户正在使用哪种语言，再选择对应的ASR、提示词或TTS音色。
如果实时语音模型可以在音频流中直接识别语言，并在对话过程中处理语种切换，就能减少单独调用语言分类器的需要。
不过，“支持某种语言”并不代表所有语言都拥有完全相同的识别准确率、语音自然度、端点检测能力和响应速度。微软目前尚未公布MAI Realtime的分语言评测数据，也没有说明不同语言是否使用相同模型和音频处理链路。
五. 当前仅提供两种测试音色
曝光的MAI Realtime测试版本目前提供Victoria和Grant两种音色。
TestingCatalog认为，两种音色的自然度高于当前Copilot语音模式。不过，这属于媒体体验判断，微软尚未公开盲测结果、MOS评分或与其他模型的正式对比数据。
现有信息还显示，MAI Realtime暂不支持唱歌，也不能生成环境声音等非语音音效。
MAI Realtime与MAI-Voice-2并不是同一类产品
微软已经正式发布的MAI-Voice-2是一款文本转语音模型，支持15种语言、情绪标签、长文本语音生成和基于参考音频的零样本音色生成。
MAI Realtime更关注实时对话中的输入与输出协同，包括用户插话、轮次判断、语言切换和低延迟响应。
两者都与语音生成有关，但面向的工作负载不同：MAI-Voice-2偏向可控的语音合成，MAI Realtime则更接近面向Voice Agent的实时语音交互模型。
六. 调试面板暴露延迟与推理过程
TestingCatalog展示的测试界面还包含一套调试面板，可以查看延迟、推理Token和内部处理步骤。
MAI Realtime调试面板可展示模型延迟、推理Token和处理流程，便于开发者定位实时语音链路中的性能瓶颈。图片来源：TestingCatalog。
对于Voice Agent开发者而言，这类可观测性十分重要，因为用户最终感知到的等待时间并不只来自模型生成。
一次完整的实时语音响应可能涉及：
- 音频上传延迟；
- 语音起点和终点检测时间；
- 模型首Token生成时间；
- 工具或RAG检索耗时；
- 首段语音生成时间；
- 音频下行与播放缓冲时间。
为什么只看模型推理速度不够？
即使模型本身生成速度很快，过于保守的端点检测仍可能让系统等待较长时间才开始回复。类似地，工具调用、数据库查询和网络抖动也可能让整体语音响应明显变慢。
因此，一个完整的语音智能体调试面板需要把端点检测、模型生成、工具调用和音频播放拆开统计，开发者才能判断延迟究竟出现在哪个环节。
目前尚不清楚MAI Realtime是否会将这些内部指标通过正式API提供，还是仅在MAI Playground的测试环境中展示。
七. MAI Realtime何时开放API？
MAI Realtime目前尚未出现在微软公开的Foundry模型目录中，也没有正式API文档。
TestingCatalog表示，该模型以隐藏的早期访问项目出现在MAI Playground中，可能只有少量合作伙伴获得测试权限。
从微软现有MAI模型的发布路径来看，未来若MAI Realtime正式开放，Microsoft Foundry是较有可能的开发者接入入口。微软此前已经通过Foundry和MAI Playground发布MAI-Voice、MAI-Transcribe和MAI-Image等自研模型。
但这只是基于现有产品路径作出的推测。微软尚未确认MAI Realtime是否会上架Foundry，也没有公布公测、API开放或Copilot集成时间。
目前仍缺少哪些关键规格？
开发者真正进行技术选型前，至少还需要等待以下信息：
- 首音频包延迟；
- 用户插话检测延迟；
- 最大上下文长度；
- 音频输入和输出格式；
- WebRTC或WebSocket接入方式；
- 函数调用和MCP支持情况；
- 并发数与速率限制；
- 各语言的识别和合成效果；
- Token或音频时长计费方式；
- 数据存储、区域和合规策略。
在这些数据公布之前，还无法严谨比较MAI Realtime与GPT Realtime、Gemini Live或其他实时语音模型的性能和成本。
八. MAI Realtime与Azure Voice Live API有什么关系？
MAI Realtime是一款尚未正式发布的模型，而Azure Voice Live API是一套已经面向开发者提供的实时语音服务，两者不能直接等同。
Voice Live API将语音识别、生成式AI、语音合成、降噪、回声消除、打断检测和高级轮次结束检测整合在统一接口中，并通过WebSocket与开发者后端连接。
微软官方文档显示，Voice Live API目前并非只使用GPT Realtime。开发者还可以根据场景选择GPT-5、GPT-4.1、GPT-4o、Phi以及Azure Realtime等不同模型。
不能简单理解为微软正在替换OpenAI模型
MAI Realtime的曝光说明，微软正在补齐自研实时语音模型能力，但现有信息不足以证明微软将用它全面替代Azure中的OpenAI模型。
更可能的产品方向是，微软继续在Voice Live API中提供多种模型选择，同时逐步增加自研MAI模型，使开发者能够根据延迟、效果、价格和数据要求选择不同底层模型。
只有当MAI Realtime正式进入Foundry或Voice Live支持列表后，开发者才能确认它与微软现有语音服务之间的具体关系。
九. 对Voice Agent开发者意味着什么？
虽然MAI Realtime仍处于早期测试阶段，但它曝光的技术方向具有一定参考价值。
首先，实时语音模型的竞争重点正在从“能否完成语音对话”转向“能否自然处理用户插话”。模型是否能够边听边说、准确判断话语结束，并在打断后快速调整回答，直接影响用户对语音交互自然度的判断。
其次，多语言能力不再只是支持语言数量的竞争。自动语言检测、对话中途切换语言，以及不同语种下稳定的端点检测和语音输出，才是全球化Voice Agent真正需要解决的问题。
最后，可观测性会成为实时语音平台的重要能力。只有能够分别查看网络、端点检测、模型推理、工具调用和语音生成耗时，开发者才能持续优化端到端延迟。
不过，MAI Realtime目前还不能作为正式的技术选型对象。它没有公开API，没有正式价格，也没有可复现的性能评测。
十. 总结
MAI Realtime是微软正在测试的一款原生实时语音模型。曝光信息显示，它可能支持全双工语音交互、两套端点检测方案、用户插话处理、17种语言、自动语言检测和两种测试音色。
这些能力表明，微软在实时语音领域释放出的技术信号：下一阶段Voice Agent的竞争重点，将不只是语音听起来是否自然，而是模型能否持续监听、准确理解停顿、及时响应插话，并在复杂工具调用过程中保持足够低的端到端延迟。
