视觉感知未来,高德数据采集模型部署实践

简介: 作为DAU过亿的国民出行服务平台,高德地图每天为用户提供海量的检索、定位和导航服务,实现这些服务需要有精准的道路信息,比如电子眼位置、路况信息、交通标识位置信息等。读者是否会好奇,高德是如何感知到现实世界的道路信息,并提供这些数据给用户呢?

作为DAU过亿的国民出行服务平台,高德地图每天为用户提供海量的检索、定位和导航服务,实现这些服务需要有精准的道路信息,比如电子眼位置、路况信息、交通标识位置信息等。读者是否会好奇,高德是如何感知到现实世界的道路信息,并提供这些数据给用户呢?


事实上,我们有很多的方法将现实世界的道路要素采集回收,并更新到高德地图App上。其中一种非常重要的方法是利用计算机视觉的手段,将视觉算法部署到客户端,通过对图片的检测识别,快速将道路的信息回收。


为了低成本,高实时性地实现道路要素回收,我们借助MNN引擎(一个轻量级的深度神经网络推理引擎),将卷积神经网络模型部署到客户端,在客户端进行端侧的模型推理,从而完成在计算能力低,内存小的客户端进行道路要素采集的任务。


传统的CNN(卷积神经网络)计算量非常大,且业务场景需要部署多个模型。如何在低性能的设备上部署多个模型,并在不影响实时性的情况下保证应用的"小而优"是一个非常大的挑战。本文将分享利用MNN引擎在低性能设备上部署深度学习应用的实战经验。


2. 部署

2.1 背景介绍

如Figure2.1.1所示,业务背景是将道路要素识别相关的CNN模型部署到客户端,在端侧进行模型推理,并提取道路要素的位置和矢量等信息。


由于该业务场景的需要,目前端上需同时部署10+甚至更多的模型,以满足更多的不同道路要素的信息提取需要,对于低性能设备来说是非常大的挑战。


image.png

Figure 2.1.1 高德数据采集


为了达到应用的"小而优",MNN引擎部署模型的过程中遇到了很多问题和挑战。下面就这些问题和挑战分享一些经验和解决办法。


2.2 MNN部署

2.2.1 内存占用

应用运行内存对于开发者来说是始终绕不开的话题,而模型推理产生的内存在应用运行内存中占有很大的比例。因此,为了使模型推理内存尽可能小,在模型部署的过程中,作为开发者必须清楚模型运行产生内存的主要来源。根据我们的部署经验,部署单模型的过程中,内存主要来源于以下四个方面:


image.png

Figure 2.2.1 单模型部署内存占用


ModelBuffer: 模型反序列化的buffer,主要存储模型文件中的参数和模型信息,其大小和模型文件大小接近。


FeatureMaps: Featuremaps的内存,主要存储模型推理过程中,每一层的输入和输出。


ModelParams: 模型参数的内存,主要存储模型推理所需的Weights, Bias, Op等内存。其中Weights占用了该部分的大部分内存。


Heap/Stack: 应用运行中产生的堆栈内存。


2.2.2 内存优化

知晓模型运行内存占用后,就能方便理解模型运行时的内存变化。经过多个模型部署实践, 为了降低部署模型的内存峰值,我们采取的措施如下:


  • 模型反序列化(createFromFile)并创建内存(createSession)后,将模型Buffer释放(releaseModel), 避免内存累加。

  • 处理模型输入,图像内存和inputTensor可内存复用。

  • 模型后处理,模型输出Tensor和输出数据的内存复用。
    image.png

image.gif                          Figure 2.2.2.1 MNN模型部署内存复用方案


经过内存复用,以部署1个2.4M的视觉模型为例,模型运行时从加载到释放,中间各阶段所占用内存变化可以用以下曲线表示:

image.png

image.gif

Figure 2.2.2.2 单模型应用内存曲线(Android memoryinfo统计)


  • 模型运行前,模型占用内存为0M

  • 在模型加载(createFromFile)和创建内存(createSession)后,内存升到5.24M, 来源于模型反序列化和Featuremaps内存创建。

  • 调用releaseModel内存降低至3.09M,原因是释放了模型反序列化后的buffer。

  • InputTensor和图像内存复用,应用内存增加到4.25M, 原因是创建了存储模型输入的Tensor内存。

  • RunSession(),应用内存增加到5.76M,原因是增加了RunSession过程中的堆栈内存。

  • 在模型释放后,应用恢复到了模型加载前的内存值。


经过多次模型部署的实践,下面总结了部署单模型到端的内存峰值预估公式:


image.png


MemoryPeak:模型运行时内存峰值。


StaticMemory:态内存,包括模型Weights, Bias, Op所占内存。


DynamicMemory:态内存,包括Feature-maps所占内存。


ModelSize:模型文件大小。模型反序列化所占内存


MemoryHS:运行时堆栈内存(经验取值0.5M-2M之间)。


2.2.3 模型推理原理

本章节分享模型推理原理,以便于开发者遇到相关问题时,快速定位和解决问题。


模型推理前模型的调度: MNN引擎推理保持了高度的灵活度。即可以指定模型不同的运行路径,也可以对不同的运行路径指定不同的后端,以提高异构系统的并行性。此过程主要是调度或者任务分发的过程。


对于分支网络,可以指定当前运行分支,也可以调度分支执行不同后端,提高模型部署的性能。Figure2.2.3.1所示为一个多分支模型, 两个分支分别输出检测结果和分割结果。


image.png

Figure 2.2.3.1 多分支网络


部署时可做如下优化 :

  • 指定模型运行的Path。当仅需检测结果时,只跑检测分支,无需跑完两个分支, 减小模型推理时间。

  • 检测和分割指定用不同的后端。比如检测指定CPU, 分割指定OpenGL,提高模型并行性。


模型推理前的预处理: 本阶段会根据上一步的模型调度信息进行预处理,本质是利用模型信息和用户输入配置信息,进行Session(持有模型推理数据)的创建。


image.png

Figure 2.2.3.2 根据Schedule创建Session


本阶段根据模型反序列化的模型信息和用户调度配置信息来进行运算调度。用于创建运行的Piplines和对应的计算后端。如Figure2.2.3.3所示。


image.png

Figure 2.2.3.3 Session创建


模型的推理: 模型推理本质是根据上一步创建的Session,依次执行算子的过程。运算会根据预处理指定的模型路径和指定后端进行模型每层的运算。值得一提的是,算子在指定的后端不支持时,会默认恢复到备用后端执行计算。


image.png

Figure 2.2.3.4 模型推理计算图


2.2.4 模型部署时间

本部分统计了单模型部署过程各阶段耗时,方便开发者了解各阶段的耗时,以便更好的设计代码架构。(不同设备有性能差异,耗时数据仅供参考)

image.gifimage.png

Figure 2.2.4.1 模型推理计算图


模型反序列化和Session创建相对耗时较长,进行多张图的推理时,尽量执行一次。


2.2.5 模型误差分析

模型部署时,开发者难免会遇到部署端和X86端(Pytorch, Caffe, Tensorflow)训练模型输出结果有偏差的情况。下面分享误差原因, 定位思路以及解决办法。


模型Inference示意图如Figure 2.2.5.1所示:


image.gifimage.png

Figure 2.2.5.1 模型Inference示意图


模型误差的确定: 查看是否有模型误差最直观的方法是,固定部署端模型和X86端模型的输入值,分别推理,对比部署端模型和X86端模型输出值,可确认是否有误差。


模型误差的定位: 当确定有模型误差时,先排除因模型输入误差导致的模型输出误差。因为X86端和部分Arm设备浮点的表示精度不一致,输入误差在某些模型中会被累积,最终造成较大的输出误差。用什么方法来排除是输入误差导致的问题呢?我们提供一种方法是将模型输入设置为0.46875(原因是该值在X86设备和部分Arm设备表示一致,本质是1经过移位获得的浮点数在两种端上表示均一致)。然后观察输出是否一致即可。


模型误差的定位思路: 在排除模型输入误差导致模型输出误差(即模型输入一致时,模型输出不一致)的情况下,很可能是模型某些算子导致的误差了。如何定位模型哪个OP导致的误差呢?通过下述的步骤可以定位模型内部引起误差的原因:


1)通过runSessionWithCallBack来回调模型每个OP的中间计算结果。目的是定位模型从哪个Op开始出现误差。


2)定位到该层之后,即可定位到产生误差的算子。


3)定位到算子后,通过指定的后端信息即可定位到对应的算子执行代码。


4)定位到对应的执行代码后,调试定位产生误差的代码行,从而定位到产生模型误差的根本原因。


3. 总结

MNN引擎是一个非常好的端侧推理引擎,作为开发者来说,模型的端上部署和性能优化在关注业务逻辑优化的同时,也需关注对引擎计算过程,框架设计和模型加速的思想,反过来可以更好的优化业务代码,做出真正"小而优"的应用。


4. 未来规划

随着设备性能的普遍提升,后续的业务会搭载到性能更高的设备,我们会利用更丰富的计算后端做模型的加速,比如OpenCL, OpenGL等, 从而加速模型的推理。


未来设备会搭载更多的模型到客户端,用于实现更多品类道路要素信息的回收,我们也会利用MNN引擎,探究更高效,更高实时性的代码部署框架,以更好的服务于地图采集业务。


我们是高德地图数据研发团队,团队中有大量HC,欢迎对Java后端、平台架构、算法端上工程化(C++)、前端开发感兴趣的小伙伴加入,请发送您的简历到 gdtech@alibaba-inc.com ,邮件标题格式: 姓名-技术方向-来自高德技术。我们求贤若渴,期待您的加入。



电子书免费下载

《高德技术2020年刊合辑》




高德技术重磅发布《高德技术2020年刊合辑》电子书,覆盖了大前端、算法、架构、汽车工程、质量等多个领域,以及数篇高德入选顶会论文的解读,分享高德在智慧出行上的最佳技术实践和总结。

相关文章
|
6月前
|
存储 机器学习/深度学习 人工智能
阿里云视觉智能开放平台确实拥有视频目标检测的能力
【2月更文挑战第9天】阿里云视觉智能开放平台确实拥有视频目标检测的能力
146 7
|
1天前
|
人工智能 知识图谱
轻松搭建AI版“谁是卧底”游戏,muAgent框架让知识图谱秒变编排引擎,支持复杂推理+在线协同
蚂蚁集团推出muAgent,兼容现有市面各类Agent框架,同时可实现复杂推理、在线协同、人工交互、知识即用四大核心差异技术功能。
11 2
|
5月前
|
文字识别 算法 数据挖掘
视觉智能开放平台产品使用合集之对于统计研究和数据分析,有哪些比较好的工具推荐
视觉智能开放平台是指提供一系列基于视觉识别技术的API和服务的平台,这些服务通常包括图像识别、人脸识别、物体检测、文字识别、场景理解等。企业或开发者可以通过调用这些API,快速将视觉智能功能集成到自己的应用或服务中,而无需从零开始研发相关算法和技术。以下是一些常见的视觉智能开放平台产品及其应用场景的概览。
|
3月前
|
人工智能 自然语言处理 搜索推荐
声临其境!体验阿里云开源音频基座大模型——FunAudioLLM
阿里通义实验室开源了全新的音频基座大模型FunAudioLLM,包含SenseVoice与CosyVoice两大核心模型。SenseVoice专精于多语言语音识别、情感辨识与声音事件检测,支持50余种语言,中文及粤语识别准确率提升50%以上。CosyVoice则擅长语音合成,只需3-10秒原始音频即可克隆音色,并支持跨语言合成。FunAudioLLM的应用场景广泛,包括语音到语音翻译、情感语音对话、互动播客及有声读物等。CosyVoice的在线体验显示,其生成的语音自然流畅,支持定制化及高级情绪控制,超越竞品ChatTTS。SenseVoice在情感识别及长音频处理方面表现出色。
21893 26
|
5月前
|
文字识别 API 开发工具
视觉智能开放平台产品使用合集之模板视频人脸融合的耗时大概是多久
视觉智能开放平台是指提供一系列基于视觉识别技术的API和服务的平台,这些服务通常包括图像识别、人脸识别、物体检测、文字识别、场景理解等。企业或开发者可以通过调用这些API,快速将视觉智能功能集成到自己的应用或服务中,而无需从零开始研发相关算法和技术。以下是一些常见的视觉智能开放平台产品及其应用场景的概览。
|
6月前
|
机器学习/深度学习 API 计算机视觉
阿里云视觉智能平台的自学习服务
【2月更文挑战第2天】阿里云视觉智能平台的自学习服务
69 10
|
算法
视觉智能平台在图片识别方面有一定的能力
视觉智能平台在图片识别方面有一定的能力
59 1
|
人工智能 城市大脑 API
基于阿里云视觉智能开放平台的动漫化视频产出方案
阿里云视觉智能开放平台的现有API能力,做出一个批量化生成动漫化视频的方案。
869 2
基于阿里云视觉智能开放平台的动漫化视频产出方案
|
监控
构建三维一体立体化监控,看这一篇就够了!
如果你需要搭建一套能够立体化监控你的应用及业务,出现问题及时告警的监控体系,这篇文章应该是你所需要的!
556 0
构建三维一体立体化监控,看这一篇就够了!
|
传感器 机器学习/深度学习 人工智能
[OpenVI-视觉生产系列之视频稳像实战篇]再见吧云台,使用AI“魔法”让视频稳定起来
随着自媒体与短视频的兴起,人们有了越来越多的拍摄视频的需求。然而由于手持拍摄、硬件限制等原因,利用手机等普通摄影设备拍摄的视频难免存在视频抖动问题。尤其是开启较高倍数的变焦后,手持拍摄很难拍摄到稳定的视频,极易产生抖动的现象。使用云台、斯坦尼康等外设可以缓解这样的抖动,但是很多时候多带一个外设降低了拍摄视频的便利程度,会使得随时随地的拍摄体验大打折扣。
680 0
[OpenVI-视觉生产系列之视频稳像实战篇]再见吧云台,使用AI“魔法”让视频稳定起来