首页过去两年，语音模型的数量进入爆发期。Whisper、Qwen3-ASR、Qwen3-TTS 等开源模型不断降低部署门槛；OpenAI、Google等厂商持续推出实时语音、语音识别与语音合成 API。开发者现在只需要几行代码，就能让一个 AI 应用”听见”和”开口”。
同一个模型，在安静环境的 Demo 里表现惊艳，接入真实电话后可能识别不了人名和数字；一个听起来极其自然的 TTS，放进实时对话链路后，可能因为首包延迟过高而让用户频频抢话。排行榜上”最强的语音模型”，在具体业务里未必是最合适的选择。
一. 模型越多，选型越不能从模型开始
今天的语音模型已经出现明显分化。有的强调多语言和方言识别，有的针对电话、会议等垂直音频优化；有的追求极低延迟，有的强调情绪、韵律和声音表现力；还有一些模型直接跳过传统的 ASR、LLM、TTS 串联链路，实现音频输入、音频输出。
Qwen3-ASR 同时覆盖多语言、中文方言和语言识别，Qwen3-TTS 强调流式生成、声音设计与音色克隆。模型能力越来越专用，开发者很难再根据一个通用榜单完成选型。
所以选型的起点是场景，不是模型。会议转写需要高准确率、说话人区分和长音频稳定性；AI 外呼更看重电话音质下的识别、数字准确率、低延迟和打断处理；AI 陪伴则更依赖情绪理解、自然表达和对话节奏。场景不同，答案完全不同。
二. 先选技术路线，再选具体模型
在比较厂商和参数之前，要先确定系统架构。
第一种是传统的级联架构：ASR → LLM → TTS。每个模块可以独立观察、测试和替换——可以查看识别文本、修改提示词、控制回复内容，也可以单独更换 ASR 或 TTS。对于客服、外呼、金融、医疗等强调流程控制、信息准确和审计留痕的场景，级联架构通常更实用。
第二种是端到端语音模型，直接处理音频输入并生成音频输出，能保留语气、情绪、停顿等声学信息，减少多模块串联造成的信息损失，更适合陪伴、教育、游戏 NPC 和开放式交互。OpenAI Realtime API 已经将文件转写、语音合成与实时语音对话划分为不同的产品路径；Google Gemini Live API 也支持连续的音频、视频和文本流。语音应用正在从单一的”语音转文字”走向原生实时交互。
端到端不一定适合所有任务。需要精确记录金额、地址、产品名称，或者需要严格控制业务流程时，级联架构更容易调试和兜底。现实中更可行的方向往往是混合架构：用端到端模型承担自然对话，用结构化链路完成身份确认、数据采集和工具调用。
三. 选 ASR，别只盯着 WER
ASR 选型最常见的误区是直接比较公开榜单上的词错误率。WER、CER 当然重要，但通用测试集上的平均成绩，并不代表模型在具体业务中的表现。对于 AI 外呼来说，把一个语气词识别错了可能无关紧要，但把”398″识别成”388″，就可能直接导致任务失败。
更实用的评测指标应该包括：人名、品牌名、地址、金额和号码的实体识别准确率；8kHz 电话音频、远场、噪声和回声环境下的表现；方言、口音、中英混说和多人重叠语音的识别能力；流式识别结果是否频繁回滚；用户说完后多久输出最终结果；端点判断是否过早截断或迟迟不结束。
此外还要关注热词、自定义词表、时间戳、置信度和说话人区分等工程能力。Google Cloud 的官方文档将模型适配和短语偏置作为改善专业词汇、专有名词与噪声场景识别的重要手段。企业真正应该衡量的不是抽象的 WER，而是”关键业务字段错误率”和”任务失败率”。
四. 选 TTS，自然度只是入场券
今天大多数主流 TTS 在单句试听中已经足够自然。真正拉开差距的，往往是实时使用中的稳定性。开发者至少需要考察六个维度：
| 维度 | 关注点 | 优先场景 |
|---|---|---|
| 首包延迟 | 用户多久能听到第一个声音，不是整段音频生成需要多久 | Voice Agent、实时对话 |
| 流式能力 | 能否一边接收 LLM 输出，一边生成和播放语音 | 所有实时场景 |
| 发音准确性 | 人名、数字、英文缩写和行业术语能否稳定读对 | 外呼、客服、金融 |
| 表达控制 | 是否能控制情绪、语速、停顿、音量和语气 | 陪伴、教育、内容配音 |
| 声音一致性 | 长对话或高并发情况下音色是否漂移 | 陪伴、客服 |
| 中断恢复 | 用户打断后 TTS 能否立即停止并自然进入下一轮 | 所有实时对话场景 |
不同指标之间通常存在取舍。ElevenLabs 的官方说明将低延迟的 Flash 系列与强调表现力和音质的模型区分开来，并特别说明约 75ms 只是模型推理时间，不等于完整链路延迟。OpenAI 的 TTS 文档同样区分低延迟、音质以及可通过指令控制语气和节奏的模型。内容配音可以优先追求音质和表现力，Voice Agent 更应该优先考虑首包延迟、流式生成和中断响应。
五. 选语音系统，不能只评估语音模型
用户感受到的延迟，并不等于模型厂商公布的推理延迟。一轮真实语音对话通常包括音频采集、降噪与回声消除、网络传输、端点检测、ASR、LLM、TTS、音频下发和播放。任何一个环节不稳定，都会破坏最终体验。
所以除了模型本身，还需要评估：用户能否自然打断 AI；系统能否区分真正的打断、背景人声和”嗯、对”等附和词；弱网与丢包环境下是否仍然能保持连续对话；多轮交互后延迟是否持续上升；每个环节是否具备可观测性和故障定位能力。
以声网对话式 AI 引擎架构为例，除了连接 ASR、LLM 和 TTS，系统还需要处理 VAD、降噪、回声消除、打断检测和背景人声过滤。模型决定 AI 能不能听懂和说好，实时互动系统决定这些能力能不能稳定地送到用户面前。
成本评估也要用全链路视角。开源模型没有 API 费用，但可能增加 GPU、弹性扩缩容和运维成本；低价 API 如果频繁超时、重试或导致任务失败，实际成本反而更高。比”每分钟多少钱”更有价值的指标是：
单次成功任务成本 = 全链路总成本 ÷ 成功完成的任务数
六. 一套更实用的选型方法
选型过程可以压缩为四步：
| 步骤 | 做什么 | 注意点 |
|---|---|---|
| 第一步：定义场景边界 | 明确音频来源、语言与方言、是否实时、是否允许云端处理、最大可接受延迟、并发规模以及合规要求 | 没有这些条件，”最好”就没有意义 |
| 第二步：建立自己的测试集 | 测试集必须来自真实场景。电话业务要加入 8kHz 音频、噪声、口音、抢话、数字和专有名词；陪伴类产品要覆盖情绪变化、长对话和频繁打断 | 一开始不需要很大，但必须真实 |
| 第三步：只保留两到三个候选方案 | 分别测试准确率、首包延迟、p50/p95 尾延迟、任务完成率、稳定性和成本 | 一次接入十几个模型，大量时间会消耗在接口适配上 |
| 第四步：用真实流量验证 | 离线测试只能发现模型能力问题，在线 A/B 测试才能暴露网络波动、并发、长会话、用户打断和异常输入 | 正式上线后尽量保持模型接口可替换，避免把整个产品锁死在单一模型上 |
没有绝对最强的语音模型，只有现阶段最适合业务目标的模型组合。真正拉开产品差距的，是谁能更准确地理解自己的场景，并把 ASR、TTS、语音模型、业务逻辑与 RTE 基础设施组合成稳定、自然、可规模化的用户体验。
