Walle: Device-Cloud Collaborat 向けのエンドツーエンドの汎用大規模生産システム

0.はじめに

        主流のクラウドベースの機械学習 (ML) パラダイムのボトルネックを解消するために、デバイス クラウドの共同 ML を採用し、基盤として Walle と呼ばれる最初のエンド ツー エンドの一般的なシステムを構築します。Walle には、ML タスクを 10 億レベルのデバイスにタイムリーに分散する展開プラットフォーム、タスク入力を効率的に準備するデータ パイプライン、毎日のタスクの反復を容易にしながらクロスプラットフォームで高性能の実行環境を提供するコンピューティング コンテナーが含まれます。具体的には、コンピューティング コンテナーは、モバイル ニューラル ネットワーク (MNN)、テンソル コンピューティング エンジン、データ処理およびモデル実行ライブラリに基づいており、さまざまな ML タスクと同時実行タスクをサポートするために、変更された Python スレッド レベルの仮想マシン (VM) を通じて公開されます。実行。MNN のコアは、オペレーター分解と半自動検索の新しいメカニズムであり、数十のハードウェア バックエンドに対して数百のオペレーターを手動で最適化する作業負荷を大幅に削減し、計算グラフの最適なバックエンドとランタイムの最適化をさらに迅速に特定します。Data Pipeline は、ユーザーの行動データをソースで処理できるオンデバイス ストリーム処理フレームワークを導入します。デプロイ プラットフォームは、効率的なプッシュ アンド プル方式を使用して ML タスクを発行し、マルチ粒度のデプロイ戦略をサポートします。実際の電子商取引アプリケーション シナリオで Walle を評価し、その有効性、効率性、およびスケーラビリティを実証します。広範なマイクロベンチマークも、MNN と Python スレッドレベル VM の優れたパフォーマンスを強調しています。Walle は大量生産され、Alibaba で使用されていますが、MNN はオープンソース化されており、コミュニティに幅広い影響を与えています。

1 はじめに

        業界の数百万人、場合によっては数十億人のスマートフォン ユーザーにインテリジェント サービスを提供するための主流のパラダイムは、モバイル デバイスが生データを介してリクエストを送信し、データ処理とモデルの実行後にクラウドが結果を返すようにすることです。ただし、このパラダイムには 3 つの主要なボトルネックがあります。

(1) 高い待ち時間: 各モバイル デバイスとクラウド間のネットワーク遅延とクラウドの要求処理遅延は秒単位であり、一部のリアルタイム インタラクティブ アプリケーションでは許容できません。たとえば、コンピューター ビジョン (CV)、自然言語処理 (NLP)、およびレコメンデーション タスクの実際の待機時間の要件は、数百または数十ミリ秒です。

(2) 高コストと高負荷: デバイス側では、Wi-Fi がない場合、生データをアップロードすると、セルラー データの使用率が高くなります。クラウドでは、多数のモバイル デバイスから大量の生データを受信して​​保存し、さまざまな複雑な機械学習アルゴリズムを使用してデータを処理し、時間内に結果を返すことは、必然的に高いオーバーヘッドにつながります。たとえば、60 年代のビデオまたはオーディオのサイズは MB 単位であり、各ユーザーが 1 日あたりに推奨するオリジナル データのサイズは MB 単位です。これにさらにモバイル デバイスのサイズを掛けると、生データの合計サイズは膨大になります。

(3) データのセキュリティとプライバシー: 機密性の高いコンテンツ (個人情報やユーザーの行動など) を含む生データをアップロードすると、セキュリティとプライバシーに関する深刻な懸念がユーザーに生じる可能性があります。生データをクラウドに保存して処理すると、データ侵害のリスクにさらされる可能性があります。

クラウドベースの ML パラダイムを分解すると、 10 年間の開発の後、モバイル デバイスが適切なデータ処理とモデル実行負荷を担えるようになったことを無視して        、単純にモバイル デバイスをインターフェイスとして扱っていることがわかります。そのため、デバイス側がユーザーやデータ ソースに近いという本来の利点を活用していないため、遅延と通信コストが削減され、クラウドの負荷が軽減され、プライベート データがローカル デバイスに保持されます。主流のクラウドベースの機械学習パラダイムのボトルネックを克服するために、一部の機械学習タスクをモバイル デバイスにオフロードすることを提唱する、デバイスとクラウドの共同機械学習パラダイムが登場しました。これにより、クラウドとモバイル デバイスが協力して機械学習を完了することができます。タスク。既存の研究は、推論またはトレーニング段階でのアルゴリズムの決定に焦点を当てる傾向があり(デバイスとクラウドのタスク分割戦略 [29] やコラボレーション/インタラクション パラダイム [34] など)、多くの場合、特定のアプリケーション(ビデオ分析など) 分析 [6、 11,31]、テキスト処理[5]、推奨[17,44])。しかし、実際の産業シナリオでは、数百万、場合によっては数十億のモバイル デバイスにサービスを提供するさまざまな CV、NLP、およびレコメンデーション アプリケーションのフル サイクルが含まれることが多く、デバイスとクラウドのコラボレーション ML を大量生産するための一般的なシステムを構築することは困難な問題です。新しい要件。

必要な情報 (データ、機能、サンプル、モデル、モデルの更新、中間結果など) を交換することで、各段階で ML タスクをサポートすることを全体的な目標として、Walle と呼ばれるエンドツーエンドのシステムを構築しました        。コラボレーション (シングル デバイス クラウドやマルチデバイス クラウドなど)。図 1 に示すように、Walle は、モバイル デバイスとクラウド サーバーの両方で、開発 (毎日の ML タスクの反復と展開の実際的なニーズの頻繁な実験など) および運用 (ML タスクの実行とデバイス クラウド) の両方で ML プロセス全体をサポートします。データ転送) フェーズタスク サイクル(つまり、前処理、モデルのトレーニングとモデルの推論、および後処理)。多数のアプリケーション固有またはプラットフォーム固有のソリューションを統合するのではなく、汎用システムを構築するという哲学に従い、Walle は、標準 API を備えた基盤となる ML インフラストラクチャとして、モバイル アプリケーションの軽量な制約を維持し、1,000 以上をサポートしています。大規模 本番環境でのさまざまな CV、NLP、レコメンデーション タスク。

        Walle を構築する際に、設計上の決定を下すいくつかの実際的な要件と課題に遭遇しました。Walle は ML タスク指向であり、デプロイ プラットフォーム、データ パイプライン、およびコンピューティング コンテナーで構成され、それぞれ ML タスクのデプロイ、入力の準備、および実行に向けられています。

(1) コンピューティング コンテナーの場合、主要な要件は、ML タスクの反復をモバイル アプリの月単位または週単位の更新から切り離すことであり、新機能をアプリに統合する従来のアプローチは実行不可能になります。もう 1 つの重要な要件は、さまざまなオペレーティング システム (OS)、モバイル デバイス、およびクラウド サーバーを備えた異種ハードウェア全体で、さまざまな ML タスクを高いパフォーマンスでサポートすることです。これには、C/C++ を使用してテンソル コンピューティング エンジンを構築し、オペレーター レベルと計算グラフ レベルで各ハードウェア バックエンドを最適化する必要があります。2 つの主な戦略は、手動の最適化 (ほとんどすべての ML エンジンなど) で、これは非常に労力がかかり、一部の一般的なケースしかカバーできません; 自動チューニング (TVM [9] など) は実行時の最適化をサポートできません。多数の異種デバイスが関係する産業シナリオや、ML タスクの頻繁な高速反復が必要な産業シナリオでは実行できません。テンソル コンピューティング エンジンに基づいて、ライブラリは前処理、モデルのトレーニングと推論、後処理、およびモバイル デバイスとクラウド サーバーを統合された方法で実装する必要があります。 PyTorch (モバイル版)。統合された設計がなければ、テンソル コンピューティング エンジンの高性能をさまざまなライブラリに公開することはできず、各ライブラリの異種バックエンド最適化には多くの作業と大規模なパッケージが必要です。

(2) データ パイプラインの主な目標は、オンデバイスまたはクラウドベースの ML モデルへの入力として、さまざまなソースから取得し、さまざまな形式で構造化できる生データを準備することです。集約処理のためにすべてのデバイス側の生データをクラウドにアップロードするという主流のパラダイムは、非効率的でエラーが発生しやすいものです。

(3) 展開プラットフォームの主要な要件は、大規模な ML タスクの展開要件、断続的なデバイスの可用性、および潜在的なタスクを考慮して、多数のモバイル デバイスの ML タスクをきめ細かくタイムリーかつ堅牢な方法で管理、公開、および展開することです。失敗。

上記の主要な課題を克服し、Walle を構築しました。
(1) Walle で ML タスクを開発するためのスクリプト言語として、動的に型付けされ、広く使用されている Python を選択しました. CPython への 2 つの改善を通じて、コンピューティング コンテナーのコアとして Python VM を実装しました: 1 つはグローバル インタープリター Lock を放棄することです( GIL ) であり、VM の分離とデータの分離を使用してタスクレベルのマルチスレッドをサポートします。2 つ目は、実際のデバイス側の要件に合わせて調整することです。このような設計により、毎日の ML タスクを反復処理できます。計算コンテナーの下部に、テンソル計算エンジンと、MNN [2] と呼ばれる標準のデータ処理およびモデル実行ライブラリを実装します。MNN はまず、変換演算子と複合演算子をアトミック演算子に分解する新しい幾何学的計算メカニズムを導入し、数十のバックエンドに対して数百の演算子を手動で最適化する作業負荷を大幅に削減します。一連のオペレーターのランタイム最適化による最適なバックエンド。コンピューティング コンテナーの上で、MNN を標準 API として Python スレッドレベル VM に公開し、標準データ入力を使用してさまざまな ML タスクの完全なサイクルをサポートします。

(2) Walleのデータパイプラインは、主にエンドサイドのストリーム処理フレームワークを新たに構築し、ユーザーの行動データのソース処理を実現しました。重要な新規性は、複数のストリーム処理タスクのトリガー条件を管理して、同時にトリガーされるトライ構造でさまざまな機能を生成することにあります。また、新しい機能をデバイスからクラウドに送信して使用するためのリアルタイム トンネルも確立しました。

(3) Walle のデプロイ プラットフォームでは、git を使用してタスク エンティティを管理し、タスクに関連するファイルを共有ファイルと専用ファイルに分割して、多粒度のデプロイを容易にすることを提案します。段階的に。

        Walle は現在、Alibaba の ML バックボーン インフラストラクチャの一部であり、1 日に 1,530 億回以上呼び出され、1 日あたり 3 億人を超えるアクティブ ユーザー、30 を超えるモバイル アプリケーション、および 300 を超える ML タスクをサポートしています。MNN は現在オープン ソースであり、GitHub には 6,600 を超えるスターと 1,300 を超えるフォークがあり、他の 10 社以上の企業でも運用に使用されています。実際のアプリケーション例 (ライブ ストリーミングやレコメンデーションなど) とプラットフォームの統計に関する Walle の評価は、有効性、効率性、およびスケーラビリティを示しています。MNN と Python スレッドレベル VM のマイクロベンチマークは優位性を示しています。

        主な貢献を次のように要約します。

(1) Walleは、最下層でハードウェアとソフトウェアの異種性を保護し、毎日の反復サイクルと高性能をサポートする、最初のエンドツーエンド、汎用、大規模なデバイスクラウド共同 ML 生産システムです。多様化した ML タスク。

(2) Walle の計算コンテナーには、幾何学的計算を導入してオペレーター レベルの手動最適化の作業負荷を大幅に削減する MNN と、実行時最適化で最適なバックエンドを特定する半自動検索を導入する MNN、および Python VM の放棄を開拓した Python VM が含まれます。 GILは、タスクレベルのマルチスレッドをサポートし、モバイル端末に移植された最初のものでもあります。

(3) Walle のデータ パイプラインは、トライベースの同時実行タスクによってトリガーされるデバイス側のストリーム処理を導入し、ソースでユーザーの行動データを処理できます。

(4) Walle の展開プラットフォームは、きめの細かいタスクの公開と数億のデバイスへの展開を強力な適時性と堅牢性でサポートします。

2. 序文

        このセクションでは、まず、デバイスとクラウドの共同 ML の一般的なシステムを構築するための背景と動機について詳しく説明します。次に、主な設計上の課題について詳しく説明します。最終的にシステム要件が決まりました。

2.1 背景と動機

        機械学習タスク:開発者の観点から見ると、ML タスクには、スクリプト (Python のコードなど)、リソース (データ、モデル、依存ライブラリなど)、構成 (トリガー条件など) タスクが含まれます。ML タスクの全体的なワークフローは、前処理、モデル実行、後処理の3 つのステージまたはサブタスクに分けることができます。前処理段階では、複数のソースからの生データをクリーニング、統合、処理して特徴を抽出し、サンプルを生成してから、モデルに入力します。モデルの実行段階で、トレーニングまたは推論のためにモデルが読み込まれます。後処理段階では、モデル推論の結果が処理され (たとえば、いくつかのランキング戦略やビジネス ルールを適用することによって)、最終的にユーザーにサービスを提供します。

        産業用アプリケーションの促進:現在、Alibaba には少なくとも数百のオンライン ML タスクがあり、ビジネス シナリオで数十億人のモバイル アクティブ ユーザーにサービスを提供しています。そのうち CV、NLP、およびレコメンデーション タスクは、およそ 30%、10%、および 60% を占めています。タスクの総数と 1 日あたりの実行数は、それぞれ 10 億、1,000 億、10 億です。具体的には、（1）典型的なCVアプリケーションシナリオには、ライブブロードキャスト、画像検索、短いビデオ分析、拡張現実、セキュリティ検査などが含まれ、主なタスクには、キーフレーム検出、画像のセグメンテーションと分類、オブジェクト認識、顔認識、等 認識と効果、人体のキー ポイントと姿勢の検出、およびポルノの検出 (2) 典型的な NLP アプリケーション シナリオには、ライブ ブロードキャストと音声ナビゲーションが含まれ、主なタスクには、自動音声認識、テキスト読み上げ、テキスト分析、およびテキストが含まれます。 (3) 典型的 推奨されるアプリケーション シナリオには、製品の再配置、スマート リフレッシュ、メッセージ ポップアップ、ページの再配置などが含まれ、主要なタスクには、クリック率予測、クリック コンバージョン率予測、ユーザー ステータスの識別などが含まれます。ユーザーの意図の検出。

        デバイスとクラウドのコラボレーション システムが必要です。これらのアプリケーションでは、ML タスクに厳しいレイテンシ要件が課せられます。一般的に言えば、(1) CV タスクは各画像を 30 ミリ秒以内に処理する必要があります; (2) NLP タスクは 5 秒の音声セグメントを 500 ミリ秒以内に処理するか、音声ストリームを 100 ミリ秒未満の遅延で処理する必要があります; (3) レコメンデーション タスクは出力で処理され、300 ミリ秒以内に生成されます。さらに、大量のユーザー入力から ML タスクへの生データは膨大です。たとえば、(1) CV タスクの場合、長さ 60 秒、1080p、8Mbps のビデオのサイズは約 60MB です; (2) NLP タスクの場合、長さ 60 秒の WAV/PCM オーディオのサイズは約 10MB です; (3)通常、ユーザーは毎日何千もの生データを生成し、各データのサイズは KB です。さらに、未加工のユーザー データは多かれ少なかれ機密性が高く、セキュリティとプライバシーに関する懸念が生じます。
        上記の実際的な要件により、主流のクラウドベースの ML パラダイムは実現不可能になり、デバイス クラウドの共同 ML を採用することになります。重要な原則は、ML タスクはクラウドだけでなく、純粋にクラウドではなく、モバイル デバイスでも実行できるということです。モバイル デバイスは、機械学習タスクの実行中にクラウドへのリレーとして機能することができ、その逆も可能です。どの段階でどのパーティを実行するかを柔軟に選択でき、ML タスクの実際のニーズとクラウドおよびモバイル デバイスの特性を組み合わせる必要があります。たとえば、前処理にどちらの側を選択するかは、その側がデータ ソースに近いかどうかを考慮する必要があります。多様な ML タスクと大規模なデバイスをサポートする産業上のニーズをさらに観察することで、デバイスクラウドのコラボレーション ML を大量生産できるエンドツーエンドの一般的なシステムを構築することに意欲的です。

2.2 実際の課題

        オンデバイス クラウドの共同 ML システムは、以下に示すように、ML タスクの実行、入力準備、および展開フェーズにまたがるいくつかの実際的な課題に直面しています。

        実行上の課題:  (1) 長い反復サイクル: モバイルアプリの一般的な更新サイクルには、開発、テスト、新しい機能の統合 (コンテキストで言及されている ML タスクなど)、およびアプリストアのレビューとリリースが含まれます。バッチ内の多数のモバイル デバイス。その結果、ほとんどのアプリは毎週更新されますが、一部のスーパー アプリ (Alibaba が所有し、毎日 3 億人のアクティブ ユーザーを持つショッピング アプリ、Handao など) は毎月更新されます。ただし、ML タスクでは、さまざまな ML アルゴリズムとモデルの有効性を迅速に検証し、機能とハイパーパラメーターの最適な組み合わせを決定するために、現実の世界で頻繁に実験/展開を行う必要があります。

(2) 異種バックエンド: クラウド サーバーとモバイル デバイスでは、ハードウェア (CPU、GPU、NPU、命令セット アーキテクチャ (ISA)、メモリなど) とオペレーティング システム (Android、iOS、Windows、Linux など) に大きな違いがあります。 . モバイルでは、エコシステムはより細分化されています。

(3) 多様な ML タスク: 産業用アプリケーションにはさまざまな ML タスクが含まれ、多様なモデル構造が必要です (たとえば、畳み込みニューラル ネットワーク (CNN)、再帰型ニューラル ネットワーク (RNN)、変換器、生成的対立ネットワーク (GAN)、Deep Interest)ネットワーク (DIN))。同時に、前処理と後処理には、多数の画像、テキスト、および数値処理方法も含まれます。

(4) デバイスのリソースは限られています。各モバイル APP には 1 つのプロセスしかありません。モバイル タオバオの最大 RAM は 200MB のみで、パッケージ サイズは 300MB を超えることはできません。

        入力準備の課題:  (1) 非典型的なユーザー行動データ: CV および NLP タスクの場合、ほとんどの生データ (画像、ビデオ、テキスト、オーディオなど) は標準形式であり、標準ライブラリは前処理をサポートできます。前処理を直接サポートできないもう 1 つの主要なデータ ソースは、多くの ML (特にレコメンデーション) タスクにとって重要な、モバイル アプリケーションと対話するときの時間とページのシーケンスにおける各ユーザーの異なる動作です。伝統的に、すべてのユーザー行動データはソースから離れたクラウドにアップロードされ、Flink でストリーミングされます。ただし、ソースでの前処理を有効にするために、オンデバイス ストリーム処理フレームワークはありません。

(2) 多様なトリガー条件: ML タスクは多くの場合、多くの機能を必要とします。各特性は、ストリーム処理タスクとそのトリガー条件に対応しています。同時タスクによってトリガーされる複数のトリガー条件を効果的に管理する方法は、簡単な作業ではありません。

        展開の課題: (1) 大規模なタスクの展開要件: アリババでは、少なくとも数百のアクティブな ML タスクがあり、対象となるモバイル デバイスの数は数億に達する可能性があります。各 ML タスクのリリースには、APP バージョン、デバイス エンド、およびユーザー エンドの違いも組み合わせる必要があります; (2) 断続的なデバイスの可用性: モバイル デバイスのワイヤレス接続が不安定で、フォアグラウンドで実行できるアプリケーションは 1 つだけです。ユーザーは、アプリケーションを頻繁に切り替えることがよくあります。したがって、アプリの観点からは、各デバイスの可用性は動的です。従来のプッシュ (長期接続に基づくなど) またはプル (ポーリングに基づくなど) 展開方法では、適時性を保証できず、クラウドの負荷が高くなります; (3) 潜在的なタスクの失敗: モバイル APP は、プロセス。いずれかのタスクが失敗すると、アプリ全体がクラッシュし、ユーザー エクスペリエンスに深刻な影響を与えます。さらに、多数のタスク展開要件があるため、関連するすべてのタイプの実際のデバイスで各プレリリース タスクをテストすることは現実的ではありません。

2.3 システム要件

        上記の課題を考慮すると、デバイスとクラウドの共同機械学習システムの設計は、いくつかの要件を満たす必要があります。
        ML タスク実行環境は、次の要件を満たす必要があります: (1) タスクの高速反復: ML タスクは、モバイル APP で毎日反復でき、APP の元の更新サイクルへの依存を取り除きます; (2) クロスプラットフォーム: オペレーティング システム レベルとハードウェア レベルはシールドする必要があります。各 ML タスクの前処理、モデル実行、および後処理段階は、エンド ツー エンドの方法でサポートする必要があります; (5) 軽量: 特にモバイル デバイスの場合、パッケージ全体のサイズを小さくする必要があります。
        ML タスク入力準備パイプラインでは、ユーザーの行動データをソースで処理できるように、並列タスクをトリガーする機能を備えた新しいオンデバイス ストリーム処理フレームワークを最初に導入する必要があります。クラウドが生成された特徴をソースから離れた低レイテンシーで消費するには (特徴の融合やモデルの推論など)、モバイル デバイスとクラウドの間のリアルタイム チャネルも必要です。
        ML タスク展開プラットフォームは、(1) 多粒度: タスク発行は、統一されたデバイス レベルのグループ化、ユーザー レベルのグループ化、さらには極端なデバイス固有の戦略をサポートする必要があります; (2) 適時性:短時間 多数のモバイル デバイス (3) 堅牢性: タスクの展開では、安定性を第一に考えなければなりません。

3. Walle: アーキテクチャとデザインの原則

システム要件に基づいて、私たちは Walle を構築しました。最初に全体的なアーキテクチャを紹介し、次に設計原則を紹介します。

3.1 アーキテクチャの概要

        図 2 に示すように、Walle のコンピューティング コンテナーには、(1) 基盤となるクロスプラットフォームの高性能テンソル コンピューティング エンジン、(2) テンソル コンピューティング エンジンに基づくデータ処理およびモデル実行ライブラリ、(3) Pythonスレッド レベル VM; (4) 標準 API を上に。データ パイプラインの紹介: (1) デバイス上のストリーム処理フレームワーク、(2) リアルタイム エンド クラウド トンネル。Walle の展開プラットフォームには、(1) タスク管理モジュール、(2) タスク リリース展開モジュールが含まれます。

3.2 設計原則

        

        計算コンテナーの根拠:図 3 の上部に示すように、スクリプト言語として Python を選択します。これは、Python が ML アルゴリズムの開発に広く使用されており、動的に型付けされ、解釈される言語でもあるためです。さまざまなプラットフォーム、特にリソースに制約のあるモバイル デバイスで ML タスクを実行する Python スクリプトをサポートするために、CPython を改良して Python VM を実装し、モバイル アプリの実際のニーズに合わせて調整しました。さらに、複数のタスクの同時トリガー、異なるタスク間の独立性、個々の ML タスクごとの異なるステージの順次実行など、ML タスク実行の特性を考慮して、最初に各 MLを設定することによって Python VM の GIL を放棄します。task はスレッドにバインドされた後、タスクレベルのマルチスレッドをサポートするためにスレッド分離されます。この Python VM ベースの設計により、コンピューティング コンテナーが動的なタスク配信を利用できるようになり、毎日の ML タスクの反復が毎月/毎週のモバイル アプリの更新から分離されます。

        下部では、クロスプラットフォームと高性能を考慮して、C/C++ でテンソル コンピューティング エンジンを実装しました。図 5 に示すように、中核となるのは、幾何学的計算と半自動検索の新しいメカニズムです。特に、幾何学的計算は、座標変換のプロパティと、要素座標とそのメモリ アドレス間の線形マッピングを活用することにより、変換演算子から新しい原子演算子を抽出します。このようにして、全演算子の約 49% を占める変換演算子と複合演算子をアトミック演算子に分解できます。これにより、16 種類のバックエンド アルゴリズム、ISA、メモリ、および 124 演算子のアセンブリの手動実装と最適化が削減されます。 . ワークロードの 46%。次に、モバイル デバイスまたはクラウド サーバーで利用可能なバックエンドをすばやく特定して、一連の演算子を使用して最小コストで計算グラフを実行するために、Walle ランタイムで半自動検索を適用して、利用可能な各バックエンドの各演算子を見つけます。最適なパラメーターを使用して最適に実装されたアルゴリズム。パラメーター検索は、バックエンドのハードウェア プロパティと実装アルゴリズムへの入力のサイズを組み合わせることにより、制約付き最適化問題の解決に変換されます。テンソル コンピューティング エンジンに基づいて、科学計算、画像処理、モデル推論、モデル トレーニング用のライブラリを実装し、それらを標準 API として Python VM に提供し、標準データ入力でさまざまな ML タスクの完全なサイクルをサポートします。

        データ パイプラインの基礎:アーキテクチャを図 4 に示します。まず、ユーザーの行動は時間レベルのイベント シーケンスとして自然に記録されます。これに基づいて、同じページ内のイベントを集約することで、ページ レベルのイベント シーケンスを作成できます。次に、ストリーム処理タスクのトリガー条件は、イベント/ページ ID シーケンスによって指定できます。同時トリガーをサポートするために、複数のトリガー条件とイベント シーケンスのマッチング問題を、複数のワイルドカード パターンを使用した文字列マッチング問題としてモデル化し、トライを使用してトリガー条件を編成することを提案します。これにより、新しいイベントが到着した場合、トリガーされたすべてのタスクがすべて実行のために選ばれます。ストリーム処理タスクは、連続的に生成されるイベント シーケンスで頻繁にトリガーされる可能性がある一方で、1 回の出力のサイズは小さいため、書き込み頻度を減らすための一括ストレージ メカニズムを設計します。最後に、デバイス ストリーム処理の出力を低レイテンシでアップロードするために、永続的な接続を利用してリアルタイム トンネリングを実装し、500 ミリ秒で最大 30KB のデータを転送します。

        デプロイ プラットフォームの基本原則:最初に git を使用してタスク エンティティを管理し、タスク関連のファイルを、これらのファイルを共有できるデバイスの数に応じて、共有ファイルと専用ファイルに分割します。ファイルの分類により、タスク展開戦略の統合とカスタマイズがさらに容易になります。タスク展開の適時性を確保するために、プッシュ機能がビジネス サービスの既存のクライアントの http 要求を再利用し、プル機能がコンテンツ配信ネットワーク (CDN) を通過する、瞬時接続に基づく新しいプッシュ プル方式を提案します。およびアリ クラウド エンタープライズ ネットワーク ( CEN )。タスク展開の堅牢性のために、リリース前にクラウド コンピューティング コンテナーのタスク シミュレーション テストを導入し、タスクが失敗した場合のロールバックを許可しながら、タスクを段階的に強制的にリリースします。
        次に、セクション 4 でコンピューティング コンテナーの設計と実装の詳細、セクション 5 でデータ パイプライン、セクション 6 でデプロイ プラットフォームについて説明します。

4. Walle でのコンテナの計算

        テンソル計算エンジンとデータ処理およびモデル実行ライブラリである MNN、Python スレッドレベルの仮想マシン、および MNN の標準 API という計算コンテナーをボトムアップ方式で紹介します。

4.1 Tensor 計算エンジン

        テンソル コンピューティングは、データ処理と機械学習の基礎と見なすことができます. 基礎となるテンソル コンピューティングの演算子は、次の 4 つのカテゴリに分類できます。

(1) バックエンド最適化の基本単位としてのアトミック演算子。いくつかの一般的な単項演算子 (たとえば、2 乗を取る) や 2 項演算子 (たとえば、加算、減算、乗算、および除算) など。

(2) 転置、スライス、連結、順列など、形状を変更したり、要素を並べ替えたりする変換演算子。

(3) 3D 畳み込みとプーリング、正規化、指数線形単位、長短期記憶単位などのアトムと変換演算子に分解できる複合演算子。

(4) if と while を含む制御フロー演算子。

        幾何学的コンピューティング:現在、MNN は Naop = 61 のアトミック オペレーター、Ntop = 45 の変換オペレーター、Ncop = 16 の複合オペレーター、および Nfop = 2 の制御フロー オペレーターをサポートできます。MNN ですべての Nba = 16 バックエンドのオペレーターを実装して最適化する労力は O((Naop + Ntop +Ncop)×Nba +Nfop = 1954) です。さらに、アトミック オペレーターと制御フロー オペレーターが関与するワークロードが避けられないことを考慮して、全体のワークロードの約半分を占め、将来的に増加する変換オペレーターと合成オペレーターが関与するワークロードの削減に目を向けます (たとえば、より多くの複合オペレーターが必要より多くの種類のディープ ニューラル ネットワーク (DNN) をサポートします)。私たちの重要なアイデアは、「 raster 」と呼ばれる変換演算子から新しい原子演算子を抽出することです。次に、変換演算子と複合演算子の両方をラスター演算子とアトミック演算子に分解できます。各バックエンドはアトミック オペレーターとラスター オペレーターのみを最適化する必要があるため、全体のワークロードは O((Naop +1)×Nba +Ntop +Ncop +Nf op = 1055) になり、ワークロードが約 46% 削減されます。ここで、ラスター オペレーターとは何か、またそれをどのように実装するかが問題になります。幾何学的計算機構を以下のように提案する．

        基本的に、変換演算子の基本的な機能は、要素をあるメモリ アドレスから別のメモリ アドレスに移動すること、またはジオメトリから要素の座標を別のメモリ アドレスに変換することです。さらに、メモリ アドレスは座標の決定論的な線形関数です。さらに、特定の変換演算子が与えられると、座標変換の式を決定できます。したがって、入力テンソルまたは出力テンソルの要素の座標、通常は入力テンソルまたは出力テンソルの要素のインデックスに基づいて、元のメモリ アドレスと移動されたメモリ アドレスも決定できます。メモリ アドレスとトラバーサル座標に基づいて、入力テンソルと出力テンソルの間で要素を移動するためのラスター オペレーターが導入されました。スライスを例に取りましょう。A は、一意の識別子/ポインターを使用して連続したメモリ アドレスに配置された 2 × 4 行列です。スライス A は、1 行 4 列の行列である 2 番目の行のみを保持することによって B として表されます。B の行インデックスは i、列インデックスは j (つまり、B の座標 (i, j)) であり、B の一意の識別子に関連するメモリ識別子は i×4+j であり、線形です。ここで、係数 (4,1) はストライドと呼ばれます。スライスの定義/規則 (つまり、Bi, j = Ai+1, j) によれば、A 内の対応する要素 Ai+1, j の座標は (i+1, j) であり、相対メモリ識別子は ( i+1)× 4+ j = 4i+ j +4、ここで係数 (4,1) はストライドで、切片 4 はオフセットと呼ばれます。ラスター演算子は、座標 {(i,j)|0≤i<1,0≤j<4,i,j∈Z} を反復することにより、メモリ アドレスを使用して各 Ai+1,j を Bi に移動できます。j は次の関数を実現します。スライス。

        ラスタ オペレータの実際の実装では、入力テンソル、座標範囲、および入力とストレージ内の要素の座標とそれらのメモリ アドレス間の線形マッピングを含む「領域」と呼ばれるサポート概念を導入します。「ビュー」と呼ばれる出力テンソルは、ストライドとオフセットで指定できます。さらに、オペレーターが分解された後、いくつかのラスター操作を組み合わせて最適化することができます。1 つの戦略は垂直マージと呼ばれ、主に 2 つの連続するラスター操作を扱い、間接参照をスキップし、元のテンソルを操作します。もう 1 つの戦略は水平マージと呼ばれ、同じ領域で 2 つの並列ラスター操作を扱います。1 つのラスターのみ動作は残ります。

        アトミック オペレーターの最適化:ラスター オペレーターを含むアトミック オペレーターに固有の、ハードウェアの異種性を組み合わせて、アルゴリズム、ISA、メモリ、およびアセンブリの観点からそれらを最適化および実装します。(1) アルゴリズム レベルの最適化は、通常、畳み込みや行列の乗算など、計算量の多い操作に固有のものです。Winograd および Strassen アルゴリズムを含む、より効率的なアルゴリズムを採用して、乗算の数を大幅に削減します; (2) ISA レベルの最適化は、ARM Neon や x86 AVX512 などの Single Instruction Multiple Data (SIMD) を使用して加速されます。SIMD のデータレベルの並列処理を最大限に活用するために、データ レイアウトとデータ パッキングを慎重に設計しました。具体的には、新しい NC/4HW4 レイアウト [35] と畳み込み用のチャネル メイン カプセル化を採用します; (3) メモリ レベルの最適化は、主に読み取りと書き込みの数を減らし、メモリ割り当ての継続性を改善することに焦点を当てています。特に、行列の乗算では、タイリングとメモリの並べ替えを適用します; (4) アセンブリ ベースの最適化により、命令レベルの高速化を実現できます。手書きのアセンブリ コードを使用してコア オペレーターを実装し、ループ展開、ソフトウェア パイプライン処理、命令の並べ替えなどの最適化を慎重に適用します。

        半自動検索:通常、データ処理とモデルの実行には、一連の演算子 (分解された原子演算子、ラスター演算子、および制御フロー演算子) が含まれます。同時に、バックエンドが異なればオペレーター向けの実装と最適化も異なり、モバイル デバイスやクラウド サーバーには複数のバックエンドが利用できることがよくあります。半自動検索の全体的な目標は、最小限のコストでバックエンドを特定することです。各バックエンドのコストは、最適な実装を持つすべてのオペレーターの合計です。特定のバックエンドで特定のオペレーターに最適な実装アルゴリズムを決定するには、可能なアルゴリズムごとに最適なパラメーターを見つける必要があります。これは、計算コストまたはメモリ コストが目標であり、制約にはバックエンドのハードウェア制約とアルゴリズム入力のサイズが含まれる、迅速に解決できる制約付き最適化問題に変換されます。半自動検索のプロセス全体を定式化し、次のように詳細に説明しました

        BA は利用可能なすべてのバックエンドのセットを表し、op1 → op2 → ... → opn は実行する n 個のオペレーターのシーケンスを表します。バックエンド ba ∈ BA のコストは次のように定義されます。

        ここで、Copi,ba は、バックエンド ba で最適に実装されたオペレーター opi のコストを表します。半自動検索の目的は、最小コストでバックエンドを見つけることです。これは、次のように表すことができます。

        では、各 Copi,ba をどのように計算するかが問題です。各オペレーター opi とバックエンド ba について、algs(opi,ba) が最適なパラメーターを持つ実行可能なすべての実装アルゴリズムを表すようにします。このとき、Copi,ba は次のように定義されます。

        ここで、(1) Qalg はアルゴリズム alg の基本的な計算の数を表し、与えられた (ここでは「最良の」) パラメータと入力サイズを取得できます; (2) Pba はバックエンド Ba のパフォーマンスを表します。MNN では、CPU タイプのバックエンドの場合、バックエンド ba が ARMv8.2FP16 をサポートしている場合、Pba​​ は経験的に 16 倍の周波数を使用し、それ以外の場合は Pba は 8 倍の周波数を使用します。GPU タイプのバックエンドの場合、Pba​​ は手動テストにより経験的に 1 秒あたりの浮動小数点演算 (FLOPS) に設定されます; (3) Salg,ba は、バックエンド ba のアルゴリズム alg のスケジューリング コストを表します。
        MNN では、CPU 型バックエンドの場合、Salg,ba は 0 に設定され、GPU 型バックエンドの場合、Salg,ba は主にデータ転送の時間を考慮して経験的に設定されます。さて、残りの問題は、演算子 opi、バックエンド ba、実装アルゴリズム alg、および入力のサイズ、アルゴリズムの最適なパラメーターを決定する方法です。実際には、これを制約付き最適化問題に変換します。その目標は、計算コストまたはメモリ コストを最小限に抑えることです。制約には、主に SIMD ユニットの幅、レジスタの数、スレッドの数、および入力の数が含まれます。さらに、SIMD のパック サイズ、行列乗算のタイル サイズ、Winograd アルゴリズムのブロック単位、および Strassen アルゴリズムを使用した基本的な計算の削減というパラメータの最適化に主に焦点を当てています。例として、行列乗算におけるタイル サイズの最適化を取り上げます。A は a×e 行列、B は e×b 行列、te は同じサイズの軸に沿ったタイル サイズ、tb は列 B の軸に沿ったタイル サイズ、Nr は登録数量。最適化の目標は、メモリの読み取りと書き込みの数を最小限に抑えることです。最適化問題の定式化は次のとおりです。

これは実行時に効率的に解決できます。

        いくつかの共通パラメーターを使用してアルゴリズムを 1 つずつ最適化するために各オペレーターが手動で検索する場合と比較して、半自動検索は作業負荷を大幅に削減できるだけでなく、より高い確率で最適なパラメーターを見つけることができます。TVM が自動チューニングを使用しない理由については、オペレーターの最適化に手動の経験がない. 特定のバックエンドでは、オペレーターおよびグラフ レベルで大きな検索スペースがあり、静的コンパイルに時間がかかり、ランタイムの最適化がサポートされていません。最も重要なことは、iOS デバイスでの実行可能ファイルと Just-In-Time (JIT) コンパイルのセキュリティ上の制約を考えると [4]、TVM で生成されたコンパイル モデルをモバイル アプリにリンクし、毎月/毎週更新する必要がありますが、これは期待できません。毎日。したがって、TVM は、多数の異種デバイスが関係する産業用アプリケーションや、頻繁に高速なタスクの反復が必要な産業用アプリケーション (展開された ML モデルの更新など) には適していません。対照的に、当社のテンソル計算エンジンの設計は基本的に、異種バックエンドの手動オペレーター レベルの最適化を利用して、半自動検索のスペースを縮小し、モデルを通常のリソース ファイルとしてデプロイできるようにし、ランタイムの最適化と Python VM での毎日の反復をさらに促進します。 ML タスク。もう 1 つの利点は、ますます多くの ML タスクに対して、モバイル アプリのバンドル サイズが長期的に増加しないことです。

4.2 データおよびモデル関連のライブラリ

        テンソル コンピューティング エンジンを通じて、機械学習タスクの前処理段階と後処理段階のために、科学計算と画像処理のためのライブラリ、モデル推論とモデル トレーニングのためのライブラリを実装します。特に、科学計算と画像処理のライブラリは、NumPy [21] と OpenCV [28] の最適化された実装と見なすことができ、軽量で高性能です。軽量とは、手動でトリミングせずにライブラリのサイズを縮小することを意味します。NumPy 1.9.3 と OpenCV 3.4.3 の元のサイズは 2.1MB と 1.2MB ですが、MNN ではそれぞれ 51KB と 129KB に縮小されています。ハイ パフォーマンスとは、基礎となるテンソル コンピューティング エンジンのパフォーマンスの最適化をライブラリに継承できることを意味し、追加のワークロードを回避します。以下にライブラリの実装を紹介します。

        科学計算と画像処理:アトミック、ラスター、および制御フロー演算子を使用して、配列の作成と操作ルーチン、バイナリ演算、線形代数、論理関数、配列への入力、ランダム サンプリング、数学関数などを科学計算ライブラリでサポートします。画像処理ライブラリでは、フィルタリング、幾何学的およびその他の画像変換、プロット関数、色空間変換などがサポートされています。

        モデル推論とモデル トレーニング:現在、MNN では、セッションとモジュールと呼ばれるモデル推論の 2 つのモードを提供しています。モジュール モードは、トランスフォーマーや動的 RNN などで必要な制御フロー オペレーターをサポートできますが、セッション モードはサポートできません。セッションベースのモデル推論は 4 つのステップに分けられます: (1) モデルをロードし、セッションを作成し、計算グラフ内のすべての演算子をトポロジー順に配置し、すべての演算子に必要なテンソルを適用します; (2) 各入力が与えられた形状テンソルと各演算子の定義の、すべてのテンソルの形状を計算する; (3) 幾何学的計算を実行する、具体的には、まず変換演算子と複合演算子を原子演算子とラスター演算子に分解し、次にラスター演算子を垂直方向に結合し、 (4) 最適なバックエンドを半自動的に検索して特定し、各オペレーターにメモリを適用して順次実行し、推論結果を返します。2 番目のステップでは、制御フロー演算子は、後続の実行シーケンスを決定するために中間結果を必要としますが、これはセッション モードではサポートされていません。この問題を解決するために、モジュール パターンは、最初のステップでモデルをロードするときに、制御フロー オペレーターの位置に従って計算グラフを繰り返しモジュール (つまり、サブグラフ) に分割します。その後、各モジュールの実行はセッションと同じです。
        確率的勾配降下 (SGD) と適応モーメント推定 (ADAM) という 2 つの一般的なオプティマイザーを追加して、モデル トレーニングを実装します。下部に、すべてのアトミック オペレーターとラスター オペレーターのグラデーション オペレーターを追加します。

4.3 Python スレッドレベルの仮想マシン

        ほとんどの ML タスクは Python で実装されており、Python スクリプトを実行するには Python VM が必要です。CPython [43] と呼ばれる、公式で最も広く使用されている Python コンパイラおよびインタプリタを選択します。ただし、特にリソースに制約のあるモバイル デバイスへの CPython の移植には、2 つの重要な問題があります。最初の問題は、パッケージのサイズが大きいことです。たとえば、CPython 2.7.15 には、500 を超える C スクリプトと 1,600 を超えるライブラリが含まれており、モバイル アプリケーション用の多くの冗長な機能が含まれています。2 つ目の問題は、CPython が効率を向上させるためにマルチスレッドをサポートできないことです。CPython はもともと並行プログラミングをサポートできず、マルチプロセッシングを行うために GIL を導入しました。GIL では、1 つのプロセスで一度に 1 つのスレッドしか許可されません。ただし、各モバイル アプリには 1 つのプロセスしかなく、複数のプロセスは許可されていません。Python VM でタスクレベルのマルチスレッドをサポートする方法が問題になります。

        パッケージのサイズを縮小するために、Mobile Taobao の実際のニーズに応じて関数、ライブラリ、およびモジュールを調整しました。(1) 関数の調整: CPython は、最初に Python コードをファイル サフィックス ".pyc" を持つバイトコードにコンパイルし、次に実行のためにバイトコードを解釈します。コンパイル段階をクラウドに残し、実行のためにバイトコードのみをモバイル デバイスに送信することで、すべてのコンパイル モジュールを削除し、17 個のスクリプトを C で保持することができました。(2) ライブラリとモジュールのプルーニング: 36 個の必要なライブラリ (abc、type、re、func ツールなど) と 32 個のモジュール (zipimport、sys、exception、gc など) を保持しました。パッケージ仕立て後、業界初となる軽量モバイルPythonインタープリターを実装。たとえば、ARM64 ベースの iOS では、バンドル サイズが 10MB 以上からわずか 1.3MB に縮小されました。

        マルチスレッドに関しては、GIL を放棄し、複数のタスクの同時実行をサポートする業界初の Python スレッドレベル インタープリターをさらに設計および実装しました。図 6 に示すように、各タスクはスレッドにスケジュールされます。スレッドは独立した VM を作成し、VM ランタイムとタスク関連のデータを含みます。スレッド セーフの鍵は、スレッド レベルの VM 分離とデータ分離を実行し、VM をそのスレッドにバインドしてから、VM ランタイムのコンテキストをスレッドにバインドすることです。(1) VM 分離: 元の Python VM のライフサイクルはプロセス上で固定され、各プロセスには VM があります。VM インスタンスの作成を変更して、1 つのプロセスが複数のスレッド レベルの VM を保持し、それぞれが独自のライフサイクルを持つようにする必要があります。CPython では、VM は PyInterpreterState と呼ばれる C の構造体として定義されます。CPython が起動すると、PyInterpreterState インスタンスが初期化されます。CPython の初期化を変更しました。具体的には、スレッドごとに PyInterpreterState インスタンスを作成して初期化しました。(2) データの分離: VM 自体に加えて、VM ランタイムのコンテキスト (型システム、モジュール、タスク関連データなど) もスレッド レベルで分離して、マルチスレッドの同時実行性の問題と GIL を回避する必要があります。保護。データ分離にはスレッド固有データ (TSD) テクノロジを使用します. 各スレッドには独自のデータ空間があり、異なるスレッドが同じデータに同時にアクセスすることはできません. 主に、TSD を型システム、バッファー プール、オブジェクト割り当て、およびガベージ コレクションに適用します。

4.4 標準 API

        ML タスクをサポートするために、Python VM を介してデータ処理とモデル実行のクロスプラットフォーム ライブラリを公開します。前処理と後処理については、科学計算と画像処理 API は NumPy と OpenCV の元の API と一致しており、matmul、swaaxes、concatenate、split、resize、warpAffine、warpPerspective、cvtColor など、開発者にとって使いやすいものになっています。 、GaussianBlur など。推論およびモデル トレーニングのモデルについては、データの読み込み、モデルの読み込みと保存、セッションの作成と実行、オプティマイザー、ハイパーパラメーターの設定、損失の計算など、一般的なモデル レベルおよびデータ レベルの操作用の API が公開されています。

5. Walle のデータ パイプライン

        オンデバイス ストリーム処理フレームワークと、データ パイプラインのリアルタイム デバイス クラウド チャネルについて詳しく説明します。

5.1 デバイス側ストリーム処理フレームワーク

        主要な設計目標は、単一のデバイスで無限のデータ ストリームに対するステートフルな計算をサポートすることです。モバイル アプリケーションでのユーザーの行動データは、正確なタイム スタンプを使用してストリームで追跡されます。ユーザー行動データの処理はステートフルであり、中間結果はメモリにキャッシュされるか、後で使用するためにローカルに保存されます。1 つのデバイスのリソースは限られているため、多くのストリーム処理タスクのトリガー条件を適切に管理する必要があります。イベント シーケンスの作成、トリガー管理、タスクの起動、タスクの実行、および一括ストレージから、デバイス上のストリーム処理を導入します。ワークフローを図 7 に示します。

        イベント シーケンスの作成:ユーザーがモバイル アプリケーションを操作すると、ユーザーのアクションがイベントとして追跡されます。基本的なイベントには、ページ エントリ、ページ スクロール、インプレッション、クリック、ページ終了の 5 つの主なタイプがあります。各イベントは、一意のイベント ID、ページ ID、タイムスタンプ、およびイベント コンテンツ (たとえば、露出タイプのイベントのアイテム ID、クリック タイプのイベントのグラフ ウィジェット ID) と共にログに記録されます。ユーザーの行動には当然時系列があるため、時間レベルのイベント シーケンスを直接作成できます。特定のページ内または複数のページにわたるイベントの処理をさらに容易にするために、ページ レベルのイベント シーケンスは、同じページの入口イベントと出口イベントの間のイベントを集約することによって作成されます。
        トリガー管理:イベント シーケンス ベースのストリーム処理タスクには、スクリプトと構成が含まれます. スクリプトはデータ処理アルゴリズムを実装し、構成には主にトリガー条件が含まれます. 特に、トリガー条件は、一連のトリガー ID によって指定できます。トリガー ID は、イベント ID またはページ ID です。

        特定のモバイル デバイスでは、さまざまな機械学習タスクのさまざまな機能を生成するために、複数の前処理タスクを効率的に維持する必要があります。これにより、イベントが到着したときにすべての関連タスクをすぐにトリガーできます。重要なのは、トリガー条件を整理し、それらをすばやく一致させることです。トリガー条件をリストに格納する単純な方法は、リスト全体を毎回トラバースする必要があるため、非効率的です。実際、複数のトリガー ID シーケンスとイベント シーケンス (イベント ID とページ ID) の一致は、複数のワイルドカード パターンを使用した文字列一致問題としてモデル化できます。したがって、効率的なトリガー管理のために、トライと呼ばれるプレフィックス ツリー データ構造を活用します。具体的には、トライには開始ノード、中間ノード、葉ノードの 3 種類のノードがあります。トライのルートは唯一の開始ノードです。トリガー ID は中間ノードです。ストレージ ストリーム処理タスクのエンド ノードはツリーのリーフ ノードであり、その逆も同様です。新しいストリーム処理タスクが到着すると、トリガー ID シーケンスが中間ノード シーケンスとして抽出され、開始ノードと終了ノードのペアがノード シーケンスの最初と最後の位置にそれぞれ追加されます。次に、ルートから開始して、現在のトライに対して深さ優先検索が実行されます。パスがノードのシーケンスと正確に一致する場合、ストリーム処理タスクがリーフ ノードに追加されます。そうでない場合、一致しないノードは、深さ優先検索中に最後に一致したノードをルートとする新しいサブツリーとしてトライに追加されます。トライの各パスが一意のトリガー条件に対応し、リーフ ノードが同じトリガー条件でストリーム処理タスクを格納していることに気付きました。2 つのトリガー ID シーケンスが共通のプレフィックスを共有する場合、それらは同じサブツリーに配置され、トライのルートから共通のトリガー ID に対応するサブツリーのルートまでのパスに中間ノードが配置されます。

        トリガーされたタスク:新しいイベント (イベント ID とページ ID を含む) が到着すると、一連のトリガーされたタスクが返されます。最初に、2 つのトライ ノード リストを導入して、複数のトリガー条件の同時一致ステータスを記録し、ワイルドカード パターン マッチングによるブロックを回避します。静的保留リストには、すべてのトリガー条件の第 1 レベルのトリガー ID に対応するトライ ルートのすべての子ノードが格納され、照合のために常にアクティブに保たれます。動的保留リストには、進行中の一致で予想されるトリガー条件の次のノードが格納されます。ストリーム内のイベントの場合、そのイベント/ページ ID が静的リストまたは動的リスト内のいずれかのノードのトリガー ID と一致する場合、そのノードの各子ノードがチェックされ、それがリーフ ノードであるかどうかが確認されます。子ノードがリーフ ノードである場合、エンド ノードでストリーム処理タスクを返します。それ以外の場合、子は、新しい予想される次のノードとして動的リストのバッファに追加されます。タスク トリガー イベントの最後に、動的リストがバッファーに置き換えられ、バッファーがフラッシュされます。
        タスクの実行:タスクがトリガーされると、コンピューティング コンテナーでスクリプトが実行され、関連するイベントが処理されます。ストリーム処理フレームワークは、コンピューティング コンテナーの標準的なデータ処理およびモード実行 API に加えて、イベント シーケンスから関連するイベントおよびイベント コンテンツを抽出する処理を容易にするために、次のようないくつかの基本的な機能も提供します。 KeyBy、戻り値および特定のキー一致イベント。(2) TimeWindow、特定の時間枠内のイベントを返します。(3) Filter、定義されたルールに従ってフィルター処理されたイベントを返します。(4) Map、定義された関数を使用してイベント コンテンツを処理します。
        集合ストレージ:ストリーム処理タスクごとに、その出力 (通常は機能) が SQLite を使用してテーブルとして保存されます。ストリーム処理タスクが複数回トリガーされる可能性があり、1 回の出力が小さいことを考慮して、コレクション データ ストレージ API が SQLite の上にカプセル化され、書き込み回数が減り、パフォーマンスが向上します。具体的には、バッファ テーブルがメモリ内に作成され、ストリーム処理タスクの出力が最初にバッファ テーブルに書き込まれます。書き込み回数が特定のしきい値に達するか、読み取り操作が呼び出されると、バッファー テーブルはデータベースに 1 回書き込まれます。

5.2 リアルタイム デバイス クラウド チャネル

        ローカルで使用するだけでなく、オンデバイス ストリーム処理の出力をクラウドにアップロードして、リアルタイムで使用することもできます。永続的な接続ベースのデバイス クラウド トンネルを実装しました。Secure Sockets Layer (SSL) プロトコルは、接続の確立、暗号化、および復号化の時間を短縮するように最適化されています。データは送信前に圧縮され、送信後に解凍されます。高スループットに対応するために、完全非同期のサービス フレームワークがクラ​​ウド上に構築されます。

6. 展開プラットフォーム

        ML のタスク管理、公開、デプロイの詳細を紹介します。ワークフロー全体を図 8 に示します。
        タスク管理: Git [41] を採用して、さまざまなタスクの分離と特定のタスクのバージョン管理を実現しながら、アクセス制御による共同開発をサポートします。特に、タスク管理全体を git グループと見なし、各ビジネス シナリオは git リポジトリ (倉庫) に対応し、ビジネス シナリオ内の各タスクはブランチに対応し、タスクの各バージョンはタグに対応します。
        タスク エンティティの管理に加えて、タスク関連ファイル、特にリソース (データやモデルなど) はサイズが大きくなる可能性があり、統合されたカスタマイズされた展開をサポートするためにきめ細かい方法で管理されます。ファイルは 2 つのカテゴリに分類されます: 1 つは共有ファイルで、多数のモバイル デバイス (たとえば、特定のバージョンの APP を搭載したデバイス) で使用できます。もう 1 つは、一部のユーザーのみが使用できる専用ファイルです。デバイスまたは特定のデバイスでさえ。共有ファイルと専用ファイルは、それぞれ CDN と CEN を介して効率的に要求できます。

        タスクのリリースと展開:統合またはカスタマイズされた戦略を採用して、ターゲット デバイスにタスクを展開できます。統一された戦略は、APP バージョンごとのタスクのグループ化と公開をサポートしますが、カスタム戦略は、デバイス側の情報 (OS とそのバージョンまたはデバイスのパフォーマンスなど) およびユーザー側の情報 (年齢や習慣など) をさらにサポートできます。グループ内のデバイスの数に応じて、大まかな統合展開には一般に共有ファイルのみが含まれますが、きめ細かいカスタム タスクの展開には共有ファイルまたは専用ファイルが含まれます。非常にパーソナライズされたシナリオでは、カスタム ポリシーは特定の種類のタスクの展開をサポートしますが、個々のデバイスごとにユーザー固有/排他的なファイルを展開します。

        タスクのリリースに関しては、新しいプッシュ アンド プル アプローチを採用しています。既存のクライアント サービス リクエストを再利用してプッシュを実装し、モバイル デバイスのローカル タスク構成ファイルを HTTP ヘッダーに追加することで、クラウドが最新のタスク構成ファイルと比較できるようにします。新しいタスクをリリースする必要があり、統合された展開戦略が採用されている場合、クラウドは共有タスク ファイルの CDN アドレスに応答します。新しいタスクがカスタム展開戦略を採用している場合、クラウドはまずルール マッチングを通じてモバイル デバイスが属するグループを決定し、次に共有ファイルの CDN アドレスまたは排他ファイルの CEN アドレスに応答します。モバイル デバイスは、クラウドから応答を受信した後、CDN または CEN アドレスを使用して、最も近いノードからタスク ファイルを取得できます。頻繁なクライアントのビジネス要求を考慮すると、CDN と CEN は実際には比較的高速であり、タスクの展開の適時性を確保できます。
        タスクのリリースと展開の安定性を確保するために、クラウド コンピューティング コンテナーを使用して、さまざまなオペレーティング システムでさまざまなバージョンの携帯電話 APP シミュレーターを作成し、プレリリース タスクの広範なテストを実施できます。シミュレーション テストに合格すると、ベータ リリースが実行され、少数のターゲット デバイスにのみタスクが展開されます。内部テストに合格すると、段階的にグレースケール リリースが強制的に実行され、すべてのターゲット デバイスが徐々にカバーされます。展開プラットフォームには、タスクの失敗率をリアルタイムで監視できる例外処理モジュールも装備されており、失敗率が特定のしきい値を超えた場合は、すぐにロールバックできます。

7. ウォールの実験

        2 つの Alibaba アプリケーション シナリオで Walle を評価します。また、MNN、Python スレッドレベル VM、およびリアルタイム チャネルで広範なベンチマークも実行します。最後に、デプロイされたプラットフォームに関する統計を報告します。

7.1 e コマース シナリオでのパフォーマンス

        ライブ ブロードキャストにおけるコンピューティング コンテナーのパフォーマンス: e コマースのライブ ブロードキャストは、何億ものユーザーに新しいオンライン ショッピングの方法をもたらしました。2020年、モバイル淘宝ライブストリーミングのGMVは4000億元を超える。このシナリオにおける重要な ML タスクは、ハイライト認識です。つまり、アンカーがアイテムに関する魅力的な情報を紹介している時点を特定します。

        従来のクラウドベースの ML パラダイムでは、スポット認識のために各アンカーのモバイル デバイスからクラウドにビデオ ストリームがアップロードされます。スポット認識には、主にアイテムの検出と認識、アンカーの顔検出と音声検出が含まれます。多数のオンライン アンカーと長いビデオ ストリームが原因で、ハイライト認識には遅延に関する厳しい要件があり、クラウドの負荷が重すぎます. ビデオ ストリームの一部と少数のサンプリングされたフレームしか分析できません。実際の重要なボトルネック。

        Walle を使用すると、軽量モデルのハイライト認識タスクをアンカーのモバイル デバイスにオフロードし、エンド クラウドのコラボレーション ワークフローを実現できます (図 9 参照)。オンデバイス モデルがビデオ内の信頼性の高いストリーム ハイライトを識別できる場合、これらのハイライトは後処理後にユーザーに直接表示できます。モバイル デバイスで低い信頼度で識別され、実際には約 12% を占める明るいスポットのみが、クラウド内の大規模モデルによって処理される必要があります。クラウドに認識された後、認識率は約 15% で、ハイライトはモバイル端末に送信されます。

        デバイスとクラウドの連携により、ハイライト認識でカバーされるアンカーとビデオ ストリームの数が大幅に増加し、クラウドの負荷も大幅に軽減されました。特に、ビジネス統計によると、クラウドベースのパラダイムと比較して、新しいエンドクラウド コラボレーション ワークフローでは、ハイライト認識を使用するアンカーの数が 123% 増加し、各ハイライト認識のクラウド コンピューティング負荷が 87% 削減され、各ユニットがクラウド コストについて毎日特定される明るい点のサイズは 74% 増加しました。また、Huawei P50 Pro および iPhone 11 でのハイライト認識をサポートする Walle コンピューティング コンテナーのパフォーマンスも評価します。合計レイテンシは、それぞれ 130.97 ミリ秒と 90.42 ミリ秒です。具体的には、表 1 に、採用されたモデルのネットワーク アーキテクチャ、パラメーター サイズ、および推論レイテンシーを示します。上記の結果は、コンピューティング コンテナーの高いパフォーマンスと、デバイスとクラウドのコラボレーションの実際の有効性を示しています。

        レコメンデーションのデータ パイプライン:アリババのクラウドおよびデバイス側のレコメンデーション モデルでは、製品詳細ページでのユーザーの行動 (お気に入り、ショッピング カートへの追加、購入など) を記録するアイテム ページ ビュー ( IPV ) 機能は、かなりの重要性。従来のクラウドベースのパラダイムでは、IPV 署名を生成するために、すべてのユーザーの生のイベント データがクラウドにアップロードされてストリーム処理され、明示的な識別のためにユーザー ID と混合されます。各モバイル デバイスからの時間レベルのイベント シーケンスは、複数の同種のシーケンスに分割され、1 つのシーケンスには何らかのイベントが含まれます。各ユーザーの IPV 特性を取得するために、クラウドはユーザー ID とページ ID をキーとして使用して、すべてのユーザー イベントに対して共同操作を実行します。これは、時間がかかり、リソースを大量に消費し、エラーが発生しやすくなります。
        データ パイプラインのデバイス側のストリーム処理フレームワークを通じて、各モバイル デバイスは、ユーザーに対応するローカル イベントのごく一部を処理するだけで済みます。これは、より効率的で自然です。実際、IPV 機能は一連のページ レベル イベントの生成プロセスを呼び出します。入力は一連の時間レベルのイベントです。トリガー条件はページ終了イベントです。トリガー ストリーム処理タスクは、すべてのイベントを集約することです (つまり、同じ種類のイベントをクラスター化し、ページ エントリおよびページ終了イベントをカウントします)。各イベントの生のコンテンツには冗長なフィールド (デバイス ステータスなど) が含まれているため、イベント コンテンツにフィルタリングが適用されます。さらに、IPV 機能が最初にレコメンデーション モデルで (たとえば、RNN を介して) エンコードされるという事実を考慮すると、コンピューティング コンテナーのモデル推論 API を使用して、エンコード プロセスをモバイル デバイスにオフロードすることもできます。

        最初に、未加工のイベント データから IPV 機能および IPV エンコーディングへのサイズ削減を示します。平均して、IPV 署名のサイズは約 1.3KB で、19.3 個の raw イベントを含み、サイズは 21.2KB ですが、IPV エンコーディングはわずか 128 バイトです。
これは、ストリーム処理のために未加工のイベント データをクラウドに転送する従来のパラダイムと比較して、新しい IPV データ パイプラインが通信コストを 90% 以上節約できることを示しています。通信効率に加えて、オンデバイスとクラウドベースのストリーム処理のレイテンシーも比較します。生のイベントを IPV 署名に処理する 10,000 を超える実世界のケース (200 万のオンライン モバイル クライアントのケース プールからランダムにサンプリング) を分析することにより、デバイスの平均遅延はわずか 44.16 ミリ秒です。比較すると、Blink と呼ばれる Alibaba の内部バージョンの Flink を使用した場合、IPV 機能を生成するための平均レイテンシは 33.73 秒でした。特に、200 万人を超えるオンライン ユーザーの元のイベントのクラウドベースのストリーム処理は 253.25 コンピューティング ユニット (CU) を消費し、そのうち 1 CU は 1 CPU コアと 4 GB のメモリを表し、IPV 機能生成のエラー率は 0.7 です。 %; 平均遅延 10,000 のランダム サンプルで通常の条件下で分析されます。これらの結果は、主流のクラウドベースのデータ パイプラインと比較して、Walle の新しいデータ パイプラインが、機能の適時性と有効性を改善しながら、デバイスとクラウドの通信コストとクラウドの負荷を実際に削減できることを示しています。

7.2 ベンチマーク

        最初に、MNN を Android および iOS デバイスと Linux サーバーで TensorFlow (ライト バージョン) および PyTorch (モバイル バージョン) と比較します。デバイス側のテストには Huawei P50 Pro と iPhone 11 を使用し、バックエンドはシングルスレッドの ARMv7、ARMv8、ARMv8.2、OpenCL、Metal をカバーしています。サーバー側のテストには、AMD Ryzen 9 3900X (x86)、Alibaba Cloud の ecs.g6e.4xlarge (Intel Xeon (Cascade Lake) Platinum 8269CY、16 vCPU、64GiB メモリ)、および NVIDIA GeForce RTX 2080 Ti を使用して、それぞれバックエンドをカバーします。 4 スレッドと CUDA を備えた AVX256 および AVX512。ResNet 18 [22]、ResNet 50 [22]、MobileNet V2 [38]、SqueezeNet V1.1 [27]、ShuffleNet V2 [33]、BERT-SQuAD 10 [10]、DIN [46] をテスト モデルとして使用します。 CV、NLP、および推奨アプリケーションで一般的に使用されます。CVモデルの入力サイズは1×3×224×224、BERT SQuAD 10の入力サイズは(1×256,1×256,1×256,1)、DINの入力サイズは1×100×32に設定されています。図 10 の左側に CV および NLP モデルの推論時間を示し、非常に低い DIN の結果 (たとえば、MNN を使用した iPhone 11 で < 0.2ms) を省略しています。ほとんどすべてのテスト ケースで、MNN が TensorFlow (ライト バージョン) および PyTorch (モバイル バージョン) よりも大幅に優れていることがわかります。MNN はデバイス側の各バックエンドのすべてのモデルをサポートできますが、TensorFlow Lite と PyTorch Mobile は一部のバックエンドやモデルをサポートできないため、MNN はより高いパフォーマンスに加えて、モバイル デバイス側でもより包括的です。

        MNN と TVM の比較を続けます。MacBook Pro 2019 と NVIDIA GeForce RTX 2080 Ti を TVM ホストとして使用して、モバイル デバイスと GPU サーバーをそれぞれ自動的に調整およびコンパイルします。TVM オートチューニングの試行回数は 30 回とした．2 台のモバイル デバイスでの BERT-SQuAD 10 の TVM 自動調整は curs タイムアウト クラッシュにあるため、モデルの推論にはデフォルトのパラメーター設定を使用します。図 10 の右側に示されている評価結果から、TVM の自動調整とコンパイルに数千秒のオーダーがかかったという重要な観察結果があります。対照的に、ランタイム最適化のための MNN の半自動検索には、数百ミリ秒のオーダーがかかります。セクション 4.1 の比較分析とさらに組み合わせると、MNN は多数の異種デバイスを含み、頻繁かつ高速なタスクの反復を必要とする産業シナリオをサポートできますが、TVM はサポートできないと結論付けることができます。2 番目の重要な観察結果は、すべてのバックエンドのすべてのモデルで、特に GPU サーバーで、MNN が TVM よりも推論時間が短いことです。この利点は、主に手動オペレーター レベル、MNN におけるバックエンド レベルの最適化によるものです。

        次に、約 3,000 万回のオンライン ML タスク実行を使用して、Walle の Python スレッドレベル VM を元の Python VM (つまり、CPython と GIL) と比較します。パフォーマンスをタスク実行時間の逆数と定義し、平均的なパフォーマンスの向上を図 11 に示します。Python スレッド レベルの VM は、軽量タスク、中重量タスク、および重量タスクで、それぞれ 52.11%、144.36%、および 25.70% のパフォーマンス向上パーセンテージを提供します。GIL を使用しないタスクレベルのマルチスレッド化がパフォーマンス向上の鍵であると結論付けることができます。
        最終的に、約 3 億 6,400 万回のアップロードでリアルタイム トンネルのレイテンシを評価しました。図 12 は、さまざまなデータ サイズのレイテンシとアップロード数を示しています。アップロードの 90% 以上が 3KB 未満で、平均 250 ミリ秒未満であることがわかります。0.1% のアップロード サイズが 30KB に増加しても、平均レイテンシは約 450 ミリ秒にしか増加しませんでした。

7.3 展開プラットフォームの統計

        2017 年末以来、Wole 展開プラットフォームは、Taobao、AliExpress、Xianyu、Youku、Cainiao Guoguo などの 30 以上のモバイル アプリをサポートしており、稼働時間は約 1,500 日です。合計 1000 以上の ML タスクがデプロイされ、タスクあたり平均 7.2 バージョンでした。現在、展開プラットフォームは、3 億を超えるモバイル デバイスで 348 のアクティブなタスクを維持および監視しています。タスク展開の適時性を実証するために、ML タスクをランダムに選択し、そのリリース プロセスを監視します。図 13 では、対象となるデバイスの数が時間とともにどのように変化するかを示しています。曲線の最初の部分は灰色のリリース フェーズで、600 万台のオンライン デバイスすべてに到達するまでに 7 分かかります。特に、約 400 万台のデバイスが最後の 1 分間で段階的にカバーされました。その後、オンラインになるモバイル デバイスが増えるにつれて、対象となるデバイスの数が増加します。19 分までに、ほぼ 2,200 万台のデバイスがカバーされました。このデータは、Walle の展開プラットフォームのスケーラビリティと適時性を示しています。

8. 関連作品

        このセクションでは、学界と産業界での関連する仕事を簡単に確認します。

        クラウドベースの機械学習システム:多くの企業が自社の ML システムをクラウド上に構築しています。これは、Amazon Web Services、Microsoft Azure、Alibaba Cloud、Google Cloud などのクラウド コンピューティング プラットフォームによってサポートされています。データ ストレージ (HBase [14] や HDFS [13] など)、バッチおよびストリーム処理 (Storm [42]、Spark [45]、Flink [7] など)、ML エンジン (など) の標準モジュールを含む明確なアーキテクチャTensorFlow [1]、PyTorch [36]、MXNet [8] など)、仮想化とコンテナー化 (KVM [37] や docker [26] など)、エラスティック オーケストレーション (Kubernetes [15] など) などです。

        オンデバイス ML システム:一部のモジュールはオープンソースであり、オンデバイス推論エンジン (例: TensorFlow Lite [16]、PyTorch Mobile [12] ]、Core ML [3] ]、および NCNN [39]); SQLite [24] は、小型で自己完結型の SQL データベース エンジンです。ただし、アーキテクチャ全体はまだ混乱しており、複数の ML タスクの迅速な開発と同時実行をサポートするオンデバイス実行環境や、さまざまな CV、NLP、および推奨タスク。
        Device-Cloud Collaborative ML:この概念はエッジ/モバイル コンピューティングにまでさかのぼりますが、単純なデータ分析タスクをクラウドからエッジ サーバーまたはモバイル デバイスにオフロードするのではなく、複雑な ML タスクを実行する際のクラウドとモバイル デバイスのコラボレーションに焦点を当てています。これまでの研究は、アルゴリズムのフレームワークやソリューションに焦点を当てており、多くの場合、ある種のアプリケーションに固有のものでした。これに対応して、Walle の目標は、一般的で大規模な生産システムのサポートです。以下に代表的な作品をいくつか紹介する。
        最初のパラダイムは、モデルのトレーニングをクラウドに保持し、モデルの推論 (顔認識、写真の強調、質問への回答など) をモバイル デバイスにオフロードして、レイテンシの短縮とプライバシーの保護におけるオンデバイスの利点を実証することです。このパラダイム増殖の鍵は、量子化 [19]、刈り込みとスパース化 [20]、知識の蒸留 [23]、ニューラル アーキテクチャ検索 [47] など、モデル サイズを縮小し、モデル構造を最適化するためのモデル圧縮アルゴリズムの進歩です。その後、Mistify [18] は、異種モバイル デバイスのカスタマイズのニーズを考慮して、クラウドからデバイスへのモデル移行プロセスを自動化し、一部の研究では、完全な推論タスクをオフロードする代わりに、より合理的なタスク分割戦略を設計しました。たとえば、Neurosurgeon [29] は、DNN レイヤーの粒度でモバイル デバイスとクラウドの間で DNN 計算を自動的に分割することを提案しています。

        推論に加えて、人気のあるクロスデバイス連合学習 (FL) フレームワーク [34] は、従来のパラメーター サーバー フレームワーク [30] をエレガントに一般化し、複数のモバイル デバイスがクラウド サーバーの調整の下でグローバル モデルを共同でトレーニングできるようにします。FL の目的は、ユーザー データをローカル デバイスに保存して、データのセキュリティとプライバシーを保護することです。FL でのデバイスとクラウドのコラボレーションは、純粋に交換モデルと定期的な更新を通じて行われます。タスク分割戦略は、モバイル デバイスでモデルをトレーニングし、クラウドでモデルを更新することです。Google は、言語モデルを改良するために Gboard と呼ばれる Android キーボードに実験的に FL を展開しました [5]。

        最後に、デバイスとクラウドのコラボレーションの原則の下で、多くのアプリケーション固有のソリューションが提案されています。FilterForward [6] と Reducto [31] は、効果的かつ効率的なカメラ側のフレーム フィルタリングに ML 技術を使用して、クラウドベースのビデオ分析を促進する方法を検討しています。DDS [11] は、カメラが最初に低品質のビデオ ストリームをアップロードし、次にクラウドからのフィードバックに基づいて高品質のいくつかの重要な領域を再送信して、推論の精度を向上させるインタラクティブなワークフローを採​​用しています。COLLA [32] は RNN を使用してユーザーの行動予測タスクを研究し、知識の蒸留を使用して、デバイス側の小さなモデルとクラウド上の大きなモデルの間で知識を継続的に転送することで、時間の経過に伴うデータの不均一性とデータのドリフトを軽減しました。DDCL [44] と CoDA [17] は推奨に重点を置いています。DDCL は、デバイス上のモデルのパーソナライゼーションにパッチ学習を利用し、モデルの蒸留を通じてモバイル デバイス上のパッチをクラウド内のグローバル モデルに統合します。代わりに、クラウド内のグローバル プールから同様のサンプルを取得して、各モバイル デバイスのローカル データセットを拡張し、パーソナライズされたレコメンデーション モデルをトレーニングする CoDA が提案されています。Walle の支援を受けて、CoDA は Mobile Taobao に参入しました。

9. 結論

        この作業では、Walle と呼ばれる、デバイスとクラウドの共同 ML 用の最初のエンドツーエンドの汎用大規模生産システムを構築します。Walle は ML タスクのライフ サイクルを重視しており、クロスプラットフォームで高性能、高速反復コンピューティング コンテナー、より合理的で効率的なデータ パイプライン、およびスケーラブルでタイムリーで強力な展開プラットフォームで構成されています。実際の e コマース シナリオと広範なマイクロ ベンチマークでの Walle の評価は、デバイスとクラウドのコラボレーションの必要性と各コンポーネントの優位性を示しています。Walle は Alibaba で大規模な生産と使用に展開されており、毎日何十億ものモバイル デバイス ユーザーにサービスを提供しています。