阶跃星辰 StepAudio 3：五款语音模型一次放出，全双工对话拿下两个全球第一

TL;DR 速览

• 形态：9-15 一次性发布 五款（Realtime / ASR / TTS / Gen / Music），均已上线开放平台，是国内音频大模型第一次以完整矩阵形态推出
• 成绩（第三方榜单）：Realtime 拿下 Artificial Analysis Conversational Dynamics 98.9% 与 Speech Reasoning 99.7% 两个第一；ASR WER 1.7% 并列第一；Gen 的 Arena Elo 1755.3，领先第二名 211.1
• 架构内核：原生全双工 + 推理与语音生成并行 + Tool Call 与长任务异步执行不阻塞会话 → 语音交互从"一轮问答"变成"可以挂长任务"
• 接入分层的含义：Realtime 走 WebSocket，其余四款走 HTTP——这个分层本身就说明了实时语音与其它语音能力的架构差异
• 要打的折扣：三处第一均为官方引用的第三方榜单成绩，榜单表现不等于真实业务场景稳定性

9-15 阶跃星辰把 StepAudio 3 系列五款模型一次放了出来：Realtime（实时语音交互）、ASR（语音识别）、TTS（语音生成）、Gen（完整音频生成）、Music（音乐创作），全部上线开放平台。

国内音频模型以单点突破为主，一次性放出五款、覆盖"听说理解交互创作"完整链路的，这是第一次。但参数和榜单不是这篇文章的重点，我想写的是它的接入分层暴露了什么。

一、成绩先摆清楚（请注意口径）

模型	成绩	榜单
Realtime	98.9% 全球第一	Artificial Analysis Conversational Dynamics
Realtime	99.7% 全球第一	Artificial Analysis Speech Reasoning
ASR	WER 1.7%，并列全球第一	非流式语音识别准确性榜
Gen	Elo 1755.3 第一，领先第二名 211.1	Chinese Human-Likeness Arena

先把口径说清楚：以上均为官方引用的第三方榜单成绩。 不同榜单的评测集、对手构成与更新频率差异很大，横向比较需要谨慎——这一点后面还会再说。

其中 Conversational Dynamics 这个榜值得单独解释一下：它测的是对话节奏感——什么时候该接话、什么时候该等你说完、用户插话该按打断处理还是当附和。这是实时语音里最像人、也最难做对的部分。 语识别准确率早就不是瓶颈了，难的是"话轮"的判断。

二、能力边界的三处变化

这五款模型真正带来的是三个层面的能力变化。

变化一：从"对话"到"对话 + 推理 + 执行"

Realtime 支持原生全双工，能同时理解语义、语气、情绪、副语言与环境声；推理与语音生成并行；Tool Call 与长任务异步执行、不阻塞当前会话。

最后这条是工程上最有价值的。它意味着语音交互不再是"一轮问答"，可以挂长任务——查资料、跑流程、等结果这类操作，用户说完之后不用僵在那里听静音，可以继续说别的，结果好了再回来。

对做语音入口的产品来说，这条改变了设计空间：过去语音界面必须把任务拆得极短，因为用户无法在等待中做任何事；现在"语音发起 + 异步执行 + 语音回报"可以成立。

变化二：从"念出文字"到"演出表达"

TTS 的能力不止音色、语调、节奏、停顿、情绪，还包含笑声、迟疑、结巴、改口这类副语言表现，并且流式边生成边播放。

这不只是"更像人"的问题。迟疑和改口在真实对话里承担语义功能——它们标记"我在思考"“我刚才说错了”。一个完全没有这类表现的语音合成，听起来会像播报而不是对话。要做到这一点，模型必须能对生成过程本身做控制，而不是先把文字定稿再念出来。

变化三：从"单点生成"到"统一音频生成"

Gen 把人声、音效、环境声、背景音乐整合进同一个框架：基于 StepAudio Tokenizer，以 12.5Hz 帧率在共享残差码空间里联合量化语义与波形级声学特征，并且可以指定各声部出现的时间与顺序。

"能指定时间与顺序"这一点是关键。 音效生成和视频生成有个共同的难题——模型自由发挥的产物很难剪进实际内容里。当你能够控制"第几秒出现什么"，生成结果才有资格进入剪辑流程，而不是只能当素材看。

Music 则支持歌词、清唱配乐、参考歌曲，以及基于 ABC 记谱法的多轮交互创作——记谱法意味着音乐结构是可控的，不只是"再来一段"。

三、接入分层才是这篇最该看的部分

上线开放平台后，五款模型的接入方式是分开的：

模型	传输方式
Realtime	WebSocket 长连接
ASR / TTS / Gen / Music	HTTP API

这个分层本身就说明了两类语音能力的架构差异。

• 实时语音必须是双向流 + 状态保持：全双工意味着双方都在持续发送，打断处理要求系统能在任意时刻中断当前生成、回退上下文、重开始。这是有状态的长会话，请求-响应模型在原理上就不成立——这也是为什么它只能走 WebSocket。
• 其余四款是批处理形态：给定音频或文本，返回结果。没有会话状态，没有并发方向性，HTTP 一次性调用足够了。

给做选型的人一个实用结论：如果你只需要"把录音转成文字"或"把文字读出来"，不要为了"实时"两个字去接 WebSocket——那会把你拉进一套需要处理连接保活、断线重连、会话续传的基础设施里，而这些投入对你的场景没有回报。

反过来，如果你要做的是语音助手，那就必须接受这套复杂度：WebSocket 的连接管理、打断信号的处理、以及长任务结果回来时用什么方式插回正在进行的对话——第三点是全双工系统里最容易出问题的地方。

四、必须打的折扣

三处"全球第一"均为官方引用的第三方榜单成绩。 两点需要写明：

第一，榜单成绩反映的是特定评测集上的表现，不等于真实业务场景的稳定性。 真实场景里会同时出现嘈杂环境、方言混说、多人重叠说话、专业术语、长时间会议——这些组合起来的难度远高于任何单一评测集。

第二，五款模型的实际延迟与并发成本需要按自己的业务压测。 语音交互的体验瓶颈通常在链路的总延迟上（采集 → 识别 → 推理 → 合成 → 播放），单模块的榜单成绩好，不代表端到端体验好。做压测时要测端到端，而不是逐个模块测。

另一个值得注意的行业判断：阶跃自己的定位是"单项能力竞赛的窗口期正在关闭，全栈体系化成为壁垒"。这个判断可以讨论——五条产品线同时推，本质上是在赌音频会成为统一的能力层，而不是分散的功能点。对做应用的团队来说，这确实意味着一种选择：用一个平台覆盖全部音频能力（集成成本低、一致性有保障），还是按每个能力项分别选最优（上限更高、集成成本更高）。这个选择没有标准答案，取决于你的语音功能是不是核心竞争力。

我的判断

这次发布真正改变的不是"语音识别又准了多少"，而是语音交互的能力边界：全双工 + 推理生成并行 + 长任务异步执行，三样凑齐之后，语音才从"输入法"变成了"入口"。

过去语音做不了助手，不是因为它听不懂，而是因为它不能等——所有任务必须在一次对话轮次里完成，否则用户就得对着静音发呆。长任务异步执行把这个限制去掉了，这是形态上的解放，不只是指标上的提升。

对做产品的团队，我的建议是先想清楚一个问题：你的语音入口里，有多少操作是"说完就想要结果"，有多少是"说完可以去干别的"？ 后者的比例决定了这套能力对你有多大价值。如果绝大多数请求都是前一类，那榜单第一和你其实没什么关系。

最后提醒一处：五款模型一次性放出，短期内的文档完整度、SDK 成熟度、社区案例都需要时间。做 POC 时留出踩坑预算，别按"已上线"三个字假设它就是生产可用的。

做接入选型时我把各家的协议、计费和限制都记在一处，方便横向比——这些记录和选题一起收在 墨衍 里，不用每次重查一遍文档。