How to Break the Dilemma of Limited Computing Power on Edge Chip

1. 背景

1.1 チップがなければ AI なし

人工知能産業の急速な発展は、アルゴリズムの実現、大量のデータの取得と保存、コンピューティング能力の発揮のいずれにおいても、現在の唯一の物理的基盤であるチップと切り離せません。市場のビジネスニーズを満たす AI チップの有無が重要になります。

対象アプリケーションが「トレーニング」か「推論」か、そして「クラウド」か「エッジ」かによって、AI チップは前述の図に示すように 4 つの象限に分類できます。

クラウドトレーニング：深層ニューラルネットワークのほとんどはクラウド上でトレーニングされます。この市場では、NVIDIA シリーズの GPU チップが最も広く使用されています。

クラウド推論：モデルトレーニングとは異なり、多くの企業がクラウド推論専用のチップを投入しています。Google の TPU チップ、Intel の Nervana シリーズチップ、Cambrian の MLU100 チップなどがその例です。Pingtouge は今年中に最初の AI チップである Ali-NPU を発売する予定です。Ali-NPU はクラウド推論に使用されます。

エッジ側推論：クラウドと比較して、エッジ側は現在主に推論を中心に展開しています。AI コンピューティング能力をエッジに投入してエッジインテリジェンスを実現することが大勢であり、ますます多くの AI アプリケーションがエッジデバイス上で開発・デプロイされるようになっています。

エッジ側トレーニング：同時に、Google が Federated Learning (FL) を提唱し、最初の商用グレードのエッジ側分散機械学習システムを投入したことにより、エッジおよび組み込みデバイスでの学習とトレーニングがますます重要になっています。クラウド上でのトレーニングと比較して、エッジデバイスでのトレーニングは、ユーザープライバシーの保護やよりパーソナライズされたサービスの提供において大きな利点があり、モデルをよりスマートにし、ユーザーができるだけ早く更新されたモデルを体験できるようにします。

1.2 なぜエッジコンピューティングが必要なのか

エッジコンピューティングは低レイテンシ、帯域幅の節約、オフラインでの可用性、プライバシー保護といった特徴を備えているため、多くのアプリケーションがエッジデバイス上での推論に適しています。インテリジェンスは端末デバイスに集約され、インテリジェントなエッジコンピューティングが台頭してきます。たとえば、数百万台の高精細カメラからのデータをすべてクラウドで処理する場合、ビデオ監視タスクではネットワークに大きな負荷がかかります。また、自動運転の推論はクラウドで実行することはできません。ネットワークに問題が発生した場合、壊滅的な結果を招く可能性があるためです。

1.3 なぜ独自開発のアルゴリズムエンジンが必要なのか

エッジデバイスはカメラや携帯電話だけにとどまりません。その応用範囲は、コンピューティング能力への需要が大きい自動運転から、複数のセンサーフュージョンを搭載した配膳ロボット、消費電力とコストに敏感なウェアラブルデバイスまで多岐にわたり、その種類はさまざまです。現在の AI アプリケーションシナリオでは、エッジデバイスは主に推論計算を実行しますが、これにはエッジデバイスのチップに十分なコンピューティング能力が求められます。しかし、現状のエッジプロセッサチップのコンピューティング能力は比較的限られています。この限られたコンピューティング能力をより有効に活用し、基盤となるハードウェアの詳細を隠蔽し、ビジネスの迅速な実装を実現するのがアルゴリズムエンジンの責務です。

ACE (AI Labs Compute Engine) は、デバイスとクラウドの統合ソリューションにおいて、エッジデバイス側で CPU、GPU、DSP、専用 AI チップなどのヘテロジニアスコンピューティング方式をサポートするコンピュートエンジンです。独自開発ハードウェアについては、メインチップとデータ処理チップの選定段階からチップメーカーと緊密に連携し、ドライバ層から HAL 層、システム層に至るまで深いカスタマイズと最適化を行い、独自ハードウェア専用のアルゴリズムエンジンを開発して上位レベルのビジネスのより良い運用をサポートします。

Tmall Genie を例に挙げると、アルゴリズムチームと緊密に連携し、使用していた低価格チップを実際のビジネスに合わせてカスタマイズ・最適化しました。ACE を通じて、ジェスチャー認識など比較的高いリアルタイムコンピューティング能力を必要とするアプリケーションを正常に実装できました。

2. アーキテクチャ概要

計算エンジン：

コンピューティング層：モデル量子化、ヘテロジニアスコンピューティング、メモリフレンドリ性、アセンブリ最適化などの手法を採用してアルゴリズムを高速化します。

アクセス層：アルゴリズムサービスを計算グラフの形式で編成し、共通の演算子を提供して開発サイクルを短縮します。

モデル管理：

クラウド：AutoAI プラットフォームと連携してモバイルモデルを生成します。

エッジ：クラウドからのコマンドを受信し、能動的に情報をプッシュします。

3. 計算エンジン

3.1 コンピューティング層

人工知能は高価なエンタープライズサービスだけに存在するものではなく、AI の楽しさをスマートテレビ、IoT、スマートスピーカーなど多くのスマートデバイスに導入し、より多くのユーザーに AI がもたらす変化を体験してもらう必要があります。これらの端末スマートデバイスのコンピューティング能力は一般的に限られているため、モデル量子化、ヘテロジニアスコンピューティング、メモリフレンドリ性、アセンブリ最適化などの手法を採用してアルゴリズムを高速化します。

■モデル量子化
低価格コンピューティングチップを使用する製品にジェスチャーアルゴリズムを最初に適用した際、クラウドで使用していた検出モデルは float32 モデルで、処理に数百ミリ秒を要していました。コア処理時間は 130 ms まで短縮しましたが、理想的な 20 フレーム/秒の速度にはまだ一定のギャップがありました。

そこでモデル量子化を採用してさらに高速化を図ります。量子化された固定小数点計算は、浮動小数点計算に比べて計算リソースとメモリを節約できます。さらに量子化後の推論プロセスを深く最適化します。

量子化後、シングルコアの処理時間は 59 ms に短縮され、検出フレームレートは 17 フレーム/秒に達し、4 コアの float32 モデルよりも高速になりました。

より良い量子化加速効果を得るため、メモリフレンドリ性やアセンブリ最適化といった従来の手法を採用するとともに、QNNPACK アクセラレーションライブラリを導入しました。このライブラリはモデル量子化加速に特化して設計されており、TFLite と同じ量子化原理を採用しています。最終的に、ジェスチャーモデルのシングルコア処理時間を 41 ms に短縮し、合計 3.17 倍の加速を実現し、モデルメモリ使用量を 74% 削減しました。

標準的な mobilenet_v2_1.0_224 モデルを例に取ると、シングルコア量子化の加速効果は 2.2 倍に達します。

マルチスレッドのシナリオに向けて、カーネルの並列性も高め、2 コアでの加速効果は約 3 倍になりました。

■ヘテロジニアスアクセラレーション
CPU 上では他の多くのビジネスが実行されているため、計算に使用できる CPU リソースは比較的限られており、汎用プロセッサの CPU 性能はもはやムーアの法則に従って成長できなくなっています。一方、データの増加は「ムーアの法則」を超える速度でコンピューティング性能を要求しており、コンピューティング能力の需要と実際のパフォーマンスの間に大きなギャップが生じています。ヘテロジニアスコンピューティングはそのギャップを埋める主流のソリューションです。

汎用性を追求する汎用計算とは異なり、専用計算は特定の用途に最適化されています。パフォーマンスや消費電力などの指標は通常、汎用 CPU よりも桁違いに優れていますが、適用できるシナリオは限られています。汎用と専用の関係は、何でも知っているが基本的にはどれも得意ではない「ゼネラリスト」と、特定の分野で深く研究しているが他の分野についてはほとんど知らない「スペシャリスト」のようなものです。ヘテロジニアスコンピューティングは一般的に CPU と専用デバイス (GPU、DSP、VPU、FPGA など) で構成される混合システムであり、異なる種類の命令セットと異なるアーキテクチャを使用して協調計算を実行します。

あるチップ上のビジネスを例に取ると、大量のビジネスが CPU を使用している一方で GPU は比較的空いています。この状態で CPU 上でペン先検出アルゴリズムを実行すると、4 スレッドで 260 ms を要し、CPU 消費量が 240% を超え、他のビジネスに大きな影響を与えます。しかし、CPU と GPU のヘテロジニアスコンピューティング方式を使用すると 150 ms で済み、CPU 消費量は 245% から 50% に削減され、全体のリソースをより有効に活用できます。

このチップでは、GPU のほかにヘテロジニアスコンピューティングリソースとして固定小数点計算アクセラレータ VPU があります。ペン先検出モデルを量子化すると、VPU を使用して加速できます。量子化バージョンのペン先検出モデルを CPU 4 スレッドで計算すると約 76 ms で、float32 の 260 ms から大幅に改善されますが、CPU のすべてのコンピューティングリソースを消費し、他のビジネスが正常に動作しなくなります。しかし、CPU と VPU のヘテロジニアスコンピューティング方式を使用するとわずか 51 ms で済み、CPU リソースの大部分を節約し、全体の消費電力も削減できます。

3.2 アクセス層

アクセス層の役割は、アルゴリズム開発プロセスを簡素化し、デバッグとメンテナンスの効率を向上させ、ビジネスの迅速な実装を実現することです。主に以下の方法でこの目標を達成します。

AutoAI のワンストップソリューションと連携して、モデルトレーニング、計算グラフ構築、モデル管理の全プロセスを統合します。

アルゴリズムチームと共同で共通の High Level および Low Level 演算子を開発し、モジュール化された演算子ライブラリを作成します。

API と UI を簡素化して計算グラフの構築を容易にし、計算グラフ、モデル、設定などのリソースを単一ファイルにパッケージングできるようにして、管理の難易度を下げます。

ディープラーニングと従来のアルゴリズムのハイブリッドグラフ計算をサポートし、エンジニアリングコードの開発量を削減するとともに、パフォーマンス分析、問題の特定、アルゴリズム評価などの機能を提供して、デバッグの難易度を下げ、ビジネス実装のスピードを向上させます。

4. モデル管理

モデル管理は ACE の重要な機能です。クラウドとエッジの 2 つの部分で構成され、モデルとビジネスの 2 つのディメンションを柔軟に管理できます。従来、エッジ側はシステムソフトウェアのアップグレードを通じてモデルを更新する必要があり、新モデルのオンラインリリースやグレーリリーステストもソフトウェアアップグレードのペースに合わせる必要がありました。しかし、新モデルを迅速に小規模テストしたい場合もあるため、この機能をサポートするモデル管理システムが必要になります。

4.1 クラウドモデル管理

モデル管理システムは、正確にはエッジ側の各アルゴリズムモデルを管理するクラウドバックグラウンドシステムであり、その中核はクラウドにあります。クラウドモデル管理システムの構造は前述の図の通りです。バックグラウンドインターフェイスでは、サーバー側からエッジ側を制御する操作を行えます。現在サポートされている操作は以下の通りです。

クエリ (Query)：特定のデバイス上のモデルの詳細を照会します。

ダウンロード (Download)：特定のモデルをエッジ側にダウンロードします。

リロード (Reload)：エッジ側の特定のモデルやビジネスを切り替えます。

リセット (Reset)：エッジ側のモデルを初期状態にリセットします (緊急時のみ使用)。

4.2 エッジモデル管理

一般的に、モデル管理はモデルディメンションのみに基づいて行われ、モデル間の結合はありません。しかし、場合によってはこのアプローチが適切でないことがあります。ペット検出と動画でのジェスチャー認識を例に、モデル結合のケースを説明します。

前述の図に示すように、エッジ側のストレージ容量と計算量を節約するため、ペットとジェスチャーの 2 つのビジネスが同じモデルを共有しています。したがって、モデルベースの単一次元管理だけでは需要を満たせなくなります。

この問題を解決するため、モデルディメンションにビジネスディメンションを追加します。ビジネスはモデルの上位層の抽象化です。ビジネスとモデルは多対多の関係を持ち、複数のビジネスが同じモデルを共有できるため、結合の問題を効果的に解決できます。

5. 将来に向けて

ACE の使命は、アルゴリズムを Tmall Genie やロボットなどの独自開発エッジデバイスに迅速かつ正確に適用し、関連する上位レベルのサービスを適切にサポートすることです。まだ改善の余地はありますが、今後の開発プロセスでユーザビリティを継続的に向上させ、ボトムレイヤーの最適化とアクセラレーションに注力し、メーカーとさらに深く連携してソフトウェアとハードウェアの組み合わせを実現し、端末の限られた計算リソースを合理的に活用していきます。