链载Ai

标题: 腾讯语音合成技术:模型优化与推理加速实践 [打印本页]

作者: 链载Ai    时间: 昨天 11:55
标题: 腾讯语音合成技术:模型优化与推理加速实践

导读随着人工智能技术的不断进步,语音合成技术在游戏和娱乐领域扮演着越来越重要的角色。本次分享题目为“腾讯游戏知几语音合成大模型推理加速实践”,主要介绍腾讯在语音合成领域的产品展示、模型结构分析、推理加速方案以及未来展望。

今天的介绍会围绕下面四点展开:


ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">1.背景-产品展示

2.模型结构选型与分

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">3.模型推理加速方案

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">4.未来展望

出品社区|DataFun


01

背景-产品展示


首先,让我们来看一下腾讯自研的知音语音大模型在语音合成领域的应用展示。该模型能够提供更自然、韵律丰富且实时性更强的语音合成体验。其两大显著优点如下:



我们的产品主要分为三种形态:


这三种产品形态分别涵盖了文本、语音以及多模态交互,旨在为用户提供多样化且高度沉浸式的互动体验。


02


模型结构选型与分析



接下来,我将详细讲解我们语音合成模型的结构选型和分析。传统的语音合成方案通常包括以下步骤:


然而,这种传统方案存在一个显著缺点:需要大量的训练语料。在游戏场景中,例如 NPC(非玩家角色),往往难以获取如此大量的训练数据。因此,我们的研究方向转向了基于语言模型的解决方案。


1. 语音合成大模型结构



新方案的主要流程如下:


2. 面临的挑战



高并发场景的挑战:在高并发环境下,模型需要高效处理大量请求。


实时率要求:特别是在游戏场景中,需要实时处理语音并触达玩家,对实时率的要求非常高。


针对上述挑战,第三部分我们将详细介绍模型推理的加速方案,以提高系统的并发处理能力和实时性能。


03


模型推理加速方案



在选择加速方案时,我们首先考虑借鉴自然语言处理(NLP)领域的一些成熟加速方法,并将其应用到语音合成大模型上。在 NLP 领域的大模型中,已经有许多成熟的推理加速方法,这些方法可以分为工程上的优化(KV Cache,prefix KV Cache,flash attention,flash decode和page attention)和偏算法上的优化(投机采样,int4/int8 量化等)。这给我们带来了非常多的启发。


1. KV Cache



为了将 KV Cache 技术应用于语音合成大模型,我们需要确保 Attention Mask 的设计满足特定条件。这些条件使得 KV Cache 能够有效地缓存之前的计算结果,从而减少冗余计算并提高推理速度。


(1)使用 KV Cache 的条件



(2)语音 AR 模型中的 Attention Mask 设计


在语音自回归(AR)模型中,Attention Mask 的设计通常满足上述条件,因此可以有效地使用 KV Cache。注意力掩码(attention_mask)和掩码后的 QK 矩阵(Mask(QK))的变化过程:左侧展示了一个注意力掩码的例子,其中每个元素表示对应位置的 token 是否参与注意力计算。中间展示了掩码后的 Q*K 矩阵,其中非零元素表示有效的注意力权重。当生成第 n 个 token 时,注意力掩码会发生相应的变化,新的 token 会被加入到掩码中。右侧展示了更新后的注意力掩码和相应的掩码后的 Q*K 矩阵。


通过这种方式,每次生成新 token 时,只需要计算新增的部分,而不需要重新计算整个序列的注意力权重,从而大大减少了计算量,提高了推理速度。



2. GQA



在预填充(Prefill)阶段,计算瓶颈是主要的限制因素。这一阶段通常涉及大量的并行计算,特别是在处理初始输入时,模型需要对整个序列进行编码,生成所有 Token 的 Key (K) 和 Value (V) 值。这种大规模的计算需求使得计算资源成为主要瓶颈。


而在解码(Decode)阶段,内存访问瓶颈则成为主导。在解码过程中,模型逐步生成新的 Token,并且每次生成新 Token 时都需要访问之前生成的所有 Token 的 K 和 V 值。频繁的内存访问导致了较高的延迟,使得内存带宽成为主要的性能瓶颈。



相比于使用 KV Cache、INT8/FP8 量化等方法,选择组量化注意力(Grouped Query Attention, GQA)可以提供更可控的压缩率。GQA 通过将多个查询头(Query Heads)组合在一起,减少了模型中注意力头的数量,从而降低了计算复杂度和内存访问量。这种方法可以在保证模型效果的同时,显著提高推理效率。


具体来说,通过将注意力头数量从 16 减少到 4,我们不仅减少了模型的计算复杂度,还降低了内存访问的需求。实验结果显示,这种优化可以使推理耗时降低 20%。这表明,GQA 是一种有效的手段,能够在保持模型性能的同时,显著提升推理速度。



3. BPE


在引入 KV Cache 机制后,AR 模型被划分为两个主要阶段:预填充(Prefill)阶段和解码(Decode)阶段。预填充阶段负责初始化模型的状态,并为后续的解码过程准备必要的上下文信息;而解码阶段则基于这些上下文信息逐个生成音频样本或 token。对于生成一段时长为 10 秒的高质量音频而言,采用传统方法通常需要 AR 模型产生大约 500 个 token。



NLP 领域中广泛采用字节对编码(Byte Pair Encoding, BPE)技术来解决 OOV 问题。BPE 算法首先将输入文本中的每个单词拆分成单个字符序列,随后通过统计分析找出出现频率最高的字符对,并用一个新的复合符号代替这对字符。这一替换步骤会重复进行,直至达到预设的最大循环次数或满足其他停止条件为止。这种方法有效地增加了词典容量的同时,保持了相对较小的词汇表大小,有助于提高模型训练效率及泛化能力。



为了直接使用 NLP BPE,先将原始音频数据转换成一系列离散化的 audio token,然后将这些 token 与唯一的 Unicode 字符建立一一对应关系。这样一来,每一个特定的 Unicode 字符实际上就编码了一个或一组相关的音频信号片段。这种做法不仅简化了模型结构,还极大地提升了处理效率。实验结果显示,通过应用上述优化策略,合成相同长度即 10 秒钟音频所需的 token 数量可由原来的约 500 个减少至约 170 个左右,显著降低了计算复杂度并加速了整个生成流程。



4. 连续性批处理



LLM 中优化吞吐主要有两种方式:


朴素批处理:每个时间步(T1 到 T8)分别独立地处理不同的句子(S1 到 S4),并且每个句子在达到结束标记(END)之前都会被单独处理。


连续性批处理:试图在同一时间步内同时处理多个句子,以实现更高的并行性和效率。例如,在第一个时间步(T1),四个句子(S1 到 S4)都被处理;随后的时间步继续处理这些句子直到它们各自完成。


这里可以直观的看到两种批处理方法的区别:


左上角图表:显示了朴素批处理的结果,每个时间步仅处理一个句子。


右上角图表:显示了朴素批处理的最终状态,每个句子都在各自的结束点停止。


左下角图表:显示了连续性批处理的开始阶段,所有句子在第一个时间步都被处理。


右下角图表:显示了连续性批处理的最终状态,不同句子在不同的时间步完成。



在大型语音合成模型中,可以采用两种不同的批处理(batching)策略。下面分别介绍了这两种方案及其优缺点:


优点:当需要对文本和音频特征进行类似嵌入(embedding, emb)的操作时,这种方案提供了更加简洁直接的方法。它允许模型分别处理文本和音频数据,从而简化了特征处理流程。


缺点:在推理阶段,尤其是在解码过程中执行注意力机制计算时,必须为每次计算提供填充注意力掩码(padding attention mask)。这增加了推理框架实现上的复杂性,因为需要额外处理这些掩码以确保正确地忽略掉填充部分。


优点:该方案简化了注意力机制在推理过程中的应用,无需为每次计算单独定义或传递填充注意力掩码。因此,它可以无缝集成到现有的大规模语言模型(LLM)推理框架中,提高了易用性和效率。


缺点:然而,在面对需要同时处理文本和音频特征的情况时,如进行嵌入操作,这种方法可能导致处理流程变得更为复杂。由于不能像方案一那样直接分离处理,因此可能需要设计额外的逻辑来协调不同模态之间的交互,增加了系统的整体复杂度。



这里我们介绍一下结合腾讯 Trpc 微服务框架,在语音合成大模型中实践 continuous batching 推理的过程。该框架旨在提升模型推理性能,降低延迟并提高资源利用率。


左侧的架构图介绍的是一个典型的分布式系统结构。其中,“master”进程作为主控节点,负责任务调度和管理。从“master”分支出来的“Dispatcher”进程用于接收用户请求并将它们分配给各个工作进程组。工作进程组包含多个“Worker”进程,它们运行在 GPU 或 CPU 上,负责实际的模型推理任务。此外,还有一个“Task”进程,其内部有一个缓冲区(buffer),用于存储待处理的任务。这些任务经过前处理后,进入模型推理阶段,最后返回结果并进行后处理。


右侧的流程图详细描述了具体的持续批量推理过程。首先,通过 rpc 框架请求队列收集用户请求,然后进行二次批量处理和优先级调整。接着,这些请求被送入 AR 模型进行连续性的推理。完成推理后,异步式地返回结果,并将其放入 NAR 队列中等待进一步处理。最后,将处理好的结果发送回用户端。



5. 推理加速效果



实时率从 2.09 优化到 0.085,吞吐可达到 1 秒 2500tokens。



04


未来展望



在未来的研究与开发中,我们计划实施以下几项关键举措以进一步优化语音合成技术。








欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5