DidiがAoEをオープンソース化: AIの迅速な統合を可能にする端末操作環境SDK

Didi は、エンドサイド AI 統合ランタイム環境 (IRE) である AoE (AI on Edge) をオープンソース化しました。 AoE は「安定性、使いやすさ、セキュリティ」を設計原則として設計されており、開発者がさまざまなフレームワークのディープラーニングアルゴリズムを端末に簡単に展開して効率的に実行できるように支援します。

Didi がこのようなランタイムフレームワークを構築したい理由は 2 つあります。

まず、人工知能技術の急速な発展により、過去2年間で端末上で動作する推論フレームワークが数多く登場しました。開発者に選択肢が増える一方で、端末にAIを導入するコストも増加しています。
第二に、推論フレームワークを通じて AI に直接アクセスするプロセスは、動的ライブラリアクセス、リソースの読み込み、前処理、後処理、リソースの解放、モデルのアップグレード、安定性の確保などの問題を伴うため、かなり面倒です。

紹介によると、現在端末上で実行されている主流の推論フレームワークは 8 つあります。

基本的に、どのような推論フレームワークであっても、初期化、前処理、推論実行、後処理、リソース解放という 5 つの処理ステップが含まれている必要があります。これらの推論プロセスを抽象化することが、AoE がさまざまな推論フレームワークをサポートするための基礎となります。現在、AoE は NCNN と TensorFlow Lite の 2 つの推論フレームワークをサポートしています。

具体的には、最も基本的な AoE 統合オペレーティング環境は抽象推論操作です。依存性反転の設計により、ビジネスは特定の推論フレームワークのアクセス実装を気にすることなく、AoE の上位レベルの抽象化のみに依存します。この設計の最大の利点は、開発者がフレームワークの実装を変更することなくいつでも新しい推論フレームワークを追加できるため、ビジネス開発と AoE SDK 開発が完全に分離されることです。

AoE SDK では、この抽象化は次のようになります。

InterpreterComponent:モデルの初期化を処理し、推論を実行し、リソースを解放します。
コンバーター:モデル入力の前処理とモデル出力の後処理を処理するために使用されます。

AoEのもう一つの特徴は、安定性が保証されていることです。ご存知のとおり、Android プラットフォーム開発における重要な問題は、特に多数のネイティブ操作を伴うシナリオでのモデルの適応です。モデルの適応の問題は特に重要です。特定のモデルでアプリケーションがクラッシュすると、エクスペリエンスに与えるダメージは甚大です。

統計によると、パフォーマンスの問題により、モバイルアプリの 5% が毎日アクティブユーザーを失っています。これらの失ったユーザーのうち、60% は沈黙してアプリの使用をやめ、30% は競合製品に切り替え、残りは単にアプリをアンインストールします。したがって、大規模なユーザーベースを持つモバイルアプリケーションの場合、アプリのメインプロセスがいつでも利用可能であることを保証することが、最も基本的かつ重要なことです。

AI推論プロセスを考慮すると、必然的にネイティブプロセスで大量の操作が発生し、推論操作だけでなく、一部の前処理やリソース回復操作でも互換性の問題が発生しやすくなります。このため、AoE ランタイム環境 SDK では、Android プラットフォーム用の独立したプロセスメカニズムを開発し、ネイティブ操作を独立したプロセスで実行できるようにしながら、推論の安定性 (偶発的なクラッシュが後続の推論操作に影響を与えない) とメインプロセスの安定性 (メインプロセスがいかなるときもクラッシュしない) を確保しています。

具体的な実装プロセスは、主に、独立したプロセスの登録、例外によるプロセスの再バインド、プロセス間通信の最適化という 3 つの部分で構成されます。

現在、AoE SDK は Didi 銀行カード OCR に適用されています。AoE、推論フレームワーク、ホストアプリの関係をより明確に理解するには、次のビジネス統合図を参照してください。

オープンソースのランタイム環境 SDK には、Android および iOS プラットフォームが含まれます。また、Linux プラットフォームのランタイム環境 SDK も鋭意開発中で、9 月末にリリースされる予定です。

<<: 28歳で普通のエンジニアからAIに転職すべきか？

>>: 李開復：「AI+」には4つの段階があると考える理由