CNN 推論エンジンを使用して IoT デバイスにディープラーニングを実装するにはどうすればよいですか?

[[212457]]

ディープラーニング技術により、モノのインターネット (IoT) デバイスは非構造化マルチメディア データを解析し、ユーザーや環境のイベントにインテリジェントに応答できますが、これには厳しいパフォーマンスと電力消費の要件が伴います。この記事の著者は、ディープラーニングを低電力 IoT デバイスにうまく統合するための 2 つのアプローチを検討します。

近年、周囲の環境データを収集し、従来の機械学習技術を使用してそのデータを理解する IoT 製品が市場にますます多く登場しています。一例として、Google の Nest サーモスタットが挙げられます。このサーモスタットは、温度データを構造化された方法で記録し、アルゴリズムを使用してユーザーの温度設定やスケジュールを学習します。ただし、オーディオ信号や視覚画像などの非構造化マルチメディア データには無力です。

新たな IoT デバイスは、ニューラル ネットワークを使用して環境を探索する、より洗練されたディープラーニング技術を採用しています。たとえば、Amazon Echo は人間の音声コマンドを理解し、音声認識を使用してオーディオ信号を単語の文字列に変換し、これらの単語を使用して関連情報を検索できます。最近、マイクロソフトの Windows IoT チームは、ディープラーニング技術を使用して、ユーザーの顔が認識されると自動的にドアのロックを解除する顔認識ベースのセキュリティ システムをリリースしました。

IoT デバイス上のディープラーニング アプリケーションには、厳しいリアルタイム要件が求められることがよくあります。たとえば、物体認識に基づく防犯カメラが家の中に現れた不審者に迅速に反応するには、通常、対象イベントを捕捉して処理するのに 500 ミリ秒未満の検出遅延が必要です。消費者向け IoT デバイスは、通常、クラウド サービスを使用して何らかのインテリジェンスを提供します。ただし、これらのデバイスが依存する高品質のインターネット接続は特定のエリアでのみ利用可能であり、高額な費用がかかることが多く、デバイスがリアルタイム要件を満たせるかどうかという問題が生じます。対照的に、接続品質の影響を受けないように、IoT デバイスに直接ディープラーニングを実装する方がよい選択肢となる可能性があります。

しかし、ディープラーニングを組み込みデバイスに直接実装するのは困難です。実際、低消費電力はモバイル IoT デバイスの重要な機能であり、通常は計算能力が限られており、メモリ容量が小さいことを意味します。ソフトウェア側では、メモリフットプリントを削減するために、アプリケーションはベアメタル上で直接実行されるか、サードパーティのライブラリを最小限に抑えた軽量のオペレーティング システム上で実行されることがよくあります。対照的に、ディープラーニングは高性能コンピューティングを意味し、高い電力消費を伴います。さらに、既存のディープラーニング ライブラリでは通常、多くのサードパーティ ライブラリを呼び出す必要があるため、IoT デバイスへの移行は困難です。

ディープラーニングタスクで最も広く使用されているニューラル ネットワークは畳み込みニューラル ネットワーク (CNN) であり、非構造化画像データを構造化オブジェクト ラベル データに変換できます。一般的に、CNN のワークフローは次のようになります。まず、畳み込み層が入力画像をスキャンして特徴ベクトルを生成します。次に、活性化層が画像推論中にどの特徴ベクトルを活性化して使用するかを決定します。3 番目に、プーリング層を使用して特徴ベクトルのサイズを縮小します。最後に、完全接続層を使用してプーリング層のすべての出力を出力層に接続します。

この記事では、CNN 推論エンジンを使用して IoT デバイスにディープラーニングを実装する方法について説明します。

サービスをクラウドに移行する

低電力 IoT デバイスの場合、電力とパフォーマンスの要件を満たしながらクラウドにディープラーニングを展開できる信頼性の高いソリューションがあるかどうかが問題となります。この質問に答えるために、Nvidia Jetson TX1 デバイスに CNN ベースのオブジェクト推論を実装し、そのパフォーマンスと電力消費をこれらのサービスをクラウドに移行した場合のパフォーマンスと電力消費と比較しました。

サービスをクラウドに移行することで電力消費を削減し、物体認識タスクのリアルタイム要件を満たすことができるかを判断するために、画像をクラウドに送信し、クラウドが結果を返すのを待ちました。研究によると、物体認識タスクの場合、ローカル実行時の消費電力は 7 W ですが、クラウドへの移行後は消費電力が 2 W に削減されます。これは、サービスをクラウドに移行することが、実際に電力消費を削減する効果的な方法であることを示しています。

ただし、クラウドに移行すると、少なくとも 2 秒、場合によっては最大 5 秒の遅延が発生し、500 ミリ秒というリアルタイム要件を満たすことができなくなります。さらに、レイテンシの大きなジッターにより、サービスの信頼性が非常に低くなります (比較のため、これらの実験はそれぞれ米国と中国で実行しました)。これらの実験を通じて、リアルタイムのディープラーニングタスクをクラウドに移行することは、現在のネットワーク環境ではまだ実現可能なソリューションではないという結論に達しました。

ディープラーニングプラットフォームを組み込みデバイスに移植

現実的ではないクラウドへの移行の代わりに、既存のディープラーニング プラットフォームを IoT デバイスに移植するという選択肢もあります。この目的を達成するために、私たちは、Google が開発しオープンソース化したディープラーニング プラットフォームである TesnsorFlow を移植し、PerceptIn のベアメタル ARM システム オン チップであるオブジェクト推論機能を備えた IoT デバイスである Zuluko を構築することを選択しました。 Zuluko は、1GHz で動作する 4 つの ARM v7 コアと 512 MB の RAM で構成され、ピーク時の消費電力は約 3W です。私たちの調査によると、TensorFlow は ARM-Linux ベースの SoC で最高のパフォーマンスを発揮できるため、これを選択しました。

移植は数日以内に完了する予定ですが、TensorFlow は多くのサードパーティ ライブラリに依存しているため、移植は簡単ではありません (図 1 を参照)。リソースの消費量を削減するために、ほとんどの IoT デバイスはベアメタル上で実行されるため、すべての依存関係を移植するのは困難な作業になる可能性があります。 TensorFlow を Zuluko で実行できるようになるまで、1 週間の懸命な作業が必要でした。この経験から、既存のプラットフォームを移植するよりも、新しいプラットフォームをゼロから構築する方が価値があるかどうかを再考するようになりました。ただし、畳み込み演算子などの基本的な構成要素がないため、ゼロから構築するのは簡単ではありません。さらに、ゼロから構築された推論エンジンが、十分にテストされたディープラーニング フレームワークを上回るパフォーマンスを発揮することは困難です。

図 1. TensorFlow のサードパーティ ライブラリへの依存性。 TensorFlow などの既存のディープラーニング プラットフォームを IoT デバイスに移植するのは、多くのサードパーティ ライブラリに依存しているため、簡単なプロセスではありません。

推論エンジンをゼロから構築する

ARM は最近、ARM Cortex-A シリーズ CPU プロセッサと ARM Mali シリーズ GPU 向けのソフトウェア機能の包括的な統合を提供する Compute Library (ACL、developer.arm.com/technologies/compute-library) のリリースを発表しました。具体的には、ACL は、アクティベーション、畳み込み、完全接続とローカル接続、正規化、プーリング、ソフトマックス関数など、CNN の基本的な構成要素を提供します。これらの機能はまさに推論エンジンを構築するために必要なものです。

ACL ビルディング ブロックを使用して、メモリ フットプリントが小さく組み込みデバイスに適した SqueezeNet アーキテクチャを備えた CNN 推論エンジンを構築しました。 SqueezeNet は 1×1 畳み込みカーネルを使用して、同様の推論精度を維持しながら 3×3 畳み込み層の入力サイズを削減します。次に、SqueezeNet 推論エンジンのパフォーマンスを Zuluko 上の TensorFlow と比較します。公平な比較を行うために、TensorFlow で ARM NEON ベクトル計算最適化を有効にし、SqueezeNet エンジンの作成時に NEON 対応のビルディング ブロックを使用しました。両方のエンジンが NEON ベクトル演算を使用していることを確認して、パフォーマンスの違いがプラットフォーム自体のみに起因するようにします。図 2 に示すように、TensorFlow が 227×227 ピクセルの RGB 画像を処理するのに平均 420 ミリ秒かかりますが、SqueezeNet では同じ画像の処理時間が 320 ミリ秒に短縮され、25% の高速化が実現されています。

図 2. TensorFlow 上で実行される SqueezeNet 推論エンジンと、ARM Compute Library (ACL) を使用して構築された SqueezeNet 推論エンジンのパフォーマンスの比較。シンプルな推論エンジンをゼロから構築すると、開発時間が短縮されるだけでなく、TensorFlow などの既存のディープラーニング エンジンよりもパフォーマンスが向上します。

パフォーマンスの向上がどこから来るのかをよりよく理解するために、実行プロセスを 2 つの部分に分割しました。最初の部分には畳み込み、ReLU (正規化線形関数) アクティベーションとカスケーディングが含まれ、2 番目の部分にはプーリングとソフトマックス関数が含まれます。図 2 に示す分析では、SqueezeNet によって TensorFlow のパフォーマンスが最初の部分で 23%、2 番目の部分で 110% 向上することが示されています。リソース使用率を考慮すると、TensorFlow で実行する場合、平均 CPU 使用率は 75%、平均メモリ使用量は 9MB です。SqueezeNet で実行する場合、平均 CPU 使用率は 90%、平均メモリ使用量は約 10MB です。パフォーマンスが向上した理由は 2 つあります。1 つ目は、SqueezeNet はより優れた NEON 最適化を提供し、すべての ACL 演算子は NEON によって提供される演算子を使用して直接開発されるのに対し、TensorFlow は NEON 最適化を提供するために ARM コンパイラに依存していることです。 2 番目に、TensorFlow プラットフォーム自体が追加のパフォーマンス オーバーヘッドを引き起こす可能性があります。

次に、TensorFlow からさらにパフォーマンスを引き出し、私たちが構築した SqueezeNet 推論エンジンを上回ることができるかどうかを確認したいと考えています。一般的な手法は、8 ビットの重みを使用してベクトル量子化を使用し、精度とパフォーマンスをトレードオフすることです。 8 ビットの重みを使用すると、ベクトル演算を通じて 1 つの命令だけで複数のデータ単位を計算できます。ただし、この最適化にはコストがかかり、再量子化と逆量子化の操作が必要になります。この最適化を TensorFlow に実装しました。図 3 では、最適化ありと最適化なしのパフォーマンスを比較しています。ベクトル量子化を使用すると畳み込みのパフォーマンスが 25% 向上しますが、逆量子化と再量子化の操作によりオーバーヘッドも大幅に増加します。全体として、推論プロセス全体が 100 ミリ秒以上遅くなりました。

図 3. ベクトル量子化ありとなしの TensorFlow パフォーマンス。 TensorFlow などの既存のディープラーニング プラットフォームを手動で最適化するのは難しく、パフォーマンスが大幅に向上しない可能性があります。

ネットワーク接続は不安定であるため、ISP またはネットワークに障害が発生した場合でもデバイスが動作を継続できるように、何らかの形のインテリジェンスをデバイスにローカルに実装できるようにしたいと考えました。ただし、これを実現するには、より高いコンピューティング性能と電力消費が必要です。

サービスをクラウドに移行すると IoT デバイスの電力消費を削減できますが、リアルタイムの要件を満たすことは困難です。さらに、既存のディープラーニング プラットフォームは、トレーニング タスクと推論タスクの両方に適した汎用タスク向けに設計および開発されているため、これらのエンジンは組み込み推論タスク向けに最適化されていません。また、ベアメタル組み込みシステムではすぐには利用できない追加のサードパーティ ライブラリにも依存しているため、移植が非常に困難です。

ACL ビルディング ブロックを使用して組み込み CNN 推論エンジンを構築することで、SoC の異種コンピューティング リソースを最大限に活用して高いパフォーマンスを実現できます。したがって、既存のエンジンを移植する方が簡単なのか、それともゼロから構築する方が簡単なのかという疑問が生じます。私たちの経験では、モデルが単純な場合は、ゼロから構築する方がはるかに簡単です。モデルが複雑になるにつれて、既存のエンジンを移行する方が効率的な場合もあります。ただし、組み込みデバイスが実際に実行するタスクを考慮すると、複雑なモデルが必要になる可能性は低くなります。したがって、組み込み推論エンジンをゼロから構築することが、IoT デバイスにディープラーニング機能を提供するための実行可能なアプローチである可能性があると結論付けています。

さらに一歩進んで

手動でモデルをゼロから構築するのではなく、IoT デバイスにディープラーニング機能を提供するより便利な方法が必要です。 1 つの解決策は、特定のモデルを最適化し、それをターゲット プラットフォーム上で実行可能なコードにコンパイルできるディープラーニング モデル コンパイラを実装することです。図 4 の中央の図に示すように、このコンパイラのフロントエンドは、主要なディープラーニング プラットフォーム (MXNet、Caffe、TensorFlow など) のモデルを解析できます。その後、オプティマイザーは、モデルのプルーニング、量子化、異種実行などの追加の最適化を実行できます。最適化後、コード ジェネレーターは、ACL (ARM デバイスの場合)、TensorRT (Nvidia GPU の場合)、またはその他の ASIC デバイスなどのターゲット プラットフォーム用の実行可能コードを生成します。

図 4 IoT デバイス サービス アーキテクチャ。 IoT デバイスでディープラーニングを実現するには、新しいシステム アーキテクチャが必要です。まず、ディープラーニング モデルを直接コンパイルして最適化し、ターゲット デバイスで実行可能なコードを生成する必要があります。次に、マルチタスクとデバイス間の効率的な通信を可能にする非常に軽量なオペレーティング システムが必要です。 IMU: 慣性計測ユニット。

NNVM プロジェクト (github.com/dmlc/nnvm) は、この目標に向けた第一歩です。 ACL を使用して ARM デバイスでのディープラーニング操作を高速化できるように、NNVM を拡張してコードを生成することに成功しました。このアプローチのもう 1 つの利点は、モデルがより複雑になっても、IoT デバイスに簡単に実装できることです。

現在の IoT デバイスは、コンピューティング リソースが限られているため、通常は単一のタスクを実行します。ただし、複数のタスクを実行できる低電力 IoT デバイスが間もなく登場すると予想されます (たとえば、当社の Zuluko デバイスには 4 つのコアが含まれています)。これらのデバイスを使用するには、さまざまなサービスを接続するための非常に軽量なメッセージング プロトコルが必要です。

図 4 に示すように、IoT デバイスの基本サービスには、センシング、認識、意思決定が含まれます。センシング ノードは、カメラ、慣性測定ユニット、ホイール オドメトリなどからの生のセンサー データの処理に関与します。認識ノードは、処理されたセンサー データを使用して、オブジェクト ラベルやデバイスの場所などのキャプチャされた情報を解釈します。アクション ノードには、所有者の顔が検出されたときにドアのロックを解除したり、障害物が検出されたときにロボットの動作パスを調整したりするなど、特定のイベントが検出されたときにどのように応答するかを決定する一連のルールが含まれています。 Nanomsg (nanomsg.org) は、同様のタスクに適した非常に軽量なメッセージング フレームワークです。もう 1 つの選択肢は Robot OS ですが、メモリ フットプリントと計算リソース要件の点で IoT デバイスには重すぎることがわかりました。

ディープラーニングを IoT デバイスに効果的に統合するために、コンシューマーグレードのセンサー入力用のセンサー インターフェイス、既存のディープラーニング モデルを実行可能コードにコンパイルして最適化する NNVM ベースのコンパイラ、すべてのノードを接続する Nanomsg ベースのメッセージ伝送フレームワークを含む独自のオペレーティング システムを開発しました。

この記事が、研究者や開発者にインスピレーションを与え、これまでよりも小型の組み込みデバイスでよりスマートな IoT システムを設計するきっかけになれば幸いです。