微软首款全双工语音模型开测

微软正在小范围测试首款自研原生全双工语音模型 MAI Realtime，试图把 AI 语音交互从“轮流发言”推进到更接近真人通话的状态。根据 8 月 2 日曝光、8 月 4 日流出的测试信息，该模型已经向部分合作伙伴开放，可同时接收用户语音和输出回答，并支持自动识别语言、对话途中切换语言，以及中文在内的多语言交互。

**MAI Realtime 是微软面向实时语音对话打造的原生全双工模型。**这里的“原生”意味着它的目标不是简单地把语音识别、大语言模型和语音合成三个模块串起来，而是尽可能在统一的实时模型中处理音频输入、语义理解与语音输出；“全双工”则意味着用户和模型可以同时说话，不必严格遵循“你说完，我再说”的回合制流程。

截至 2026 年 8 月 4 日，MAI Realtime 仍处于受限测试阶段，并没有在 Microsoft Foundry 面向所有开发者开放。微软也尚未公布模型价格、首音频延迟、支持的上下文长度、并发限制和正式发布日期，因此现在更适合把它看成一次技术路线验证，而不是已经可以部署到生产环境的成熟服务。

最大变化不是声音更自然，而是模型允许你插话

**全双工交互解决的是语音 AI 最影响体验的“抢话”和“等话”问题。**传统语音助手通常先通过端点检测判断用户是否说完，再把完整音频送去识别和推理，最后调用语音合成模块播放结果；任何一个环节判断失误，都会出现长时间沉默、用户停顿时被提前打断，或者用户已经纠正问题、助手仍继续念旧答案的情况。

MAI Realtime 的核心能力是让输入和输出两条音频流并行运行。模型在回答时仍会继续监听麦克风，一旦检测到用户插话，就需要判断这是无意义的附和、背景噪声，还是要求它立即停止并修改回答的新指令。例如模型正在介绍一份财报，用户说“先别讲营收，直接说利润率”，理想状态下，模型应该立刻停止当前句子，保留已经形成的上下文，并自然转向利润率，而不是继续朗读十几秒后再处理新问题。

**真正的全双工系统比低延迟语音合成更难。**语音合成只需要尽快把已有文本读出来，而全双工模型必须同时解决语音活动检测、端点判断、回声消除、打断检测、上下文修正和输出节奏控制。用户说“嗯”“对”“你继续”时，模型不应该停下；用户说“不对，我问的是去年”时，模型又必须立即中断，这种判断往往比单纯降低几十毫秒延迟更决定产品是否好用。

从目前披露的信息看，MAI Realtime 采用双向、全双工交互机制，无需等待一方彻底结束发言。测试界面还会展示实时延迟、处理步骤和与模型决策有关的调试信息，不过这些面板究竟会以什么粒度开放、是否属于开发阶段内部观测工具，目前没有官方说明，也不应直接等同于向用户展示完整模型推理过程。

支持语言数量出现“16 种”和“17 种”两套口径

**MAI Realtime 已确认覆盖中文和多种主流语言，但公开报道中的语言数量存在明显计数冲突。**相关报道将其概括为支持 16 种语言，随后列出的语言名称实际上共有 17 种，包括英语、德语、西班牙语、法语、意大利语、葡萄牙语、日语、韩语、中文、荷兰语、印地语、印度尼西亚语、阿拉伯语、俄语、土耳其语、越南语和泰语。

| 区域 | 披露的语言 | |---|---| | 东亚 | 中文、日语、韩语 | | 欧洲 | 英语、德语、西班牙语、法语、意大利语、葡萄牙语、荷兰语、俄语、土耳其语 | | 南亚及东南亚 | 印地语、印度尼西亚语、越南语、泰语 | | 中东 | 阿拉伯语 | | 按名单合计 | 17 种 | | 报道标题口径 | 16 种 |

**在微软公布正式模型卡之前，更稳妥的说法是“已披露名单包含 17 种语言”。**造成差异的可能原因包括测试版本调整、语言与区域口音的统计方式不同，或原始测试页面与报道转述之间出现遗漏，但目前没有足够信息判断哪一种解释准确。对于准备做产品规划的开发团队，这个差异不能被忽略，尤其是语言支持通常还涉及地区变体、混合输入和输出能力是否对称。

**自动语言检测和中途切换比静态多语言列表更有实际价值。**用户可以主动指定交流语言，也可以让系统自动识别；在同一段对话中，模型还能处理语言切换。这对跨国会议、旅游客服和双语家庭助手很重要，例如用户可以用中文提出问题、读出一段英文产品名，再要求模型用日语复述，而不必每次进入设置菜单切换语言。

**多语言全双工的难点在于切换必须发生在音频流内部。**系统不仅要识别当前说的是哪种语言，还要处理中文夹英文缩写、品牌名、数字和人名等混合表达，并在用户插话后及时调整输出语言。静态识别一段完整录音相对容易，实时判断一句话中间何时发生语言切换，则更考验流式编码和上下文追踪能力。

Victoria 和 Grant 只是两种声音，不代表开放声音定制

**MAI Realtime 当前测试提供 Victoria 和 Grant 两个语音角色。**现有描述认为这两种声音比 Copilot 当前语音模式更自然，但微软尚未给出主观听感测试、盲测胜率或公开音频集，因此“更自然”目前仍属于测试者评价，而不是可以量化复核的性能结论。

**两个预设声音也说明 MAI Realtime 现阶段优先验证交互，而非建设庞大的音色库。**对于客服、陪伴助手和车载系统，两种声音远远不够覆盖品牌人格、地区口音与企业定制需求；但在早期测试阶段，减少音色变量有利于团队把注意力放在打断、延迟、稳定性和语言切换上。

MAI Realtime 暂不支持唱歌或生成非语音音效，这进一步明确了它的产品边界。它不是 Suno 一类音乐生成模型，也不是可以任意生成环境声和拟音的通用音频模型，而是一个以实时对话为核心目标的语音系统。这个限制未必是缺点，因为对企业语音 Agent 来说，可控地说清楚话通常比会唱歌更重要。

MAI Realtime 补上了微软自研语音栈最关键的一块

**微软此前公开的 MAI 语音模型主要承担单向任务。**MAI-Voice 系列负责把文本变成语音，MAI-Transcribe 系列负责把语音转成文本，两者都可以嵌入语音 Agent，但它们本身并不等于一个能够实时听说、处理插话和维护对话状态的全双工模型。

| 模型或产品 | 核心任务 | 交互方向 | 已披露语言信息 | 当前定位 | |---|---|---:|---:|---| | MAI Realtime | 实时语音对话 | 双向、全双工 | 报道称 16 种，名单实际为 17 种 | 合作伙伴受限测试 | | MAI-Voice-2 | 文本转语音 | 单向输出 | 15 种语言、18 个区域设置 | Foundry Tools 公共预览 | | MAI-Voice-2-Flash | 低延迟文本转语音 | 单向输出 | 15 种语言、18 个区域设置 | 面向实时 Agent 的快速合成 | | MAI-Transcribe-1.5 | 语音转文本 | 单向输入 | 已披露覆盖 43 种语言 | 转录与语音识别 |

**MAI Realtime 的战略意义在于微软终于有机会用一套自研模型控制完整语音回路。**此前微软可以用自研转录模型接收语音，再调用语言模型完成推理，最后通过 MAI-Voice 输出，但串联式架构会在每个模块之间产生缓冲和信息损失。比如语音识别通常只保留文字，用户的犹豫、语速、重音和情绪可能在进入语言模型前被压缩掉；原生语音模型则有机会直接利用这些声学线索。

**统一模型并不意味着传统流水线会立刻消失。**模块化架构的优势是容易审计、替换和控制，企业可以单独保存转录文本、屏蔽敏感词，并为每个环节设置明确指标；端到端实时模型虽然自然，但调试更困难，输出行为也更难拆解。微软很可能会让两条路线长期并存：对延迟和自然度敏感的消费者场景使用 MAI Realtime，对合规和流程控制要求更高的企业场景继续提供可组合的语音组件。

微软瞄准的是 OpenAI 和 Google 已经争夺的入口

**实时语音已经成为大模型厂商争夺下一代交互入口的核心战场。**OpenAI 的 Realtime 系列强调原生音频输入输出与低延迟对话，Google 的 Gemini Live 强调连续交流、多模态上下文和终端生态，而微软此前虽然拥有 Azure Speech、Copilot Voice 和大量企业渠道，却缺少一个标签清晰的自研全双工基础模型。

| 产品路线 | 实时双向语音 | 插话处理 | 多语言 | 生态优势 | 当前主要不确定性 | |---|---:|---:|---:|---|---| | Microsoft MAI Realtime | 支持 | 支持 | 披露名单含中文等 17 种 | Windows、Copilot、Teams、Foundry 与企业客户 | 未公开价格、延迟和上线时间 | | OpenAI Realtime 系列 | 支持 | 支持 | 支持多语言交互 | ChatGPT 与开发者生态成熟 | 不同版本能力和成本持续变化 | | Google Gemini Live | 支持 | 支持 | 支持多语言交互 | Android、Gemini 与 Google 服务整合 | 企业部署方式依产品而异 | | 传统 ASR＋LLM＋TTS | 取决于工程实现 | 通常需要额外编排 | 可自由组合 | 可控、可替换、便于审计 | 链路更长，交互自然度较弱 |

**MAI Realtime 的优势暂时不在参数，而在微软手中的分发场景。**如果模型进入 Copilot，它可以覆盖 Windows PC 和移动端助手；如果进入 Teams，它可以承担会议问答、实时翻译和语音摘要；如果进入 Dynamics 365 联络中心，它又能成为客服 Agent 的对话层。单独看模型，微软现在还没有公布足以压过竞品的延迟或质量数据，但从企业软件入口看，它比多数语音创业公司更接近真实业务流。

**微软自研 MAI 模型也有降低外部依赖和优化成本结构的现实考虑。**复杂推理仍可以交给更强的通用模型，而语音识别、合成和实时对话属于调用频率高、成本敏感、延迟要求严格的工作负载，更适合通过自研模型做针对性优化。换句话说，MAI Realtime 未必需要在所有推理基准上击败最强模型，它首先要做到的是足够快、足够稳，并能以可接受的成本运行在 Copilot 的巨大调用量下。

现在最缺的不是功能列表，而是可验证的性能数字

**MAI Realtime 目前没有公布任何可横向比较的核心性能指标。**官方尚未披露首音频延迟、用户插话后的停止时间、语音识别错误率、弱网表现、并发能力和单位分钟价格，这些数据比“支持全双工”更能决定模型能不能真正上线。

开发者后续应重点关注以下指标：

• 首音频延迟：从用户停止或形成可回答语义，到模型发出第一个可听音节需要多少毫秒。
• 打断停止延迟：用户开始插话后，模型需要多少毫秒停止当前输出。
• 误打断率：背景声、咳嗽和“嗯”等附和词导致模型错误停止的比例。
• 端点检测准确率：模型能否区分自然停顿和真正说完，尤其是在中文长句中。
• 语言切换准确率：混合语言输入时，是否会错误翻译品牌名、人名或专业术语。
• 长对话稳定性：持续通话几十分钟后，是否出现延迟累积、人格漂移和上下文遗忘。
• 单位时间成本：输入音频、输出音频和文本推理是否分别计费，以及静默监听是否产生成本。

**语音模型的跑分也不能只看转录错误率。**一个词错误率很低的系统，仍可能因为打断慢、语调机械或频繁抢话而难以使用；反过来，一个偶尔识别错专有名词、但能自然确认和修正的模型，实际满意度可能更高。MAI Realtime 是否真正领先，需要真实双人对话测试，而不是只播放几段精心挑选的演示音频。

距离 Copilot 真正用上，还有三道门槛

**MAI Realtime 首先必须证明它能在复杂声学环境下稳定工作。**实验室里的单人近讲麦克风不能代表地铁、车载、会议室和呼叫中心，回声、多人重叠说话、网络抖动都会破坏全双工体验。尤其当模型输出声音又被麦克风收回时，系统必须可靠地区分自己的声音与用户插话。

**MAI Realtime 还必须解决企业合规和数据治理问题。**持续监听意味着系统会处理比传统按键式助手更多的环境音频，企业会要求明确的数据保留策略、地区部署、日志审计和用户告知机制。2026 年 8 月欧盟对 AI 交互透明度的要求已经进入更严格的执行阶段，合成语音标识和用户知情不会只是产品设置里的可选项。

**MAI Realtime 最后必须给出有竞争力的商业价格。**全双工模型会同时占用输入和输出通道，且需要持续维护会话状态，如果按音频时长叠加推理资源计费，长时间在线的客服和陪伴产品可能面临显著成本。微软没有公布任何价格之前，开发者无法判断它会替代现有语音流水线，还是只适合 Copilot 等高价值场景。

判断：方向正确，但现在还不能下“可用”结论

**MAI Realtime 是微软自研模型战略中一块迟到但必要的拼图。**它把 MAI-Transcribe 的“听”和 MAI-Voice 的“说”推进到同一条实时交互链路，也让微软首次有机会不依赖外部基础模型，独立控制 Copilot 的语音体验。

**这次测试最值得关注的能力不是 17 种语言或两个声音，而是插话之后能否正确理解用户为何打断。**如果模型只是迅速停下来，却丢失刚才的上下文，或者每次听见短促声音都中止回答，那么它仍然只是低延迟语音管线；只有当模型可以边说边听、判断意图并自然修正，才称得上真正的全双工对话。

**现阶段对 MAI Realtime 的合理评价是“技术路线值得期待，产品成熟度无法验证”。**微软还需要公布正式模型卡、可复现的延迟数据、计费方式和公开测试入口，才能回答它是否比 OpenAI Realtime、Gemini Live 或成熟的模块化方案更好。对于开发者而言，现在可以关注其架构和未来接入 Foundry 的方式，但不应基于一轮受限测试就调整生产系统。

参考来源

• IT之家：微软测试其首款自研全双工 AI 语音 MAI Realtime 模型——汇总 MAI Realtime 的测试范围、全双工机制、语言名单、语音角色和当前产品限制。