エッジでのビジョンモデル推論に向けたNeural Compute Stickの最適化

Tulip 、現場業務向けの ノーコード・コンピュータビジョンソリューションです。これにより、コンピュータビジョApps 業務を推進・監視Apps Tulip Apps を作成できます。Tulip 、作業ステーションでの動作の検知、物体や人物の追跡などに利用可能です。ビジョン信号を活用することで、安全性の監視、手作業による組立作業、キット化やピッキングなど、信頼性を高め、ミスを減らすさまざまな用途に対応できます。 現場向けビジョンの中核には、深層ニューラルネットワークに基づくコンピュータビジョンアルゴリズムがあります。これらのアルゴリズムは、現場にある既存のハードウェア（多くの場合、Windows を実行する低スペックの PC）上で動作するように設計されています。現場の低スペックなコンピュータに最先端の AI をもたらすため、当社はIntel Compute Stick バージョン 2（NCS v2）、別名 Movidius Vision Processing Unit（VPU）を採用しています。 これは、深層ニューラルネットワークの実行用に設計された演算ハードウェアを搭載したUSBデバイスであり、PCのCPUやGPUから演算処理の負荷を軽減します。NCSは、エッジAI向けの低コストかつ低消費電力のソリューションであり、プラグアンドプレイにも対応しています。

なぜ最適化が必要なのでしょうか？

Tulip ニーズにおいて、Intel 高性能なプロセッサであることが分かりました。当社は、生産ライン上の人物とその動作の検知に注力しているため、入力されるカメラ映像から手や人物を検知できることが重要です。最新の人体検知モデルでは深層ニューラルネットワークや大規模なモデルが採用されており、NCSにとって性能面での課題となっています。

ハンド検出モデルを標準設定で実行したところ、推論処理において14フレーム/秒（FPS）の速度を達成できました。人間の動作をリアルタイムで検出するという目標（一般的には30 FPS以上、つまりほとんどのカメラの通常動作速度とみなされる）を達成するには、ある程度の最適化が必要です。 また、初期費用を支払って導入したNCSハードウェアの性能を最大限に引き出すことも目指していました。NCSの仕様では理論上の処理速度として100 GFLOP/s（1秒あたりのギガ浮動小数点演算数）が規定されていますが、当初は14 FPSで1.5 GFLOPのネットワークを使用しても、わずか20～25 GFLOP/sしか出せず、かなりの遅延も生じていました。

この記事では、私たちが検討した最適化手法について解説するとともに、実際に大きな効果をもたらし、リアルタイム推論の領域に確実に到達させてくれた手法について紹介します。Intel NCSv2向けのネットワーク最適化に関する有益なガイドを提供しており、私たちは今回の作業でそれを活用しました。

まず、手検出ネットワーク用のグラフと重みを取得しました。 私たちは、製造現場での性能に最適化された独自の手検出モデルを学習させていますが、オンラインには驚くほど精度の高いモデルが無料で公開されています。以下に、テストやベースライン比較に使用したGitHub上のモデル例を示します。事前学習済みのモデルを使用する場合、目的やデータに合わせて微調整を行うことが望ましいでしょう。私たちは、GoogleのTensorFlowが提供する一連のツールを使用して、微調整や転移学習の手法を検証しました。

NCS上でモデルを実行するには、そのモデルを適切な形式に変換する必要があります。Intel 、NCS向けの開発にOpenVINOを採用しています。これは非常に包括的なツールキットであり、異種環境（CPU、GPU、VPUなど）でのモデル実行、TensorFlow、ONYX、PyTorchなどの多様なソースアーキテクチャからの変換、および様々な方法によるモデルの最適化を可能にします。

モデルを変換するには、まずモデルを「フローズングラフ」の状態にする必要があります。これは、推論に必要なニューラルネットワークの部分のみを残し、それ以外のすべてを削除するとともに、グラフのすべての重みが確定していることを確認することを意味します。 ニューラルネットワークの実行グラフには、トレーニングに関連するデータがいくつか付随していますが、これらは推論には不要であり、変換の際に問題を引き起こす可能性があります。この例の手の検出モデルをフローズングラフ状態にするには、以下のスクリプトを使用します：

python3 /content/models/research/object_detection/export_inference_graph.py \
 --input_type=image_tensor \ 
 --pipeline_config_path=/path/to/pipeline.config \
 --output_directory=/path/to/output_directory \
 --trained_checkpoint_prefix=/path/to/model.ckpt-xyz # xyz をチェックポイントのステップ値に置き換えてください。

図1.TensorFlow Object Detection APIで学習させたモデルの推論グラフスクリプトのエクスポート

変換には、OpenVINOのDL（ディープラーニング）ワークベンチを利用します。これは主要なOSであれば簡単にインストールでき、スタンドアロンのGUIアプリケーションとして動作するほか、コマンドラインからも操作可能です。 ここでは、操作を視覚化するためにGUIの使用に焦点を当てます。OpenVINOは、DL Workbenchの優れた「入門ガイド」を提供しています。DL Workbench上でモデルを読み込み、入力および出力のテンソルの形状を指定します。

図2. Intel Learning Workbenchのモデル構成

このワークベンチには、モデルの実行やパフォーマンスをベンチマークするための非常に便利なツールに加え、実装されたニューラルネットワークの層に関して、モデルがNCS上で動作可能であることを確認するためのテスト機能も備わっています。

図3. Intel CPUを使用したテストデータ（アノテーションなし）でのモデルベンチマーク

最後に、このワークベンチを使えば、モデルをNCSが要求する形式に簡単に変換できます：

図4.変換されたOpenVINOモデルのダウンロード

まずは、OpenVINOの物体検出用サンプルコードを使用しました。 これは、モデル実行に時間がかかることを前提として、NCSに対して推論リクエスト（IR）を送信し、その完了を待機（スレッドをブロック）する単純な同期APIを使用しています。その結果、当初は14 FPS程度という期待外れのパフォーマンスしか得られませんでした。数値を分析したところ、これはNCSの能力から見て著しく性能が低いことが判明しました。

モデルが大きすぎるため、性能が低下しているのではないかと推測しました。そこでまず、モデルへの入力画像のサイズを縮小してみることにしました。当時、プール処理前の大きな入力サイズに対する初期の畳み込み層が、計算負荷の大部分を占めているという説が有力でした。 そこで、入力形状を元の224x224から64x64および128x128に変更しました。しかし、これにより精度も大幅に低下してしまい、これは受け入れがたい結果でした。

図5.FPSとモデル入力サイズの関係を示す棒グラフ。すべてのモデルはMobilenetv2をベースとしたSSDLiteモデルである。Mobilenetv2の場合、xy-abcにおいて、xyは深度乗数、abcは入力サイズを表す。

また、OpenVINOモデルズーで提供されているMobileNet V3やEfficientDetなど、さまざまなバックボーンや検出器のアーキテクチャも試しました。しかし、NCS上での推論における速度と精度のトレードオフは、我々のユースケースには適していないという結論に至りました。

図6.モデルのバックボーンとアーキテクチャのFPS推移。すべてのMobilenetバックボーンは、ボックス検出器としてSSDLiteを採用している。

この結果に困惑した私たちは、モデルのプルーニングを試みました。プルーニングとは、モデルの性能にあまり寄与していない部分を削除し、速度を犠牲にして精度を高める手法です。 私たちは、TensorFlowの「軽量レイヤー」を特定するスマートなモデル剪定を試みました。現在、TensorFlowはKerasベースの逐次モデルのみモデル剪定をサポートしており、TensorFlow Object Detection APIを使用して学習されたモデルはサポートしていません。このことが、軽量な剪定済みモデルを作成しようとする私たちの取り組みをさらに阻む結果となりました。

最適化のもう一つのアプローチとして、量子化があります。量子化では、ネットワーク内の特定の層の数値精度を、負荷が軽く高速なタイプに変更します。 これは、携帯電話などの処理能力の低いハードウェアでは、浮動小数点演算（例：32ビット浮動小数点、FLOAT32）が整数演算（例：8ビット整数、INT8）よりも処理速度が遅いという前提に基づいています。これはニューラルネットワークの最適化において最も効果的な手法の一つです。しかし、NCSはINT8演算をサポートしていないため、また振り出しに戻ってしまいます。

最終的に、最適化手法を何度も試行した結果、OpenVINOの非同期API（ガイドに記載されている通り）を使用すれば、推論リクエストが完了するのを待たずに、並行して別のリクエストを実行できることがわかりました。 他の推論リクエストがまだ実行中の間に新たなリクエストを受け取り、それを別の画像の検出処理に渡すことができます。カメラからのリアルタイムなフレーム取得を行っているため、出力にはわずかな遅延が生じますが、速度面では非常に大きな向上が得られます。次の図は、非同期IRストリームの利点を示しています：

実際には、4つの並列推論リクエストからなるプールを実行しています。プールのサイズは、推論デバイス、つまりNCSによって決定されます。CPUの場合、NCSよりも多くのIRを処理でき、高性能なGPUであればさらに多くのIRを処理できる可能性があります。いずれにせよ、モデルが大きいために処理が遅く、リクエストの完了に時間がかかる場合、IRのプールが枯渇してしまい、それでもフレームレートが低下してしまう可能性があります。

パフォーマンス評価における主要な指標は、FPSとレイテンシです。私たちはより高いFPSとより低いレイテンシを求めていますが、非同期APIのアプローチでは、この2つはトレードオフの関係にあります。より多くのIRを並行して実行すると、ウォームアップ期間やレイテンシは長くなりますが、全体的な処理時間は短縮されます。

パフォーマンスを測定するために、社内のツールに加え、OpenVINOが提供するC++ベンチマークツールも活用しました。このツールはNCS上でモデルを実行することができ、非常に有用な統計情報を提供してくれます。Tulip におけるモデル推論の完全なシミュレーションとは言えませんが、フレームワーク上で実際にモデルを実行することなく、非常に有益なデータを得ることができました。

図7.非同期APIおよび同期APIを使用したSSDLite MobilenetV2のモデル性能。

Intel とOpenVINOツールキットは、私たちのニーズに非常に役立つことがわかりました。モデルを実行するための異種プラットフォームとしてNCS VPUとシームレスに連携するだけでなく、変換やベンチマークに対するサポートも非常に充実しており、最適化に役立つツールも備えています。 非同期推論のオプションを見つけるまで、私たちは様々な試行錯誤を重ね、その過程で多くのことを学びました。こうして、Tulip を活用し、非常に低コストでクライアントに最高レベルのパフォーマンスを提供しています。OpenVINOの非同期APIは、モデル推論の最適化手法における他の多くの従来型アプローチと比較して、最も大きなパフォーマンス向上をもたらしましたが、今後さらに多くのディープラーニングモデルをVisionの本番環境に展開していく中で、それらの手法も依然として役立つ可能性があります。