• https://github.com/NVIDIA-NeMo/Speech
• https://huggingface.co/blog/nvidia/nemotron-transcribe-granary
• https://github.com/NVIDIA-NeMo/Curator/tree/main/tutorials/audio/granary_v2

一、核心结论

• Nemotron 3.5 ASR Streaming 是约 0.6B 参数的多语言流式 ASR。
• 核心架构是 24 层 Cache-Aware FastConformer 编码器、RNN-T 解码器和语言 ID Prompt Conditioning。
• 声学表示维度为 1024，语言向量为 128 维；一个 checkpoint 支持 40 个 language locale。
• 运行时支持 80 ms、160 ms、320 ms、560 ms、1.12 s 五个 chunk 配置。
• FLEURS 上，Transcription-ready 19 个 locale 的平均 LangID WER 从 80 ms 的 10.38% 降到 1.12 s 的 8.84%；Auto-detect 从 11.14% 降到 9.21%。
• 单张 H100 上，80 ms 时约支持 240 路并发流，Parakeet RNNT 1.1B buffered streaming 约 14 路；1.12 s 时约为 2,400 路对 400 路。

设计目标不是只追求离线 WER，而是在准确率、端到端延迟、显存和并发之间提供可调的 Pareto 点。

二、模型架构

2.1 Cache-Aware FastConformer

FastConformer 结合卷积对局部声学模式的建模能力和注意力对长程依赖的建模能力。Nemotron 3.5 使用 24 层 Cache-Aware FastConformer。缓存同时覆盖 self-attention 和 convolution 状态，因此当前 chunk 可以复用上一 chunk 的隐藏状态。

设第 k 个音频块为 x_k，上一步缓存为 C_(k-1)：

传统 buffered streaming 会把上一段上下文与当前音频重新拼接，导致重叠帧重复计算；Cache-Aware 方案只计算新到达的帧，缓存负责保留上下文。

2.2 语言 ID Prompt Conditioning

编码器输出 H_a 的形状是 (1024,T)。语言 ID 被编码为 128 维向量 e_lang，沿时间轴广播为 H_l，二者拼接后经过投影层送入 RNNT：

已知语言时可以输入 en-US、de-DE、zh-CN 等 locale；未知语言时使用 auto 模式。语言向量是每个时间帧都可见的条件信号，而不是附加在最终文本后的标签。

2.3 RNN-T

RNN-T 用 prediction network 建模已输出的 token 历史，用 joint network 融合声学状态与标签状态：

它能在音频流持续到达时逐步发射 token，比必须等待整段音频的离线 encoder-decoder 更适合实时语音代理。

三、创新点

• 缓存级流式计算，减少 buffered streaming 的重叠重算。
• 语言提示让一个共享 checkpoint 覆盖多语言 locale。
• chunk size 可在推理时切换，不需要重新训练。
• 原生支持 punctuation 和 capitalization。
• 0.6B 参数配合缓存式推理，在 H100 上获得高并发。

四、训练数据：规模、来源与标签

官方模型卡给出的训练数据范围是 10,000 到 1,000,000 小时，覆盖 40 个 language locale。来源包括 NVIDIA Riva multilingual ASR training set（专有）、NVIDIA Granary、Multilingual LibriSpeech、Mozilla Common Voice、FLEURS、VoxPopuli 和 Europarl-ASR。

训练标签包括人工标签和合成标签。合成 ASR 标签来自 Canary、Parakeet Multilingual 1.1B RNNT、Parakeet CTC 1.1B、Whisper large-v3 与 FunASR 的模型集成；标点和大小写由 Qwen3-32B 生成：

Consensus 不能被擅自解释为简单多数投票，因为官方没有披露集成规则。工程上还应结合语言一致性、字符速率、重复检测、空输出和长度比过滤。

4.1 Granary 数量级

Granary 覆盖 25 种欧洲语言，聚合规模约 1M 小时；ASR 侧约 643,238 小时，AST 侧约 351,000 小时。

Granary 主要提供 NeMo JSONL manifest 和元数据，部分来源需要另行下载音频。典型字段包括 audio_filepath、text、source_lang、target_lang、original_source_id 和 dataset_source。

五、训练阶段

• 阶段 A：收集和统一 manifest。保留路径、时长、采样率、语言、来源、许可证和原始 ID。
• 阶段 B：切分、VAD、说话人和语言质检。检查时长、静音比例、字符速率、语言一致性、空文本和异常重复。
• 阶段 C：多模型伪标注与 PnC。生成候选、做一致性筛选，再用 Qwen3-32B 统一标点和大小写。
• 阶段 D：流式多语言 ASR 训练。使用 Cache-Aware FastConformer-RNNT、语言 ID 条件和混合多语言数据。
• 阶段 E：多延迟点评测。以 80 ms 为基本帧，测试 80 ms、160 ms、320 ms、560 ms、1.12 s。

六、Granary v2 流水线

Granary v2 把原始录音加工成带元数据、可追溯、可继续处理的训练数据。官方教程包括 Metadata extraction、Indic ASR、Qwen Omni ASR 和 Text pipeline。

6.1 Metadata extraction

• 读取 recording manifest，重采样到单声道 16 kHz WAV。
• Sortformer 做说话人分离并输出 RTTM。
• Silero TensorRT VAD 切分语音段。
• CNN14 TensorRT 预测声音事件。
• SpeechBrain、Indic Canary、Whisper 做多级语言识别。
• 根据一致性选择 source_lang，保留拒绝原因。
• 片段编码为 Opus，并写出 JSONL metadata。

没有语音的录音保留 vad_empty 审计行；语言意见不一致时保留 skip 标记和预测结果，避免把“无语音”和“文件缺失”混为一谈。

6.2 Indic ASR

Hindi 示例有 11 个阶段：读取 manifest；准备单声道 16 kHz 音频；Canary 主转写；主结果 hallucination 检查；Parakeet 恢复候选；恢复结果检查；选择最佳预测；正则清洗；缩写合并；计算 WER；写回 JSONL。两个 ASR 模型会对每个有效片段都运行。

示例限制 0.5 到 40 秒；最终字段包括 primary_model_prediction、fallback_model_prediction、best_prediction、cleaned_text、abbreviated_text 和 wer_pct。

6.3 Qwen Omni ASR 与 Text pipeline

Qwen3-Omni 生成主转写，已有 transcript 只作为回退文本，不发送给 Qwen。随后执行规则型 hallucination 检查、最佳预测选择、标点和空白清理、缩写合并。Text pipeline 不读取音频，负责实体恢复、PnC、语言识别与验证、逆文本规范化、captioning、code switching 和 speech QA。

6.4 Xenna 与 Ray Data 吞吐

官方对比使用 8 张 H100 80 GB GPU、相同 cohort、镜像、模型和 stage 设置。音频管道吞吐包含模型启动时间；Text pipeline 复用了已启动的模型服务器。

七、实验对比：FLEURS 与流式延迟

在 1.12 s、LangID 条件下，官方表中英语 WER 为 7.91%，西班牙语 4.11%，意大利语 4.25%，葡萄牙语 5.48%，Hindi 6.81%，德语 8.31%，法语 9.03%，俄语 9.17%，乌克兰语 13.07%。Hindi 在 80 ms 下 LangID 为 8.13%，Auto-detect 为 11.47%；1.12 s 下分别为 6.81% 和 8.23%。日语、韩语和普通话使用 CER。

chunk 增大通常带来更多右侧上下文，平均 WER 下降但等待时间上升：

八、吞吐对比与系统意义

优势来自参数规模、缓存复用、chunk 粒度和 H100 推理实现的共同作用，而不是单纯参数更小：

• Fish Audio Drama 3 技术报告：https://arxiv.org/html/2610.18010v2
• Github：https://github.com/fishaudio/fish-speech
• Fish Audio 权重：https://huggingface.co/fishaudio/drama-3

一、论文要点与模型定位

Drama 3 是一个开放权重语音生成模型，总参数量约 35B，但采用稀疏混合专家结构，每个 Token 实际激活约 3B 参数。模型主干由 Qwen3.5-35B-A3B 初始化，采用 40 层混合架构：每四层包含三层 Gated DeltaNet 线性注意力和一层 Gated Full Attention。语音部分沿用 Fish Audio S2 的离散音频 Tokenizer，每个音频帧由 10 个 Codebook 表示；模型主干预测语义 Codebook，新的 Codebook-MTP Decoder 在同一时间位置并行预测其余 9 个声学 Codebook。

论文把创新概括为三点：

• Hybrid Backbone + Codebook-MTP Decoder：用线性注意力处理长上下文，同时用少量 Full Attention 保留远距离检索能力，并将 S2 的逐 Codebook Fast AR 替换成一次运行 13 层的多 Token 预测解码器。
• 一个模型统一多任务：多参考音色克隆、自然语言控制、多角色场景、多轮导演式修改、Speech Infilling、长文本合成和 Streaming Text Input 使用同一种交错文本—音频 Token 流表示。
• 单一人类偏好奖励：RL 不再把 ASR WER、音质模型和 Speaker Similarity 作为规则奖励，而是训练一个小型 Speech Language Model 作为人类偏好 Reward Model。

二、总体架构

Drama 3 没有额外的音频编码器。参考音频、提示音频和生成音频都先通过离散 Audio Tokenizer 转换成 Codebook 序列，之后与文本 Token 交错输入语言模型。每一个音频帧只占用一个 Backbone 序列位置，因此一秒语音约占 21.5 个位置，与该帧包含多少个 Codebook 无关。

2.1 音频 Tokenizer

• 基于 Descript Audio Codec，输入采样率为 44.1 kHz。
• 约每秒 21.5 个音频帧，每帧 10 个 Codebook。
• Codebook 0 是语义码，Codebook 1–9 是逐级增加细节的残差声学码。
• 编码和解码完全因果，可以流式运行。
• 参考音频以离散 Token 进入上下文，因此参考音频的细粒度声学信息可以被后续 Decoder 直接访问。

2.2 Hybrid Backbone 与 MoE

主干初始化自 Qwen3.5-35B-A3B，仅使用其语言模型部分。40 层结构由三层 Gated DeltaNet 加一层 Gated Full Attention 组成周期。DeltaNet 使用近似常数大小的状态保存历史，只有每四层中的 Full Attention 保留随上下文增长的 KV Cache；Full Attention 用来精确检索长上下文中的参考音色、早先台词和场景信息。

每一层的前馈网络都是 MoE：共有 256 个 Routed Experts，每个 Token 路由到 8 个专家，并额外经过一个 Shared Expert。总参数约 35B，但每个 Token 约激活 3B 参数。MoE Router 在预训练和 SFT 阶段都加入负载均衡损失，避免大多数 Token 集中到少数专家。

2.3 Partial Codebook Fusion

S2 将 10 个 Codebook 全部反馈给 Backbone。Drama 3 只把语义码和第一层声学码反馈给 Backbone，Codebook 2–9 绕过 Backbone，作为 Decoder 的侧输入。这样既保留参考音频和已生成语音的粗粒度声学线索，也减少模型暴露在自身采样细节上的误差累积。

设第 t 帧的语义码和第一层声学码分别为 \(q_t^{(0)}\) 和 \(q_t^{(1)}\)，则 Backbone 的音频输入为：

其中 \(s(\cdot)\) 把语义码映射到新增的 4096 个语义 Token，\(\mathbf{E}^{\mathrm{LM}}\) 是语言模型词嵌入，\(\mathbf{E}^{(1)}\) 是第一声学 Codebook 的嵌入表。文本位置只使用语言模型嵌入；Codebook 2–9 不进入 Backbone。

2.4 Codebook-MTP Decoder

在第 t 个位置，Backbone 预测下一帧的语义码 \(q_{t+1}^{(0)}\)；Decoder 在同一位置预测下一帧的 9 个声学码 \(q_{t+1}^{(1)},\ldots,q_{t+1}^{(9)}\)。Decoder 共有 13 层：前 4 层是共享层，后 9 层分别对应声学 Codebook 1–9。每一层沿完整时间序列做因果注意力，所以每一个声学 Codebook 都能看到参考音频和此前所有帧的声学细节。

每层先把注入的 Codebook 嵌入与上一层隐藏状态合并：

随后经过因果 Transformer Block：

第 k 个 Codebook 的输出分布可以写为：

相较于 S2 的 4 层 Fast AR 重复运行 10 次，Drama 3 的 13 层 Decoder 每帧只运行一次，因而大幅缩短顺序路径。

三、训练数据与三阶段预训练

数据由完成转录的语音和文本文档组成；所有语音在进入训练前先经过质量控制；文本文档用于保持 Backbone 的语言建模能力；总体训练规模为数千亿 Token；语言覆盖沿用 S2，约 80 种语言和方言。

3.1 Stage 1：基础文本到语音映射

• 最大序列长度 8K Token。
• 训练样本包括纯文本文档和多轮 TTS 对话。
• 目标是学习文本到音频 Token 的映射、普通 TTS 和零样本音色克隆。
• System 轮保存任务指令和参考音频，User 轮保存待合成文本，Assistant 轮保存目标音频 Token。
• 损失只计算在 Assistant 的音频输出、必要的分隔符和结束 Token 上。

3.2 Stage 2：降低梯度噪声

Stage 2 继续使用 Stage 1 的序列格式和任务分布，主要变化是 Batch Size 翻倍，从而降低梯度噪声；学习率衰减留到 Stage 3。它并非独立的新任务阶段，而是让基础语音建模能力在更稳定的优化条件下继续收敛。

3.3 Stage 3：长音频、流式和编辑

• 最大序列长度提升到 16K Token。
• 加入整段录音合成：参考音频来自同一录音的后部，目标是前部，避免参考片段和监督目标重叠。
• 加入逐行合成，用 \(<|audio_separator|>\) 对齐输入文本行和输出音频段。
• 加入 Streaming Interleave：每个 User 轮包含当前文本块和一个前瞻文本块，模型边生成当前块边知道后续内容。
• 加入 Speech Infilling：保留原音频编辑窗口前后的 Token，只生成窗口内部的新内容。
• 样本使用 Document Masking 打包成每行 128K Token，优化器为 Muon。

3.4 预训练目标

令 \(\mathcal{T}\) 为需要监督的文本位置（包括结束 Token 和逐行分隔符），\(\mathcal{S}\) 为语义 Codebook 监督位置，则：

总损失为：

文本、语义码和声学码各自按自己的监督桶取平均，避免一个 Batch 中文本和语音比例变化导致损失权重漂移；声学 Codebook 损失会反向传播到 Backbone。预训练和 SFT 同时加入 MoE Router 负载均衡损失。

四、Instruction SFT 阶段：如何让模型学会“听懂导演指令”

SFT 从 Stage 3 Checkpoint 开始，最大序列长度为 32K Token，使用 Indexed Reference Layout。SFT 的目标不是重新学习基础发音，而是把已经具备 TTS 和克隆能力的模型转化为能够遵循复杂自然语言指令、处理对话和场景的生成器。

4.1 SFT 数据类型

• 普通音色克隆：一段或多段参考音频 + 待合成文本。
• Point Tags：在文本位置插入 [laughs]、[pause]、[coughs] 等局部事件。
• Scoped Tags：用 <whisper>...</whisper> 只控制被包围的词或短语。
• Style Prefix：控制整句的情绪、语速、表达方式。
• Director’s Note：用自然语言描述意图、节奏、重音和表演方式。
• 多说话人对话：每个角色绑定一个或多个参考音频，通过 speaker Token 切换角色。
• 多角色场景：一次提供所有台词，并使用显式分隔符，使当前句能够利用后续台词和场景上下文。
• 多轮修改：保留旧参考和上一版生成结果，下一轮用“更柔和、更温暖”“比上一版更快”等相对指令生成新版本。
• 长文本、Speech Infilling 和 Text-only Chat：继续混入训练，防止 SFT 破坏 Stage 3 已学能力。

4.2 SFT 样本如何组织

训练序列采用 ChatML 风格。System 轮包含“把给定文本转换成语音”的任务说明、参考文本和参考音频；User 轮包含目标文本、说话人标记、控制标签和语言/时长提示；Assistant 轮以 \(<|voice|>\) 开始，输出目标音频的 10 个 Codebook。对于多轮修改，旧的 Assistant 音频保留在上下文中，下一轮 User 给出相对上一版的修改意见。

损失只作用于模型自己的 Assistant 输出：语音帧的 10 个 Codebook、需要学习的音频分隔符和 \(<|im_end|>\)。参考音频只提供上下文，不直接产生生成损失。Speech Infilling 额外对编辑窗口两侧的接缝加大监督，使新旧音频能够自然拼接。

五、RL：从可控生成到符合人类偏好的表演

RL 从 SFT Checkpoint 开始。S2 使用 ASR 转录错误、语音质量和 Speaker Similarity 三类规则奖励；Drama 3 去掉它们，因为笑声和长停顿会改变 ASR 结果，耳语和喊叫会降低与中性参考的相似度，而整句质量模型无法评价某个词是否按指令变得更柔和或更有情绪。

5.1 人类偏好 Reward Model

Reward Model 是一个较小的 Speech Language Model，使用相同的 Audio Tokenizer 和序列格式预训练到 Stage 2，并在每条 Take 的结束 Token 上增加 Scalar Head。它直接读取完整 Prompt 和生成音频 Token，不需要额外运行 ASR、Tokenizer Decoder 或 Speaker Model，因此参考音色、文本内容和表演风格都能在同一奖励路径中被判断。

对两条 Take 的人类偏好使用 Bradley–Terry 损失：

5.2 GRPO 配置

• 每个 Prompt 采样 \(G=8\) 条 Take，温度为 1，不使用 Top-p 或 Top-k 截断。
• 每条 Take 最长约为期望时长的 2.5 倍，且不超过 4096 帧，约 190 秒。
• 组内 Reward 标准差低于 0.05 的组丢弃。
• 使用 Group Relative Policy Optimization，采用均值中心化优势，不使用 KL Penalty 和 Reference Model。
• 每一步使用 1536 个 Prompt × 8 条 Take，采用大 Batch、少步骤、恒定 Muon 学习率和无 Weight Decay。
• RL 时 Codebook-MTP Decoder 保持冻结，只更新 Backbone 的语义 Token 策略。
• Rollout 使用块缩放 FP8 专家权重；训练器使用 BF16，并通过路由回放减少训练和推理路由不一致。

奖励标准化与组内相对比较可写为：

论文强调，大 Batch、少更新步可以让策略朝向更广泛的人类偏好移动，并减少小 Batch、多步训练出现的 Reward Over-optimization。

六、推理引擎与吞吐优化

线上请求分为 Prefill 和 Decode 两阶段：Prefill 一次读取文本与参考音频，Decode 每帧执行一步。单 GPU 同时服务多个流，按轮次执行新请求 Prefill 或所有运行中流的一步 Decode。

• 减少顺序路径：Codebook-MTP 13 层每帧运行一次；S2 的 Fast AR 需要 10 次、共 40 层顺序 Pass。
• FP8 Routed Experts：专家使用块缩放 FP8，每个专家参数约 1 Byte。Drama 3 每帧读取约 6.0 GB 权重，不到 S2 的五分之二。
• 删除 CUDA Graph 之外的 Kernel：辅助 Decode Kernel 从 1429 个降到 1278 个，B300、并发 32 时提升 1.7%；融合 Gated DeltaNet Decode 和采样器计数器后减少 100 个 Kernel，单流提升 4.2%。
• Prefill Graph：Gated DeltaNet Prefill 每层 Kernel 从 23 个降为 13 个；首帧采样的 Host 时间从 30.9 ms 降至 14.7 ms，早期开发模型在 H200 并发 32 时提升 15.3%。
• 按线上 Shape 优化 Kernel：从真实服务日志抓取矩阵形状、Batch 和并发分布，再做 Nsight Profiling、算子级验证、引擎内 Token/WER 验证和同机 A/B 测试。FP8 MoE Kernel 在 \(M=256\) 时将 MoE 层耗时降低 19.2%。
• Prefill–Decode 解耦：新请求的 Prefill 不再阻塞正在播放的 Decode 流，降低高并发下的流式卡顿。

七、实验设置与结果

实验统一使用论文附录中的 Prompt 格式，采样温度 0.7、Top-p 0.7、Top-k 30。静音、语音过短、长度失控、长段噪声或长段静音的输出会被重新生成并重新计分。中文使用 Paraformer-zh 转录，其余语言使用 Whisper-large-v3；Speaker Similarity 使用 WavLM-large + ECAPA-TDNN 说话人嵌入余弦相似度。

7.1 Preference Reward 对表达性的影响

在 Expresso 中，将同一说话人同一句话的中性读法与风格读法配对。耳语相对中性读法的 SIM 下降 0.310，笑声使 WER 上升 0.79 个百分点；因此相似度奖励在耳语样本中 99.7% 偏好中性读法，在笑声样本中 93.9% 偏好中性读法。Drama 3 的 Preference RM 在提示中明确写出风格后，偏好耳语的比例为 62.2%，偏好笑声的比例为 64.4%；不写方向时分别只有 10.6% 和 27.1%。

在 Seed-TTS-Eval 上，RL 后 Drama 3 的首轮中文 CER 从 SFT 的 1.66 降到 1.00，英文 WER 从 3.49 降到 2.20；信号检查失败率从中文 2.82% 降到 1.24%，英文 3.40% 降到 1.84%。重生成异常样本后，中文 CER 为 0.83，英文 WER 为 1.54。

7.2 多参考零样本音色克隆

论文在 LibriSpeech-PC test-clean 上扩展多参考测试集：1127 句、39 位说话人，每个目标说话人额外提供两段不包含目标句的参考音频。Drama 3 使用一段参考时 WER 1.85%、SIM 0.605、UTMOS 4.31；使用三段参考时 WER 仍为 1.85%，SIM 提升到 0.633，UTMOS 仍为 4.31。单参考时，UTMOS 4.31 高于 OmniVoice 的 4.28 和 CosyVoice 3 的 4.28；Qwen3-TTS 为 4.41，但其 WER 和 SIM 分别为 1.60 和 0.704。

7.3 MiniMax 多语言克隆

MiniMax Multilingual Testset 覆盖 24 种语言。Drama 3 相比 OmniVoice 在 15 种语言上错误率更低，相比 FireRedTTS3-Base 在 17 种语言上更低；在阿拉伯语、中文、荷兰语、英语、芬兰语、法语、德语、波兰语、葡萄牙语、土耳其语和越南语 11 种语言上同时低于 OmniVoice、FireRedTTS3-Base 和 Fish Audio S2。与实际通过 API 运行的商业系统比较时，Drama 3 低于 Inworld TTS-2 的语言数为 18，低于 Soniox TTS RT v2 的语言数为 21/23，低于 ElevenLabs v4 的语言包括中文、荷兰语、英语、德语、韩语、俄语、西班牙语、泰语和土耳其语。

7.4 Streaming Synthesis

在 1088 条 Seed-TTS-Eval 英文测试句上，流式输出 WER 为 1.86，非流式输出 WER 为 1.83；两者 SIM 都为 0.640。结果说明把音频边生成边发送不会带来明显质量损失。

7.5 Speech Infilling 编辑

在 Ming-Freeform-Audio-Edit 中，先用 Qwen3-ForcedAligner-0.6B 将源音频和转录对齐，再把从第一个不同词到最后一个不同词的区域作为编辑窗口。删除操作还会包含相邻未改变词，以保证窗口有可学习的边界。模型保留窗口前后源音频 Token，只生成窗口内部的目标文本，然后整体解码，避免把源波形直接贴回造成拼接痕迹。

中文结果中，Drama 3 在插入和替换上的 SIM 分别为 0.909 和 0.898，高于专用编辑模型 CosyEdit2 的 0.89；删除 WER 为 7.82，低于 CosyEdit2 的 8.23。与 Cartesia Sonic-3 的 Infill API 比较，Drama 3 在 Ming-Freeform 基础集/完整集上的英文 WER 为 3.49/3.43，中文为 3.69/2.35；Cartesia 对应为英文 4.58/4.68、中文 8.64/6.53。

7.6 多轮导演式修改

Step-Audio-Edit 要求模型先克隆声音，再通过最多三轮指令逐步靠近目标情绪或风格。Drama 3 在每轮中保留原始参考和上一版 Take，并以 [happier versus previous] 一类相对指令重生成。情绪准确率从第 0 轮的 55.5% 提升到第 3 轮的 58.2%，风格准确率从 76.5% 提升到 81.8%。使用 [coughs] 等 Point Tag 进行局部插入并 Infilling 后，拟声事件评分从 1.32 提升到 2.32。

八、工程实现启示

• 长上下文语音模型可以采用“多数线性注意力 + 少量 Full Attention”，在降低 KV Cache 成本的同时保留参考音频和早期台词的精确检索。
• 多 Codebook 音频生成不必让主干逐一预测所有声学码；将粗语义信息反馈给 Backbone，把细节留给时间因果 MTP Decoder，可以同时降低曝光偏差和推理顺序长度。
• 如果训练目标是表现力，WER、SIM 和整句音质分数不宜直接作为唯一奖励。更合理的做法是让 Reward Model 读取“指令 + 参考音频 + 生成音频 Token”的完整上下文。
• SFT 数据应把多轮对话、参考音频索引、Point/Scoped Tag、分隔符和编辑窗口作为一等数据结构，而不是只把音频和文本做成单句配对。
• 线上性能主要受权重搬运、Kernel Launch 和 Prefill 阻塞影响。需要从真实服务 Shape 出发做算子优化，并将 Prefill 与 Decode 分离。

九、结论

Drama 3 的关键不只是把模型扩大到 35B，而是把模型、数据格式、SFT 任务和 RL 奖励统一到“导演式表演”这一目标上。Hybrid Backbone 解决长上下文，Partial Codebook Fusion 控制反馈复杂度，Codebook-MTP Decoder 直接利用参考音频的细粒度声学信息；三阶段预训练建立基础语音能力，32K Token 的 Instruction SFT 教会模型遵循指令和维护多轮上下文，单一人类偏好 Reward Model 则让笑声、耳语、停顿和情绪表达不再被传统规则奖励压制。

从实验结果看，Drama 3 在多参考克隆、多语言识别准确率、流式生成、语音编辑和多轮修改上都表现出统一模型的优势；从工程结果看，它在单 H200 上达到 271 frames/s，高于参数量小得多的 Fish Audio S2。论文没有公开完整数据来源和样本规模，这一限制需要在复现或二次训练时单独补齐。

摘要：哔哩哔哩 Index LLM 团队在 2026 年 9 月发布了 Index-Translate。它不是单一的“文本翻译模型”，而是以 Qwen3.5 为基础，向文本、语音翻译、音节可控配音和原生长文档翻译扩展的模型家族。

• Index-Translate GitHub README：https://github.com/bilibili/Index-Translate/blob/main/README_zh.md
• Index-Translate 技术报告：arXiv:2609.40181
• HOMURA：arXiv:2601.10187
• RIVAL：arXiv:2506.05070
• Hugging Face 论文合集：Index-Translate Papers

一、项目定位：把“翻译质量”扩展为可交付能力

传统机器翻译通常优化句子级质量，但真实内容生产还需要保留 JSON、CSV、Markdown、变量占位符和术语；字幕要适配时长；社区文本要翻出梗意；书籍翻译要维持人物、术语和概念层级。Index-Translate 的核心判断是：翻译模型应当同时优化语义、约束、模态和上下文，而不是只追求一个 BLEU 或 COMET 分数。

模型家族目前包含五类成员：

• Index-Translate：文本、结构化内容、指令翻译与社区表达，覆盖 150 种语言，提供 2B、9B 和 35B-A3B（preview）。
• Index-Echo：语音到文字（S2TT）和语音到语音（S2ST），支持目标语言字幕、配音与说话人声音条件。
• Index-Homura：接收目标音节数，在保持语义的同时重组译文长度。
• Index-NativeLong：输入完整文档并连续生成译文，面向书籍、网文和长篇资料的一致性。

二、统一基础模型：多语种中训 + 专家融合

1. 多语言 Mid-training

技术报告将训练拆成 constant 和 decay 两阶段。constant 阶段混合通用文本、平行语料和单语文本，采样比例为 1:1:1，7,000 步、117.44B tokens；decay 阶段使用通用文本、pivot-20 与 pivot-148 数据，比例为 1:4:2，3,000 步、50.33B tokens。总预算约 167.77B tokens，序列长度通常为 4,096，随后为长文档任务增加更长上下文。

这里的 pivot 组织不是简单地把双语句对堆在一起，而是通过英文锚点把多个语言版本连接起来。例如：

\(x_{zh}\leftrightarrow x_{ja}\) 表示普通平行数据；\(x_{zh}\leftrightarrow x_{en}\leftrightarrow x_{ja}\) 表示 pivot 数据。报告中的消融显示，多语言覆盖能明显提升非核心语言表现，同时仍需控制对通用能力的损耗。

2. 专家训练与融合

团队分别训练通用翻译专家、指令翻译专家和 MEME（社区文化表达）专家。指令专家使用约 104.5 万条、覆盖十类真实场景的样本；训练目标既包括术语、格式和结构保护，也包括风格、上下文消歧和跨句一致性。通用翻译和指令翻译使用 GRPO，MEME 使用参考引导的 LLM judge。

融合不是简单拼接多个 LoRA，而是先做参数插值：

发布模型使用的代表性权重为 \(w_G:w_I:w_M=0.8:0.1:0.1\)，之后用针对弱项的多教师 on-policy distillation（MOPD）修补融合后的能力缺口。这种设计的价值在于：通用质量、指令遵循和文化适配可以共享底座，但不必强行用一个训练目标解决所有任务。

三、三项关键扩展：语音、音节与长文档

1. Index-Echo：从“翻译文本”到“翻译声音”

Index-Echo S2TT 将 Qwen3-Omni AuT 音频编码器与 Index-Translate 解码器连接起来，直接从源音频生成目标语言文字。S2ST 则在 S2TT 基础上增加约 3,000 万参数的 Hidden2CV 映射器，把翻译器隐藏状态映射到 CosyVoice3 的语义层，并使用 DiffRO 通过 Gumbel-Softmax 语音 token 优化内容一致性；源音频还提供说话人 embedding 与声音提示。

报告还比较了 pipeline 与端到端 S2ST。以中文到日语为例，9B 端到端方案的内容错误率均值/中位数为 0.0436/0.021，音色相似度 Spk 为 0.782；这说明语音翻译的评价不能只看文本，还要同时考察内容、时间轴和说话人条件。

2. Index-Homura：把音节预算写进优化目标

HOMURA 论文指出，大语言模型翻译存在跨语言“冗长偏置”：译文往往比时间预算允许的长度更长。它提出 Sand-Glass 基准，用真实视频转写、停顿分段和信息密度校准构造音节级时长约束。中文到英文、德文、西班牙文的理论扩展约为 1.03、1.19、1.49 倍，但未经约束的 LLM 平均扩展可达到 1.35、1.59、1.84 倍。

HOMURA 的基本长度比定义为：

其中 \(\sigma(\cdot)\) 是音节数。模型使用动态区间 \([L(x),R(x)]\)，短句会适当放宽下界，长度奖励采用区间内满分、区间外指数衰减；质量奖励则由回译语义相似度、流畅性判定和可选的 GenRM 组成。整体目标可写为：

在 3,600 条 Sand-Glass 测试案例中，Index-Homura-9B 的输出有 81.92% 与目标音节数偏差不超过 10%，明显高于普通模型的约 13%–48%。代价是：当约束越来越紧时，COMET 等质量指标会下降，模型必须在信息密度与自然度之间做可解释的折中。

3. Index-NativeLong：原生长文档而不是“分块 + 词表”

NativeLong 的关键假设是：书籍翻译中的人物身份、术语层级和叙事关系，不能完全依靠分块翻译后再拼接。2B/9B 模型通过约 4K–64K 中文侧 token 的双向文档监督进行全参数 SFT，并在 mid-training decay 阶段使用 128K 序列实验。报告显示，Index-NativeLong-9B 在 GuoFeng、BWB、General Books 上的平均得分分别为 0.7891、0.7683、0.8848。

案例中，32K token 奇幻文本里的“王妃”在原生全文翻译的三个位置都保持为 Wang Fei，而同一 9B 模型使用分块和自动词表时，后文变成 the Dean、The Queen Consort。冰川史案例也显示，原生全文能够区分 ice age（冰河时代）、glacials（冰期）和 interglacials（间冰期），避免把上下位概念压成同一个词。

四、RIVAL 与 HOMURA：两条强化学习技术线

Index-Translate 技术报告明确吸收了 RIVAL 的训练思想。RIVAL 发现，传统 RLHF 中离线 reward model 会因为策略分布不断变化而失配，模型可能通过“奖励投机”获得高分，却生成不存在于原文的内容。因此 RIVAL 把 reward model 与翻译模型写成迭代的 min–max 对抗过程：

RIVAL 的 reward model 同时学习定性偏好和定量偏好：前者用强/弱翻译排序，后者用 BLEU 的 MAE 近似。实验中，MAE 的定量误差为 0.19、定性准确率为 99.5%，优于 MSE 的 0.93 和 97.0%。在中文到英文的口语字幕任务上，RIVAL-Iter1 的 GPT-4o 平均评分为 3.68，优于 Qwen2.5-7B-SFT 的 3.46；WMT 中文到英文在 Iter2 达到 BLEU 33.42、COMETKiwi 73.61。

两条技术线各自解决不同问题：RIVAL 解决 reward model 与策略分布漂移，HOMURA 解决时长约束下的质量—压缩折中。Index-Translate 则把这些训练方法组合到通用翻译、指令翻译、MEME 和字幕任务中。

五、实验对比：质量、约束遵循与小语种不能混成一个分数

技术报告使用 FLORES-200、FLORES 低资源对、WMT24++、WMT26、instTrans、IFMTBench、MEME、OPUS-Books、Biomedical、MTNT、MuST-Cinema 和 GuoFeng-Webnovel 等数据。需要注意：COMET-22、XCOMET-XXL、WMT judge、IFscore 和 MEME 分数的量纲不同，不能直接横向相加。

低资源结果更能体现项目的训练取向：35B-A3B 在 FLORES_minor_pair 上取得 COMET-22 0.8168、XCOMET-XXL 0.7164，off-target 仅 2.4%；9B 在 instTrans_minor 上取得 IFscore 0.7725，且 off-target 为 3.47%。指令基准 instTrans 包含 3,000 条中文到 20 种语言任务，低资源扩展另有 2,793 条；MEME 则包含 3,638 条中译英社区表达，覆盖 703 个词语和 857 个词义。

通用能力方面，Index-Translate-9B 的 C-Eval、GPQA-Diamond、INCLUDE、MMMLU 分数分别为 69.6、36.3、63.1、66.6；这说明专家融合后仍保留一定基础模型能力，但它的主要优势仍在翻译与约束任务，而非通用问答榜单。

六、最值得关注的创新点

• 能力边界被显式建模：把“格式是否保留、术语是否一致、目标语言是否正确、音节是否命中、长文身份是否稳定”作为可测量目标，而不是只看译文流畅度。
• 多语基础与专门模型分工：150 语种共享基础模型，语音、音节、长文档采用专门训练，避免一个模型在所有约束上互相牺牲。
• 奖励函数更接近生产需求：通用翻译使用 XCOMET、目标语言 gate 和 adequacy；指令翻译加入硬约束 gate；HOMURA 加入动态音节奖励；RIVAL 用迭代 reward model 缓解 reward hacking。
• 参数融合后再定向蒸馏：先用 0.8/0.1/0.1 融合通用、指令和 MEME 专家，再通过 MOPD 修复融合造成的局部退化。
• 从句子级走向内容生产级：语音输出、时间轴、声音条件、结构化数据和全篇一致性都进入同一产品路线。

七、局限与使用建议

第一，35B-A3B 仍是 preview，论文与 README 的部分评测使用不同解码和汇总口径；引用数据时应注明模型版本和指标。第二，音节数只是语音时长代理，真实配音还受语速、停顿、音素时长和声码器影响。第三，NativeLong 对超长文档的显存、吞吐和错误恢复要求较高，生产部署仍要评估上下文窗口与并发成本。第四，LLM judge、回译和 XCOMET 都可能存在偏差，官方也记录了引用后缀、终止标记等 judge failure cases。

如果你的任务是结构化资料、社区内容或多语言产品文本，优先选择 Index-Translate-9B；如果是低延迟或资源受限场景，可从 2B 开始。如果是视频字幕和配音，建议使用 Index-Echo + Index-Homura 的组合，并把实际音频时长作为最终验收标准；如果是书籍、网文或技术报告，优先测试 NativeLong 的全篇一致性，再决定是否采用分块流程。

八、结语

Index-Translate 的价值不只在于“多翻几种语言”，而在于重新定义翻译模型的交付指标：能否保留结构、接住语境、压进时长、维持音色，并在一整本书里保持同一个人物和概念。它的工程路线也很清晰：共享多语底座，专家化训练，参数融合与定向蒸馏，再为语音、长度和长文档建立专门接口。对于希望把翻译直接接入内容生产流程的团队，这种模型家族式设计比单一榜单分数更值得关注。

参考资料

• Index-Translate GitHub README：https://github.com/bilibili/Index-Translate/blob/main/README_zh.md
• Index-Translate 技术报告：arXiv:2609.40181
• HOMURA：arXiv:2601.10187
• RIVAL：arXiv:2506.05070
• Hugging Face 论文合集：Index-Translate Papers
• 公众号文章：B站开源 Index-Translate 多语言翻译模型家族

• https://www.modelscope.cn/models/MiniMax/MiniMax-Music3
• https://www.minimaxi.com/blog/minimax-music-3-0-cn

MiniMax Music 3 是一种高性能的音乐创作模型，能够生成时长可达五分钟的完整歌曲。该模型基于歌词和详细的音乐描述进行创作，能够生成结构紧凑、富有表现力的歌曲，同时具备稳定的长音频质量。只需提供一个创意想法和可选的歌词，模型即可在一次生成中完成作曲、编曲、演唱与制作，创作出一首完整的歌曲。

从音乐描述、语言模型到声音渲染重新设计了整条生成链路：用细粒度时序描述呈现情绪、配器与演唱的发展，以全局—局部协作的 Hybrid-LM 兼顾长程结构和声学细节，再通过多层 RVQ、Hidden States 融合与 Flow-Matching/Flow-VAE 提升最终声音的保真度。由此带来三项核心升级：更准确地理解创作意图、更完整且富于变化的编曲，以及更清晰、更自然的声音表现。

MiniMax Music 3 模型结合了一个 8 亿参数的全局语言模型，用于构建长期的音乐结构；以及一个 0.6 亿参数的局部语言模型，用于处理帧级的声音细节。该模型还采用了基于流匹配和流变显式估计的连续隐藏状态合成系统。最终，该模型能够生成 32 kHz 采样率、16 位立体声的 WAV 音频文件。

MiniMax Music 3.0 技术解析：开放权重音乐模型如何实现完整歌曲生成

MiniMax 正式推出新一代音乐生成模型 MiniMax Music 3.0。用户只需输入一个创意想法，并根据需要提供歌词，模型便可以在一次生成中完成作曲、编曲、演唱与制作，生成最长约 5 分钟的完整歌曲。

与只追求“生成一段好听音频”的传统方案不同，Music 3.0 更关注创作者意图能否贯穿整首作品：情绪是否持续一致，乐器是否按照结构合理进入和退出，人声是否自然，歌曲是否具有完整而连贯的发展。

MiniMax 官方将 Music 3.0 定义为开放权重、生产级全能音乐模型。其核心技术路线由 Tokenizer、Hybrid-LM 和 Synthesis 三个部分组成，并通过 Structured Caption、Hidden State Fusion、Flow-Matching 和 Flow-VAE 等技术，提升音乐结构、编曲细节与声音质量。

一、Music 3.0 解决了音乐生成中的哪些难题？

音乐生成看似只需要“输入提示词、输出音频”，但真正困难的地方在于如何把抽象的创作要求转化为可持续执行的音乐结构。

• 用户指定的乐器能否贯穿整首歌曲，而不是只在开头出现？
• 歌曲从主歌进入副歌时，情绪是否有自然的铺垫和释放？
• 长达数分钟的生成过程中，节奏、调性和人声是否保持稳定？
• 复杂编曲中，鼓组、贝斯、人声和旋律乐器能否保持清晰分离？
• 生成的人声是否具有自然的发音、换气、连贯性和情感变化？

Music 3.0 的设计目标，正是同时解决这些问题。它不仅要生成一段合理的音乐，还要尽可能实现一套完整、连贯的创作构想。

二、三层技术架构：Tokenizer、Hybrid-LM 与 Synthesis

Music 3.0 的完整生成流程可以概括为三个阶段：

1. Tokenizer：将音乐压缩成适合模型理解和预测的多层离散表示。
2. Hybrid-LM：同时建模歌曲的全局结构和局部声学细节。
3. Synthesis：将语言模型理解到的音乐信息还原为高保真音频。

1. 多层 RVQ：分离音乐结构与声学细节

Music 3.0 使用八层残差向量量化（Residual Vector Quantization，RVQ）表示音乐信息。

• 第一层主要负责音乐的核心语义和结构。
• 第二至第八层逐步补充声学残差和声音细节。
• 第一层使用大小为 16,384 的码本。
• 第二至第八层分别使用大小为 1,024 的码本。

在训练过程中，模型会先单独训练第一层，使其建立稳定的音乐信息骨架，再联合训练全部八层。这样的分层设计，可以避免单层 Token 同时承担过多的结构和音质信息，也有助于降低长歌曲生成时的累计误差。

2. Hybrid-LM：全局结构与局部声学协同建模

为了兼顾长程结构和局部细节，Music 3.0 采用了全局模型与局部模型协同工作的 Hybrid-LM 架构。

• 8B Global LLM：基于 Qwen3.5-8B 初始化，负责逐帧预测音乐语义 Token，并理解整首歌曲的上下文、结构和发展方向。
• 0.6B Local LLM：随机初始化，负责在每一帧内部沿深度轴预测声学 Token，补充局部的音色、演奏和声音细节。

训练过程分为两个阶段。第一阶段主要建立 Global LLM 对音乐语义的预测能力；第二阶段则对 Global LLM 与 Local LLM 进行全参数联合训练。

这种“全局负责方向、局部负责细节”的分工，使模型能够在最长 5 分钟的歌曲中保持结构稳定，同时保留不同段落应有的变化。

3. Hidden State Fusion：从离散预测走向连续声音渲染

传统音乐生成流程通常会将离散声学 Token 直接送入解码器。Music 3.0 则进一步融合 Global LLM 与 Local LLM 的连续 Hidden States，并将其作为声音生成模块的条件输入。

官方公布的声音生成链路为：

LLM 融合特征 → Flow-Matching → VAE Hidden States → Flow-VAE Decoder → 最终音频

其中，2.4B Flow-Matching 模块负责将融合后的语言模型特征映射至 VAE 隐空间；123M Flow-VAE 则负责完成最终的音频解码。

相比只依赖离散 Token，连续 Hidden States 能够保留更多高维声学信息，从而改善人声发音、乐器连贯性和音乐细节表现。

三、Structured Caption：让模型真正理解创作意图

音乐提示词最大的难点，是很多听感描述并不能直接转化为可执行的生成条件。例如，“温暖但克制”“逐渐变得宏大”“像一场现场演出”等表达，对人类音乐制作人来说很直观，但对模型而言却需要更细粒度的结构化描述。

Music 3.0 使用 Structured Caption 对音乐进行细粒度的时序描述。它不仅描述曲风，还会进一步说明：

• 速度、拍号与调性；
• 音乐情绪如何随时间变化；
• 主奏和伴奏乐器何时进入、叠加或退出；
• 鼓组、贝斯和律动基础如何发展；
• 人声的音色、唱法、气声、假声与和声；
• 空间感、混音质感、Delay 和 Autotune 等效果。

这套描述方式将抽象的音乐感受转化为更接近专业编曲语言的生成条件，使模型能够在歌曲发展过程中维持统一的音乐身份，同时保留合理的动态变化。

Prompt Enhancement：降低专业音乐创作门槛

为了让非专业用户也能使用这些复杂的音乐描述，MiniMax 构建了基于模板的 Prompt Enhancement System。

系统可以从专业 Structured Caption 模板库中选择合适的表达，并结合音乐术语与编曲规则，将用户的一句话扩展为逻辑更完整、细节更丰富的结构化提示词。

例如，用户只需输入“做一首温暖、克制的不插电歌曲”，系统就可以进一步补充人声类型、吉他演奏方式、空间感、动态变化和混音方向，使最终结果更接近用户真正想要的作品。

四、更完整、更富于变化的长歌曲编曲

长歌曲生成并不只是把音频“延长”。真正的难点在于让不同段落之间形成合理的发展关系。

Music 3.0 支持使用段落标签描述歌曲结构，包括：

• [intro]：前奏
• [verse]：主歌
• [pre-chorus]：副歌前段
• [chorus]：副歌
• [bridge]：桥段
• [instrumental]：器乐段
• [solo]：独奏段
• [outro]：尾奏

这些标签提供宏观结构，而 Structured Caption 则进一步描述每个时间阶段中的情绪、配器、人声、节奏和空间效果。两者结合后，模型可以更好地理解“哪里应该发生什么变化”。

在模型侧，8B Global LLM 负责维护全曲上下文，0.6B Local LLM 负责补充每个时间帧内的声学细节。这样的协作机制，可以帮助歌曲保持整体方向，同时避免长时间生成中出现段落重复、编曲单一或情绪突然中断。

五、声音品质升级：更清晰的混音与更真实的乐器

Music 3.0 在声音表现方面也进行了系统升级，目标是让混音更加开阔、清晰和平衡，减少传统生成音乐中常见的拥挤与浑浊感。

多层 RVQ 负责保留从核心结构到声学细节的不同层次信息；Hidden State Fusion 则在连续特征层面连接语言模型和声音渲染模块。通过这两种方式，模型可以更准确地响应具体的乐器指令，并呈现滑音、连奏等更接近真实演奏的技法。

• 独奏乐器的触弦、运弓和演奏细节更加清晰；
• 鼓组和贝斯具有更明确的冲击力与层次；
• 复杂电子编曲中的声部分离度更高；
• 低频保持力量感，同时减少对其他声部的遮蔽；
• 人声周围的空间感更加自然。

六、重塑自然人声：减少“机器感”

人声往往是生成音乐中最容易暴露机器感的部分。高频伪影、发音不清、乐句僵硬、不自然的换气，都会影响听众对歌曲情感的感受。

Music 3.0 通过新的声音渲染系统，对音色、唱法、气声、假声、和声以及 Delay、Autotune 等人声效果进行更细致的描述。

结合 Global LLM 与 Local LLM 的连续 Hidden States，Flow-Matching 和 Flow-VAE 可以将这些演唱信息带入最终的音频生成过程，从而改善：

• 歌词发音的准确性；
• 旋律线条的连贯性；
• 主歌与副歌之间的情绪变化；
• 呼吸和停顿的自然程度；
• 多层和声与主唱之间的融合。

理想情况下，生成的人声可以从克制的主歌逐渐过渡到开阔的副歌，也可以根据歌曲风格完成节奏型演唱、持续旋律、气声和声等不同表达。

七、一个适合 Music 3.0 的提示词示例

如果希望获得更稳定的结果，可以参考以下结构编写提示词：

温暖的中文流行抒情歌曲，74 BPM，A♭大调。
情绪从克制怀旧逐渐发展到温暖明亮的副歌。
成熟男中音，细腻但不过度夸张的演唱，
以钢琴、木吉他、古筝和柔和弦乐为主要配器。
主歌保持留白，副歌加入鼓组和宽阔和声，
整体采用自然的现场录音室混音质感。

[Intro]
[Verse]
[Pre-Chorus]
[Chorus]
[Bridge]
[Final Chorus]
[Outro]

这个提示词同时包含了风格、速度、调性、情绪发展、人声特征、配器、混音方向和歌曲结构，通常比单独输入“生成一首温暖的中文歌曲”更容易得到稳定、可控的结果。

八、Music 3.0 对 AI 音乐创作的意义

从技术路线来看，Music 3.0 的重点并不是单一模型规模的提升，而是对音乐生成全链路进行重新设计。

• Tokenizer 负责把音乐拆解为结构与细节；
• Hybrid-LM 负责同时理解长程结构和局部声学；
• Structured Caption 负责把创作者意图转化为可执行描述；
• Hidden State Fusion 负责连接语言理解与连续声音渲染；
• Flow-Matching 与 Flow-VAE 负责还原更高保真的最终音频。

这意味着 AI 音乐正在从“生成一个片段”逐步走向“完成一首作品”。对于音乐人、短视频创作者、游戏开发者、影视制作团队和普通用户来说，未来的重点不再只是能否生成音乐，而是能否更准确地表达创作意图，并在生成过程中保持结构、情绪和声音质量的一致性。

结语

MiniMax Music 3.0 通过多层 RVQ、Hybrid-LM、Structured Caption、Prompt Enhancement、Hidden State Fusion、Flow-Matching 和 Flow-VAE 等技术，试图解决音乐生成中最具挑战的几个问题：长歌曲结构稳定、编曲具有发展、人声更加自然，以及复杂混音中的细节还原。

它所展示的方向非常明确：音乐生成不应只是“听起来像音乐”，而应该更加接近真正的创作流程，让用户可以从一个想法出发，逐步得到一首完整、连贯并具有制作质感的歌曲。

关于模型权重、使用方式和具体开放政策，请以 MiniMax 官方最新发布页面为准。

参考资料：
MiniMax Music 3.0：新一代开放权重、生产级全能音乐模型｜MiniMax 官方技术博客