LiteRT 代理人

デリゲートを使用すると、GPU や Digital Signal Processor(DSP)などのオンデバイス アクセラレータを活用して、LiteRT モデルのハードウェア アクセラレーションを有効にできます。

デフォルトでは、LiteRT は ARM Neon 命令セット用に最適化された CPU カーネルを利用します。ただし、CPU は多目的プロセッサであり、通常、ML モデルで見られる重い算術演算(畳み込みレイヤと密レイヤに関連する行列演算など)に最適化されているとは限りません。

一方、最新のモバイル デバイスのほとんどには、このような重い処理に適したチップが搭載されています。ニューラル ネットワーク オペレーションにこれらを利用すると、レイテンシと電力効率の面で大きなメリットが得られます。たとえば、GPU を使用すると、レイテンシを最大 5 倍高速化できます。

これらのアクセラレータにはそれぞれ、カスタム コンピューティングを可能にする API(モバイル GPU の OpenCLOpenGL ES など)が関連付けられています。通常、これらのインターフェースを介してニューラル ネットワークを実行するには、多くのカスタムコードを記述する必要があります。各アクセラレータには長所と短所があり、ニューラル ネットワーク内のすべてのオペレーションを実行できるわけではないことを考慮すると、さらに複雑になります。TensorFlow Lite の Delegate API は、TFLite ランタイムとこれらの下位レベルの API の間のブリッジとして機能することで、この問題を解決します。

代議員を含むランタイム

デリゲートの選択

LiteRT は複数のデリゲートをサポートしています。各デリゲートは、特定のプラットフォームと特定のタイプのモデル用に最適化されています。通常、ユースケースに適用できるデリゲートは複数あります。これは、ターゲットとするプラットフォーム(Android か iOS か)と、高速化しようとしているモデルタイプ(浮動小数点か量子化か)という 2 つの主要な基準によって異なります。

プラットフォーム別の委任

クロス プラットフォーム(Android と iOS)

  • GPU デリゲート - GPU デリゲートは Android と iOS の両方で使用できます。GPU が利用可能な 32 ビットと 16 ビットの浮動小数点ベースのモデルを実行するように最適化されています。また、8 ビットの量子化モデルもサポートしており、浮動小数点バージョンと同等の GPU パフォーマンスを提供します。GPU デリゲートの詳細については、GPU 上の LiteRT をご覧ください。

iOS

  • 新しい iPhone と iPad 向けの Core ML デリゲート - Neural Engine を搭載した新しい iPhone と iPad では、Core ML デリゲートを使用して、32 ビットまたは 16 ビットの浮動小数点モデルの推論を高速化できます。Neural Engine は、A12 SoC 以降を搭載した Apple モバイル デバイスで利用できます。Core ML デリゲートの概要と手順については、LiteRT Core ML デリゲートをご覧ください。

モデルタイプ別のデリゲート

各アクセラレータは、特定のビット幅のデータを想定して設計されています。8 ビットの量子化演算のみをサポートするデリゲートに浮動小数点モデルを提供すると、すべての演算が拒否され、モデルは CPU 上で完全に実行されます。このような事態を避けるため、次の表にモデルタイプに基づくデリゲート サポートの概要を示します。

モデルタイプ GPU CoreML
浮動小数点(32 ビット)
トレーニング後の float16 の量子化
トレーニング後のダイナミック レンジの量子化 いいえ
トレーニング後の整数量子化 いいえ
量子化認識トレーニング いいえ

パフォーマンスを検証する

このセクションの情報は、アプリケーションを改善できるデリゲートを絞り込むための大まかなガイドラインとして機能します。ただし、各デリゲートにはサポートするオペレーションの事前定義されたセットがあり、モデルやデバイスによって動作が異なる場合があることに注意してください。そのため、通常は、デリゲートがニーズにどの程度役立つかを測定するために、ベンチマークを実施することをおすすめします。また、LiteRT ランタイムにデリゲートをアタッチすることに関連するバイナリ サイズの増加を正当化するのにも役立ちます。

LiteRT には、パフォーマンスと精度の評価ツールが豊富に用意されています。これにより、デベロッパーはアプリケーションでデリゲートを安心して使用できます。これらのツールについては、次のセクションで説明します。

評価ツール

レイテンシとメモリ使用量

LiteRT のベンチマーク ツールは、適切なパラメータで使用して、平均推論レイテンシ、初期化オーバーヘッド、メモリ フットプリントなどのモデル パフォーマンスを推定できます。このツールは、モデルに最適なデリゲート構成を特定するための複数のフラグをサポートしています。たとえば、--gpu_backend=gl--use_gpu で指定して、OpenGL で GPU の実行を測定できます。サポートされている委任パラメータの完全なリストは、詳細なドキュメントで定義されています。

adb を介して GPU を使用する量子化モデルの実行例を次に示します。

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

Android 向け 64 ビット ARM アーキテクチャのこのツールのビルド済みバージョンは、こちらからダウンロードできます(詳細)。

精度と正確性

通常、デリゲートは CPU とは異なる精度で計算を実行します。そのため、ハードウェア アクセラレーションにデリゲートを使用すると、通常はわずかな精度のトレードオフが発生します。これは常に当てはまるわけではありません。たとえば、GPU は浮動小数点精度を使用して量子化モデルを実行するため、精度がわずかに向上する可能性があります(たとえば、ILSVRC 画像分類で上位 5% の精度が 1% 未満向上)。

LiteRT には、特定のモデルに対するデリゲートの動作の精度を測定するための 2 種類のツール(タスクベースタスク非依存)があります。このセクションで説明するツールはすべて、前のセクションのベンチマーク ツールで使用される高度な委任パラメータをサポートしています。以下のサブセクションでは、モデルの評価(モデル自体がタスクに適しているか)ではなく、デリゲートの評価(デリゲートが CPU と同じように動作するか)に焦点を当てています。

タスクベースの評価

LiteRT には、2 つの画像ベースのタスクで正しさを評価するツールがあります。

これらのツール(Android、64 ビット ARM アーキテクチャ)の事前ビルドバイナリとドキュメントは、こちらにあります。

次の例は、Pixel 4 で GPU を使用した画像分類の評価を示しています。

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

想定される出力は、1 ~ 10 の Top-K 指標のリストです。

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

タスクに依存しない評価

確立されたオンデバイス評価ツールがないタスクや、カスタムモデルを試している場合は、LiteRT に Inference Diff ツールがあります。(Android、64 ビット ARM バイナリ アーキテクチャ バイナリはこちら

推論差分では、次の 2 つの設定で LiteRT の実行(レイテンシと出力値の偏差)を比較します。

このツールは、ランダムなガウス データを生成し、2 つの TFLite インタープリタに渡します。1 つはシングル スレッドの CPU カーネルを実行し、もう 1 つはユーザーの引数でパラメータ化されます。

各 Interpreter の出力テンソル間の絶対差とレイテンシを要素ごとに測定します。

単一の出力テンソルを持つモデルの場合、出力は次のようになります。

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

つまり、インデックス 0 の出力テンソルでは、CPU 出力の要素とデリゲート出力の要素の平均差が 1.96e-05 になります。

これらの数値を解釈するには、モデルと各出力テンソルが意味する内容について、より深い知識が必要です。スコアやエンベディングを決定する単純な回帰の場合、差は小さくなければなりません(そうでない場合は、デリゲートにエラーがあります)。ただし、SSD モデルの「検出クラス」などの出力は、解釈が少し難しくなります。たとえば、このツールで差分が表示されても、デリゲートに本当に問題があるとは限りません。2 つの(偽の)クラス「TV(ID: 10)」と「Monitor(ID: 20)」を考えてみましょう。デリゲートがゴールデン トゥルースからわずかに外れていて、TV ではなくモニターが表示された場合、このテンソルの出力差分は 20 - 10 = 10 ほどになる可能性があります。