前言越来越多的企业会用到AI相关的技术。大多数人工智能模型都部署在云端。毕竟服务器端计算速度更快，管理也更容易。随着终端设备性能的提升，人工智能模型在终端上的使用具有更大的价值，可以更好地满足业务对实时响应和数据隐私的需求。滴滴出行的银行卡识别功能也计划部署在客户端，但遇到的问题比较多：1、机型升级困难。模型在终端上的存在一般是应用软件的载体，用户可以选择是否使用该应用。软件更新，导致机型版本出现分歧。2、硬件适配问题，不同终端设备由于厂商深度定制因素，会存在一定的兼容性问题。3、不同机型运行框架不同，对客户端工程师不够友好。针对这些问题，滴滴终端智能团队推出了AoE作为解决方案。在设计之初，将多模型管理支持、可能的升级、多框架支持、模型加密等功能定义为基础设施。AoE是如何做好模型管理的？针对遇到的问题，我们主要做了三部分工作：尝试多模型覆盖测试，做好模型验证。利用运行环境的配置实现模型的加载，通过动态更新升级模型。下面分别介绍这三项。运行环境配置AoESDK将推理框架概括为五个过程，分别是初始化、预处理、执行推理、后处理和资源释放。对于AoE综合运行环境来说，最基础的就是抽象推理运算。通过依赖倒置的设计，业务只依赖于AoE的上层抽象，无需关心具体推理框架的接入实现。这种设计最大的好处是开发者可以随时添加新的推理框架，无需修改框架实现，实现业务开发和AoESDK开发完全解耦。用户只需简单描述json文件即可完成运行环境的配置，简化了用户的使用流程，更加简洁高效。简单配置如下：{"version":"1.0.0",//版本号"tag":"tag_mnist",//区分业务场景"runtime":"tensorflow",//运行时类型"source":"installed",//安装源"modelDir":"mnist",//文件夹"modelName":"mnist_cnn_keras",//模型文件名"updateURL":"https://www.didiglobal.com"//升级配置链接}模型覆盖率测试针对硬件差异的问题，我们在模型验证时尝试了多模型覆盖率测试，记录模型在不同模型上的表现，反馈给模型制作团队，帮助模型继续升级修复。部分测试产生的耗时对比数据大致如下：虽然机型不同，使用的指令也可能不同，但可以大概了解机器的性能，具体数值仅供参考.在这个过程中，开发了基准测试工具来帮助验证多个模型的覆盖率测试。未来这个工具也会开源一部分，帮助大家验证模型的可用性，建立有效的模型对比。动态更新AoE模型管理模块，根据分布方式将模型分为两种：本地模型，即应用软件自带的模型远程模型，通过策略从服务器下载匹配的模型到本地模型配置。模型之间最大的区别是本地模型不能更改，只能随应用软件一起更新，而远程模型是较新的模型，通过与本地模型的比较来更新，模型是按版本比较的.本地模型和远程模型可以共存，也可以独立存在。在最新版本的滴滴出行中，为了减小包的体积，甚至没有本地模型。所有模型都是从远端下载的。之所以将模型分为两部分，是为了保证模型的可用性和可靠性。你为什么这么说？一般本地机型都是经过长时间的测试后，随着APP作为稳定版上线。可以作为最新版本使用，也可以作为后期稳定版使用：即使发现后期下载升级的远程模型效果不理想，也可以通过以下方式停止使用远程模型灰度测试，保证模型的高可用。远程模型的存在使得业务模型具备动态更新的能力，便于产品迭代，不再依赖于客户端的发布周期。借助动态开关的写入辅助，甚至可以精确指定模型版本的加载。整体模型管理的结构如下：如何使用模型加载？模型管理器是AoE的基本组件。以iOS为例，组件在Loader目录下实现。默认支持的模型配置文件为json格式，运行环境配置部分的代码描述了mnistdemo的配置。通过继承AoEModelConfig类可以修改模型的格式配置和模型配置文件名以及远程版本的存储地址。具体使用方法可以参考squeezenet的实例。在开源版本中，AoE还为您提供了单一功能和多种功能。模型支持，以识别银行卡为例，整个过程分为两步，一是找到卡片和卡片上的数字区域，二是根据数字的图片识别卡号面积，所以整个过程需要两个模型。开源项目使用的模型配置的tag字段主要用于定义模型的功能。结合dir字段，可以定位到具体型号。写在最后，远程加载和多维灰度测试配置是帮助模型稳定安全运行的保障。虽然该模型的远程加载功能在开源版本中还未上线，但已经在日程安排中，预计9月底上线。.如果您对本项目感兴趣，如果您对终端AI运行环境有想法，如果您在使用过程中有任何疑问，我们诚邀您的加入。项目链接：https://github.com/didi/AoE
