您现在的位置:主页 > 技术 > 正文内容

1 概述

作者:admin 来源:未知 更新日期:2020-09-07 浏览次数:

  云侧是一种集中式服务,把所有图像、音频等数据通过网络传输到云中心进行处理然后把结果反馈回去。云侧资源集中通用性强,但是随着数据的指数爆发式增长,云侧已暴露出了很多不足,比如数据处理的实时性、网络条件制约、数据安全等。基于云测的局限性,端侧的推理越来越重要。端侧推理具体以下优势:1)低延时;2) 保证数据隐私;3)不依赖网络。然而端侧的计算资源、内存、存储都比较有限,如何满足性能的需求至关重要。日趋异构化的终端硬件平台,能够提升端侧的计算能力,然而复杂的开发环境让AI技术在端侧的应用落地颇受挑战。

  语音识别(Automatic Speech Recognition,简称ASR),是语音交互中最基础的一个AI技术环节,常见的应用场景如智能音箱、同传、通话翻译等。ASR识别需要强大的计算能力,如何实现一个低延迟、高性能、低功耗的端侧ASR面临着重大挑战。

  ARM(CPU)是目前AI端侧推理的主要计算平台,随着技术的发展和数据的增长,端侧对性能和功耗要求越来越高,单纯的ARM平台不再能满足新的需求,终端异构计算平台可以提供更强大的计算能力,逐步成为AI端侧推理的主流计算平台。DSP(Digital Signal Process)芯片,也称数字信号处理器,是一种进行数字信号处理运算的微处理器。相比强大的CPU,DSP尤其擅长在低功耗下处理这些任务。高通骁龙芯片提供了ARM+DSP异构计算平台,可以更好的服务于AI端侧推理,我们实现了基于高通骁龙865平台上的CPU+DSP协同计算离线ASR系统,该方法保证识别质量降低一个百分点以内,计算性能相对CPU版本加速3.89-4.42倍,功耗降低30.3%,异构计算平台降低了延迟和功耗,提高端侧设备待机时间。

  有道离线ASR是运行在移动设备端的应用程序。离线与在线的区别是,离线ASR是运行在设备端,不需要联网就可以进行语音识别的应用程序,而在线是必须依靠网络服务才可以获取语音识别结果的过程。

  各个Stage之间独立运行,保证了在语音识别过程中,各模块单元的运行效率和识别质量。

  离线ASR可以运行在安卓系统和ios系统中,支持armV7和armV8等多种arm处理器的指令集。离线ASR引擎以其轻量、简洁、扩展性强等特点,可以便捷的集成在如智能手机、智能手表、智能音箱等设备中。

  有道离线ASR已在翻译王、词典笔、电子词典、某手机离线通话翻译等产品中广泛使用。

  DSP架构与CPU或GPU截然不同,DSP具有两个关键的特点:1)DSP充分体现了每个时钟周期的计算能力;2)DSP在较低时钟频率下也可以提供高性能的计算能力,以低时钟频率节省功耗。

  在移动端应用中,利用本地资源进行计算越来越重要。CPU计算带来功耗高的问题,导致移动终端的续航时间短、温度高等问题突出。DSP相对于CPU更擅长在低功耗下处理这些任务,具有高性能、低功耗等特性,提供更好的用户体验。

  高通芯片在手机移动应用中广泛使用。最新的高通骁龙865处理器,如表 1所示。在CPU方面,搭载了三丛集的架构设计结构,1个大核最高主频2.84GHz,3个主频2.42GHz的中核,还有主频为1.8GHz的4个小核。除了CPU架构,865还搭配了高性能、低功耗的DSP——Qualcomm Hexagon 698。

  Hexagon DSP能够通过硬件多线程技术和最大化每个时钟周期所能完成的工作,在低时钟频率下运行,同时又能提供高性能。

  Hexagon DSP核心计算模块为cDSP(Compute DSP),Hexagon 698使用的是cDSP V66架构,如图 1所示。cDSP支持4个硬线组Hexagon向量计算模块。cDSP通过多线程和SIMD指令获得性能。cDSP上浮点计算性能较差,更擅长做8位、16位和32位定点数计算,因此,在DSP上实现深度学习推理服务时,量化是获得高性能的重要手段。

  从算法角度分析,forward最核心的计算为Tdnnf,Tdnnf先做一次矩阵重组,input相邻两行组成新矩阵aux的一行,然后做全连接计算,如图 2所示,同样分析得到gemm是最核心、最耗时计算。

  8bit量化是深度学习训练和推理中提高计算性能的一种常用方法,量化方法分为对称量化和非对称量化两种方法,如图 2所示。我们在DSP上采用了uint8(无符号8bit)非对称量化的方法。

  其中,r表示float真实值,q表示量化值,S为缩放系数,Z为零值量化值,S和Z用公式3和4表达,S数据类型为float,Z数据类型为uint8。

  为了能把所有层的计算都转完uint8量化计算,需要把int32中间结果重新量化成uint8类型,称为重量化。

  Forward模块中,fc计算以及其他计算模块需要做向量求和或矩阵求和的计算,需要实现其量化计算。

  公式11中表示的是两个向量或矩阵中对应的元素值相乘,_i表示第i个元素,结果为int32对称量化。

  一个系数乘向量的量化计算,不需要做向量的计算,只需要使用原向量的缩放因子S乘以系数c做结果向量的缩放因子,Z值和uint8量化值保持不变。

  DSP版本采用了uint8量化计算,只需申请量化的权重空间,比float32节省75%的空间,并且加载数据量也只有原来的1/4,既节省了内存空间,又减少了数据加载的时间。

  DSP程序开辟太多的内存buffer数量会严重影响性能,我们对buffer数量进行了缩减,把所有层权重申请在一块buffer中,通过偏移量进行控制。

  FastRPC调用一次需要0.5-2毫秒,调用次数将会影响整个应用程序的性能,因此,FastRPC调用次数越少越好,把一次forward计算做一次FastRPC调用,IDL接口如下所示。

  a)多线个硬线程,forward DSP底层计算中均采用了4线程并行计算。Gemm 4线所示,由于ASR forward计算中,结果矩阵行大小N较小,不适合并行,我们划分列大小M并采用4线程并行计算。

  为了提高DSP cache命中率,对gemm计算进行了分块计算,如图 6所示,采用了4*32的分块,保证数据的cache以及SIMD宽度。

  为了进一步提高计算性能,还采用了对齐策略,训练模型大小设置为128的倍数,使DSP多线程并行和分块更容易。

  骁龙865芯片有大中小核三丛集的架构设计结构,离线ASR应用程序属于计算密集型,原CPU版本ASR程序会持续运行在中核或大核上,计算性能较好。把forward迁移到DSP计算后,CPU相对比较空闲,安卓系统会把其他模块计算自动切换到小核上执行,从而导致整体性能较差,为了解决这个问题,可以采用亲和性设置。亲和性是一种调度属性,它可以将一个进程绑定 到一个或一组CPU上。CPU+DSP协同计算的离线ASR应用程序做了中核和大核的亲和性设置,如下。

  测试集来自公开数据集aishell-1、openslr,使用test测试集验正确性,从中选择4条测试用例用于测试计算性能和功耗,如表 5所示。

  Fastrpc实现了CPU调用DSP模块的接口,接口buffer数量会对性能带来严重的影响,表 8展现了减少buffer数量对性能的影响,可以让fastrpc时间降低11.62倍,从而提升整体应用程序的性能。

  设置中大核之后,无论是在CPU上的计算模块还是DSP上计算模块性能都得到较大幅度的提升,如表 9所示,整体性能提升112%。

  进一步对优化后的DSP程序分析发现,fastrpc调用时间仍然较长,在forward计算中,fastrpc调用时间占比达到30%,如表 10所示,这是DSP硬件决定的,单次计算时间较少的模块迁移到DSP上时会因为fastrpc时间导致整体性能反而变差的情况发生,因此DSP应用具有一定的局限性。平均单次fastrpc调用时间达到了1.8ms以上,如果需要移植到DSP上的模块在CPU端运行时间小于这个时间是不适合迁移到DSP模块。

  DSP相对CPU具有更好的功耗表现,CPU+DSP方案比纯CPU方案功耗下降30.3%。

  通过手机端CPU+DSP异构计算的离线ASR的实现,验证了其效果,在保证wer增加不超过1个百分点的前提下,计算性能相对纯CPU版本加速3.89-4.42倍,功耗降低30.3%,极大的提高了移动设备的续航时间。端侧异构计算,已经成为了端侧AI落地平台的发展趋势,DSP、NPU等AI芯片的发展将会大大促进AI在端侧的落地。结论

  TensorFlowLite (TFLlite) 后,有道技术团队第一时间跟进 TFLite 框架,并很快将其用在了有道云笔记产品中。本文将介绍我们是如何将 TFLite 运用在有道云笔记中的文档识别工作中的,以及 Tflite 都有些什么特性。主题:

  NLPCC的全称为“CCF国际自然语言处理与中文计算会议”,英文为“Natural Language Processing and Chinese Computing”,是中国首个NLP领域的国际会议,由中国计算机学会(CCF)主办,至今已经举办了七届。在今年的竞赛单元中,首次增加了中文语法错误修正任务(Shared Task 2: Grammatical Error Correction)。该项任务的目标是:检测并修正由非中文母语者书写的中文句子中的语法错误[1]。可以认为该项任务的输入是一句可能含有语法错误的中文句子,输出是一句经过修正后的中文句子。作为一个比赛任务,这个工作更关注算法的效果,即结果的正确性,而不太考虑处理速度、资源占用等应用落地的问题。

  比赛方要求参赛者主要使用主办方提供的数据进行模型算法的训练和调试,在比赛截止前一周发布测试集原文,参赛者使用算法生成指定格式的自动批改结果以后提交结果。 主办方给出的训练数据来源于一个语言学习网站,该网站提供了一个开放平台让对应语言的母语者可以自由地对平台上语言学习者写的作文进行语法修正。训练数据共有71万条记录,每一条记录包含一个可能含有语法错误的句子和零到多句对应句子修正结果。如果是零句修正结果,则可以认为这句话是不需要修正的;如果是多句修正结果,可以认为有多种修改方法。 在一个传统的自然语言处理任务中,训练数据的收集和清洗往往会占到整个策略工作的50%甚至70%的时间,数据预处理的策略也会对后续算法的选择和效果有非常大的影响。通过对训练语料的分析,我们最终使用的策略是:将训练语料中每条记录拆成多个错误到正确的语句对,如果某条记录没有修正结果,则生成一个正确到正确的语句对。经过上述处理后,我们最终获得了122万条训练语料,并且将其中的3000句预留作为调试用的开发集,不参与到训练当中。原始训练数据的对应修正结果分布及样例分别如图表 1和图表 2所示。

  随着深度学习算法在图像领域中的成功运用,学术界的目光重新回到神经网络上;而随着 AlphaGo 在围棋领域制造的大新闻,全科技界的目光都聚焦在“深度学习”、“神经网络”这些关键词上。与大众的印象不完全一致的是,神经网络算法并不算是十分高深晦涩的算法;相对于机器学习中某一些数学味很强的算法来说,神经网络算法甚至可以算得上是“简单粗暴”。只是,在神经网络的训练过程中,以及算法的实际运用中,存在着许多困难,和一些经验,这些经验是比较有技巧性的。

  有道云笔记不久前更新的文档扫描功能中使用了神经网络算法。本文试图以文档扫描算法中所运用的神经网络算法为线索,聊一聊神经网络算法的原理,以及其在工程中的应用。

  Avazu Click-Through Rate Prediction比赛分享

  Avazu Click-Through Rate Prediction是移动广告dsp公司avazu在kaggle上举办的广告点击率预测的比赛,全球共有1604支队伍参加,我和周骁聪组队参加了比赛,最终我们获得了第三名。下面是我们比赛的方法分享。

  整个比赛历时两个多月,在这个过程中我们和众多数据挖掘高手交流切磋,对于广告点击率预测问题也有了更深的理解。点击率预测算法在经历了多年的研究和发展之后,如今再要有一个大的提升已经是一个比较困难的事情了。当前点击率预测算法的主要收益大都是来自于线性模型的改进+特征工程,最近几年工业界已经开始尝试用非线性模型去解决点击率预测的问题,也取得了一些不错的结果。通过这次比赛,我们也相信非线性模型的使用以及多模型的融合会带来点击率预测算法的下一次飞跃。

  移动互联网当道的今天,变化已经是大家习以为常的事情了。也许昨天还在街边苦等久久不来的出租车,今天已经可以在手机上点点预约车辆准时到达门口。优秀的产品带来了生活习惯、甚至生活方式的变化,这是从前无法想象的。在这背后则是互联网产品服务的变化,在这个大潮中,“进化”的周期变得越来越短,大家也许还记得当年各大杀毒软件厂商,每年才会发布一个新的功能版本,而如今几乎每一天大家的手机上都会收到各种各样的软件更新。而在这种快速更新的软件背后,需要一种能够很好适应并响应变化的团队组织方式——已经为大家所熟知的敏捷开发方法Scrum。

(责任编辑:admin)
【字体: