牛逼，一个快速集成AI的终端运行环境

今天给大家推荐一个非常不错的开源项目&＃xff0c;是来自于滴滴公司的。在这里大致给大家介绍一下&＃xff0c;希望能够对大家有所帮助。

1

背景

1.1

AoE是什么

AoE (AI on Edge) 是一个滴滴开源的终端侧AI集成运行时环境(IRE)。以 “稳定性、易用性、安全性” 为设计原则&＃xff0c;帮助开发者将不同框架的深度学习算法轻松部署到终端高效执行&＃xff0c;Github 地址是 https://github.com/didi/aoe。

为什么要做一个 AI 终端集成运行时框架&＃xff0c;原因有两个&＃xff1a;

一是随着人工智能技术快速发展&＃xff0c;这两年涌现出了许多运行在终端的推理框架&＃xff0c;在给开发者带来更多选择的同时&＃xff0c;也增加了将AI布署到终端的成本&＃xff1b;

二是通过推理框架直接接入AI的流程比较繁琐&＃xff0c;涉及到动态库接入、资源加载、前处理、后处理、资源释放、模型升级&＃xff0c;以及如何保障稳定性等问题。

目前AoE SDK已经在滴滴银行卡OCR上应用使用&＃xff0c;想更加清晰地理解 AoE 和推理框架、宿主 App 的关系&＃xff0c;可以通过下面的业务集成示意图来了解它。

1.2

终端推理框架一览

下面是终端运行的8种主流推理框架&＃xff08;排名不分先后&＃xff09;。

1.3

AoE 如何支持各种推理框架

从本质上来说&＃xff0c;无论是什么推理框架&＃xff0c;都必然包含下面 5 个处理过程&＃xff0c;对这些推理过程进行抽象&＃xff0c;是 AoE 支持各种推理框架的基础。

目前&＃xff0c;AoE 实现了两种推理框架 NCNN 和 TensorFlow Lite 的支持&＃xff0c;以这两种推理框架为例&＃xff0c;说明一下 5 个推理过程在各自推理框架里的形式。

1.4

AoE 支持哪些平台

目前&＃xff0c;AoE 已经开源的运行时环境 SDK 包括 Android 和 iOS 平台&＃xff0c;此外 Linux 平台运行时环境 SDK 正在紧锣密鼓地开发中&＃xff0c;预计在9月底也会和大家正式见面。

2

工作原理

2.1

抽象推理框架的处理过程

前面已经介绍了&＃xff0c;不同推理框架包含着共性的过程&＃xff0c;它们分别是初使化、前处理、执行推理、后处理、释放资源。对 AoE 集成运行环境来说&＃xff0c;最基本的便是抽象推理操作&＃xff0c;通过 依赖倒置 的设计&＃xff0c;使得业务只依赖AoE的上层抽象&＃xff0c;而不用关心具体推理框架的接入实现。这种设计带来的最大的好处是开发者随时可以添加新的推理框架&＃xff0c;而不用修改框架实现&＃xff0c;做到了业务开发和 AoE SDK 开发完全解耦。

在 AoE SDK 中这一个抽象是 InterpreterComponent&＃xff08;用来处理模型的初使化、执行推理和释放资源&＃xff09;和 Convertor&＃xff08;用来处理模型输入的前处理和模型输出的后处理&＃xff09;&＃xff0c;InterpreterComponent 具体实现如下&＃xff1a;

Convertor的具体实现如下&＃xff1a;

2.2

稳定性保障

众所周知&＃xff0c;Android平台开发的一个重要的问题是机型适配&＃xff0c;尤其是包含大量Native操作的场景&＃xff0c;机型适配的问题尤其重要&＃xff0c;一旦应用在某款机型上面崩溃&＃xff0c;造成的体验损害是巨大的。有数据表明&＃xff0c;因为性能问题&＃xff0c;移动App每天流失的活跃用户占比5%&＃xff0c;这些流失的用户&＃xff0c;6 成的用户选择了沉默&＃xff0c;不再使用应用&＃xff0c;3 成用户改投竞品&＃xff0c;剩下的用户会直接卸载应用。因此&＃xff0c;对于一个用户群庞大的移动应用来说&＃xff0c;保证任何时候App主流程的可用性是一件最基本、最重要的事。结合 AI 推理过程来看&＃xff0c;不可避免地&＃xff0c;会有大量的操作发生在 Native 过程中&＃xff0c;不仅仅是推理操作&＃xff0c;还有一些前处理和资源回收的操作也比较容易出现兼容问题。为此&＃xff0c;AoE 运行时环境 SDK 为 Android 平台上开发了独立进程的机制&＃xff0c;让 Native 操作运行在独立进程中&＃xff0c;同时保证了推理的稳定性&＃xff08;偶然性的崩溃不会影响后续的推理操作&＃xff09;和主进程的稳定性&＃xff08;主进程任何时候不会崩溃&＃xff09;。

具体实现过程主要有三个部分&＃xff1a;注册独立进程、异常重新绑定进程以及跨进程通信优化。

第一个部分&＃xff0c;注册独立进程&＃xff0c;在 Manifest 中增加一个 RemoteService 组件&＃xff0c;代码如下&＃xff1a;

第二个部分&＃xff0c;异常重新绑定独立进程&＃xff0c;在推理时&＃xff0c;如果发现 RemoteService 终止了&＃xff0c;执行 “bindService()” 方法&＃xff0c;重新启动 RemoteService。

第三个部分&＃xff0c;跨进程通信优化&＃xff0c;因为独立进程&＃xff0c;必然涉及到跨进程通信&＃xff0c;在跨进程通信里最大的问题是耗时损失&＃xff0c;这里&＃xff0c;有两个因素造成了耗时损失&＃xff1a;

• 传输耗时

• 序列化/反序列化耗时

相比较使用binder机制的传输耗时&＃xff0c;序列化/反序列化占了整个通信耗时的90%。由此可见&＃xff0c;对序列化/反序列化的优化是跨进程通信优化的重点。

对比了当下主流的序列化/反序列化工具&＃xff0c;最终AoE集成运行环境使用了kryo库进行序列化/反序列。以下是对比结果&＃xff0c;数据参考oschina的文章《各种 Java 的序列化库的性能比较测试结果》。

3

MNIST集成示例

3.1

对TensorFlowLiteInterpreter的继承

当我们要接入一个新的模型时&＃xff0c;首先要确定的是这个模型运行在哪一个推理框架上&＃xff0c;然后继承这个推理框架的InterpreterComponent实现&＃xff0c;完成具体的业务流程。MNIST是运行在TF Lite框架上的模型&＃xff0c;因此&＃xff0c;我们实现AoE的TF Lite的Interpreter抽象类&＃xff0c;将输入数据转成模型的输入&＃xff0c;再从模型的输出读取业务需要的数据。初使化、推理执行和资源回收沿用TensorFlowLiteInterpreter的默认实现。

3.2

运行时环境配置

接入MNIST的第二个步骤是配置推理框架类型和模型相关参数&＃xff0c;代码如下&＃xff1a;

3.3

推理执行

以下是MINST初使化推理框架、推理执行和资源回收的实现&＃xff1a;

4

最后

看完这个开源项目&＃xff0c;不知道大家感觉怎么样呢&＃xff1f;感兴趣的同学可以去 GitHub 上去学习和研究一下。

开源项目地址&＃xff1a;https://github.com/didi/aoe

公众号对话框&＃xff0c;回复关键字 “1024”

免费领取程序员赚钱实操教程

- 长按识别关注 -

技术&＃xff0c;职场&＃xff0c;产品&＃xff0c;思维

行业观察