AoE:一種快速整合AI的終端執行環境SDK

滴滴技術發表於2019-08-14

一、背景

1.1 AoE是什麼

AoE (AI on Edge) 是一個滴滴開源的終端側AI整合執行時環境(IRE)。以 “穩定性、易用性、安全性” 為設計原則,幫助開發者將不同框架的深度學習演算法輕鬆部署到終端高效執行,Github 地址是 https://github.com/didi/aoe

為什麼要做一個 AI 終端整合執行時框架,原因有兩個:

一是隨著人工智慧技術快速發展,這兩年湧現出了許多執行在終端的推理框架,在給開發者帶來更多選擇的同時,也增加了將AI佈署到終端的成本;

二是通過推理框架直接接入AI的流程比較繁瑣,涉及到動態庫接入、資源載入、前處理、後處理、資源釋放、模型升級,以及如何保障穩定性等問題。

目前AoE SDK已經在滴滴銀行卡OCR上應用使用,想更加清晰地理解 AoE 和推理框架、宿主 App 的關係,可以通過下面的業務整合示意圖來了解它。

圖片描述

1.2 終端推理框架一覽

下面是終端執行的8種主流推理框架(排名不分先後)。

圖片描述

1.3 AoE 如何支援各種推理框架

從本質上來說,無論是什麼推理框架,都必然包含下面 5 個處理過程,對這些推理過程進行抽象,是 AoE 支援各種推理框架的基礎。

目前,AoE 實現了兩種推理框架 NCNN 和 TensorFlow Lite 的支援,以這兩種推理框架為例,說明一下 5 個推理過程在各自推理框架裡的形式。

圖片描述

1.4 AoE 支援哪些平臺

目前,AoE 已經開源的執行時環境 SDK 包括 Android 和 iOS 平臺,此外 Linux 平臺執行時環境 SDK 正在緊鑼密鼓地開發中,預計在9月底也會和大家正式見面。

二、工作原理

2.1 抽象推理框架的處理過程

前面已經介紹了,不同推理框架包含著共性的過程,它們分別是初使化、前處理、執行推理、後處理、釋放資源。對 AoE 整合執行環境來說,最基本的便是抽象推理操作,通過 依賴倒置 的設計,使得業務只依賴AoE的上層抽象,而不用關心具體推理框架的接入實現。這種設計帶來的最大的好處是開發者隨時可以新增新的推理框架,而不用修改框架實現,做到了業務開發和 AoE SDK 開發完全解耦

在 AoE SDK 中這一個抽象是 InterpreterComponent(用來處理模型的初使化、執行推理和釋放資源)和 Convertor(用來處理模型輸入的前處理和模型輸出的後處理),InterpreterComponent 具體實現如下:

/**
 * 模型翻譯元件
 */
interface InterpreterComponent<TInput, TOutput> extends Component {
    /**
     * 初始化,推理框架載入模型資源
     *
     * @param context      上下文,用與服務繫結
     * @param modelOptions 模型配置列表
     * @return 推理框架載入
     */
    boolean init(@NonNull Context context, @NonNull List<AoeModelOption> modelOptions);
 
    /**
     * 執行推理操作
     *
     * @param input 業務輸入資料
     * @return 業務輸出資料
     */
    @Nullable
    TOutput run(@NonNull TInput input);
 
    /**
     * 釋放資源
     */
    void release();
 
    /**
     * 模型是否正確載入完成
     *
     * @return true,模型正確載入
     */
    boolean isReady();
}

Convertor的具體實現如下:

interface Convertor<TInput, TOutput, TModelInput, TModelOutput> {
    /**
     * 資料預處理,將輸入資料轉換成模型輸入資料
     *
     * @param input 業務輸入資料
     * @return 模型輸入資料
     */
    @Nullable
    TModelInput preProcess(@NonNull TInput input);
 
    /**
     * 資料後處理,將模型輸出資料轉換成業務輸出資料
     *
     * @param modelOutput 模型輸出資料
     * @return
     */
    @Nullable
    TOutput postProcess(@Nullable TModelOutput modelOutput);
}

2.2 穩定性保障

眾所周知,Android平臺開發的一個重要的問題是機型適配,尤其是包含大量Native操作的場景,機型適配的問題尤其重要,一旦應用在某款機型上面崩潰,造成的體驗損害是巨大的。有資料表明,因為效能問題,移動App每天流失的活躍使用者佔比5%,這些流失的使用者,6 成的使用者選擇了沉默,不再使用應用,3 成使用者改投競品,剩下的使用者會直接解除安裝應用。因此,對於一個使用者群龐大的移動應用來說,保證任何時候App主流程的可用性是一件最基本、最重要的事。結合 AI 推理過程來看,不可避免地,會有大量的操作發生在 Native 過程中,不僅僅是推理操作,還有一些前處理和資源回收的操作也比較容易出現相容問題。為此,AoE 執行時環境 SDK 為 Android 平臺上開發了獨立程式的機制,讓 Native 操作執行在獨立程式中,同時保證了推理的穩定性(偶然性的崩潰不會影響後續的推理操作)和主程式的穩定性(主程式任何時候不會崩潰)。

具體實現過程主要有三個部分:註冊獨立程式、異常重新繫結程式以及跨程式通訊優化。

第一個部分,註冊獨立程式,在 Manifest 中增加一個 RemoteService 元件,程式碼如下:

<application>
    <service
        android:name=".AoeProcessService"
        android:exported="false"
        android:process=":aoeProcessor" />
 
</application>

第二個部分,異常重新繫結獨立程式,在推理時,如果發現 RemoteService 終止了,執行 “bindService()” 方法,重新啟動 RemoteService。

@Override
public Object run(@NonNull Object input) {
    if (isServiceRunning()) {
        ...(程式碼省略)//執行推理
    } else {
        bindService();//重啟獨立程式
    }
    return null;
}

第三個部分,跨程式通訊優化,因為獨立程式,必然涉及到跨程式通訊,在跨程式通訊裡最大的問題是耗時損失,這裡,有兩個因素造成了耗時損失:

傳輸耗時
序列化/反序列化耗時

相比較使用binder機制的傳輸耗時,序列化/反序列化佔了整個通訊耗時的90%。由此可見,對序列化/反序列化的優化是跨程式通訊優化的重點。
對比了當下主流的序列化/反序列化工具,最終AoE整合執行環境使用了kryo庫進行序列化/反序列。以下是對比結果,資料參考oschina的文章《各種 Java 的序列化庫的效能比較測試結果》。

三、MNIST整合示例

3.1 對TensorFlowLiteInterpreter的繼承

當我們要接入一個新的模型時,首先要確定的是這個模型執行在哪一個推理框架上,然後繼承這個推理框架的InterpreterComponent實現,完成具體的業務流程。MNIST是執行在TF Lite框架上的模型,因此,我們實現AoE的TF Lite的Interpreter抽象類,將輸入資料轉成模型的輸入,再從模型的輸出讀取業務需要的資料。初使化、推理執行和資源回收沿用TensorFlowLiteInterpreter的預設實現。

public class MnistInterpreter extends TensorFlowLiteInterpreter<float[], Integer, float[], float[][]> {
 
    @Nullable
    @Override
    public float[] preProcess(@NonNull float[] input) {
        return input;
    }
 
    @Nullable
    @Override
    public Integer postProcess(@Nullable float[][] modelOutput) {
        if (modelOutput != null && modelOutput.length == 1) {
            for (int i = 0; i < modelOutput[0].length; i++) {
                if (Float.compare(modelOutput[0][i], 1f) == 0) {
                    return i;
                }
            }
        }
        return null;
    }
}

3.2 執行時環境配置

接入MNIST的第二個步驟是配置推理框架型別和模型相關引數,程式碼如下:

mClient = new AoeClient(requireContext(), "mnist",
        new AoeClient.Options()
                .setInterpreter(MnistInterpreter.class)/*
                .useRemoteService(false)*/,
        "mnist");

3.3 推理執行

以下是MINST初使化推理框架、推理執行和資源回收的實現:

//初使化推理框架
int resultCode = mClient.init();
//推理執行
Object result = mClient.process(mSketchModel.getPixelData());
if (result instanceof Integer) {
    int num = (int) result;
    Log.d(TAG, "num: " + num);
    mResultTextView.setText((num == -1) ? "Not recognized." : String.valueOf(num));
}
//資源回收
if (mClient != null) {
    mClient.release();
}

四、加入我們

幫助AI在終端落地,開源AoE整合執行環境是我們走出的第一步!未來,為終端的開發者提供更多推理框架的支援,提供更多有價值的特性,是我們不懈追求的目標。如果您對這個專案感興趣,如果您在終端AI執行環境方面有想法,如果您在使用時有疑問,誠摯邀請您加入我們。

github地址:

圖片描述
您的每一個Star都是對我們最大的肯定:)

QQ交流群:

圖片描述
您的每一個問題都會幫我們成為更好的自己:)
QQ群號: 815254379

同時,也歡迎您關注滴滴技術公眾號,我們會及時釋出最新的開源資訊和技術乾貨!

滴滴技術公眾號:

圖片描述

相關文章