エッジでの視覚モデル推論のためのニューラル・コンピューティング・スティックの最適化

Tulip Visionは、現場作業のためのコード不要のコンピュータ・ビジョン・ソリューションです。Tulip Visionは、コンピュータ・ビジョンを使用して、オペレーションを駆動・監視するTulip Apps 作成することができます。Tulip ビジョンは、ワークステーションでの活動の検出、物体や人の追跡などに使用できます。ビジョン信号は、安全性、手作業による組み立て作業、キッティングとピッキング、その他信頼性を高めてミスを減らす多くのアプリケーションを監視するために構築できます。現場用ビジョンの中心には、ディープニューラルネットワークをベースとしたコンピュータビジョンアルゴリズムがあります。このアルゴリズムは、多くの場合Windows実行する控えめなPCである、現場の既存のハードウェア上で実行できるように設計されています。最新のAIを現場の非力なコンピューターに導入するために、私たちはIntel 2（NCS v2）、別名Movidius Vision Processing Unit（VPU）を使用しています。深層ニューラルネットワークを実行するために設計された計算ハードウェアを搭載したUSBデバイスで、PCのCPUやGPUから演算処理を取り除きます。NCSは、エッジでAIを実行するための低コスト低消費電力ソリューションで、プラグアンドプレイにも対応しています。

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

Intel NCSは、Tulip ビジョンのニーズに対して非常に高性能なプロセッサーであることがわかりました。私たちは、ライン上の人間とその操作を検出することに重点を置いているため、入力されるカメラストリームから手や人物を検出できることが重要です。最新の人間検出モデルは、ディープ・ニューラル・ネットワークとヘビー・モデルを採用しており、性能面でNCSに挑戦しています。

手の検出モデルをバニラで実行したところ、推論速度は14フレーム/秒（FPS）を達成することができました。人間の操作をリアルタイムで検出するという目標を達成するためには、いくつかの最適化が必要です（俗に30FPS以上と考えられており、ほとんどのカメラの通常の動作速度です）。また、私たちはNCSハードウェアを最大限に活用したいと考えていました。NCSの仕様では、理論上100 GFLOP/s（ギガ浮動小数点演算/秒）の処理速度が指定されていますが、当初は、かなりの待ち時間が発生する中、わずか20～25 GFLOP/s（14 FPSで1.5 GFLOPのネットワーク）を引き出すことができました。

この記事では、私たちが検討した最適化手法と、実際に私たちに違いをもたらし、リアルタイム推論を可能にした手法について説明します。Intel 、NCSv2用のネットワークの最適化に関する有用なガイドをすでに提供しており、私たちはそれを参考にしました。

手始めに、手検出ネットワークのグラフと重みを求めました。私たちは手の検出のために、現場のシーンでのパフォーマンスに合わせてチューニングした独自のモデルをトレーニングしていますが、驚くほどよく機能するモデルがオンラインで自由に利用できます。これはGitHubにあるモデルの例で、テストとベースライン比較に使用しました。事前に訓練されたモデルを使用すると、自分の目的とデータに合わせて微調整することができます。私たちはGoogleのTensorFlowの一連のツールを使って、微調整と転移学習技術をテストしました。

任意のモデルをNCS上で実行するためには、適切なフォーマットに変換する必要があります。Intel NCSは、NCS向けの開発にOpenVINOを使用しています。これは非常に包括的なツールキットで、ヘテロジニアスな環境（CPU、GPU、VPUなど）でモデルを実行したり、TensorFlow、ONYX、PyTorchなど多くのソースアーキテクチャから変換したり、様々な方法でモデルを最適化したりすることができます。

モデルを変換するには、まずグラフを凍結した状態にする必要があります。つまり、推論に必要なニューラルネットワークの部分だけを残し、それ以外はすべて破棄し、グラフの重みがすべて確定していることを確認します。ニューラルネットワークの実行グラフには、トレーニングに関係するいくつかのデータが付随していますが、これらは推論には必要なく、実際には変換時に問題を引き起こす可能性があります。手の検出モデルを凍結グラフの状態にするために、次のスクリプトを使用します：

python3 /content/models/research/object_detection/export_inference_graph.py  \
 --入力タイプ=image_tensor ୧-͈ᴗ-͈)◞ᵒᵒᵒ 
 -pipeline_config_path=/path/to/pipeline.config。
 -pipeline_config_path=/path/to/output_directory ˶ -output_directory=/path/to/output_directory
 --trained_checkpoint_prefix=/path/to/model.ckpt-xyz # xyzをチェックポイントステップの値に置き換えます。

図1.Tensorflow Object Detection APIで学習したモデルの推論グラフスクリプトをエクスポート。

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

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

ワークベンチには、モデルの実行とパフォーマンスをベンチマークするための非常に便利なツールや、実装されたNNレイヤーの観点からNCS上でモデルが動作可能であることを確認するためのテストもあります。

図3. Intel i7-8700T CPUを使用したテストデータ（注釈なし）のモデルベンチマーク

最後に、ワークベンチはモデルをNCSが要求する形式に変換するのが非常に簡単です：

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

手始めに、オブジェクト検出にはOpenVINOのサンプルコードを使いました。これは単純な同期APIを使用しており、NCSに推論要求（IR）を出し、それが完了するまで待ちます（スレッドをブロックします）。これによって、約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を使用してトレーニングされたモデルをサポートしていません。これは、軽量プルーニングモデルを作成する私たちの努力をさらに妨げました。

最適化のもうひとつの切り口は量子化です。量子化では、ネットワーク内のいくつかのレイヤーの数値精度を、より軽量で高速なタイプに変更します。これは、携帯電話などの弱い実行ハードウェアは、整数演算（8ビット整数、INT8など）よりも浮動小数点演算（32ビット浮動小数点、FLOAT32など）の実行が遅いことを想定しています。これはNN最適化のための最良のトリックの1つです。しかし、NCSはINT8演算をサポートしていないため、また振り出しに戻ってしまいます。

最終的に、最適化テクニックを何度も試した結果、OpenVINOの非同期APIを使えば、推論要求の完了を待たずに別の推論要求を並列に実行できることがわかりました（ガイドに記載されています）。他の推論要求がまだ実行されている間に別の推論要求を取得し、検出のために別の画像に渡すことができます。カメラからリアルタイムでフレームを取得しているため、出力にわずかなタイムラグが生じますが、速度は非常に向上します。以下の図は非同期IRストリームの利点を示しています：

実際には、4つの同時推論要求のプールを実行します。プールのサイズは推論デバイス、つまりNCSによって決まります。CPUはNCSより多くのIRを持ち、強力なGPUはさらに多くのIRを持つかもしれません。いずれにせよ、モデルが大きく、したがって遅く、要求を完了するのに長い時間がかかる場合、IRのプールを使い果たしてもフレームレートが低下する可能性があります。

性能評価の主な指標はFPSとレイテンシーです。私たちはより高いFPSレートとより低いレイテンシを望んでいますが、非同期APIアプローチではこの2つはトレードオフの関係にあります。より多くのIRを同時に実行すると、ウォームアップ期間とレイテンシが長くなりますが、全体的なターンアラウンド・タイムは速くなります。

パフォーマンスを測定するために、内部ツールもありますが、OpenVINOから入手可能なC++ベンチマークツールも使用しました。これはNCS上でモデルを実行することができ、非常に有用な統計情報を与えてくれます。Tulip Visionにおけるモデル推論の真のシミュレーションではありませんが、私たちのフレームワークで実際にモデルを実行する必要なく、非常に良いデータを得ることができました。

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

Intel NCSv2とOpenVINOツールキットは、私たちのニーズにとって非常に有用であることがわかりました。モデルを実行するためのヘテロジニアス・プラットフォームであり、NCS VPUとスムーズに動作するだけでなく、変換やベンチマークに対するかなり広範なサポートや、最適化のための便利なツールも備えています。私たちは非同期推論オプションを見つけるまでに多くのことを試しましたが、その過程で多くのことを学びました。こうして私たちは、Tulip Visionを使って、非常に低コストで一流のパフォーマンスをクライアントに提供しているのです。OpenVINOの非同期APIは、モデル推論最適化のトリックにおいて、他の多くの伝統的なアプローチと比較して最高のパフォーマンス向上をもたらしました。