越来越多的业务会用到AI相关的技术,大多数的AI模型是部署在云端使用的,毕竟服务端计算更快,管理也更容易。随着终端设备性能提升,在终端使用 AI 模型有了更大的价值,可以更好满足业务对响应实时性、数据隐私性的需求。滴滴出行的银行卡识别功能也打算部署在客户端,但是遇到的问题也不少:
针对这些问题滴滴的终端智能团队推出了AoE作为解决方案,设计之初就将多模型管理支持可能升级、多框架支持、模型加密等功能定为基础设施。
我们针对遇到的问题,主要做了3部分工作:
下面针对这三项分别进行介绍。
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):
欢迎加群聊~
原文:https://blog.51cto.com/14522787/2436804