VITA-Audio：高效、低延迟的实时端到端语音大模型

VITA-Audio: Fast Interleaved Cross-Modal Token Generation for Efficient Large Speech-Language Model

项目训练和推理代码以及模型权重完全开源，VITA-Audio 支持中英双语，且训练过程中仅使用开源数据，却在同等参数量级中稳居性能第一梯队。

如何高效生成Audio Token？

在端到端语音模型中，生成音频往往要经历以下流程：首先，语音 Token 随着语言模型（LLM）前向传播被逐步自回归地生成；随后，多个已生成的语音 Token 会被收集并送入解码器，最终合成为可播放的音频。由于每一步都依赖上一步的输出，这种多次循环推理的方式在生成首个音频片段前会消耗大量时间，且随着模型规模的扩大，延迟问题愈发严重。

VITA-Audio 团队对模型最后一层解码器的 Hidden States 进行了可视化分析。结果表明，语音模型在预测某个音频 Token 时，对应的文本 Token Hidden States 所承载的注意力权重显著高于其他位置。

更进一步的实验发现：

当屏蔽所有文本位置的 Hidden States 时，模型无法生成正常的音频；
但如果仅保留与当前音频 Token 对应的那一位置的文本 Hidden States，模型依然能够输出准确、连贯的语音，且这些 Hidden States 已隐含了足够的上下文信息（例如，区分多音字“行”读作“xíng”还是“háng”）。

这一发现表明，语音生成并不需要对整个文本—音频序列的全局语义空间进行复杂建模；相反，只需利用对应位置的文本 Hidden States，通过相对简单的映射模块即可完成高质量的音频 Token 预测。

基于此，VITA-Audio 提出了一种轻量级的多重跨模态标记预测（Multiple Cross-modal Token Prediction，MCTP）模块。该模块直接在单次前向传播中预测多个音频 Token，大幅减少自回归循环次数，不仅加速了整体推理流程，更显著降低了流式场景下首个音频片段的生成延迟。

VITA-Audio 的核心组件包括音频编码器、音频解码器、LLM[Qwen2.5-7B]、十个轻量级 MCTP 模块。CosyVoice as the audio encoder and decoder。其推理流程如下：

1. 文本与音频特征分别经编码后输入 LLM，LLM 在单次前向传播中生成文本 Token 或音频 Token。
2. 将 LLM 最后一层的隐藏态和输出先输入第一个 MCTP 模块，其输出再依次传递给后续的 9 个 MCTP 模块；每个模块各自预测一个音频 Token，累计得到 10 个 Token，并由音频解码器合成为音频片段。
3. 在下一次前向传播中，LLM 生成的 Token 会与 MCTP 模块生成的音频 Token 一并作为 LLM 输入，进行下一次前向传播。

由于每个 MCTP 子模块的参数量远小于 LLM，单次预测耗时仅需约 2.4 ms（约为 LLM 推理时间的 11%），显著降低了首个音频片段的生成延迟，并大幅提升整体推理速度。

为了解决同时从头训练10个 MCTP 模块带来的不稳定性，VITA-Audio 采用了如下四阶段渐进式训练策略：

1. 第一阶段-音频–文本对齐：利用大规模语音预训练任务，将音频建模能力融入 LLM，使其 Hidden states 同时承载文本和音频信息。
2. 第二阶段-单 MCTP 模块训练：训练初始 MCTP 模块，使其能够基于 LLM 的输出 Token 和 Hidden States 预测下一个标记。
3. 第三阶段-多 MCTP 模块训练：将首个 MCTP 模块的能力扩展到多个 MCTP 模块，每个模块根据前一个 MCTP 模块的输出标记和 Hidden States 预测其对应位置的标记。
4. 第四阶段-监督微调：以语音问答数据集为主进行监督微调，同时穿插 TTS、ASR 及纯文本数据，确保模型在各类任务上的泛化能力与训练收敛的平衡。

VITA-Audio 提供四种推理范式，以满足不同应用场景对速度与质量的平衡需求：

VITA-Audio-Turbo：最高效的方式，每次前向传播 LLM 生成一个标记【音频或者文本token】，MCTP 模块生成 10 个标记【音频或者文本token】，但因 MCTP 模块也参与文本预测，性能会略有下降，常用于 ASR 和 TTS 任务中。
VITA-Audio-Boost：LLM 专注生成文本 Token，MCTP 模块生成 Audio Token，并且第一次前向中就使用全部的 MCTP 模块，可以在第一次前向中就生成可以用于解码的 Audio Token Chunk。
VITA-Audio-Balance：在前两次前向中仅激活部分 MCTP 模块，保以维持文本与音频 Token 的合理配比（1:2），随后逐步激活部模块，通过动态调节文本／音频 Token 输出比例，实现生成速度与质量的最优平衡。
VITA-Audio-Vanilla：完全依赖 LLM 自回归生成所有 Token，不调用 MCTP 加速模块，推理速度最慢，但可获得最高的音频细节与一致性。

本文介绍了 VITA-Audio，这是一个轻量级框架，其核心在于引入独立高效的多重跨模态令牌预测（MCTP）模块，能够直接从文本 Token 与 LLM Hidden States 中生成音频响应，无需依赖 LLM 的全局语义建模，仅通过简单映射即可完成文本隐藏态到音频令牌的转换。

实验表明，VITA-Audio 在仅仅使用开源数据的情况下，在 ASR、TTS 和 SQA 任务的多个基准测试中均跻身同参数量级开源模型的第一梯队；同时，其推理速度与响应延迟也取得了显著突破。由此，VITA-Audio 为实时语音到语音生成树立了全新的范式。

理想同学：MindGPT-4o-Audio实时语音对话大模型

原文链接：MindGPT-4o-Audio

理想实时语音对话大模型MindGPT-4o-Audio上线，作为全模态基座模型MindGPT-4o的预览preview版本，MindGPT-4o-Audio是一款全双工、低延迟的语音端到端模型，可实现像人类一样“边听边说”的自然对话，并在语音知识问答、多角色高表现力语音生成、多样风格控制、外部工具调用等方面表现突出，达到了媲美人人对话的自然交互水平。

核心功能

全双工语音对话：可同时听与说，告别“你说完我再说”的非自然交互模式，媲美真实人类对话；
低延迟：理解和生成推理延迟260ms，全链路峰值响应延迟800ms，联网搜索时全链路延迟2000ms；
语音知识问答：广泛学习海量高质量知识，具备高精度、低幻觉的知识问答能力；
多角色对话：多角色低成本定制，实现有灵魂、有温度的口语对话；
高表现力语音生成：情境感知下的高表现力TTS及口语化的语气词与副语言生成能力；
多样风格控制：多种特色风格、口音、IP人物的理解、控制及生成能力，稳定的多轮连续对话风格记忆能力；
外部工具调用：多模态任务规划和工具调用，支持实时联网的时效性问答。

1. 模型能力

1.1 整体算法方案

MindGPT-4o-Audio是一款级联式的语音端到端大模型，我们提出了感知-理解-生成的一体化端到端流式生成架构实现全双工、低延迟的语音对话。其中：

· MindGPT-4o-Audio Duplex：感知有效语音输入，实现对话响应时机判定、打断判定、环境音拒识等功能；

· MindGPT-4o LLM ：理解语音及语言模态信息，经MindGPT-4o-Audio Duplex判定为有效交互意图的音频，通过音频编码器（Audio Encoder）实现模态对齐后，由大语言模型(基于理想自研推理模型MindGPT 3.0)自主判定是否调用工具，最终完成信息理解并生成隐式token(角色/风格/文本隐式token)；

· MindGPT-4o AudioHead：生成高自然度的语音，经MindGPT-4o LLM 生成的token流式输入 AudioHead 生成相应的Audio token，通过流式语音生成器（Streaming Speech Generator），最终生成多样化的风格及角色的口语化语音。

在各项权威音频基准测试以及语言理解、逻辑推理、指令遵循等语言理解任务上，MindGPT-4o-Audio 已达到行业领先水平，在语音交互评测基准VoiceBench多类评测中均显著领先行业领先的同类模型。此外，我们实验发现，业内主流的语音端到端模型一般会在提升语音交互能力的同时，造成语言交互能力的大幅下降，MindGPT-4o-Audio通过训练策略的优化保证了语言交互能力的高水准，在IFEval，GPQA等benchmark上平均领先行业20个PP以上。

为了进一步评估理想同学与市面上优秀语音对话产品（豆包、ChatGPT）在用户体验方面的表现差异，我们组织了内部的用户对比评测，从口语真实感(对话内容及表达的准确性及类人程度)、交互自然度(对话响应及全双工对话的流畅程度)两个方面进行设计。本次评测共邀请了24位不同年龄段的测试者参与，测试者需分别对理想同学、豆包及ChatGPT三款产品在选自真实对话场景的话题表现进行深度体验并独立进行评分。统计结果显示，在口语真实感方面，理想同学以94%的满意度占优，超越了豆包的92%；在交互自然度方面，理想同学继续保持领先，满意度达到92%。

同时，我们也基于理想同学手机App进行了端到端响应延迟测试，整体端到端延迟约1100ms（注：此指标为考虑实际用户量及部署成本后的实测延迟），显著领先豆包的2100ms和GPT-4o的1900ms。

1.2 全双工语音对话：MindGPT-4o-Audio Duplex

为了让理想同学像真人一样与用户进行实时对话，我们研发了MindGPT-4o-Audio Duplex，实现全双工对话能力。我们的模型通过结合上下文联合推理实现了自适应响应、即时打断和环境背景干扰拒识能力。

· 自适应响应：我们研发的全双工模型基于对话中的停顿间隙IPU（Inter-Pausal Unit）来判断对话响应时机，预测是否进行对话轮次转换，该方案可以减少碎片化计算节约推理资源，且能够避免在用户连续说话时打扰用户。同时我们提出了一种自适应响应时间机制KLT（Keep_Listen_Time），针对用户已完成的对话内容，如“今天有什么热门新闻？”进行快速响应，判定延迟低至150ms；针对用户犹豫不决的对话内容，如“我想要……” 以及对话轮次模糊的闲聊场景，如 “我今天心情不太好” 则自适应调整响应时间，等待用户继续说；全双工模型对话轮次切换准确率达到96.5%。

打断：全双工的关键能力是边说边听，在与用户对话的同时能够持续倾听用户。为了确保理想同学在接收到用户打断语音时，快速停止说话，避免对话重叠，我们采用了流式方案响应用户的打断，打断延迟低至1s。

· 拒识：同时为提升对话连续性，避免错误中断对话，针对用户Backchannel的附和，如“对对对”、“哈哈哈”以及背景噪声等场景进行拒识。

最终，MindGPT-4o-Audio Duplex打断响应率达到99%，Backchannel拒识率达到95%。

1.3 语音知识问答

为了让理想同学拥有行业领先的语音知识问答能力，我们建立了高质量的训练数据管线、高效率的模型能力训练管线，确保了语音知识问答多方面效果达到最优。

· 高质量训练数据管线：

– 后训练数据生产管线：通过外部采集、模型蒸馏、日志回流、指令推理多种方式，生产种类和功能全面的数据，包含语音和文本混合多模态，场景覆盖大模型通用能力和业务场景。数据丰富度相对于之前有非常大的提升，高质量后训练数据达数百万量级；

– 后训练数据质量体系：通过奖励模型打分和人工抽检结合的方式，对数据进行多个维度质量打分。训练数据质量得到有效的确保，数据平均正确率达95%；

– 多模态模型能力标签体系：设计一套完整多模态数据能力标签体系，对训练数据进行能力标注和分类，实现训练数据种类的精确控制，以及训练任务效果的精确控制。多模态能力体系分三层优先级维度，26个能力类目；

· 高效率模型训练管线

我们从两个方面建设模型训练管线：

– 高效数据配比技术：选取最优训练数据规模和能力配比，达到性能和成本均衡最优化。最终实现任务能力100%覆盖，训练数据量相对冗余数据减少89%，模型训练效果相对有提升明显；

– 多阶段和多任务混合训练技术：

多阶段训练：将训练分为预训练（Pretrain）和后训练（Post train）两阶段。预训练阶段使用数百万小时语音数据进行模态对齐，实现语音内容的理解能力。后训练阶段使用语音文本混合数据进行指令对齐，实现多模指令遵循和内容理解能力。

多任务混合训练：将多个核心能力任务和业务能力任务混合在同一阶段训练。核心能力任务包含模态对齐、指令对齐、逻辑推理和内容理解等任务；业务能力任务包含角色扮演、多轮对话和检索增强等能力，实现模型同时提升核心能力和业务能力，并提升模型的泛化能力。

· 高满意度的知识问答效果

通过上述技术，我们提升了模型训练效果，提升模型的核心能力，包括内容理解、指令遵循和逻辑推理等能力；使用Prompt工程提升模型的业务能力，实现了业务快速更新能力；最终确保模型在知识问答和回复风格上达到高准确度，相比MindGPT-3o版本平均提升 6pp。

1.4 多角色对话

当前主流语音交互产品中，通用模型往往呈现出扁平、单一的性格设定，缺乏情感与个性，导致用户难以与其建立深度的沟通连接；而业内具备角色扮演型的语音产品虽然具备一定的语言风格，但由于通用知识能力和工具使用能力的薄弱，难以支撑更广泛的应用场景。为了打造更自然、更具人性化的对话体验，我们从两个核心方向出发：“人物设计” 与 “类人对话”，构建一个兼具情商、智商与工具调用能力的多角色对话能力。

· 角色档案的属性设计：有灵魂、有趣的人物

为打破传统模型中角色形象扁平、情感缺失的问题，我们精心构建了完整的人物设定系统。该系统涵盖十余个维度的大设定，每个维度下包含多个子设定，包括但不限于：

– 人物背景与成长经历

– 说话风格与口头禅

– 性格特征与情绪反应

– 兴趣爱好与价值观

我们的目标是让角色具备如真人一般完整、立体的个体属性。在数据构建上，我们围绕这些人物档案生成专属问答数据和基础人设问答数据。同时为确保模型具备强大的通用能力，我们还构建了覆盖广泛、多样性强的泛化数据集，所有角色回复都经过口语化处理，风格统一为符合角色设定的表达方式，从而增强角色的一致性与真实感。

· 角色数据的生产管线：有温度、有陪伴的对话

为实现拟人化的多轮对话体验，我们采集真实语音交互数据，并基于真实对话范式合成大量模拟对话样本。重点优化的方向包括：

– 情绪识别与情感表达能力

- 多轮对话的意图理解与上下文保持

- 自然、地道的口语化表达

- 主动引导与倾听陪伴能力

通过“拟人化角色设定”与“真实感对话交互”的双轮驱动，我们致力于打造一个既有深度情感连接，又具备实用智能能力的语音交互系统，为用户带来真正自然、有温度的陪伴体验，我们希望用户面对的不再是“一个工具”，而是一个能聊天、会共情、懂回应的朋友。

1.5 高表现力语音生成

为了提升理想同学声音的整体表达效果，我们对表达自然度、推理速度和发音精度三个维度对模型进行了大量的设计与优化。

· 表达更自然：我们验证了对话历史上文语音的引入能够显著提升模型的韵律表达自然度，预训练阶段我们采用了30万小时以上的自建大规模连续对话语音数据库，使得模型具备了对于上文语音语义信息的理解，从而有效提升了模型的韵律表达精度。此外，在副语言表现方面，不借助额外的副语言标签，而是直接通过自然语言文本对副语言进行自适应的理解建模，整体表达效果也更加自然，使理想同学在口语真实感和交互自然度方面，达到了领先水平。

· 反应更快：MindGPT-4o-Audio采用文本token和语音编码混合流式建模，模型生成的语音编码将即时输入音频生成模块转换为语音并播放。有别于传统的整句合成以及依赖文本前端的建模方式，该方案不增加任何额外计算开销，实现了真正意义的流式合成，做到“想到哪就说到哪”，将语音生成的首包整体延时做到了100ms以内。

· 发音更准：模型整体采用了字符级别的建模方案，整体对于发音精度的挑战非常大，我们采用了多种优化策略来持续优化发音精度，包括文本CFG策略、phoneme信息引入、文本正则以及长尾数据增广、DPO优化等方案。最终实测在中文、英文测试集上，发音错误率达到了极低的水平。

1.6 多样风格控制

除了让理想同学具备高表现力的对话合成效果外，我们还赋予了理想同学风格控制的能力。我们希望理想同学能够支持特色风格、口音的扮演能力，同时具备风格的多轮记忆能力。

· 丰富的风格扮演能力：MindGPT-4o-Audio即使在使用默认音色的情况下，也可以根据需要模仿不同的风格、口音。要做到这一点，往往从训练数据上就同一个发音人具备多风格和口音的演绎能力，因此实现难度大，成本高。基于此，我们重新设计了音频编码方案，在最大程度保留韵律表现力的基础上，完成音色信息的解耦，实现风格控制及韵律建模，使得模型具备了各类型情绪演绎、风格扮演和口音模仿能力。

· 语音指令控制能力：MindGPT-4o-Audio还支持显示的语音指令控制，模型具备对多种语音语义指令的泛化性理解，为了提升模型对于风格指令的遵循能力，我们引入大语言模型里的CoT（Chain-of-Thought）技术，设计出了Style CoT方案，模型将先对当前风格信息进行预判，再将其作为输入生成语音，该方案进一步增强了模型对于风格的控制生成能力，使模型能够遵循指令实现风格演绎扮演、语速、语调的调整。另外，大多数的语音交互方案对于风格的触发基本都是单轮触发，缺乏风格的多轮记忆能力，不能做到多轮的风格遵循以及强度等级的风格控制，风格CoT的引入，使得模型具备了对于多轮风格的指令遵循及强度控制能力。

2. 工具能力

为了支持时效性问答、提升知识问答效果，我们基于MindGPT-4o-Audio研发了多模态任务规划和工具调用能力。

2.1 多模态规划

我们实现了MindGPT-4o-Audio的多模态任务规划和工具调用能力，输入语音、文本多模态信息，输出任务和工具调用结果。

· 在任务规划方面，支持多轮对话和时空感知能力，能根据历史上下文信息和当前的时间、位置信息，规划合理任务。比如“现在的金价是多少”，任务规划为“2025年6月6日的金价”，“周末了，给我推荐几个遛娃的地方”，任务规划为“推荐北京市适合遛娃的地方”，然后，将规划出的任务形成DAG（有向无环图）表示，可建模单步任务、并行多任务、多步骤任务之间的拓扑关系，能很好支持复杂任务的规划。

其中，我们建立了高效的智能体后训练数据管线，按照业务维度和能力维度进行数据的构造，使用大模型泛化、线上真实数据回流、人工生产等方式，实现对话全场景的全数据覆盖。我们还设定了严格的数据准出体系，通过模型打分、人工质检的方式对数据进行清洗，确保高质量数据的比例；在训练管线上，我们按照模态和任务的双维度进行科学的数据配比，按照课程学习的思路逐步提升模型从简单任务到复杂任务的规划能力。

· 在工具调用方面，我们使用function calling技术来实现这一能力，并通过一系列工作提升模型对工具选择、参数遵循的能力。

其中，我们的数据管线首先通过清洗高质量开源数据集，获取一批通用工具数据集，然后针对内部业务工具，参考MetaTool的数据构造格式，比如直接泛化生成、关键词生成、细节生成、重复问题处理等方式，构造符合业务需求的工具数据。此外，为针对性强化模型对参数类型和参数格式的指令遵循能力，我们针对性构造区分度不明显的工具数据；在训练管线上，我们进行两阶段训练流程，先进行SFT作为冷启动，让模型初步具备工具调用能力，然后采用RL-DPO，增强模型在工具选择和参数遵循上的能力。

我们实现的多模态任务规划和工具调用在链路延迟和效果上，均有优秀的表现。在链路延迟上，根据语音输入直接进行任务规划，减少了传统链路额外语音识别的时间开销，端到端响应延迟显著领先豆包和ChatGPT；多模态任务规划在业务测试集上准确率达到95.55%；工具调用能力在业务测试集上准确率达到94.25%。在通用工具调用benchmark上，我们也达到业界一流水平。

2.2 工具调用

我们支持知识搜索、体育赛事查询、影视娱乐查询、新闻查询、天气查询、股票信息查询、交通限行信息查询、日历查询、油价查询、汇率查询、商品信息查询等工具，模型解决问题的能力大大提升。

特别在搜索效果优化上，针对多来源信息冲突矛盾、内容丰富度不足等常见问题，我们上线了更细粒度的原子化知识层级（Claim-level）的重排序，以及基于知识推理的扩展搜索技术，大幅提升内容真实性和完整性。理想同学不仅能够获知更实时的热点事件，还能更准确理解专业术语，问答效果显著提升12%。

· 传统搜索技术，以网页搜索为例，一般采用NDCG@k、Precision@k、MAP等评估指标，侧重在粗粒度文档层级衡量效果，无法反映出多文档在细粒度知识层面上的内容重复、遗漏、冲突及错误问题。RAG场景下，搜索结果整体输入大模型，对文档偏序关系不敏感，更需确保在观点层面知识的正确性与完整性。针对这一本质性差异，我们提出Claim-level Rerank技术，通过将多条搜索结果，细化为原子化知识单元Claim的集合，并定义Claim F1值作为RAG搜索的核心评估指标，即关注全部搜索结果中正确Claims的召回率和精确率。我们验证了Claim F1值与大模型RAG问答效果的相关系数达到0.212，较传统搜索的Precision@k指标的相关系数提升2.6倍。

· 面对时效性强、知识密集型或者语义模糊的用户查询时，传统搜索工具，通常面临三大技术瓶颈和挑战：

知识滞后性：大模型依赖静态训练数据，难以应对新兴名词、专业领域术语、突发实时热点事件；

语义鸿沟：用户查询存在拼写错误、概念混淆时，传统模型缺乏验证纠错机制；

扩展同质化：基于语义的朴素扩展方法易产生重复或无意义结果，搜索结果未增加有效信息。

为解决以上问题，我们融合知识图谱增强和MindGPT 3.0的思维链推理能力，实现动态Query理解框架，具备多角度、差异化的改写扩展搜索能力，分钟级覆盖热点事件，搜索结果丰富度提升35%，专业术语识别准确率提升47%，复杂Query无需用户澄清，首次搜索满足率提升28%。

为真实评估理想同学与市面上优秀语音对话产品（豆包、Kimi）在工具调用端到端回复的表现差异，我们从任务维度和场景维度设计并执行了一项用户对比评测。测试者需分别对理想同学、豆包和Kimi三款产品在这些对话场景中回复结果的真实相关性进行评测。统计结果显示，理想同学在不同复杂度任务的对话场景上均优于豆包和Kimi。

3. 安全对齐能力

我们致力于建设符合通用价值观、中国普适价值观、理想同学自身价值观的MindGPT-4o-Audio，为此设计了完备的大模型安全对齐体系，根据MindGPT风险浓度差异，深度融合系统级防御能力和大模型安全对齐能力，使得MindGPT-4o-Audio在满足通用能力显著提升的同时，保持价值观回复能力安全、可控。

· MindGuard：在输入阶段识别用户输入的风险意图，Mind Guard会对高风险的语音输入进行检测拦截；在输出阶段，Mind Guard对极端风险进行识别和拦截，避免风险内容展现给用户；为了不影响语音端到端实时效果，输入和输出安全检测均采用边生成边检测，发现风险进行仲裁；

· 风险领域完备性：开发价值观攻击模型对MindGPT进行自动化、持续性攻击，自动化攻击帮助我们完善安全体系的已知风险领域。对于未知风险领域，安全对齐团队与公司安全团队redteam合作，持续收集各种新增、长尾的风险数据，同时线上日志挖掘也是安全体系新风险扩充的重要一环；

· 安全对齐：PTST、价值观CoT SFT等方法有效降低安全对齐所需的数量，显著提升价值观思考过程有效性和最终回复的无害性，MindGPT-4o-Audio在具备强大的安全推理和思考能力的同时，降低对通用指标的负向影响；

· 价值观安全奖励模型：基于自有安全体系的安全回复准则构建rule based和model based价值观奖励模型，应用于MindGPT-4o-Audio预训练、后训练、安全自动化评估等全生命周期，显著提升了安全对齐的效率和效果。

4. 工程能力

为打造 MindGPT-4o-Audio 高品质的语音交互体验，我们在 MindGPT-3.0 对话系统的基础上全面升级，围绕全双工、低延迟进行了深度优化。其中全双工方面，我们主要应用端云结合的 RTC 通信技术；低延迟方面，我们探索了端云全链路流式架构 + 流式推理技术。

4.1 基于 RTC 的全双工架构

传统的轮次（Turn-based）对话架构只能实现半双工能力，即用户输入和模型回复只能交替进行；而我们借助 RTC 技术，将整个对话架构升级为全双工系统，模型能够在“说话”的同时，实时“听到”当前用户正在说什么，结合模型能力，实现了真正的全双工语音对话（能够实时打断、被打断、甚至“抢话”等能力）：

· 传统的半双工对话，往往依赖于 VAD （Voice Activity Detection）等模块实现下述过程：

– 收声，如检测到用户声音，停止上一轮模型回复的播报；

– 检测用户说话结束，将整段音频作为模型输入；

– 模型生成回复，在端侧调用 TTS 播放；

– 重复 a-c。

· 基于 RTC 的全双工对话，模型能够自己“说”的同时，“听”到用户在说什么，实时判定是否要停止说话（被打断），或者开始说话（打断用户或者正常接话）

– 为用户和模型生成一对一的 RTC “房间”，用户和模型都加入房间；

– 模型实时按帧对齐的，收听用户说的话，以及当前自己说的话；

– 模型自主判定，什么时候打断或被打断 （是否继续播放回复或者停止播放回复）。

4.2 全链路低延迟优化

我们分别在网络接入层、服务架构层、模型推理层进行了低延迟的深度优化，力求达到更自然、流畅的人机交互体验：

· RTC 低延迟、抗弱网优化：

– 低延迟：与传统通信技术（如 websocket）相比，我们采用 RTC 技术，通过弱网补偿、骨干网优化、音频编解码优化等手段，显著降低了通信延迟的同时仍能确保较高品质的音质，平均消息到达延迟下降 67%。

– 抗弱网：通过 RTC 抗弱网技术，我们能够在弱网环境下仍然保持较高的连通率及通话音质，相对传统技术，RTC 信道在较高丢包率的网络环境下仍能保持较流畅的通话体验。

· 全链路流式优化：传统的对话架构在处理多模态信息时往往不够优化：存在 ASR -> LLM -> TTS 级联结构，语音识别结束后才进入大模型推理，大模型推理后才能进入语音合成，存在显著的级联延迟。我们基于 MindGPT-4o-Audio 多模态的能力，消除了级联结构，并在全链路（网络接入、业务逻辑、模型推理等）各个服务层级实现了音频全流式传送，尽可能的将流式音频及时送达各服务模块并启动预计算，实现全链路通信和计算的重叠，从而显著降低了延迟水平。

· 流式推理优化：

– 重叠计算：针对语音模态输入，我们在全链路流式的基础上，重叠了多个模块的推理过程，如双工判定模块和生成模块、文本 Prefill 和 AudioEncoder 模块等；流式推理优化后首 token 延迟从 1s 降到 20ms，语音生成的首包从 500ms 降到 60ms；

– P-D分离 + 多级调度：基于 P-D 分离的思路，将多模推理分解成 AudioEncode、Prefill、Decode 等多个阶段，并且针对不同阶段进行定制的调度策略优化，如 AudioEncode 使用 Static Batching 调度，Prefill 使用 Chunked Prefill 调度，Decoder 使用 Continuous Batching 调度，保证推理性能最优，高并发时仍然可以保持推理延迟在几十毫秒量级；

– 异构计算：推理服务异构计算架构，针对多模推理各阶段的算力需求和并发特点，将其分别部署到异构型号的 GPU 上，以最优化利用机器资源，降低延迟的同时降低了部署成本；对比非异构计算版本，推理成本降低 50%。

4.3 Prompt 平台

此外为了更好支撑业务定制及运营，我们上线了高灵活度的Prompt平台，持续确保业务质量：

· 动态提示词系统：建设一套基于原子指令和组合的动态提示词系统，针对语音大模型定制一套对话系统提示词框架，实现语音对话和知识增强问答能力，增强对话遵循和知识推理能力。使得在线推理格式与模型训练格式100%匹配，同时增加模型认知、模型安全和用户环境信息等核心业务指令遵循能力，确保业务能力覆盖 100%。

· 场景化提示词系统：使用链路信号自动感知技术，实现了场景流量自动圈选能力；并且对圈选的场景定制特定功能提示词框架，确保模型整体功能稳定，实现了场景个性化能力。支持全链路个性化效果定制，可以做到T+0分钟级快速热更新，指令任务达成率 > 95%。

· 角色扮演场景化：使用场景化提示词，实现自动感知角色扮演场景，在模型推理中使用不同提示词框架，使模型输出具有当前场景个性化的角色回复风格。目前上线个性化场景7个，后续可快速更新和新增场景，场景平均达成率 >90%。

关于LLM 训练和推理的 padding

1、LLM padding 细节
2、Prepacking-消除attention padding冗余计算

训练时候可以进行左pad 或者右pad，或者对 prompt 进行左pad，对 label 进行右pad。现在其实一般预训练或者微调的时候都不pad，否则会影响训练效率，大概的思路：假设 batch size = 2，max_seq_len = 16，sequence 1、2、3、4 分别有 7、9、6、10 个 token，那么就可以组成[[s1+s2], [s3+s4]] 进行训练，这个时候需要构造一个正确的 casual attention mask。flash_attn_varlen_qkvpacked_func 接口，就可以实现这样的计算而无需 padding。

batch 推理的时候一般只用左pad。推理时也只有batch推理会有影响，另外左对齐方便所有行同时产生next token。在强化学习训练PPO/DPO/GRPO 的时候需要用到推理，所以也需要做左pad！！

padding_side 的影响

谈到 padding，我们自然要考虑 attention_mask，借助 attention_mask 可以在计算 attention weight 时将 padding 带来的影响屏蔽掉。下面是设置不同的 padding_side，tokenizer 的输出：

没有设置 padding_side 或者 padding_side=’right’：

>>> from transformers import LlamaForCausalLM, LlamaTokenizer
>>> tokenizer = LlamaTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
>>> tokenizer.pad_token = tokenizer.eos_token
>>> prompts = ["hello llama", "who are you?"]
>>> tokenizer(prompts, return_tensors="pt", padding=True)
{
    'input_ids': tensor([[    1, 22172, 11148,  3304,     2],                                                                                                                                                                                                                         │············
                         [    1,  1058,   526,   366, 29973]]),
    'attention_mask': tensor([[1, 1, 1, 1, 0],  [1, 1, 1, 1, 1]])
}

设置 padding_side=’left’：

>>> from transformers import LlamaForCausalLM, LlamaTokenizer
>>> tokenizer = LlamaTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf", padding_side="left")
>>> tokenizer.pad_token = tokenizer.eos_token
>>> prompts = ["hello llama", "who are you?"]
>>> tokenizer(prompts, return_tensors="pt", padding=True)
{
    'input_ids': tensor([[    2,     1, 22172, 11148,  3304],                                                                                                                                                                                                                         │············
                         [    1,  1058,   526,   366, 29973]]),
    'attention_mask': tensor([[0, 1, 1, 1, 1],  [1, 1, 1, 1, 1]])
}

要理解 padding_side=’right’ 为什么会导致结果不正确，关键的点是 next token 的预测是使用句子的最后一个 token 经过 transformer 层之后输出的 logit 来得到 next token 的。下面是 model.generate通过多次跳转后来到 next token 的处理逻辑：

# https://github.com/huggingface/transformers/blob/a7cab3c283312b8d4de5df3bbe719971e24f4281/src/transformers/generation/utils.py#L2411
        
model_inputs = self.prepare_inputs_for_generation(input_ids, **model_kwargs)

# forward pass to get next token
outputs = self(
    **model_inputs,
    return_dict=True,
    output_attentions=output_attentions,
    output_hidden_states=output_hidden_states,
)

next_token_logits = outputs.logits[:, -1, :]
# argmax
next_tokens = torch.argmax(next_tokens_scores, dim=-1)

从上面的代码可以看到，句子最后一个 token 所对应的 logit 会被用来计算 next token，因此，最后一个 token logit 的计算是否正确决定了推理的结果是否正确。
接下来，我们来看一下 padding_side=’left’ 和 padding_side=’right’，最后一个 token 所对应的 logit 是否是正确计算的。

我们先来看 padding_side=’left’ 的最后一个 logit 的计算过程，省略中间的具体细节，只给出关键的过程），这里只关注句子 “hello llama”：

从图 4 的计算过程可以看到，使用 padding_side=’left’ 的方式，attention score after masked 矩阵的最后一行和 V 的第一列进行内积后得到的值为正确且符合期望的值，即最后一个 token 所对应的 logit 的计算没有受 padding 的影响，该 logit 的计算过程正确。

因为最后一列计算得分时候，V第一行：pad token 的权重【 attention score】都是 0,且attention score 左下角权重为0，那么计算结果最后一列的结果只跟非pad的V有关

我们接下来看一下 padding_side=’right’ 的最后一个 logit 的计算过程：

从图 5 的计算过程可以看到，attention score after masked 矩阵的最后一行和 V 的第一列进行内积后得到的值是不符合期望的，即最后一个 token（pad token）所对应的 logit 的计算不正确，因为 pad token 也参与了计算，而正确预测 next token 的时候 pad token 是不应该参与计算的。

因为最后一列计算得分时候，V最后一行：pad token对应的的权重【 attention score 最后一行】不都是0，，那么计算结果最后一列的结果跟非pad的V有关。

至此，我们弄清楚了为什么 padding_side=’right’ 会产生不正确的结果。

Prepacking-消除attention padding冗余计算

一个batch里，不同的request，其prompt长度不一样，这样计算attention时会做padding，确保所有的request长度相同。如下图所示，1个batch总共4个句子，后面3个句子做了padding，这样做的一个问题就是，会浪费计算。

，一个解决方法是去除padding，把这些句子放在一个句子里计算。如下图所示，去除了padding之后，所有的request放在一个句子里。但是带来的问题是，attention计算只有句子之内的不同token需要进行attention计算（红色计算attention、蓝色计算attention等等），句子之间是独立的。所以这种做法必须要进行适当的数据组织，让我们的attention算子能知道自己该把哪些token放在一个句子里计算。如下图所示，虽然输入到attention算子的是一个句子，包含10个token，但是需要一些额外数据，让attention算子去把红色部分当一个request计算attention、蓝色部分当一个request计算attention、绿色部分当一个request计算attention、黄色部分当一个request计算attention。

预打包在概念上很简单；我们不是将每个序列填充到相同的长度，而是使用现成的装箱算法将多个提示打包在一起，以代替填充标记。

Whisper-Streaming

论文：Turning Whisper into Real-Time Transcription System

code：https://github.com/ufal/whisper_streaming

这篇文章介绍了最近一种先进的多语言语音识别和翻译模型Whisper，然而，它并非设计用于实时转录。在本文中，我们在Whisper基础上构建了Whisper-Streaming，这是一种实时语音转录和翻译的实现，类似于Whisper模型。Whisper-Streaming采用本地协议策略与自适应延迟，以实现流式转录。我们展示了Whisper-Streaming在未分割的长篇语音转录测试集上实现了高质量和3.3秒的延迟，并展示了它作为多语言会议现场转录服务中组件的稳健性和实用性。

Whisper-Streaming的核心组件和内部工作原理。它包括更新循环、音频缓冲区、跳过音频缓冲区中已确认的输出、修剪缓冲区、连接句间上下文，以及可选的语音活动检测。

图1 处理三个连续更新的示例。黄色高亮文本是“提示”，表示要遵循的先前上下文。黑色边框矩形是音频缓冲区，里面的文本是Whisper从该声音段生成的转录文本。蓝色垂直线是时间戳，将缓冲区分为两部分，左边是先前确认的部分，右边是未确认的部分。LocalAgreement-2策略，或搜索最长公共前缀，应用于未确认（右侧）部分的两个连续更新。最长公共前缀用绿色突出显示，绿色下划线突出显示新确认的输出，而绿色虚线下划线表示先前和随后确认的输出。灰色下划线示范了在被忽略的确认部分的更新。

更新循环 Whisper-Streaming的主要部分是一个程序，利用循环接收源音频块并触发流式策略更新。参数MinChunkSize控制延迟和质量，并确定每次迭代处理的最小持续时间。如果更新计算超过MinChunkSize，下一个更新将立即在累积的音频输入上执行。该参数影响延迟和质量。

音频缓冲区 Whisper被训练用于处理长达30秒且包含一个完整句子的序列。它提供标点和单词级别的时间戳。这个过程在图1中有所说明。每次更新都涉及将传入音频存储在音频缓冲区的顶部，并用Whisper处理整个缓冲区。我们保持不变的是缓冲区始终以新句子开头，以保持Whisper的高质量。LocalAgreement-2被应用于当前和先前的Whisper输出。“确认输出”中最后一个单词的时间戳被保存。在后续更新中，我们总是从缓冲区的开头重新处理Whisper，包括上一个“确认输出”时间戳之前的部分（在图1中以灰色背景表示）。确认部分中转录的更改被忽略，因为它们在意义上常常是微不足道的。

跳过确认部分 当确定相对于先前更新的上一个确认单词的转录单词位置时，我们考虑到了由于新音频块导致的Whisper时间戳的潜在不准确性和更新。如果一个单词的时间戳在距离上一个确认单词的1秒间隔内，我们比较其前面的n-gram（其中n的范围从1到5）与上一个确认输出中的后缀。如果它们匹配，我们跳过这些单词。然而，这个规则在未来的工作中可以通过包括诸如设置和微调字符编辑距离阈值、修剪n-gram中的标点符号和大小写等措施来进一步增强。

修剪音频缓冲区 为了避免延迟中不可接受的长峰值，音频缓冲区限制在约30秒左右。当确认输出包含结束句标点符号后面跟着一个开始新句子的单词时，缓冲区会在标点符号的时间戳处被修剪。为此目的使用了语言特定的句子分割工具（例如Koehn等人，2007），确保缓冲区始终包含一个单句。尽管如此，如果缓冲区长度超过30秒，我们会保留由Whisper标记的最后确认的段落。

连接句间上下文 Whisper的转录函数利用“prompt”参数来保持文档内的一致性（一致的风格、术语和句间引用）。我们从先前音频缓冲区的确认输出中提取最后200个单词作为“prompt”参数，如图1所示（黄色背景文本）。

语音活动检测 有一个参数用于激活或停用Whisper的默认语音活动检测（VAD）过滤器，影响质量和延迟。

MWER loss 实现

1、paraformer 负例采样策略：

The implementation of Minimum Word Error Rate Training loss (MWER) based on negative sampling strategy from <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>

https://gist.github.com/TeaPoly/234429e6c2d74d10fcb4987bc541d528

def create_sampling_mask(log_softmax, n):
    """
    Generate sampling mask
    # Ref: <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>
    #       https://arxiv.org/abs/2206.08317
    Args:
        log_softmax: log softmax inputs, float32 (batch, maxlen_out, vocab_size)
        n: candidate paths num, int32
    Return:
        sampling_mask: the sampling mask (nbest, batch, maxlen_out, vocab_size)
    """
    b, s, v = log_softmax.size()

    # Generate random mask
    nbest_random_mask = torch.randint(
        0, 2, (n, b, s, v), device=log_softmax.device
    )

    # Greedy search decoding for best path
    top1_score_indices = log_softmax.argmax(dim=-1).squeeze(-1)

    # Genrate top 1 score token mask
    top1_score_indices_mask = torch.zeros(
        (b, s, v), dtype=torch.int).to(log_softmax.device)
    top1_score_indices_mask.scatter_(-1, top1_score_indices.unsqueeze(-1), 1)

    # Genrate sampling mask by applying random mask to top 1 score token
    sampling_mask = nbest_random_mask*top1_score_indices_mask.unsqueeze(0)

    return sampling_mask

2、CTC decoder mwer loss：

https://github.com/Mddct/losses/blob/main/py/mwer.py

关键：计算前缀束搜索候选路径

self.ctc_prefix_beam_decoer = CTCDecoder(beam_width=beam_width,top_paths=beam_width)

wenet/wenet/transducer/search/greedy_search.py
wenet/wenet/transducer/search/prefix_beam_search.py

3、其他：wenet

https://github.com/wenet-e2e/wenet/tree/main#

wenet/wenet/transformer/ctc.py

wenet/wenet/transformer/label_smoothing_loss.py

Attention-based 自动语音识别（ASR）模型的 Beam Search 解码过程：wenet/wenet/transformer/search.py

Paraformer-v2: An improved non-autoregressive transformer for noise-robust speech recognition

代码：https://github.com/NiniAndy/Paraformer-V2
论文：https://arxiv.org/abs/2409.17746

原始 Paraformer 在非自回归语音识别方面取得了显著成效，尤其在普通话任务中表现突出，但其也存在一些局限性，特别是在跨语言适配和噪声鲁棒性方面。

背景：

1. 多语言适配能力有限（Multilingual Limitations）

CIF 模块难以适应非拼音型语言（如英语）：
原始 Paraformer 使用 CIF（Continuous Integrate-and-Fire） 预测每个 token embedding。该机制假设每个语音片段可以通过声学模式推断出输出 token 数量。但英语等语言往往使用 BPE（Byte Pair Encoding） 等子词单元，token 数量波动大、边界不规则，CIF 很难准确预测 token 数。

在英语、法语等语言上性能显著下降；
CIF 在 token 数量估计不准时，会导致对齐错乱、token 重复或丢失。

2、对噪声敏感（Noise Sensitivity）

CIF 预测 α 权重完全基于声学表示，不含语义约束：
- 如果输入中含有背景噪声（如会议环境），CIF 模块可能将噪声解释为有意义的语音特征；
- 导致触发 α → β 条件时“错误地触发 token”，产生虚假输出。

噪声环境下 WER/CER 明显上升；
无语音输入时仍有输出（无法正确“输出空白”）。

3. 训练对目标长度高度敏感

CIF 模块需预测 token 数量，训练时必须强制调节 α 的归一化，使 token 数接近 ground truth；
若目标长度估计不准，Decoder 会收不到足够 token embedding，导致学习不稳定

原始Paraformer：

Encoder 提取帧级表示：

CIF 生成 token embedding：使用 CIF（Continuous Integrate-and-Fire） 模块将帧级特征聚合为 token embedding 序列：

CIF 中权重 α 的生成：

Decoder 并行预测：

为使预测长度 U′U’U′ 尽可能接近 ground truth 长度 UUU，训练时需要对α1:T 做归一化：

Decoder 并行预测：Decoder 是一个 双向 Transformer

Loss：

改进：

利用 CTC 模块来获取 token embedding，事实证明，该模块具有更好的多语言适应性和更强的抗噪性。

使用 CTC 模块提取 Token Embedding：

生成帧级 posterior：类似于标准 CTC 解码头，对每一帧计算 token 分布（含 blank）

Greedy 解码得到 token 序列：

每一帧取最大概率的 token index（可能含 blank 和重复）

压缩 token 序列（Remove blanks & merge repeats）：

对重复 token 合并并平均其 posterior，得到 token 数量为 U′U’U′ 的 embedding 概率序列，去除 blank；

映射为 Token Embedding：

并行 Decoder 解码（Bidirectional）：（没有因果掩码（causal mask）限制上下文访问，每个位置的 token 同时关注其左侧和右侧所有位置）

CTC 压缩后的长度 U′U’U′ 和真实 token 长度 UUU 不一致，导致无法直接计算 CE Loss，解决方法：使用 Viterbi 对齐 将 CTC posterior 对齐到 target：

其中 A1:T 是 Viterbi 解码得到的帧与 token 的对齐序列；
这样生成的压缩 posterior 长度严格等于目标长度 U。

Paraformer-v2 同时优化：

Decoder 输出与目标之间的 CE Loss；
Encoder 输出与目标之间的 CTC Loss。

实验结果：

实际训练疑问：

新一代 Kaldi 热词识别功能

转自：https://mp.weixin.qq.com/s/d7Ab9u1_OAGLF76V1ymHmg

什么是热词

热词其实是一个特别容易引起歧义的说法，尤其是在语音领域，比如唤醒次/命令词/新词都有人称之为热词，本文中要讨论的热词识别是在语音识别语境下的“上下文词语偏置”对应的英文为 contextual biasing。热词识别到底是做什么的呢？举一个例子就非常清楚了，比如：“今天河南省教育厅有关领导参观了南阳理工大学” 这样一句话，很多的语音识别系统应该会识别成 “今天河南省教育厅有关领导参观了南洋理工大学”，“南阳理工大学”和“南洋理工大学”音同字不同，训练语料中“南洋理工大学”又大概率多于“南阳理工大学”，所以模型非常倾向于输出“南洋理工大学”。热词识别要实现的就是，给定一些外部条件，让系统了解我们当前想要说的是“南阳理工大学”而不是“南洋理工大学”。

热词的实现方法

热词的实现方法大致可以分为两大类，一类是纯字符串匹配方法，一类是NN 神经网络 方法。顾名思义，纯字符串匹配的方法就是将解码过程中的所有可能路径都一一去匹配热词列表，如果匹配上热词就给对应的路径加上分数奖励，这样该路径就更有可能在 beam 剪枝中胜出，从而实现识别热词的功能。这种方法一般是在解码阶段实现，对声学部分是透明的，而且可以随意调整奖励的分数，比较灵活。需要解决的核心问题是高效的查找，一般都是基于自动机来实现，在解码器中附带一个类似于下图的热词图。

NN 方法其实非常多，近年也是大家发论文的热点（贴一个 awesome https://github.com/stevenhillis/awesome-asr-contextualization，有兴趣的同学可以去看论文），但总的来说就是将热词列表作为神经网络的其中一个输入，以此改变神经网络输出的分布，这样神经网络就能更大概率识别出热词。此种方法的使用需要在训练模型时进行干预，也就是说如果你需要一个带热词识别功能的模型，你就得重新训一个模型，最起码得在不带热词识别功能模型的基础上做 finetune。下图是一种可能的实现方式，通过热词列表来对 transducer 的 predictor 网络进行偏置。

实际的使用中也常常将两者一起配合使用，本文讨论的是第一种纯字符串匹配的热词实现方法。

基于 Aho-corasick 的热词实现

上文提到基于匹配的热词识别主要解决的是匹配效率问题，所以基本都使用自动机来实现，openfst 作为一个高效的自动机实现受到绝大部分人的青睐，但对于热词识别，还是有一些欠缺。比如，如果不进行较复杂的状态管理，则一次只能进行一个热词的匹配，这个问题 wenet 在其实现中有举例说明。如下所示，“唯品会”和“欧阳唯一”都是热词，但“欧阳唯品会”这条路径却无法匹配到“唯品会”。（openfst 当然可以实现这些功能，但会增加复杂度以及影响效率。）

热词的实现本质是一个多模匹配问题，它需要在 hypothesis 中搜索是否包含给定的热词列表，而多模匹配的最佳数据结构就是 Aho-corasick 自动机。关于 Aho-corasick 的构建细节本文不做过多叙述，感兴趣的同学可以阅读（https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm）。

下面将一步一步叙述其怎样用于热词识别，下图是一个包含了热词 { "S", "HE", "SHE", "SHELL", "HIS", "HERS", "HELLO", "THIS", "THEM"} 的状态图（图要有一定复杂度才能够说明问题，爱学习的你一定会认真看的），Aho-corasick 图中主要有三种类型的边，goto 边（黑箭头），failure 边（红箭头）和 output 边（绿箭头），简单地说，匹配走 goto 边，匹配失败则走 failure 边直到匹配为止或者回到 ROOT 节点，而只要 output 边存在即表示命中热词 (理论上每一个终止节点都有一个指向自己的 output 边，下图中未体现）而且得沿着 output 边的路径一直回溯到没有 output 边为止。

图中每条 goto 边都有一个分数，每个节点含有两个分数（node_score, local_node_score)，node_score 为全局节点的分数即从 ROOT 节点到目前的路径分数和，local_node_score为局部节点分数即从上一个中止节点[匹配到热词的节点]到目前的路径分数和，匹配 failure 的分数为 dest.node_score - src.local_node_score（图中未画出，因为 dest 可能需要回溯几条 failure 边才能到达）。我们想在热词局部命中时就给予一定分数奖励，防止 beam search 过程将可能的热词路径剪掉，所以会有如此复杂的分数设计，部分命中给予奖励需要在匹配失败时对已施加的分数进行补偿或消除。奖励分数究竟应该在完全命中后才施加还是局部命中就预先给予，每个人有不同的看法，笔者未进行过严格的性能对比，k2 中目前的实现参照 Deep context (https://arxiv.org/pdf/1808.02480.pdf) 中 on the fly rescoring 一节所述，每匹配一个 token 都会施加分数奖励。

我们以 “DID_HE_WANT_HERS_SHELF” (注意空格 _ 也是字符），来说明整个过程是如何匹配的，以及奖励分数如何作用到路径。“DID_” 几个字符未匹配任何热词的前缀，状态一直停留在 ROOT （ROOT 的 failure 是它自己）。“H” 匹配 state 0 到 state 2 的边获得奖励 1，“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为2），此时命中 “HE” 获获得奖励 2 （total 为 4），“_” 未匹配上沿着 state 3 的 failure 边回到 ROOT 减去奖励 2 （total 为2），“WAN” 未匹配任何前缀状态一直停留在 ROOT，“T” 匹配 state 0 到 state 15 的边获得奖励 1 （total 为 3），“_” 未匹配上沿着 state 15 的 failure 边回到 ROOT 减去奖励 1 （total 为2），“H” 匹配 state 0 到 state 2 的边获得奖励 1 （total 为3），“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为4），此时命中 “HE” 获得奖励 2 （total 为 6），“R” 匹配 state 3 到 state 10 的边获得奖励 1（total 为7），“S” 匹配 state 10 到 state 11 的边获得奖励 1（total 为8），此时命中 “HERS” 获得奖励 4 （total 为 12），state 11 包含 output 边指向 state 1 即命中 “S”获得奖励 1 （total 为13）， “_” 未匹配上沿着 state 11 的 failure 边回到 ROOT 减去奖励 4 （total 为9），“S” 匹配 state 0 到 state 1 的边获得奖励 1 （total 为 10），此时命中 “S” 获得奖励 1 （total 为11），“H” 匹配 state 1 到 state 4 的边获得奖励 1 （total 为 12），“E” 匹配 state 4 到 state 5 的边获得奖励 1 （total 为 13），此时命中 “SHE” 获得奖励 3 （total 为 16），state 5 还有 output 边指向 state 3 即命中 “HE” 获得奖励 2 （total 为 18），“L” 匹配 state 5 到 state 6 的边获得奖励1 （total 为 19），“F” 为匹配上沿着 state 6 的 failure 边到达 state 12， state 12 依然没能匹配 “F” 沿着 state 12 的 failure 边回到 ROOT 减去奖励 4 （state 6 的 node_score）（total 15），匹配结束。“DID_HE_WANT_HERS_SHELF” 命中 “HE”，“HE”，“HERS” ，“S”，“S”，“SHE”， “HE” 获得 15 的分数奖励。下面还有一些测试样例，可以帮助理解整个匹配过程，实际的热词识别匹配不会这么复杂，能命中一两个热词就已经足够在 beam search 胜出了。

queries = {
        "HEHERSHE": 14,  # "HE", "HE", "HERS", "S", "SHE", "HE"
        "HERSHE": 12,  # "HE", "HERS", "S", "SHE", "HE"
        "HISHE": 9,  # "HIS", "S", "SHE", "HE"
        "SHED": 6,  # "S", "SHE", "HE"
        "HELL": 2,  # "HE"
        "HELLO": 7,  # "HE", "HELLO"
        "DHRHISQ": 4,  # "HIS", "S"
        "THEN": 2,  # "HE"
    }
    for query, expected_score in queries.items():
        total_scores = 0
        state = context_graph.root
        for q in query:
            score, state = context_graph.forward_one_step(state, ord(q))
            total_scores += score
        score, state = context_graph.finalize(state)
        assert state.token == -1, state.token
        total_scores += score
        assert total_scores == expected_score, (
            total_scores,
            expected_score,
            query,
        )

Wenet 中也有基于 Aho-corasick 实现的热词，但暂时还没有合并，可以在 wenet 仓库的 pull requests 里查找。

一些实验结果

热词的实验结果跟测试集关系很大，下面放的是早期的一些测试结果，具体效果怎样，请在自己的测试集上实验。下面测试中的热词均为测试集对应 transcript 文本上用 NER 工具提取的短语，并做了适当筛选去除特别容易识别的短语。

Aishell 测试集（包含 1073 条热词）：

Librispeech 测试集 (包含 487 条热词）：

可以看出，该实现对 contexts 子集有较明显的提升，而对其他测试集基本没有影响。

k2 热词功能现状

k2 的热词功能实现已经有一段时间了，由于作者比较懒忙一直没有全面支持，目前 icefall 中的 librispeech pruned_transducer_stateless4 recipe 和 wenetspeech pruned_transducer_stateless5 recipe 已经支持，zipformer 模型正在 PR 中（很快合并）。sherpa 和 sherpa-onnx 中已经实现了核心功能，并且封装了 python 的 API，因为已经有很好的样例，所以我们当然非常希望社区的小伙伴能一起帮忙完善，但如果你们也很懒忙，也可以在微信群告诉我们或者在 github 仓库提 issue，我们会根据需要来安排优先级，目前我们收到的两个提议是支持 sherpa-onnx android 平台和 sherpa-ncnn。

Ke-Omni-R :通过思考实现高级音频推理

Github:https://github.com/shuaijiang/Ke-Omni-R 【开源训练和推理代码】

贡献：用于将GRPO/思考过程加入到语音大模型的强化训练过程中。

[1] Xie, Zhifei, et al. “Audio-Reasoner: Improving Reasoning Capability in Large Audio Language Models.” arXiv preprint arXiv:2503.02318.
[2] Ma, Ziyang, et al. “Audio-CoT: Exploring Chain-of-Thought Reasoning in Large Audio Language Model.” arXiv preprint arXiv:2501.07246.
[3] Li, Gang, et al. “Reinforcement Learning Outperforms Supervised Fine-Tuning: A Case Study on Audio Question Answering.” arXiv preprint arXiv:2503.11197
[4] Xu, Jin, et al. “Qwen2.5-Omni Technical Report.” arXiv preprint arXiv:2503.20215

Ke-Omni-R 是基于 Qwen2.5-Omni 构建的高级音频推理模型。构建音频推理模型，通过强化学习引入深度思考过程，提升复杂任务的理解和推理能力。仅使用 10,000 个训练后样本，Ke-Omni-R 就在 MMAU Test-mini 和 Test 基准测试中取得了最佳性能。其开发过程中的关键洞察包括：

GRPO 算法 ：GRPO 算法显著增强了已经很强大的基础模型（Qwen2.5-Omni-7B）的性能，即使在看不见的语音领域也表现出卓越的泛化能力。
思考过程 ：融入简洁的思考过程（少于 50 个字）对于提高推理能力起着至关重要的作用。
KL 散度 ：通过利用 KL 散度，在 GRPO 训练期间观察到轻微的改进。
领域比例 vs. 数据量 ：领域多样性比数据量更重要。我们仅使用了 10,000 个样本，其中 5,000 个从 AVQA 中随机选取，另外 5,000 个从 MusicBench 中选取。

Performance: Accuracies (%)↑ on MMAU Test-mini and Test benchmark

Model	Method	Sound (Test-mini)	Sound (Test)	Music (Test-mini)	Music (Test)	Speech (Test-mini)	Speech (Test)	Average (Test-mini)	Average (Test)
–	Human*	86.31	–	78.22	–	82.17	–	82.23	–
Gemini Pro 2.0 Flash	Direct Inference*	56.46	61.73	58.68	56.53	51.65	61.53	55.60	59.93
Audio Flamingo 2	Direct Inference*	61.56	65.10	73.95	72.90	30.93	40.26	55.48	59.42
GPT4o + Strong Cap.	Direct Inference*	57.35	55.83	49.70	51.73	64.86	68.66	57.30	58.74
Llama-3-8B-Instruct + Strong Cap.	Direct Inference*	50.75	49.10	48.93	48.93	55.25	62.70	52.10	53.57
Qwen2-Audio-7B-Instruct	Direct Inference*	54.95	45.90	50.98	53.26	42.04	45.90	49.20	52.50
SALAMONN	Direct Inference*	41.00	40.30	34.80	33.76	25.50	24.24	33.70	32.77
Audio-Reasoner(Qwen2-Audio-7B-Instruct)	[1]	60.06	–	64.30	–	60.70	–	61.71	–
Audio-Cot(Qwen2-Audio-7B-Instruct)	[2]	61.86	–	56.29	–	55.26	–	57.80	–
R1-AQA(Qwen2-Audio-7B-Instruct)	[3]	68.77	69.76	64.37	61.40	63.66	62.70	65.60	64.36
Qwen2.5-Omni-7B	[4]	67.87	–	69.16	–	59.76	–	65.60	–
Qwen2.5-Omni-3B	[4]	70.27	–	60.48	–	59.16	–	63.30	–
Ke-Omni-R-3B(Qwen2.5-Omni-3B)	GRPO w/ think (ours)	72.37	71.87	65.57	59.60	64.26	64.17	67.40	65.17
Ke-Omni-R(Qwen2.5-Omni-7B)	GRPO w/o think (ours)	69.67	70.57	67.66	64.00	66.37	67.17	67.90	67.24
Ke-Omni-R(Qwen2.5-Omni-7B)	GRPO w/ think (ours)	69.37	71.90	69.46	67.13	67.87	67.10	68.90	68.71

Performance: CER/WER (%)↓ on ASR benchmark

Model	Method	WenetSpeech test-net	WenetSpeech test-meeting	LibriSpeech test-clean	LibriSpeech test-other
Qwen2.5-Omni-3B	[4]	6.3	8.1	2.2	4.5
Qwen2.5-Omni-7B	[4]	5.9	7.7	1.8	3.4
Ke-Omni-3B	ours	11.7	16.1	1.8	3.8
Ke-Omni-7B	ours	7.5	9.8	1.6	3.1

StreamSpeech：“All in One”流式语音模型，支持语音识别、翻译、合成

论文：https://aclanthology.org/2024.acl-long.485.pdf
代码：https://github.com/ictnlp/StreamSpeech
模型：https://huggingface.co/ICTNLP/StreamSpeech_Models
Demo：https://ictnlp.github.io/StreamSpeech-site/
语音翻译综述：Recent Advances in Direct Speech-to-text Translation

两种主要结构：编码器-解码器框架（Transformer 及其变体）和多任务框架。数据难题：数据增强、预训练、知识提炼和多语言建模。应用：实时性、分段、命名实体、性别偏见和代码转换

2024年6月，中国科学院计算技术研究所自然语言处理团队发布“All in One”流式语音模型——StreamSpeech。该模型可以在用户说话的同时，以端到端的方式实现语音识别、语音翻译、语音合成的多任务实时处理，延时低至320毫秒。StreamSpeech是能够以端到端方式同时完成多项离线和流式语音任务的开源模型。StreamSpeech可以部署在手机、耳机、AR眼镜等设备，助力国际会议、跨国旅行等场景下的低延时跨语言交流需求。

StreamSpeech采用先进的two-pass架构，集成了流式语音编码器、实时文本解码器和同步的文本到语音合成模块。通过引入连接时序分类（Connectionist temporal classification，CTC）对齐机制，StreamSpeech能够控制模型在用户说话的同时理解并生成语音识别、翻译和合成结果。StreamSpeech在离线和实时语音到语音翻译上超过Meta的UnitY架构，在开源数据集上取得当前的最佳性能。此外，StreamSpeech还能在翻译过程中生成中间文本结果，为用户提供“边听边看”的流畅体验。

StreamSpeech 采用两遍架构，首先将源语音转换为目标文本隐藏状态（自回归语音到文本翻译，AR-S2TT），然后通过非自回归文本到单元生成生成目标语音。引入源/目标/单元 CTC 解码器，通过语音识别 (ASR)、非自回归语音到文本翻译 (NAR-S2TT) 和语音到单元翻译 (S2UT) 等多个任务学习对齐，从而指导 StreamSpeech 何时开始识别、翻译和合成。

1. StreamSpeech 在离线和同步语音到语音翻译方面都实现了最先进的性能。
2. StreamSpeech 可以通过 “All in One”无缝模型执行流式 ASR、同步语音到文本翻译和同步语音到语音翻译。
3. StreamSpeech 可以在同声翻译过程中呈现中间结果（即 ASR 或翻译结果），提供更全面的低延迟通信体验。

StreamSpeech：

Architecture

StreamSpeech 由三部分组成：流式语音编码器、同步文本解码器和同步文本到单元生成模块。引入多个 CTC 解码器，通过辅助任务学习对齐，并据此指导策略。

流式语音编码器： Conformer 架构通过堆叠注意力模块和卷积模块。在语音建模方面展现出显著优势，但在流式语音输入建模方面却存在困难，这主要是由于双向自注意力和卷积运算涉及整个序列的感受野。为此，我们提出了基于块的 Conformer 架构，旨在赋予 Conformer 架构编码流式输入的能力，同时保留局部块内的双向编码。

图 3 展示了基于块（chunk-based）的 Conformer 架构。首先，原始语音输入会被转换为语音特征（在我们的工作中使用的是滤波器组特征，每个语音特征通常对应约 40 毫秒的时长。基于块的 Conformer 会将流式语音划分为若干个块（chunk），每个块包含 C 个语音特征，其中 C 是一个控制块大小的超参数。在基于块的 Conformer 中，自注意力（self-attention）和卷积操作在块内部是双向的，在块之间则是单向的，从而能够处理流式输入。

对于基于块的自注意力机制，特征 xi 会关注那些位于相同块内或前面块内的特征 xj，其计算方式如下：

其中，Attn(xi,xj)是标准的多头注意力机制，而⌈⋅⌉ 表示向上取整操作。

对于基于块的卷积（chunk-based convolution），卷积操作的上界会被截断在当前块的边界处。即当使用核大小为 k 的卷积时，其计算方式为：

在实现上，基于块的卷积可以通过掩码操作（屏蔽掉那些被截断的位置）并行计算。通过流式编码器，计算源语音的隐藏状态，记为 H=(h1,⋯,h_|H|) 。基于块的 Conformer 使得流式语音编码器不仅能够满足流式编码的需求，还能对语音进行局部双向编码。

H≤g(i) 的语义范围：

包括了从起始到第 g(i) 帧为止的语音输入（多个 chunk 累积的结果）；
每一个帧的表示都融合了：
- chunk 内的 双向上下文（强表征）
- chunk 之间的 单向依赖（因果性）

同步文本解码器： 在流式编码器之后，文本解码器通过关注源语音隐藏状态 H ，同时生成目标文本 Y 。为了实现这一点，StreamSpeech 需要一个策略来决定何时生成每个目标标记（即，解码器可以关注多少个语音状态）。合理的策略应该确保模型等到识别源语音中的源文本（读取），然后再生成相应的目标文本（写入）。

Simultaneous Text Decoder（同步文本解码器）是在流式语音编码器之后，边接收源语音隐藏状态 H，边生成目标文本 Y。为实现低延迟输出，需要一个策略（policy）来判断：

何时 READ（读取更多源语音）
何时 WRITE（生成目标 token）

核心做法：通过 CTC 对齐引导策略

1. 引入两个 CTC 解码器：

Source CTC Decoder：对齐源语音 → 源文本（ASR）
Target CTC Decoder：对齐源语音 → 目标文本（NAR-S2TT）

分别计算两个任务的 CTC Loss：

构建 READ / WRITE 策略函数。用上面两个 CTC 的输出计算当前语音段 X≤j对应的：

已识别的源 token 数 N_j^asr
已预测的目标 token 数 N_j^nar-s2tt

然后定义策略函数 g(i)，表示在什么时间步 j可以生成目标 token yi：

StreamSpeech 在接收到语音 X≤g⁢(i) 后自回归生成目标标记 yi

READ 检测（左条件）：ASR 模块识别出一个新的源 token，说明我们“听”到了新语义，应该考虑进入写入阶段。

WRITE 准备（右条件）：非自回归模块预测当前语音内容足以包含第 iii 个目标 token，我们可以放心翻译了。

尽管 NAR-S2TT 用来预测 token 数以对齐，但最终目标 token yi 是通过 AR-S2TT 来生成的，以提升翻译质量：

基于由 ASR 和 NAR-S2TT 派生的对齐策略指导的策略，同步文本解码器在接收到语音 X≤g⁢(i) 后生成 yi ，并通过自回归语音转文本翻译（AR-S2TT， X→Y ）的交叉熵损失进行优化

Non-autoregressive Text-to-Unit Generation：为了同步生成当前目标文本所对应的语音单位（unit），StreamSpeech 采用了一种 非自回归的文本到单位（T2U）架构（Gu et al., 2018），该架构由一个 T2U 编码器 和一个 单位 CTC 解码器 组成。

T2U 编码器的输入是来自同步文本解码器生成的隐藏状态 D_text。
鉴于音频单位序列 U 通常比文本序列 Y 更长，我们将 T2U 编码器的输出上采样 r 倍作为解码器输入

i_t⁢h 输入对应于 D_⌈i/r⌉^{t⁢e⁢x⁢t} 。然后，单元 CTC 解码器通过关注位于 D_⌈i/r⌉^{t⁢e⁢x⁢t} 之前的 T2U 编码器输出，以非自回归的方式生成单元序列 U 。正式地，单元 CTC 解码器 CTCD_ecU 的输出 Du⁢n⁢i⁢t 计算如下：

NAR T2U 生成通过 CTC 损失在语音到单元翻译任务（S2UT， S→U ）上进行了优化：

最终，使用一个基于单位的 HiFi-GAN 声码器（Kong et al., 2020）来根据生成的单位序列合成目标语音。注意，这个声码器是预训练的并被冻结，不参与 StreamSpeech 的联合训练。

训练（Training）：

StreamSpeech 中涉及的所有任务都是通过**多任务学习（multi-task learning）以端到端（end-to-end）**的方式联合优化的。总体训练目标L 包括以下几个任务的损失：

S2UT（语音到单位翻译）
AR-S2TT（自回归语音到文本翻译）
ASR（语音识别）
NAR-S2TT（非自回归语音到文本翻译）

多任务学习能够有效地将同步策略的学习与翻译能力的学习整合进一个统一框架中。此外，像 ASR 和 AR-S2TT 等辅助任务生成的高质量中间结果，也可以在推理过程中展示给用户，作为补充参考内容。

多块训练（Multi-chunk Training）：在推理过程中，Simul-S2ST（流式语音到语音翻译）可能会面临不同的延迟需求。为每种延迟分别训练一个模型代价很高。为了解决这个问题，我们提出了 多块训练（multi-chunk training），以提升 StreamSpeech 在不同延迟水平下的性能表现。

在多块训练中：

流式语音编码器的块大小 C不是固定的，
而是从 U(1,∣X∣) 的均匀分布中随机采样，其中 ∣X∣ 表示整个输入语音序列的长度；
特殊情况C=∣X∣ 即对应于离线 S2ST设置。

通过多块训练，单个 StreamSpeech 模型就能适应不同的延迟需求。

Inference：

在推理过程中，StreamSpeech 会基于设定的块大小 C 来处理流式语音输入，其中每个语音特征通常对应 40 毫秒的音频时长（例如，C=8 表示每 320 毫秒处理一次语音输入）。

然后，StreamSpeech 会使用 ASR 和 NAR-S2TT 的 CTC 解码器对当前接收到的语音 X^ 进行解码，分别生成源语言 token A^ 和目标语言 token Y^。

当满足以下两个条件时：

识别出了新的源 token（即 ∣A^∣>∣A∣）
当前语音中预测的目标 token 数超过已生成的目标 token（即 ∣Y^∣>∣Y∣）

模型将会进入 WRITE 阶段：

更新源文本 A
持续自回归地生成新的目标 token，直到达到 Y^ 的数量上限或遇到 <eos> 结束符
根据目标文本生成对应的单位序列 U
使用声码器合成出目标语音 S

否则，如果上述条件不满足，模型会进入 READ 阶段，等待接收下一个大小为 C 的语音块。

由于引入了多块训练（multi-chunk training），StreamSpeech 可以通过动态调整块大小 C 来控制推理延迟。其中：

较小的 C 意味着更低的延迟；
较大的 C 则带来更完整的上下文，提升质量。

实验

预处理
源语音转换为 16000Hz，将目标语音生成为 22050Hz。对于源语音，我们计算 80 维的 Mel 滤波器组特征，并进行全局的倒谱均值-方差归一化，每个语音特征对应 40 毫秒的时长。对于目标语音，通过 mHuBERT3提取离散单元，并使用预训练的基于单元的 HiFi-GAN 语音生成器进行语音合成。对于源文本和目标文本，我们分别使用 SentencePiece生成大小为 6000 的 unigram 词汇表。

离线语音到语音翻译（Offline S2ST）：StreamSpeech 采用 双阶段（two-pass）架构，相比使用单阶段（one-pass）架构的 S2UT 和 Translatotron，在性能上取得了显著提升。多任务学习（multi-task learning）不仅能指导策略学习，还能为翻译提供中间监督信号，从而进一步提升了离线 S2ST 的性能。

StreamSpeech 推理加速效果
为评估 StreamSpeech 的推理效率，表 2 报告了其相对于 UnitY 的加速比（speedup）。
在该双阶段架构中，StreamSpeech：

第一阶段翻译使用自回归结构（更适合处理复杂语言重排）；
第二阶段语音合成使用非自回归结构（尽管序列较长，但几乎单调对齐，易于并行）。

这种 先 AR 后 NAR 的两阶段架构，在保持翻译质量的同时，实现了 显著的推理速度提升。

Simul-S2ST（同步语音到语音翻译）：

在所有延迟设置下，StreamSpeech 的表现都优于 Wait-k，尤其是在低延迟条件下，BLEU 分数提升约 10 分。

Wait-k 策略是目前使用最广泛的同步策略，在同步文本到文本（T2TT）和语音到文本（S2TT）任务中表现良好。StreamSpeech 在同步语音到语音翻译中，不仅兼顾了延迟与质量，还通过对齐驱动策略实现了更自然的发声节奏，在多个基线之上取得了系统性提升。

语音翻译综述：Recent Advances in Direct Speech-to-text Translation

语音翻译综述：Recent Advances in Direct Speech-to-text Translation

两种主要结构：编码器-解码器框架（Transformer 及其变体）和多任务框架。数据难题：数据增强、预训练、知识提炼和多语言建模。应用：实时性、分段、命名实体、性别偏见和语种混合转换

名词解释：

误差累积（error accumulation）：指在连续的转录或翻译步骤中，由于前一步骤的错误会在后续步骤中积累，导致最终结果的质量逐渐下降的现象。这种误差累积通常在语音到文本（Automatic Speech Recognition, ASR）系统和文本到文本（机器翻译或文本转写）系统之间的多步骤流程中出现。在这些系统中，声音信号首先被转录成文本，然后文本再被翻译成目标语言或者以其他方式进行处理。如果在转录步骤中出现错误，这些错误将传递到后续步骤，影响最终的翻译或文本转写质量。
自回归（Autoregressive）：在 E2E ST（End-to-End Speech Translation）模型中，”autoregressive” 表示模型会逐个生成翻译文本的每个词或子词，每次生成都会依赖于前一个时间步生成的内容。这是一种逐步、串行的生成过程。典型的 autoregressive 模型包括循环神经网络（RNN）、长短时记忆网络（LSTM）、和变换器（Transformer）等。

早期的语音翻译【Speech-to-text translation (ST)】解决方案是通过级联系统，使用多个子任务进行处理。
- 比如首先通过ASR（Automatic Speech Recognition）系统，将语音转录为文本，然后再使用 MT（Machine Translation）系统将文本翻译为另一种语言。
- 对于这样的级联系统，研究方向主要为解决误差累积（error accumulation）的问题。
端到端语音翻译【end-to-end speech translation (E2E ST)】有这样的好处：
- 能够减少误差累积
- 能够减少延迟
- 拥有更多的上下文建模
- 适用于不成文语言
基础建模：
- ST 的语料库通常包含语音 s，转义文字 x，以及翻译结果 y
- 基础的 E2E ST 模型框架是基于 Encoder-Decoder 架构的
- 然而，E2E ST 模型的训练并不容易，其效果也只是接近于级联系统的结果，并不是性能最好的技术。
目前，E2E ST 模型研究方向主要为：
- 建模负担（Modeling Burden）：
  - 需要同时处理跨模态（声音到文本）和跨语言（源语言到目标语言）的问题，导致模型建模会很复杂
  - 收敛困难，性能较差
- 数据稀缺（Data scarcity）：
  - ASR、MT 的语料库非常多，且有些非常大
  - 但是 ST 的语料库其标注难度较高，因此 ST 的数据很少
- 应用问题（Application issues）：
  - 需要考虑实际应用中的问题，如实时翻译，长格式音频分割等等。

Tackling Modeling Burden：

对于语音信号这种长序列输入，我们采用高容量端到端模型，通常是 Transformer及其变种架构。
对于建模负担问题，通常采用多任务学习框架，对原始的 Transformer-based 模型进行修改。
对解码效率问题，我们采用非自回归模型，从而提高解码速度

Transformer ：

Speech-Transformer

基于 text-to-text Transformer
主要改进点为 acoustic features 在进入自注意力编码器前，首先由卷积层（通常是步长为 2 的两层，将长度压缩 4 倍）压缩，然后再接一个归一化层

Conformer

主要改进点在于，在每个 encoder blocks 的 多头自注意力模块 和 前馈层 之间加入了 卷积模块
卷积模块包括了注意力和卷积组件，由两个 Macaron-net 风格的前馈层（feed-forward layers）和残差连接（residual connections）所包围。

SSL-Transformer

这是一种结合了自监督学习（self-supervised learning，SSL）得到的语音表示模型
SSL 已经被成功应用到了提取语音特征的任务中去
SSL-Transformer 主要就是将原始的音频波形输入到自监督学习模型中，通过多个卷积层和编码层的处理，从而提取语音特征。
SSL-Transformer 模型中，自监督学习模型可以被整合到解码器中：或者作为一个独立的编码器，或者作为一个语音特征提取器，然后与整个 Transformer 模型相连接。

Multitask Frameworks：

针对模型负担的问题，多任务的核心思想是利用一些辅助工具来辅助目标任务的完成。比如ASR和MT。而有些任务模块和辅助模块的参数是可以共享的，这就导致了辅助任务的可行性。目前有三种类型的多任务框架：

Decoupled Decoder（解耦解码器）

额外的解码器用于引导模型学习文本转录（transcript），同时仍然以端到端的方式进行模型训练。主要思想有两种，一种是如何通过生成的文本转录来更好促进翻译，比如采用两遍解码器（two-pass decoder）；还有一种是同时生成文本转录和翻译（dual decoder）

Two-pass decoder：先将声学特征通过这个Decoder，然后再把转录结果和解码器结果结合起来用于翻译工作。但由于采用的是顺序生成（sequential generation），失去了低延迟的固有优势。因此有人用非自回归方法进行第一段的解码。
Dual decoder：交互式解码（interactive decoding）使用两个解码器同步生成转录和翻译。与此同时还额外使用了交叉注意力模块（cross-attention module）来为两个解码器交换信息。wait-k 策略（wait-k policy）通过首先预测转录文本的标记，为翻译标记的解码（the decoding of the translation tokens）提供了更多有用的信息。

Decoupled Encoder（解耦编码器）

对于解耦解码器，当遇到多重推理的时候可能会导致设计与延迟问题。更好的解决方案是通过解耦编码器同时识别和理解原始语音输入的语义。因此我们采用下面这张图的方案，共有两个encoder，低级语音编码器首先对来自语音输入的声学信息进行编码，语义编码器进一步学习翻译解码所需的语义表示。

编码每个阶段都可以通过转录信息进行监督学习
转录也提供了语音的对齐，可以缓解 encoding 负担

Two-stream Encoder（双流编码器）

ASR 的数据可以用来增强组件，那么 MT 的数据也可以吗？在训练过程中，我们可以同时接收语音和文字的输入，其各自有各自的编码器，还有个共享编码器。这个结构通常通过多任务训练损失进行优化，例如用于语音翻译（ST）和机器翻译（MT）的负对数似然（NLL）损失。其中的优势在于，通过与 MT 编码器共享，可以学到更好的语义表示，以提高翻译性能。

在推断过程中，则是输入语音数据，通过语音编码器，共享编码器，解码器，最终生成翻译后的文本。

Speech encoder：其需要更有能力单独提取语音输入的声学特征。Wav2vec2 等预训练语音模型可用作语音编码器，以获得更好的 ST 性能
Text encoder：文本编码器可以是文本嵌入层（text embedding layer）或文本 Transformer 编码器的几层。同时，还可以用语音音素（phoneme）来代替原始转录作为文本输入，这样可以减少两种输入的模态差异。
Interaction：也有很多语音编码器和文本编码器交互的变种。
- 有使用对比学习法（contrastive learning method）来缩短语音和文字的表达差异的
- 有提出 Chimera model 来将语音和文字表达长度对齐的。
- 还有同时考虑到表达和长度差异，从而在共享编码器后面添加交叉注意力正则化模块（cross-attentive regularization module）的，正则化模块首先通过自注意力或交叉注意力从文本或语音编码器生成两个具有相同长度的重构序列，然后优化重构序列之间的L2距离。

Non-autoregressive Modeling

端到端模型相比于同等级的级联系统大大降低了计算时延，但是这种优势仅在自回归解码的情况下有效，这个技术研究有两条路线：

参考自动语音识别（ASR）和机器翻译（MT）任务中的方法，如条件掩码语言模型和重新评分技术，来开发非自回归语音翻译模型。
探索更高效的架构，依赖纯粹的CTC（Connectionist Temporal Classification）进行预测，以提高速度。CTC 是一种用于序列标签任务的损失函数，它可以用于训练模型，使其能够将输入序列映射到输出序列。

未来发展：

LLM（Large Language Model）

LLMs 包括 ChatGPT、Bloom等等，它们都有非常强大的能力，那么如何将LLM强大的生成能力融入到 ST 的任务中去，以及如何将语音数据也纳入LLM 的训练中去，是很值得研究的方向。

第一步我们可以先优化语音的表示，使得其能够与文本的表示相媲美。
- 伪语言——语音离散表示（speech discrete representations as pseudo-language）就是一个不错的方向。
此外，预训练大规模 acoustics-aware LLMs 也是一个很 promising 的方向。

Multimodality（多模态）

人工智能生成的文本、图像、语音、视频等多模态信息爆发，推动了ST领域去探索更加复杂的人机交互（HCI，human-computer interaction）场景的研究，比如交流翻译（speech-to-speech translation），视频翻译等等。

而多模态数据爆炸式的增长也致使在多模态数据上进行上下文学习（ICL，In-Context Learning）也成为了一个很有前途的研究方向，以更好地理解和利用不同模态数据之间的关联，从而实现更准确、更综合的多模态分析和应用。

多模态预训练也被证明在许多领域中都是有效的。

多模态之间的信息交互和关联也有待被发掘，比如视频中角色的语音和同一时间段角色的图像帧、韵律环境（prosodic environments，比如声调，音高，音量，语速，停顿等等，可以传达语言的情感、语气等）之间的关联。