Press "Enter" to skip to content

你竟然是这样的端智能?

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

 

很久以前,我还是个保洁员,直到有一天上帝说不了解端智能的保洁员不是好保洁员,于是我向隔壁小哥偷学了端智能这项技术,写下了这篇文章。如有错误,请找隔壁小哥~

 

本文将谈谈端智能以及端智能在西瓜视频的发展。你可以已经听说过端智能,这犹抱琵琶半遮面的样子真是令人心痒,今天咱就扯下它的面纱看看。

 

从云智能到端智能

 

可能有很多人纳闷不是要聊端智能幺?怎幺还牵扯到边缘计算了,莫不是为了凑字数?实际上从云智能到端智能的延伸实际上也是云计算到边缘计算的扩展。我们知道云计算自身有着许多的优点,比如庞大的计算能力,海量的数据存储能力等等。现在很多对外提供服务的 APP 本质上都是依赖各种各样的云计算,比如直播平台、电商等等。但新型用户体验追求更加及时,稳定性的服务,这就促使我们想要将服务尽可能的部署在物理设备所在位置,最终推动了边缘计算的发展。

 

从云智能到端智能,本质也是如此。以无人驾驶为例,总不能在驾驶过程由于网络波动导致汽车停止对路况的计算吧,或者说在万分之一秒内还不确定是要刹车还是加速吧?

那究竟什幺是边缘计算呢?边缘计算与所谓的端智能又有什幺联系?继续往下看~

 

边缘计算

 

边缘计算是一种致力于使计算尽可能靠近数据源,以减少延迟和带宽使用的网络概念。通常来说边缘计算意味着在云端运行更少的进程,将更多的进程移动到本地设备,比如用户的手机,IOT 设备或者一些边缘服务器等。这样做的好处就是,将计算放到网络边缘可以最大程度减少客户端和服务器之间的通信量及保持服务问题。

 

不难发现,边缘计算本质是一种服务端,类似于我们现在的云计算服务,但这种服务非常靠近用户,能够给用户提供更快速的响应,简单点说就是干啥啥快。

需要注意的是,边缘计算并非用来取代云计算的,如果说云计算更注重把控全局,那边缘计算则聚焦于局部,本质上边缘计算是对云计算的一种补充和优化,可以帮我们从数据源头近乎实时地解决问题,凡是在需要减少时延或追求实时目标的业务场景下,都有它的用武之地,比如:计算密集型工作,人工智能等场景。这里的人工智能的场景就涉及到我们下面要说的端智能了。

 

端智能的本质

 

对于人工智能,想必我们已经见怪不怪了,尤其是以头条/抖音/快手为代表的软件,都是将机器学习用到极致的产品,此外像扫地机器,无人车等硬件设备也是人工智能落地的最佳示例。那我们要说的端智能又是什幺角色呢?

 

和从云计算到边缘计算的发展类似,人工智能的发展也经历从云到端的过程,我们常说的端智能实际上就是把机器学习放在端侧去做。这里的端侧想相对于云端而言的,除了我们常见的智能手机外,端侧设备也包括各种 IOT 设备,嵌入式设备等,如语言翻译器,监控摄像头等,当然无人车也属于该领域。

 

 

从 2006 年开始人工智能进入第三次发展,并以 AlphaGo 先后战胜李世石和柯洁宣告新时代的到来,这背后得益于:

 

大数据的发展及硬件算力提升,CPU/GPU 及专用计算单元;

 

深度学习算法及框架不断演进,从 Torch,Caffe 到 TensorFlow,PyTorch 等。

 

与此同时,端侧设备同样在算力,算法及框架有了突飞猛进的发展:

 

算力:CPU/GPU 性能提升,手机的算力不断增长,以及专门用于 AI 的神经网络处理芯片逐渐成为标配,已经能够不同程度上支持算法模型的运行;

 

框架:面向移动端的机器学习框架的诞生让我们能更轻松的在端侧应用机器学习,在手机侧,Apple 的 Core ML,Google 的 NNAPI 提供了系统级别的支持,除此之外业内也有很多优秀的端侧框架:TensorFlow Mobile/Lite,Caffe2,NCNN,TNN,MACE,Paddle&Paddle Lite,MNN 及 Tengine 等;

 

算法:模型压缩技术不断发展,其中量化已经非常成熟,基本能够实现在不降低精度的情况下将模型缩小为原来的 1/4~1/3;此外,针对端侧的算法模型在不断的优化过后,架构设计变得越来越成熟,对于端侧设备的兼容性也愈加友好。

 

驱动云智能和端智能发展的根本来源于实际的产品需求。从端智能的角度来看,由需求驱动的 AI 场景应用已经在软硬件多方面成为产品的主要卖点。比如手机摄像能力的提升,除了摄像头等硬件的发展外,各种摄像算法的发展也功不可没;再像抖音/快手等应用的各种模型特效,在简化创作的同时也极大提高了产品的形态。

 

为什幺要做端智能?

 

要知道为什幺做端智能其实本质就是需要搞清楚,当前云智能面临什幺样的问题。正如之前所说,云智能的发展建立现代需求之上,它主要的优势是:

 

面向海量数据,这意味我们能通过不断的累积数据,寻求问题的最优解;

 

设备资源充足,算力强大;

 

算法规模庞大,空间不受限制。

 

但这种依赖云端的架构方式也有着相应的缺陷:

 

响应速度: 依赖于网络传输,稳定性和响应速度无法得到保障,对于实时性要求高的情况而言,该问题近乎于无解;

 

非实时性,脱离及时 Context,用户敏感度差。

 

而端智能的优势恰好能作为云智能劣势的补充:

 

响应速度快:在端侧直接获取数据进行处理,不依赖网络传输,稳定性和响应度 OK;

 

实时性高:端侧设备实时触达用户,不存在中间商赚差价,能够实时感应用户状态。

 

除此之外,由于数据和生产和消费都是在端侧完成,对于敏感数据可以保证隐私性,规避法律风险;另外我们可以进行更精细化策略,有可能实现真正的实现千人千面。

 

端智能的局限

 

前文我们说了端侧智能能够补充云智能的几个缺点,但它也有着自己的问题:

 

 

和云侧硬件设备相比,端侧资源&算力相对有限,无法进行大规模持续计算,模型不宜过于复杂;

 

端侧往往只是单用户数据,数据规模小,全局最优解难寻。此外由于端侧应用生命周期不可控,数据周期往往较短。

 

 

在这两个条件的制约下,端智能往往意味着是只做推理,即云端训练模型下发到本地后做推理。

当然随着技术的演进,现在我们也开始探索 ,它本质上是一种分布式机器学习技术,主要希望在保证数据隐私安全及合法合规的情况下,可以有效解决数据孤岛问题,让参与方在不共享数据基础上实现联合建模,提升模型的效果。在这里,端上能做的就不仅仅是推理了还有学习过程。

 

5G 与端智能

 

之前有同学提到过既然 5G 又快又好,那完全没必要搞端智能啊。这里简单谈谈我自己的理解。(如有不对之处,请找隔壁小哥)

 

5G 的高速连接和超低时延,目的在于帮助规模化实现分布式智能,也就是云-端智能一体化。具体解释下:5G 给端和云之间的连接提供了更稳定,更无缝的的支撑,此时网络就不再是端云互通的瓶颈了,伴随万物互联的到来,数据规模将会进一步暴增,进入超大数据规模的时代,此时服务端的算力就会成为瓶颈,那幺此时在端侧对于处于数据的预处理和理解也就更加重要,这就需要端智能的介入。

 

举个安防领域的例子,现在很多家庭摄像头都支持云存储,如果我们希望只有在有人活动的时候才会将视频保存到云端,该怎幺做呢?最好的方式是先在端侧借助 AI 进行图像识别,然后将包含人的视频片段上传到云端,而不是先将所有视频上传到云端再进行图像处理,裁剪掉无用的视频片段,前者既可以节省流量带宽,又可以节省端侧算力,这里在端侧对视频的处理也就是我们刚才说的对数据的预处理和理解。

对于 AR 来说,端智能为 AR 提供交互能力,5G 则能满足 AR 需要的网络传输能力,在这两者的加持下,具备互动性,高品质的 AR 技术可能会实现真实世界与虚拟环境的融合。

西瓜为什幺做端智能?

 

上述内容纯粹就是简单介绍下端智能的前世今生,口水内容,简单看一分钟也就行。光说不练假把式,下面就简单介绍下西瓜在端智能上的探索及落地,很多同学知道我们在搞,但不知道搞了个啥,今天咱就揭开这道神秘的面纱。首先来看我们西瓜为啥要做端智能。

 

在后文展开之前必须得先回答一个问题:西瓜为什幺要做端智能?或者说,西瓜对于端智能的定位是如何的?

 

西瓜视频作为一款服务于广大中长视频消费用户的产品,为了满足不同细分群体的需求必然要进行更精细化的产品运营策略,但之前我们的的策略往往局限于服务端策略或者实验场景下得出的策略池,整个过程中客户端更多的作为策略的接受者,被动响应且实时性不够;

 

随着西瓜视频品质化专项的不断推进,在很多场景下也取得了显着的收益,伴随而来问题就是简单易行的策略已经不再能满足我们的胃口,要想再取得收益需要更细致灵活的策略手段。

 

西瓜视频一直在致力于为用户提供更优价值的内容,而播放作为西瓜核心功能,致力于为用户打造更加智能化的播放器,创造更好的视听环境,这无疑对我们客户端播放策略上提出了更高的要求。

 

对于视频类产品而言,带宽成本不容小视,我们希望在不影响播放体验的同时,能尽量的减少无用带宽的浪费。

 

介于上述几个因素,我们在用传统客户端技术解决问题的同时也对端侧 AI 能力有了兴趣,并于 20 年 8 月份开始调研,最终我们确立下两大目标:策略精细化和开源节流。

在这两个目标的指导下,进一步结合西瓜的需求,我们主要聚焦在下述两个领域:

 

业务领域:充分发掘相关消费侧(播放器)和创作侧可优化决策点,降低业务成本,打造更智能化的决策体系;个别场景借助端侧 AI 能力打造更好的产品功能;

 

技术领域:尝试端侧 AI 能力和稳定性/编译优化结合,自动分析并追踪相关异常链;尝试建立端侧特征库,实现热点功能/插件调度决策。

 

西瓜端智能

 

关于西瓜为什幺下手端智能,大概是说明白了。但总体该怎幺下手落地呢?从表面上看无非就是将原有服务端的体系搬到客户端来做,变化的只是前后端而已,但实际上从云到端的迁移,不但涉及端云技术链路的变化,而且更加强调不同领域工程师的合作:从客户端角度出发,我们关注工程架构及交互,但从算法角度来看,更加关注的数据和模型,这两者关注点的不同就决定了在端智能落地过程会存在比较大的困难。

 

基本流程

 

首先来简单了解下端智能从云到端的几个阶段:从云到端,主要涉及算法涉及&模型训练,模型优化,模型部署以及端侧推理预测。按照参与方来看主要涉及算法工程师和客户端工程师,按照环境则可以分为云端工程和客户端工程,如下所示:

首先算法工程师针对特定场景设计算法并训练模型,然后对该模型进行优化,降低模型体积的同时提高算法&模型执行效率,接下来在模型部署阶段将优化过的模型转换为端侧推理引擎支持的格式并部署到移动设备上,客户端工程师针对该场景做算法移植及业务改造,并在合适的时机通过推理引擎加载模型并执行推理预测。

 

三座大山

 

上述我们用一句话概括端智能落地的流程,但实际过程中要远比上图提到的更复杂:

如上图所示,不难发现端智能落地链路总体比较长,任何一个节点出现问题都会涉及比较长的排查路线;需要算法工程师和客户端工程师的高度协作,但由于算法和客户端两侧的技术栈差异比较大,知识领域也存在比较大的差异,因此协作成本其实蛮大:

 

客户端工程师对机器学习的算法和原理相对较少,这就意味着在很多时候客户端把这块当做黑盒,无法针对端侧设备的情况和业务逻辑给出一定的参考意见,也无法有效发现模型推理异常问题,对总体的运行结果不可预期;而如果涉及到算法移植这块,问题就更多了,鸡同鸭讲的情况也不是不存在;

 

算法工程师缺少对端侧设备的了解,端侧设备环境不如服务端环境单一,设备环境复杂度,如何针对端上设计出更高效的模型,避免侧推理影响到端侧性能指标是重中之重;算法移植到端侧是否符合预期也有待考量。

 

除此之外,端侧推理引擎如何兼容复杂的端侧设备,保证高可用性,实现一体化监控和模型部署等等也是端智能在落地过程要重点解决的问题。

端云一体部署

 

前文我们提到端智能在落地过程中的三个问题:链路长,协作成本高,推理部署复杂。来具体分析看下问题及相应的解决策略:

 

对于算法设计到模型训练这块,公司内的 MLX 平台提供了模型训练到服务端部署的能力,但并不支持云上模型训练到部署端上的链路,因此我们需要将端上和 MLX 平台进行打通能够实现模型部署及模型格式转换;

 

传统上端智能在端侧依赖算法和模型两部分数据,之前算法需要在云测设计完成后移植到端侧,存在一定的移植成本,且缺乏动态更新的能力;同时算法和模型数据分离属于分离状态,在算法和模型多次迭代后,版本管理相对复杂,兼容性难以保障,如果算法和模型数据能够绑定动态下发,在减少协作成本的同时也可以简化链路;

 

端侧环境复杂(尤其是 Android 设备,各种配置不一,硬件环境也更为复杂), 推理引擎至关重要。在开始落地之前,我们调研了 TensorFlow Lite,TNN,MNN 及 Paddle-Lite 以及公司内部的 ByteNN,最终我们选择 ByteNN。

 

为什幺是 ByteNN?

 

1.ByteNN 作为抖音/TikTok 的统一 AI 基础引擎库,已经在很多产品接入了,不需要额外增加体积;2.针对 处理,Adreno/Mali GPU,Apple GPU 进行定向性能调优,支持多核并行加速,性能 OK;3.终端兼容性广,覆盖了全部 Android 设备及 iOS,可用性较高;4.支持 GPU,GPU,NPU,DSP 等处理器,有厂商加持,通用性不成问题。

 

阻碍在面前的三座大山已然明了,要多的事情也很清晰,但我们并没有重新造轮子,而是直接直接复用平台团队整合的 Pitaya ,这样我们可以将更多的精力放在算法设计和业务场景挖掘中。

 

Pitaya 提供了移动平台端动态执行算法模型的整套方案,从端上数据采集到特征工程,再到端上算法模型运行环境动态化部署和监控。

 

简单来说,Pitaya 是将云上 MLX 环境和端侧环境打通,并将算法和模型统一以算法包的形式部署到端上,并对端侧特征工程予以支持,同时端侧内部集成 PythonVM 作为执行环境,并驱动特征驱动推理引擎(ByteDT/ByteNN),其基本架构如下:

关于 Pitaya 在此就不多说了,有兴趣的同学可以进一步了解下: 轻松玩转移动AI,一键集成的端智能框架Pitaya

 

现在我们可以更聚焦于业务场景的算法设计了,整体链路变得简化了不少,同时借助于 PythonVM 的执行方案,可以实现算法包的动态部署,提高整体的迭代效率,端云之间的联动性更强:

西瓜视频智能预加载

 

西瓜视频横屏内流在交互上可以理解为是一个横屏版的抖音,其渗透目前占据 33%左右,作为西瓜视频的核心场景,其播放体验直观重要。为了实现较好的视频起播效果,该场景上了视频预加载策略:在当前视频起播后,预加载当前视频后的 3 个视频,每个 800K。

 

为什幺是 800K 呢?800K 是播放器的同学通过实验得出值,旨在在不影响卡顿的情况下尽可能的降低成本,正如我们所摄像预加载显着提高播放体验,但同时也带来成本上的提升+12.7%。

 

对于 800K 大家可能没有直观感受,假设以 720P 视频为例,平均码率是 1.725Mbps,那幺 800K 的视频大小也就是 4 秒左右。

 

方便起见,我们通过一个图来展示 3*800 的流程:

不难发现,只有在首个视频的情况下才会一次性预加载三个视频,再往后就变成了增量预加载 1 个视频的操作,端上始终保留 3 个视频的预加载。

 

为什幺是端智能的方案?

 

上述方案足够粗暴简单,但却存在不少局限,比如带宽和播放体验平衡不够:

 

比如某些情况下用户不会看完 800K 的缓存视频,简单浏览标题或前几秒内容后就划到下一个,造成带宽浪费;

 

或者当用户想要认真观看视频时,有可能因为没有足够的缓存,容易导致起播失败或者卡顿,进而影响用户体验。

 

另外在上线预加载方案的时候,数据分析师也提到:

 

减少预加载大小虽然可以降低成本,但是卡顿劣化严重,短期采用 3*800K 的固定方案,长期推动动态调整预加载大小方案上线。

 

除了传统对预加载任务管理机制的优化外,我们开始重新思考如何衡量预加载的有效任务率?

 

最理想的情况下预加载的大小和播放时加载的大小一致,这样视频预加载的效率就是 100%;如果我们预加载了 1000K,但用户只看了 500K,那预加载的效率就是 50%,这浪费的 500K 可都是金灿灿的 :moneybag:;最糟糕的情况是我们预加载 1000K,但用户压根没看,不好意思,此时预加载的效率就是鸭蛋了,我们白白浪费了大把的钞票。现在我们来具体定义下用来评估预加载效率的公式:

通过上述公式不难发现,最理想的预加载策略就是使预加载大小和播放大小尽量的匹配,用户在起播阶段会看多少,我们就预加载多少,这样既能提高播放体验,又能减少带宽浪费。

 

那如何来做呢?我们希望基于端侧 AI 的能力,对用户操作行为进行实时分析,进而实现调整预加载策略,在保证用户播放体验的同时,避免带宽浪费。

 

优化方案

 

如上述公式所示,提高视频预加载效率的关键就是预测用户播放时长,使视频预加载的大小和视频播放大小尽可能的接近。但预估每个视频用户会看多久是一件很难的事情,会有很多个因素,比如用户对视频的感兴趣程度,心理状态等等。

 

抛开这些复杂的因素和变量,我们来重新思考:视频预加载的行为和和用户的浏览行为存在相关性。我们假设存在两种典型行为的用户:

 

快速滑动,短暂浏览: 用户处于蜻蜓点水状态,后续每个视频只会简单瞄一眼,主动切换视频的频率较高;

 

慢速滑动,仔细观看: 用户倾向于观看每个视频,主动切换视频的频率较低。

 

如果我们在端上能够根据用户的浏览行为,通过模型判断出用户在接下来的浏览中是倾向于那种行为的话,那是不是可帮助我们进一步来优化视频预加载策略了呢?此时预加载的流程就变成了如下所示:

除了通过端智能的方案提高预加载的效率,实现更精准的预加载调度外,在端上也有配套的业务调整和优化方案,比如聚合推理参数,模型触发时机调整,预加载任务管理完善等手段,两者互为补充。其中涉及到端智能的流程如下所示:

特征工程

 

我们通过线上用户埋点数据,提取横屏内流相关埋点数据进行标记并进行相关性分析,多次迭代后最终筛选出与用户浏览行为的相关特征。此外,借助 Pitaya 端上特征的能力,可以方便的从头不同的数据获取实时特征,并将其转化成模型输入的数据。

 

算法选型

 

机器学习的算法很多,从传统的的决策树,随机森林到深度神经网络,都可以用来支持端侧 AI 的能力。但需要根据由于端侧设备的情况,在能满足场景效果和需求的前提下,需要重点考虑模型的体积和性能:模型体积越小越小越好,性能越高越好。比如在该场景下,用 DT 和 NN 都可以对用户模式进行分类,但要综合评估模型体积,性能和效果,最后决定采用那种算法。

 

推理预测

 

首先来看决策的时机,每滑到一个视频并且在该视频(非首刷视频)起播后触发算法包,等待决策结果并调度后续预加载任务:

在触发推理时,主要依赖两部分数据:一种是已经观看过视频的数据,另外则是后续未观看视频的详情数据。前者是 Pitaya 主动通过 AppLog 获取的,后者则是需要业务方主动透传。同时端上需要考虑容错措施,在算法包异常和推理失败的情况及时回滚策略。

 

预加载任务调度

 

推理决策给出后,我们会根据最近两次推理结果进行调度:预加载任务数量的调整(保留有效任务)及每个预加载视频大小的调整(增量调整)。

 

端侧性能监控

 

除了端侧常规的监控外(性能&业务指标),还涉及模型指标的监控,比如执行成功率,耗时,PV/UV,当然也包括 accuracy 等模型的效果指标。

 

 

问题&挑战

 

西瓜从去年 12 月份开始落地该场景,到明确拿到收益并全量上线,最终大概历 1.5 个双月,加上春节假期得有 2 个双月了,这是为啥呢?从开始的实验大规模负向到正向收益,我们遇到了那些问题?

 

推理耗时

 

前期多次实验中(v1。0~v3。0)我们发现智能预加载组比线上策略在首帧耗时等指标上有劣化,比如首帧耗时上升 2ms 等。后来我们发现除原有业务缺陷外,端上聚合推理参数及推理耗时等因素也间接影响到了大盘指标。

 

最终我们通过端上定向的优化手段,比如步长推理/异步调度/首推预热/模型优化等方案,打平了相关指标。

 

带宽成本

 

带宽成本核算受多个因素影响,容易存在偏差,在播放器及视频架构团队多位同学的支援下,最终明确智能预加载实验组的 95 分位带宽成本比线上组平均降低 1.11%。

峰值模型

 

很多情况下,用户的习惯是呈现阶段性,为了我们也定向提出峰值模型,用于在用户使用的高/低峰时间段内做出更细致化的决策。

 

实验收益

 

通过一系列的周期实验和策略,最终明确了智能预加载的收益:

 

总带宽 -1.11%,预加载带宽 -10%;

 

中视频播放失败率 -3.372%,未起播失败率 -3.892%,卡顿率 -2.031%,百秒卡顿次数 -1.536%,卡顿渗透率 -0.541%。

 

当前智能预加载在 Android 端已经全量上线,同时 iOS 端也在逐步接入过程中。除此之前,我们也正在主 Feed 场景下上线智能预加载策略。

 

现状&总结

 

西瓜端智能现状

 

对于西瓜视频而言,智能预加载只是个起点,我们也在众多场景下探索端智能的落地,打造更智能化的播放体验。

 

无论是云智能还是端智能,最终带给我们的是解决问题的新思路,坦率的说我也不知道端智能对未来意味着什幺,但当下确定的是我们可以更好的将它和业务场景结合在一起,寻求更好业务成果。

 

端智能也不是银弹:不是说我们用了它就完事大吉,就一定可以拿到很好的结果。要想真正的发挥业务价值,更好的服务用户,需要我们更多的思考问题现状及端智能的适用场景,同时需要端侧研发重点关注相关性能&业务指标。以西瓜智能预加载的场景为例,端智能给出的策略处理了 60%的问题,而剩下的 40%仍然是需要端侧来做优化和调整,两者缺一不可。

 

新思路,新尝试

 

对于很多客户端工程师而言,可能会存在疑问,我们应该如何面对端智能,或者说它和我们之前解决问题的方式有什幺不同?端智能不是一个从 0 到 1 的新生物,它只是云智能发展到现在的自然延伸而已,其背后的体系还是机器学习那一套,对于客户端而言,它提供了一种全新的技术思维方式:从规则驱动到数据驱动,再到模型。我们可以借助它在适当的业务场景寻求结合点,最终获得更好的成果。

 

那对于客户端工程师而言,该如何切到这个领域呢,或者说如果我们想了解端智能可以做点什幺?

 

了解基础

 

正如我们上面很多次提到的一样,端智能只是云智能发展的自然延伸,其背后仍然基本的机器学习,对于大多数的客户端工程师而言,我们的目标不是成为机器学习领域的专家,可以不去深入研究各种算法模型,但系统的学习下理论只是还是很有必要的:

 

了解人工智能发展的过程,知道为什幺当前深度学习成为主流方向;

 

学习曾经流行的一些经典算法及能够解决的问题领域,你会发现之前一些问题的思考方式在当前深度学习中仍然是贯通的;

 

了解常见的神经网络架构,知道不同网络层(比如 CNN 中的卷积层/池化层等)的作用,整体又是怎幺组织起来的。

 

模型移植与实践

 

系统性的知识基本上可以通过阅读该领域中的经典书籍而获得。除此之外还要多动动手,我们可以先找几个示例,一步一步把训练好的模型通过量化处理后移植到客户端上去跑跑,也可以尝试在开源项目的基础上去修改算法&模型,比如尝试手写数字识别,进行人脸检测,当然也可以尝试下量化交易,用自己的做的模型预测股票价格(当然,赔了别找我 :grin:)。

 

性能优化

 

端侧设备,尤其以手机为例更注重交互,且受硬件限制较多,比如电量,存储空间,算力等,这就意味着我们的算法模型必须要具有很高的执行效率,同时模型体积不能过大,对应而来的就是性能优化在端智能领域同样非常重要。

 

对于大部分客户端工程师而言,除了传统的基于业务场景的优化方案之外,还主要涉及到推理优化和部署,在该过程中不但需要基于语言的优化,还可能会根据硬件情况进行优化,比如 Neon/SSE/AVX 指令集优化,高通(Qualcomm GSP/GPU)及华为(Huawei NPU)等硬件加速技术(当前这部分主要是你搞推荐推理引擎的时候才会遇到,有兴趣的可以去研究下)。

 

拥抱 AIOT

 

无论是边缘计算还是端智能,其载体不仅仅是手机,还包含各种各样的嵌入式设备。比如像安防领域的指纹锁,监控摄像头,无人机等等。对于我们而言,可以拿来练手的设备也很多,比如树莓派,搭载 TPU 芯片 Coral 开发版以及英特尔 ®Movidius™ 神经计算棒等等,利用他们可以做出很多好玩的东西。

Be First to Comment

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注