视频编解码芯片“沧海”，已经量产并投用数万片，并在云游戏、直点播等场景中，面向腾讯自研业务和公有云客户提供服务。高性能网络芯片“玄灵”，采用自研的网络、存储、计算加速方案，实现主机CPU的“0”占用及高达4倍的性能提升，助力打造下一代高性能网络基础设施。自研AI推理芯片“紫霄”，已经量产并在多个头部业务落地，目前在腾讯会议实时字幕上已实现全量上线，单卡紫霄机器负载可达到T4的4倍，并将超时率从0.005%降低至0。本文将从技术实践角度，解读紫霄在腾讯会议实时个性化字幕场景下的应用。在海量音视频会议中，信息实时获取和记录逐步成为了刚需。为了方便实时查看和记录会议中参会者所表达的信息，腾讯会议在2022年中旬推出了实时辅助字幕功能，方便在会议过程中结合音频，视频和会议内各类多模态信息，对会议内容进行内容实时转录和复刻。
随着业务规模的扩张，高峰期实时字幕常常十万路级别以上的并发，这对于业务的成本，延时和体验带来了极大的挑战。通常实时字幕服务不同于一句话识别或离线识别，需要实时解码各类人声密集场景的音视频信息，进行瞬态和稳态的同时呈现，在业界单T4卡做到50路是比较合理的性能配置，到达100路则会对用户体验产生影响。为此，腾讯会议天籁实验室联合在多模态内容识别推理上有丰富经验的腾讯蓬莱实验室，在腾讯自研硬件芯片上，针对该场景进行了软硬件结合优化，在降低了75%成本的同时，进一步减少了首字和尾字延迟。为确保腾讯会议实时字幕的准确性及用户体验，模型的推理需要具备极高的要求。一般来说，字幕上屏应与用户的发言一致，因此，整体发声到上屏延迟必须控制在1s以内。同时，对于任意语音段，其处理时延不能超过2秒，否则被视为超时而被丢弃。在如此高的时延要求下，所承载的是对算力和计算优化的极致要求，这正是保障腾讯会议实时字幕质量的关键。紫霄是蓬莱实验室第一款云端AI推理芯片，目前已经在腾讯头部业务规模部署，均提供至少3倍的计算加速性能，和超过45%的整体成本节省。
有关紫霄芯片的算力参数，以及跟其他常见芯片的对比，详见下表：
在紫霄落地腾讯会议的业务过程中，双方团队联合在原来的智能语音解码引擎中加入了紫霄硬件后端的支持，并开发了一套针对紫霄硬件的高性能运行时系统，能够在高并发条件下满足业务团队对于实时率、精度等指标的要求，横向对比 T4 和 A10 GPU 在单卡支持的路数、接口调用平均耗时、丢包率上均取得显著优势。
紫霄在处理语音数为T4两倍的情况下（单路语音解析成本相对T4节省50%），超时率依然为0%（任务耗时2s以上视为超时）。为了稳定，业务先以两倍T4性能上线，后续再逐步加大负载（紫霄在处理400路语音的情况下超时率依然为0%）。1. 流式解码简介
我们从全局角度分析下腾讯会议实时字幕的技术细节。在一场腾讯会议中，当会议用户在应用内点击 “开启字幕” 功能后便开始进行实时字幕处理，而后引擎开始持续识别会议中每个人的语音，在保证识别质量的前提下，对实时性和吞吐量都有很大的挑战。
实时字幕场景是一个结合会议多媒体信息内容综合解码的流式业务，主要包括瞬态和稳态两个场景，其中瞬态是常规的滚动，在关键节点，如说话人转换，瞬态置信度过低，时间过长，VAD结尾时，则会调用稳态识别，对内容进行修正。稳态识别的计算量更大，也往往会结合更多会议环境变量，如标题，联系人，视觉等信息对结果进行增强。
1. 瞬态字幕识别，在会议中瞬时的流识别结果，要求迅速返回，首字延迟低，并发量高等特点，处理流程为：
特征处理（CPU上执行），将语音数据处理为声学特征数据；
首帧模型推理/中间帧模型推理（CPU上执行），识别音频，输出识别概率；
后处理（CPU上执行），获取识别结果语句、口语精炼，内容纠错，处理标点符号，口语规整等。
2. 稳态字幕识别，在会议中，当参会者说完一句话的时候，会进行一次整句话的识别，输出最终结果，处理流程为：
特征处理（CPU上执行），将语音数据处理为声学特征数据；
声学模型推理（GPU 上执行），识别音频，输出识别概率；
语言模型 （CPU上执行）， 声学模型输出的识别概率结合语言模型进行搜索，输出n-best候选语句；
重打分模型推理（GPU上执行），对语言模型输出的候选语句进行非自回归方式重打分，再和CTC的打分结合，选出可能性最大的语句；
后处理（CPU上执行），同瞬态字幕识别的后处理。
在流式语音识别场景中，关键指标为实时率（Real Time Factor, RTF），实时率定义模型处理时间和音频长度的比值。例如处理 10s 的音频耗时 5s , 则 RTF = 5s / 10s = 0.5。如果 RTF > 1 ，则说明引擎已经无法及时处理输入数据。而针对腾讯会议实时字幕场景，在机器打满高并发下要求 RTF < 0.05，且纯算法首字延迟最好小于400ms，中间，尾字延迟小于150ms。由此可见，字幕场景的实时性要求非常高，如果不能在规定的时间内返回识别结果，将会产生丢包的情况，严重影响用户体验。
针对实时字幕的流程和特性，我们制定了以下紫霄优化思路：
(1) 瞬态模块加速：优化前，瞬态模型（首帧模型和中间帧模型）在 CPU 上进行推理，消耗了过多CPU资源，导致处理特征数据的CPU不足。紫霄团队通过微调模型去除瞬态模型动态性，可大量减少对推理显存的需求，将瞬态模型在不损失精度的情况下从CPU调度到紫霄上进行计算。
(2) 稳态模块加速：支持声学模型、重打分模型在紫霄上推理，并通过团队自研的高性能运行时 LightRuntime 统一调度瞬态模型、声学模型和重打分模型的资源分配和推理调度，最大化紫霄芯片的使用。
(3) 线程框架优化：为了更充分发挥紫霄的能力，对线程框架进行优化，去除业务组batch的线程，使用LightRuntime的组batch和调度能力。
分析发现瞬态调用次数是稳态的5倍左右，瞬态模块总模型计算量比稳态大，原有解决方案瞬态放在CPU上计算面临以下问题：1. CPU算力有限，导致瞬态模块处理慢，稳态模块需要等待瞬态处理结束才启动稳态流程处理，所以GPU利用率不高；2. 机器CPU核心数有限，无法通过开启大量语音处理路数的方式，将GPU利用率提升到合理水平。3. 如果将瞬态计算放GPU计算，由于同时处理的瞬态任务较多，onnxruntime分配大量显存导致GPU OOM问题。为了充分发挥卡的算力，紫霄加速方案将瞬态计算放到紫霄卡上。项目初期瞬态模型输入shape是动态变化的，静态shape具备高性能，紫霄采用padding-分桶的思路来支持动态输入。模型输入包括声学特征、历史推理计算结果两部分（一共26个输入）：
➢ 声学特征XS: [batch_size, seq_len, 80]
➢ subsample cache：[batch_size, cache_len, 256]
➢ encoder layer output cache: [batch_size, cache_len, 256] * 12
➢ convolution module cache: [batch_size, 256, 14] * 12
每次推理cache_len的长度会增加，导致模型的输入shape是动态变化的。分析模型结构发现padding会影响position embedding查询、softmax计算，为了消除对计算结果的影响，需要对模型结构进行微调。
2.2 消除padding对position embedding表查询结果影响数据流进入模型主干结构前，需先查询出cache subsample以及conv subsample对应的embedding表行，作为conformer block的输入。原始模型结构先将subsample_cache和conv subsample合并，合并后的张量shape信息作为查表的结束行。如果对subsample_cache进行padding，将导致conv sample对应的embedding行错位，解决方案是分别查询cache subsample、conv subsample对应的embedding行，然后将两次查询结果合并成一个张量。模型微调之后的查表步骤：
1. 查询paded subsample_cache对应的行；
2. 查询声学特征conv subsample对应的行（real_length作为xs查表时的起始行）；
3. concat算子将两次查表结果合并作为conformer层的输入。
新增real_length输入（real_length代表实际的cache length，而不是padding之后的cache length），可保证查询出conv subsample对应的表行。
2.3 消除padding对attention结构的影响softmax坐标图
新增Mask输入节点，由0、1组成，假设real_length=3，pad_len=2，则：
执行softmax之后，-inf对应的score值比较小，但仍不为0，为了完全消除padding影响，再执行一次mask将对应元素设置为0。增加Real_length、Mask两个输入节点，对position embeding、conformer block结构进行微调，即可完全消除padding对计算精度的影响。瞬态中间帧模型、稳态声学和重打分模型放紫霄计算，128 路语音时，中间帧耗时从1200ms左右降低到10ms。CPU占用大幅降低，降低长尾任务的超时率。测试过程发现随着设置的语音路数变多，首帧模型耗时增加，分析发现是由于解码引擎中只创建了一个首帧模型onnxruntime session，解决思路是初始化时创建session pool，将计算任务均匀负载到每个session上。400路语音耗时从249ms降低到30ms。➢ 模型支持padding，精度无损。并且增加slice节点，将cache_len固定在128，模型input shape不再变化；增加concat节点，分别将encoder layer output cache和convolution module cache合并，减少输入、输出节点个数，改造后模型的输入输出全景：由于模型输入不再变化，紫霄瞬态模型由多个减少到一个，降低了模型维护成本，全流程显存占用从90%左右降低到52.8%。从稳态字幕的处理流程中可知，流程包括声学特征提取、声学模型推理、语言模型生成候选语句、重打分模型进行二次打分和后处理（标点符号、大小写转换）共五个阶段。在基于GPU解码流程中，声学模型和重打分模型的推理放在GPU上执行，尤其是声学模型模块基于18层或以上的 Deep Conformer结构，为了更加有效的利用GPU算力，SDK内部做了多batch流式请求和分桶排序特征。在腾讯会议稳态字幕链路的优化中，我们充分打磨和使用了 LightRuntime 的以下几点能力：1. Auto Batch，根据实际请求在一定时间内动态组装batch，提升引擎的并发吞吐能力；特性指的是在 LightRuntime 内将用户输入的单个模型请求（batchsize 为 1）数据动态组装为更大的 batch，从而更充分的发挥 DTU 的能力优势，最终在延时允许的前提下提高模型的整体推理吞吐。在腾讯会议业务中，从实测数据上来看，针对声学模型开启Auto Batch 功能，可以提升 20% 左右的吞吐。2. Auto Padding, 自动分桶 (Auto Padding) 特性指的是在 LightRuntime 内自动为用户请求的 input 数据执行分桶并 padding 到目标超参组合的 input tensor shapes，以减少在 DTU 上部署推理的使用成本。3. 多模型调度部署，针对多模型推理部署的使用场景，LightRuntime 提供了多 Session 机制：通过不同 LightSession 对不同 ONNX 模型的所有 Shapes 请求做统一任务分发和计算调度，从而最大化利用 DTU 计算资源；并通过优先级调度，充分保证了高优模型的推理服务质量。3.1 使用 LightRuntime AutoBatch 提高吞吐针对紫霄硬件特性， 为了充分发挥紫霄算力，在 LightRuntime 的设计中，引入AutoBatch 模块，模块的设计如下图所示。
1. 生产者线程负责将用户数据按照模型下标加到对应的任务队列中；2. AutoBatchScheduler中的n个线程会对应的n个seq_len队列，积累batch，batch提交的原则同上；3. 消费者线程从合并后的 batch 任务队列中直接拿数据并进行最优拆分然后执行推理。在测试某个新版本的声学模型时，发现声学模型在半精度模式下有精度下降的情况。通排查发现，此版本声学模型在训练时，训练集中的数据分布发生了变化，导致模型在推理阶段会产生精度下降的倾向。再经过进一步的分析，剔出了conformer网络中容易在半精度下的容易溢出的网络层，如典型的 Matmul, Mul 等。剩下的事情就比较简单了，在模型编译阶段设置有溢出倾向的网络层为单精度模式，在模型推理性能和精度之间找到了一个很好的折中。
紫霄加速稳态模块后，稳态超时率为0%（超时是指耗时超过2s）。
紫霄加速了瞬态、稳态（声学、重打分）两个解码流程，由于LightRuntime的易用性、功能丰富，适配过程对业务代码改动不多。➢ 业务SDK层（生产者）：初始化时创建瞬态lrt session、声学lrt session、重打分lrt session，处理解码任务时，所有decoder共享这些session。通过Run接口将对应session的计算任务提到任务队列。
➢ LightRuntime层（消费者）：从各session的任务队列中获取task，随后由全局WorkerScheduler调度到具体的VG上进行计算。
当前紫霄已全量覆盖会议字幕总流量的~95%以上，其中中英文字幕已全量上线，运行稳定，解决了原来GPU面对高并发时的延时毛刺问题，而且节省了业务~50%的成本，极端场景下可以做到节省75%的成本。
从沧海到紫霄、再到玄灵，腾讯在自研芯片领域，正在持续深耕底层软硬件，探索最优性能和最佳性价比的结合，服务更多企业和开发者的云上创新。—END—