做者:丁超git
愈来愈多的业务会用到AI相关的技术,大多数的AI模型是部署在云端使用的,毕竟服务端计算更快,管理也更容易。随着终端设备性能提高,在终端使用 AI 模型有了更大的价值,能够更好知足业务对响应实时性、数据隐私性的需求。滴滴出行的银行卡识别功能也打算部署在客户端,可是遇到的问题也很多:github
针对这些问题滴滴的终端智能团队推出了AoE做为解决方案,设计之初就将多模型管理支持可能升级、多框架支持、模型加密等功能定为基础设施。json
咱们针对遇到的问题,主要作了3部分工做:安全
下面针对这三项分别进行介绍。bash
AoE SDK将推理框架总结了5个过程,它们分别是初使化、前处理、执行推理、后处理、释放资源。对 AoE 集成运行环境来讲,最基本的即是抽象推理操做,经过 依赖倒置 的设计,使得业务只依赖AoE的上层抽象,而不用关心具体推理框架的接入实现。这种设计带来的最大的好处是开发者随时能够添加新的推理框架,而不用修改框架实现,作到了业务开发和 AoE SDK 开发彻底解耦。服务器
用户只须要简单的描述json文件便可完成对运行环境的配置,简化了用户的使用过程,更为简洁高效。框架
简单的配置以下:工具
{
"version": "1.0.0", // 版本号
"tag": "tag_mnist", // 区分业务场景
"runtime": "tensorflow", // runtime类型
"source": "installed", // 安装源
"modelDir": "mnist", // 所在文件夹
"modelName": "mnist_cnn_keras", // 模型文件名
"updateURL": "https://www.didiglobal.com" // 升级配置连接
}
复制代码
针对硬件差别的问题,咱们在作模型验证期间尝试了多机型的覆盖测试,将模型在不一样机型上的表现都记录下来反馈给模型生产团队,帮助模型不断的升级修复。性能
截取了部分测试时产生的耗时对比数据大体以下:测试
虽然模型不相同,使用指令可能不一样,可是大体也能够了解到机器的性能,具体数值仅供参考。在这个过程当中,沉淀下来了benchmark工具来帮助验证多机型的覆盖测试,未来这个工具也会是开源的一部分来帮助你们验证模型的可用性,以及创建有效的机型比较。
AoE的模型管理模块将模型按分发方式分为两种:
本地模型与远程模型最大的区别就是本地模型没法更改,只能跟随应用软件一块儿更新,而远程模型则是经过和本地模型做比较后更新的较新模型,模型与模型之间经过版本作比较。本地模型与远程模型两者能够共存,也能够单独存在,在最新版的滴滴出行中,为了减小包的大小甚至没有本地模型,全部的模型都是来自远端下载。
之因此将模型分红两部种,是为了保证模型是可用的且可靠的,为何这么说?通常本地模型都是通过长时间测试后才做为稳定版本跟随APP带到了线上,既能够做为最新版本,又能够做为后来的稳定版本:即便发现后来下载升级的远程模型效果不理想也能够经过灰度测试中止远程使用远程模型的使用,保证模型的高可用性。
远程模型的存在使业务模型拥有了动态更新的能力,方便了产品的迭代,再也不依赖客户端的发布周期。在动态开关的写协助下,甚至能够作到精确指定模型版本的加载。
总体模型管理的结构以下图:
模型管理器是AoE的一个基础组件,以iOS为例,组件实如今Loader目录下。默认支持的模型配置文件为json格式,运行环境配置化部分的代码就描述了mnist demo的配置。
模型和模型配置文件名的格式配置以及远程版本存放地址,均可以经过继承AoEModelConfig
类来作修改,具体的使用方式能够参照squeezenet的实例
在已经开源的版本中AoE还为你们提供了单功能多模型的支持,拿银行卡识别来举例,整个过程分两步,一是找到卡片以及卡片上的数字区域,二是根据数字区域的图片识别出卡号,因此整个过程须要两个模型。开源项目使用的模型配置的tag字段主要用来定义模型所属功能,结合dir字段,就能够定位到具体的模型。
经过远程加载以及多维度的灰度测试配置是的帮助模型稳定安全运行的保证,虽然模型远程加载功能尚未在开源版本上线,可是已经安排在了日程中,预计在9月低就会上线。若是您对这个项目感兴趣,若是您在终端AI运行环境方面有想法,若是您在使用时有疑问,诚挚邀请您加入咱们。
Github地址:
欢迎star~
QQ交流群(QQ群号:815254379):
欢迎加群聊~