デリゲートは、次の方法で LiteRT モデルのハードウェア アクセラレーションを有効にします。 GPU やデジタル シグナル プロセッサなどのオンデバイス アクセラレータを活用 (DSP).
デフォルトでは、LiteRT は ARM ネオン 使用します。ただし、この CPU は汎用プロセッサであり、 機械処理によく見られる演算処理に 学習モデル(畳み込みと密集に関連する行列計算など) です。
一方、最近のほとんどのスマートフォンには、Google Pixel 8 Pro よりも 負荷の高いオペレーションを処理できますニューラル ネットワーク操作への活用 レイテンシと電力効率の点で大きなメリットを得られます。たとえば GPU は、最大 5 倍の スピードアップ 向上します
各アクセラレータには、カスタム計算を可能にする API が関連付けられています。 (OpenCL、OpenGL など) ES はモバイル GPU です。通常は これらのインターフェースを介してニューラル ネットワークを実行するために、多くのカスタムコードを記述する必要がありました。 各アクセラレータにそれぞれの機能があり、 長所とデメリットがあり、ニューラル ネットワークではすべての演算を実行できません。TensorFlow Lite の Delegate API は、TFLite 間のブリッジとして機能することで、この問題を解決します。 下位レベル API の 3 つです
代理人を選択する
LiteRT は複数のデリゲートをサポートしており、各デリゲートは、 特定のプラットフォームや特定のタイプのモデルを 保護する必要があります通常は 2 つの主要な基準に応じて、ユースケースに適用可能な複数の委任 ターゲットとするプラットフォーム(Android か iOS か)とモデルタイプ (浮動小数点数または量子化)のいずれかです。
プラットフォーム別の委任
クロス プラットフォーム(Android と iOS)
- GPU デリゲート - Android と iOS の両方で GPU デリゲートを使用できます。これは、 32 ビットおよび 16 ビット浮動小数点ベースのモデルを実行するために最適化されており、 できます。8 ビットの量子化モデルもサポートしており、 パフォーマンスは浮動小数点数と同等ですGPU の詳細については、 デリゲートについては、GPU での LiteRT をご覧ください。
iOS
- 新しい iPhone および iPad 向けの Core ML デリゲート - 新しい iPhone および Neural Engine を利用できる iPad では、Core ML のデリゲートを使用して次のことができます。 32 ビットまたは 16 ビットの浮動小数点モデルの推論を高速化します。Neural Engine は、A12 SoC 以降を搭載した Apple モバイル デバイスで利用できます。たとえば、 Core ML デリゲートの概要と詳細な手順については、以下をご覧ください。 LiteRT Core ML デリゲート。
モデルタイプ別のデリゲート
各アクセラレータは、一定のビット幅のデータを考慮して設計されています。もし 8 ビットの量子化処理のみをサポートする浮動小数点モデルをデリゲートに提供する すべてのオペレーションが拒否され、モデルは完全に あります。想定外の事態を回避するために、以下の表に モデルタイプに基づいてサポートを委任:
モデルタイプ | GPU | CoreML |
---|---|---|
浮動小数点(32 ビット) | ○ | ○ |
トレーニング後の float16 量子化 | ○ | ○ |
トレーニング後のダイナミック レンジ量子化 | ○ | いいえ |
トレーニング後の整数量子化 | ○ | いいえ |
量子化認識トレーニング | ○ | いいえ |
パフォーマンスの検証
このセクションの情報は、 デリゲートすることで、アプリケーションを改善できます。ただし 新しい P-MAX キャンペーンを 各デリゲートには、サポートする事前定義されたオペレーション セットがあります。 モデルやデバイスによって性能は異なりますそのため、通常は 委任の有用性を評価するためにベンチマークを実施することをおすすめします。 カスタマイズが可能です。また、このイベントに関連するバイナリサイズの増加を正当化するのに LiteRT ランタイムにデリゲートをアタッチします。
LiteRT には、パフォーマンスと精度を評価する デリゲートを信頼してアプリケーションで委任できます。 これらのツールについては、次のセクションで説明します。
評価ツール
レイテンシとメモリ使用量
LiteRT のベンチマーク ツールは、
平均推論など、モデルのパフォーマンスを推定するための適切なパラメータ
レイテンシ、初期化オーバーヘッド、メモリ使用量などです
モデルに最適な委任構成を特定するための複数のフラグが用意されています。対象
GPU を測定するには、--use_gpu
で --gpu_backend=gl
を指定します。
実行する方法を学びました。サポートされている委譲パラメータの完全なリストについては、
ドキュメントをご覧ください。
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 とは異なる精度で計算を実行する 使用します。その結果、精度の(通常は軽微な)トレードオフが発生します。 デリゲートを使用したハードウェア アクセラレーションに関連します。なお、 常に true になるとは限りません。たとえば、GPU では浮動小数点精度を使用して 場合、精度がわずかに向上する可能性があります(たとえば、 ILSVRC 画像分類におけるトップ 5 の改善が 1% 未満)。
LiteRT には、デリゲートの精度を測定する 2 種類のツールがある 特定のモデル(タスクベースとタスク非依存)に対する動作を確認します。すべてのツール 高度な委任は、このセクションで説明するように、高度な委任 パラメータ ベンチマーク ツールで使用した分だけ表示されます。なお、 以下のサブセクションでは、委任評価に焦点を当てています(委任は 問題(モデル自体がトレーニングに適しているか)を できます)。
タスクベースの評価
LiteRT には、次の 2 つの画像ベースのタスクの正確性を評価するツールがあります。
ILSVRC 2012(画像) 分類など)をトップ K を使って 精度
COCO オブジェクト検出(境界ボックスを使用) (平均平均適合率) (mAP)
これらのツールのビルド済みバイナリ(Android、64 ビット ARM アーキテクチャ)と ドキュメントをご覧ください。
- ImageNet 画像分類 ( 詳細) * COCO オブジェクト 検出 ( 詳細)
以下の例は、画像分類の 評価 GPU を搭載した Google Pixel 4 の場合:
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
予想される出力は、トップ K 指標(1 ~ 10)のリストです。
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 には推論と 差分 ツールです。(Android、64 ビット ARM バイナリ アーキテクチャ バイナリ、 こちら)
推論の差分では、LiteRT の実行を比較します(レイテンシと 出力値の偏差)を次の 2 つの設定で定義します。
- シングルスレッド CPU 推論
- ユーザー定義の推論 - これらのパラメータで定義
そのために、このツールはランダムなガウスデータを生成し、それを 2 つの TFLite インタープリタ - 一方はシングルスレッド CPU カーネルを実行し、もう一方はシングルスレッド CPU カーネルを実行します ユーザーの引数によってパラメータ化されます。
両方のレイテンシと、両者の絶対的な差を測定します。 要素ごとに、各インタープリタからの出力テンソルを作成します。
単一の出力テンソルを持つモデルの場合、出力は次のようになります。
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
異なる
これらの数値を解釈するにはモデルに関する深い知識が必要であり、 意味することを表します。単純な回帰であれば スコアやエンべディングなどによる場合、その差は 委任に関するエラー)。ただし、「検出クラス」のような出力は1 から SSD モデルは解釈が少し困難です。たとえば 違いはわかりますが、 デリゲート: 「TV (ID: 10)」、「Monitor (ID:20)」の 2 つの(架空の)クラスを検討します。- もし 真実から少し離れて テレビではなくモニターに 映し出されます このテンソルの出力差分は 20-10 = 10 程度になります。