StepAudio 3 系列拆解：声音怎样生成，模型怎样边听、边想、边说

想象这样一段对话：

你说：“帮我写一段雨夜电台的开场白，声音轻一点，后面放一点钢琴……”

助手开始回应，你又补充：“嗯，对——不过不要太伤感。”

这段十几秒的交流，其实提出了好几个不同的问题：雨声、钢琴和人声怎么一起生成？“声音轻一点”怎样变成声学特征？用户说“嗯”时要不要停？后半句改变了要求，正在生成的回答又该怎么调整？

StepAudio 3 系列可以沿着这些问题来读。它既涉及把声音写出来，也涉及在对话进行中持续作判断。

本文依据截至 2026 年 9 月 15 日 的两份 v1 技术报告：StepAudio 3 Gen（9 月 11 日提交）与 StepAudio 3 Realtime（9 月 12 日提交）。下文的示意图、算例和教学代码为本文绘制或编写；实验数值来自报告，未做本地模型复现。

一、先认清三个名字

ASR Max 出现在 Realtime 报告中。两者共享预训练与中期训练，在监督微调时分别针对转写和语音交互优化。Gen 的报告则独立描述生成架构。不能仅凭同属“3 系列”，就认定它们是同一套权重、同一个音频前端，或者把 Realtime 的参数规模直接套给 Gen。来源：Realtime §3–4；Gen §2

下面先拆“怎么生成声音”，再拆“怎么把对话接住”。

二、Gen 的第一步：把声音变成可预测的编号

2.1 一秒波形和一秒 token，是两种尺度

24 kHz 音频每秒有 24,000 个采样点。让语言模型一个采样点接一个采样点地生成，时间序列太长。音频 tokenizer 的工作，就是把波形压缩成较短的离散序列，再由解码器还原声音。

StepAudio Tokenizer 使用以下配置：Gen §2.1

这里的“12.5 Hz”尤其容易看错：每秒有 12.5 个帧位置，但有 200 个码本编号。 因为每帧包含 16 层，而不是只有一个 token ID。

如果所有码本都用定长二进制编号，不计封装、文本与其他开销，可以算出理论码率：

每个编号的位数 = log₂(2048) = 11 bit
完整码流的码率 = 12.5 × 16 × 11 = 2,200 bit/s

这个 2.2 kbps 是按编号推导的载荷码率，不等于产品实际传输带宽。另一个有用的尺度是：一帧对应 24,000 × 0.08 = 1,920 个输出采样点。它并不是让声音每 80 ms 才变化一次；帧内的波形细节仍由编码和解码共同表示。

2.2 RVQ：先描述大体，再逐层补差值

RVQ 是 Residual Vector Quantization，残差向量量化。先把连续音频特征记作向量 z。第一层从自己的字典里找一个近似向量；减掉这部分，第二层继续近似剩余误差，依此类推。

可以用下面的简化形式理解。Q 表示一次码本查找，实际模型使用带因子分解的余弦相似度查找：

r₀ = z
qₖ = Qₖ(rₖ)          # 第 k 层选出的码向量
rₖ₊₁ = rₖ − qₖ      # 留给下一层的残差
重建特征 ẑ = q₀ + q₁ + … + q₁₅

拿一个一维玩具例子：目标是 0.73，第一层选 0.60，第二层补 0.10，第三层再补 0.03。传输时不用发送这几个浮点数，只要发送它们各自在码本里的编号。

这个 tokenizer 有两路输入特征：冻结的自监督编码器提供语义特征，卷积编码器从波形提取 50 Hz 声学特征。两路沿通道拼接，经步长卷积压到 12.5 Hz，再进入同一个 RVQ。

因此，每一层都可能包含语义和声学信息。较早层之所以更适合承担粗粒度规划，来自训练约束：语义蒸馏让量化特征能够恢复教师表示；quantizer dropout 则让训练中的部分样本使用不完整的码本深度，促使前层承担更多信息。报告设置的 dropout 为 0.5，不能理解为推理时固定丢掉一半码本。

解码器采用因果 Transformer、25 帧滑动窗口注意力和 ISTFT 波形输出。25 ÷ 12.5 = 2 秒是窗口对应的时间尺度，不是必须等 2 秒才发声：因果窗口利用过去信息，不要求等待未来音频。Gen §2.1、§4.1

三、16 层都要生成，大模型会不会忙不过来？

3.1 把时间方向和码本方向分开

假设要生成一分钟音频：

帧位置数 = 60 × 12.5 = 750
码本编号数 = 750 × 16 = 12,000

最直接的做法是把 12,000 个编号铺成一条长序列，全交给大模型。Gen 采用另一种组织方式：

• 时间方向：LLM 预测下一帧的第 0 层码本 c₀，并处理文本与跨帧依赖。
• 码本方向：一个 4 层因果 Transformer，以 LLM 隐状态和刚选出的 c₀ 为条件，在当前帧内依次预测 c₁～c₁₅。

这个小模型叫 RVQ Code Predictor。它补完一帧后，完整的 16 层编码即可交给 codec 解码器。Gen §2.2

只看音频位置，大模型从 12,000 步变成 750 步；但这不能推出“速度提高 16 倍”。那 11,250 次残差码本预测依然存在，还要计入文本、缓存读写、解码器和调度开销。

用 Hₜ 表示生成第 t 帧时的文本、历史音频等条件，hₜ 表示相应的主干隐状态，概率分解可以写成：

p(cₜ,₀:₁₅ | Hₜ)
  = p(cₜ,₀ | Hₜ)
    × ∏ₖ₌₁¹⁵ p(cₜ,ₖ | hₜ, cₜ,₀:ₖ₋₁)

先决定当前帧的粗粒度编码，再依次决定细化编码。这里没有假设后 15 层相互独立；第 k 层能看到同帧更早的码本。

3.2 大模型输出一层，输入却能看到完整一帧

如果下一帧只能看到上一帧的 c₀，剩余 15 层的音色和声学细节就难以进入后续决策。Gen 因而在输入侧使用全部 16 个码本：每层查自己的 embedding 表，将向量相加，再通过 RVQ Adaptor 加入主干输入。

uₜ = Σₖ₌₀¹⁵ Eₖ(cₜ,ₖ)
音频位置的输入 = E_vocab(cₜ,₀) + Adaptor(uₜ)
文本位置的输入 = E_vocab(text_token)

注意 c₀ 出现了两次：一次在扩展后的语言模型词表里，一次在完整 RVQ 帧的 embedding 求和里。这是论文明确描述的设计。

Adaptor 是逐位置的残差网络，带预归一化和 SwiGLU，不是另一个沿时间编码整段音频的 Transformer。其残差分支的下投影采用零初始化，因此初始时残差块接近“原样传递”。零初始化的是残差变换分支，不是把整条音频输入置零。

为什么加这层？可以把文本 embedding 想成主干已经熟悉的坐标系。新加入的 16 路音频向量即使维度一致，尺度、方向和分布也未必合适。Adaptor 学习如何把它们送进这个坐标系；只在音频位置启用，又能避免直接改写文本位置的输入。

这也说明，“小模型不把输出反馈给主干”要分清层次：它不会把同一帧的预测器隐状态逐层回灌主干；但生成后的完整码本帧会作为后续音频上下文输入主干。

四、Gen 训练的核心问题：学会声音，别把原来的语言能力冲坏

4.1 两种损失，影响主干的方式不同

Gen 有两部分监督：文本及 c₀ 的 token 损失，以及 c₁～c₁₅ 的残差码本损失。

L = L_token + λ × L_residual

L_residual = −Σₜ Σₖ₌₁¹⁵ log p(cₜ,ₖ | 条件)

后者对 15 层求和，而不是平均。同一帧一下多出 15 项监督，且预测器一开始还是随机初始化的。如果立即让这些梯度反传进 LLM，主干就得同时适应不成熟的输入表示和声学预测目标。

“音频能力有没有学到”和“语言能力有没有保住”，因此必须一起看。

4.2 四个阶段，逐步开放影响范围

从阶段 2 起，纯文本比例维持在 50%；生成阶段的文本、TTS、交错对话比例是 3∶1∶2。整个四阶段预训练约处理 2.7T 个 LLM 时间位置 token，不能再把每帧的 16 个编号都当成 16 个主干位置重复计算。Gen §4.2

下面是说明梯度开关的 PyTorch 教学片段，函数和张量名不是官方接口：

import torch.nn.functional as F

# h: [B, T, D]，用于预测当前音频帧的主干隐状态
# codes: [B, T, 16]，当前帧的真实 RVQ 编号
condition = h.detach() if stage == 3 else h

# teacher forcing：预测 c1...c15 时，输入 c0...c14
logits = code_predictor(condition, codes[..., :-1])
# logits: [B, T, 15, 2048]
targets = codes[..., 1:]

ce = F.cross_entropy(
    logits.reshape(-1, 2048),
    targets.reshape(-1),
    reduction="none",
).reshape_as(targets)

# 先对 15 层求和，再对有效音频位置平均
frame_loss = ce.sum(dim=-1)
loss_residual = frame_loss[audio_mask].mean()
weight = 1.0 if stage == 3 else 0.1  # 此处只演示阶段 3、4
loss = loss_token + weight * loss_residual
loss.backward()

detach() 并没有冻结预测器。预测器仍从残差损失学习，只是这条损失不能通过 condition 回传到主干。等它学得比较稳定，再开放这条梯度路径。

报告的文本能力消融中，新方案的 MMLU 为 69.20，基线为 64.99；HumanEval 为 54.27 对 47.56。但基线同时缺少 RVQ Adaptor，而且训练阶段也不同。它支持整套方案更有效，不能把全部增益归因于 detach 一个开关。Gen §5.2

五、声音怎样受指令控制，GRPO 又在奖励什么？

5.1 把一段要求拆成“谁、场景、事件顺序”

Gen 用 ROLE、DIRECTOR、SCRIPT 组织指令。下面根据报告字段编写一个示意请求，不是经过实测的 API 调用：

ROLE
主播：成年男声，音色温暖，语速舒缓。

DIRECTOR
深夜电台。近距离人声在前，雨声与钢琴在后。
气氛安静，但不要悲伤；背景声不能盖过台词。

SCRIPT
[窗外持续下雨，远处偶尔传来车声]
主播：(轻声) 晚上好，今天过得怎么样？
[轻柔的钢琴进入，雨声继续]
主播：(带一点笑意) 先把肩膀放松，我们慢慢聊。

这相当于把全局设定和局部时间安排分开：ROLE 定角色，DIRECTOR 定场景与表演意图，SCRIPT 定谁在何时说什么、声音事件怎样排列。模型需要同时满足文字正确、角色稳定、局部风格变化和前后景关系。Gen §1

统一 token 空间带来的价值，是这些信息可以在同一个生成上下文里相互制约。比如“雨声继续”不是只在另一条独立音效流水线里生效，它也是后续声音生成的条件。

5.2 “很像指定风格”不能抵消“念错台词”

Gen 后训练包含约 5,000 小时 SFT 音频，覆盖多个声音领域；其中为自然对话式 TTS 筛选的语音约 1,500 小时，二者不是同一个统计口径。之后使用 GRPO 优化指令遵循。Gen §3.2、§4.3

奖励分成两个信号：

1. 音频理解模型先描述生成声音，再由文本 LLM 比较描述与原指令。独立打分 4 次取平均，得到 0～100 的风格／指令一致性分 s。
2. 对有目标台词的样本，用 ASR 转写生成音频，算 CER 或 WER，记作 e。

有目标台词：
  e ≤ 0.5 时，R = (s / 100) × exp(−3e)
  e > 0.5 时，R = 0

没有目标台词：R = s / 100

例如，同样得到 90 分的风格一致性：错误率为 0 时奖励 0.9；错误率为 0.2 时只剩约 0.494；超过 0.5 则归零。乘法把文字内容当成门槛，避免“表演很对，但台词全错”仍获得高分。

每条指令采样 16 个候选，按组内奖励算优势；组内标准差小于 0.02 的组被丢弃，因为缺少可区分的相对信号。论文目标对每个音频位置的全部 16 层码本计算 token 级概率比与裁剪项，并以 SFT 策略作为 KL 参考。这与“只对主干输出的 c₀ 做强化学习”不同。

不过，声音先变成 caption 再评分，天然有信息瓶颈。某个细微的呼吸、节奏或混音关系如果没进入描述，文本评委就无从判断。四次评分主要降低评分波动，不能自动消除音频描述模型的系统性偏差。这是理解该奖励设计时需要保留的边界。

六、Realtime：让声音成为持续到来的上下文

Realtime 的底座是基于 Step 3.7 Flash 的 MoE：约 196B 总参数、每 token 激活约 11B 参数。音频前端采用 Qwen3-Omni 的 Audio Transformer（AuT），再由 adapter 接入语言模型。Realtime §3

总参数影响权重存储，激活参数影响每步计算；11B 激活并不意味着只需装载 11B 权重。报告也没有据此给出一个可以直接照抄的消费级显卡部署配置。

它的上下文包含用户声音、模型正在说的声音、文本历史、推理进度和工具状态。模型自己的语音也进入后续交互判断，这一点很实际：你说“不是这个”，所指的往往是刚刚听到的那半句话。

训练先经过模态对齐、多模态混合、收尾三个预训练阶段，使用 32K 序列、约 1.2T token；中期训练将上下文扩到 128K，并增加音频理解和 Agent 交互数据。这个配方与 Gen 的四阶段 2.7T 配方属于不同报告，不应合并成一个训练过程。

ASR Max 的专项优化

ASR Max 在微调阶段冻结音频编码器，更新 adapter 与语言解码器；同时用时频掩码增强，并将多个识别器的结果通过 ROVER 对齐投票、过滤后组成长录音训练数据。

对罕见人名、产品编号和领域缩写，还会构造包含目标词的自然句子，合成语音并筛选发音一致的样本。它也学习使用历史对话、场景和术语提示，但最终转写仍需以波形为依据。

想象识别一句“接下来讨论 RVQ”：如果声学证据本来支持这三个字母，技术语境可以帮助消歧；如果录音根本没说 RVQ，就不该因为提示词里出现过而强行塞进转写。上下文是补充证据，不是答案模板。Realtime §4.1

七、全双工最难的部分：用户发声了，要不要让他说？

全双工允许输入与输出重叠。但“能同时录音和播放”只解决通道问题，对话仍需要判断发言权。

看三个例子：

单独看能量阈值或静音时长，无法可靠区分这些情况。Realtime 把用户音频、模型音频和历史一起交给模型，每 320 ms 音频块后接一个状态或文本 token，持续决定听、开始说、继续说或让出发言权。Realtime §5

训练因此也不只包含“问题—答案”。中期训练加入超过 10,000 小时的合成全双工交互数据，联合监督流式 ASR、VAD 与语句完整性；后训练进一步覆盖停顿、交接、附和、打断及背景说话拒绝。

从工程角度看，这相当于让模型持续回答两个问题：现在听到了什么，以及这段声音在当前对话里意味着什么。 后一个问题决定了能否接得自然。

八、“边想边说”：两路并发调用，而不是把思考念出来

8.1 为什么需要两路？

复杂问题通常需要多步推理。如果先生成完全部推理再合成语音，用户会等待很久；如果为了快速发声而完全不推理，又容易过早下结论。

Realtime 沿用 Mind-Paced Speaking 的双过程思路：对同一个音频模型发起两路并发调用。

• Formulation Brain 生成内部推理。
• Articulation Brain 根据当前已有的推理与已经说出的内容，生成短段回复。

调度器根据实际音频播放进度释放后续片段，推理在此期间继续。默认 Speak-First 不等待初始推理前缀；Think-First 则先等一小段推理再开始回复。推理完成后，后续片段可以使用完整结果，并补充或纠正前面内容。Realtime §6.3

可以用下面的概念式理解首句延迟，忽略重叠计算和网络细节：

先想完再说：首句等待 ≈ 完整推理耗时 + 首段回复生成与音频准备
Speak-First：首句等待 ≈ 首段回复生成与音频准备 + 调度开销

这只是说明推理等待可以从首句路径中移开，不是在承诺零毫秒延迟。两路调用也要消耗计算资源。

更重要的是，已经播放的话无法收回。假设用户问一个有优惠叠加规则的价格问题，第一段可以先说“我先确认一下这两个优惠怎么叠加”，但若未经核算就报出金额，后面纠正仍会损害体验。分段生成把“什么时候说出哪种承诺”变成了系统设计的一部分。

8.2 Adaptive Thinking：学习哪些轮次值得想

“你好”与“帮我比较三种方案”不需要相同的推理预算。Adaptive Thinking 的训练方式是：对同一轮构造原始推理回答和无推理回答，让盲评判断推理是否实际改善质量，再按领域与能力保留或替换推理监督。

它不是简单规定“句子短就不想”。不过也没有完美分配预算：报告的消融中，推理类别从始终思考的 71.89 降至 Adaptive Thinking 的 66.80，思考率为 59.5%；对话语用类别则从 63.59 升至 65.87。减少思考次数，和在正确的题目上省掉思考，是两件不同的事。Realtime §6.3.1

8.3 MTP：让后台推理走快一些

对仍需推理的轮次，Realtime 使用 MTP3，以三个预测头提出未来 token 草稿。可把它理解成先猜后面几步，再由主模型验证，减少串行主模型解码步骤。

报告在内部推理中采用较宽松的 typical acceptance：根据置信度接受部分严格验证可能拒绝的草稿，并施加 1.05 的重复惩罚；对外回复保留严格验证。宽松接受会改变生成分布，因此不能称作数学意义上的无损推测解码。

测量中 MTP3 配合 typical acceptance 的墙钟加速为 2.05×，但这是特定计时设置下的数字，不是整场语音交互必然快两倍。MTP5 接受的草稿更多，也没有在所报计时中更快；接受率之外，还有预测头开销、推理长度等因素。Realtime §6.3.2

九、Voice Agent：用户还在说，工具也在跑

实时对话进一步延伸到做事，就会遇到另一个时间尺度：搜索可能只需片刻，后端复杂任务可能持续多轮对话。

Realtime 区分直接回答、轻量工具调用和异步后端执行。任务运行期间，用户可以追问进度、补充要求或聊其他话题；工具结果返回后，再进入对话上下文。Realtime §7

例如，用户说“整理上周的会议”，任务已经启动，随后补一句“只要产品相关的”。系统需要知道这句话是在修改现有任务，而不是要求新建一个毫无关联的任务。报告描述了这类交互训练，但没有公开完整的任务取消、重启和状态同步实现。

这里有三种时间同时推进：用户表达意图的时间、模型思考和说话的时间、外部系统执行的时间。只有把它们关联起来，“我在处理”才不只是一句等待话术。

对于实际行动，语法完整也不意味着参数充分。模型还需要澄清缺失条件，并依据工具回执判断完成状态。“我说已经改好了”和“后端确实修改成功”必须有证据联系。这也是 τ-Voice 用最终数据库状态判定任务成功的原因。

十、除了架构，还有两项值得关注的训练选择

10.1 高质量样本的价值，可能大于继续堆 SFT 数量

Realtime 音频理解数据先做描述、能力标记与问题构造，再用多个模型独立标注，结合一致性和质量检查筛选。

一组只改变 SFT 数据的消融中，约 10 万条精选样本，相比约 200 万条随机样本，把 MMSU 从 78.78 提升到 89.70，MMAR 从 74.70 提升到 84.50。Realtime §4.2

这提示我们：音频问答里，一条“问题有价值、答案确实由声音支持”的样本，比大量泛泛描述更能提供训练信号。但多个模型达成一致仍不等于事实一定正确；它们也可能共享盲点。论文中的文本质量评委并不直接听音频，声音依据的可靠性主要通过多模型一致性估计。

10.2 多个专长教师，最后合成一个模型

Realtime 从共同底座训练四个不同数据配比的教师，再以 3∶1∶1∶1 归一化加权合并参数：

θ_merge = (3θ₁ + θ₂ + θ₃ + θ₄) / 6

这是训练后的参数合并，不是推理时让四个教师分别回答再投票。共同底座与兼容参数结构也很重要；不能随意把无关模型的权重平均。

合并模型的音频理解均分为 81.3，对话推理模式均分为 73.0；后者仍低于最强对话教师的 74.2。目标是组合互补能力，而非保证每项指标都超过每个教师。Realtime §6.4

十一、读评测时，要把“像真人”“懂声音”和“办成事”分开

把两份报告中的几项结果放在一起，更容易看清它们回答的究竟是什么。

来源：Gen §5、Realtime 表 1、2、3、4、9、10。

这里有四个需要记住的限定。

第一，TTS 的真人感是特定评测池中的偏好。 中文评测共有六个系统、1,500 次两两比较；每个系统使用一个音色，与 StepAudio 3 Gen 的直接对战每个对手 100 次。这样的结果很有参考价值，但不能外推到任意音色、语言和文本。

第二，生成能力的实验证据并不均匀。 Gen 对 TTS 和 Voice Design 给出了集中评测，对音乐、歌声、音效和混合场景更多是能力描述与演示。共享 token 空间提供了统一建模方法，却不自动证明每个子任务都领先。

第三，实时性有取舍。 StepAudioChat 的指令遵循从推理模式的 66.3 到交互系统的 54.1，均分从 73.0 到 70.4。多个系统机制一起变化，不能单独归因于某一个开关；但这些数字足以说明，低等待与完整推理不能被轻率地画等号。

第四，指标的百分数不一定具有同一种意义。 附和处理接近满分，说明更会接话；τ-Voice 才进一步检查是否真的把事情做对。两者分别约束交互行为和业务结果。

十二、这套技术最值得带走的是什么？

Gen 给出的思路是：把声音压到较慢的时间轴上，让主干处理跨帧依赖，让小预测器补充帧内细节；再用输入适配、文本回放和分阶段梯度控制，把新模态接入已有语言能力。表示如何组织、梯度流向哪里，与参数规模同样重要。

Realtime 给出的思路是：把对话视为一个持续变化的过程。用户可能在模型说话时修正要求，模型可能在推理完成前开口，工具可能在几轮之后才返回。全双工处理发言权，双过程推理处理思考与表达的节奏，异步 Agent 处理对话与执行的节奏。

这两个方向合起来，让“会发声”逐渐变成“会交流”。但它们也暴露出下一步的难题：怎样在更低等待下保住约束遵循，怎样让声学奖励真正听懂细节，以及怎样在多次打断、修正和工具执行之间保持任务状态一致。

这些问题，比一个总榜名次更值得继续跟踪。

论文与试听

• StepAudio 3 Gen Technical Report，v1：本文生成架构、训练与生成评测的主要来源。
• StepAudio 3 Realtime Technical Report，v1：本文 Realtime、ASR Max、全双工与 Agent 部分的主要来源。
• Mind-Paced Speaking：理解双过程“边想边说”的前置工作。
• Gen 官方试听：可以对照 ROLE、DIRECTOR、SCRIPT 的描述听实际声音。
• Realtime 官方演示：观察自然停顿、打断与持续对话。

本文核验的是报告与官方演示资源；没有将前代 Step-Audio 仓库的接口当作第 3 代接口。涉及实现的片段均为教学说明。