Délégués LiteRT

Les délégués activent l'accélération matérielle des modèles LiteRT en en exploitant des accélérateurs sur l'appareil tels que le GPU et le processeur de signal numérique. (DSP).

Par défaut, LiteRT utilise des noyaux de processeur optimisés pour ARM Néon ensemble d'instructions. Cependant, le CPU est un processeur polyvalent qui n’est pas nécessairement optimisé pour l'arithmétique lourde généralement utilisée dans les machines Modèles d'apprentissage (par exemple, les mathématiques matricielles impliquées dans les tâches de convolution et de densité couches).

D'autre part, la plupart des téléphones mobiles modernes contiennent des puces qui sont mieux pour gérer ces opérations lourdes. Les utiliser pour des opérations sur les réseaux de neurones offre d'énormes avantages en termes de latence et d'efficacité énergétique. Par exemple : Les GPU peuvent offrir jusqu'à 5 fois accélérer en termes de latence.

Chacun de ces accélérateurs est associé à des API qui permettent des calculs personnalisés, comme OpenCL ou OpenGL ES pour GPU mobile. Généralement, il faut d'écrire beaucoup de code personnalisé pour exécuter un réseau de neurones via ces interfaces. Les choses se compliquent encore quand on considère que chaque accélérateur a son avantages et Inconvénients et ne peut pas exécuter toutes les opérations dans un réseau de neurones. TensorFlow L'API Delegate de Lite résout ce problème en jouant le rôle de pont entre TFLite dans l'environnement d'exécution et ces API de niveau inférieur.

environnement d'exécution avec des délégués

Choisir un délégué

LiteRT prend en charge plusieurs délégués, chacun étant optimisé pour sur une ou plusieurs plates-formes et des types de modèles particuliers. Habituellement, il y aura plusieurs délégués applicables à votre cas d'utilisation, en fonction de deux critères principaux: La plate-forme (Android ou iOS) que vous ciblez et la valeur Model-type (à virgule flottante ou quantifiée) que vous essayez d'accélérer.

Délégués par plate-forme

Multiplate-forme (Android et iOS)

  • Délégué de GPU : le délégué de GPU peut être utilisé à la fois sur Android et sur iOS. Il est optimisé pour exécuter des modèles à virgule flottante 32 bits et 16 bits lorsqu'un GPU est disponibles. Il est également compatible avec les modèles quantifiés 8 bits et fournit des GPU des performances équivalentes à celles de leurs versions flottantes. Pour en savoir plus sur le GPU délégué, consultez LiteRT sur GPU.

iOS

  • Délégué Core ML pour les iPhone et iPad plus récents : pour les iPhone et les iPad récents Sur les iPad où Neural Engine est disponible, vous pouvez utiliser le délégué Core ML pour accélérer l'inférence pour les modèles à virgule flottante 32 bits ou 16 bits. Neural est disponible sur les appareils mobiles Apple dotés d'un SoC A12 ou supérieur. Pour une du délégué Core ML et des instructions détaillées, consultez Délégué Core ML LiteRT.

Délégués par type de modèle

Chaque accélérateur est conçu en tenant compte d'une certaine largeur de bits. Si vous fournir à un délégué un modèle à virgule flottante qui n'accepte que les données quantifiées 8 bits toutes les opérations sont rejetées, et le modèle s'exécute entièrement le processeur. Pour éviter de telles surprises, le tableau ci-dessous présente les l'assistance en fonction du type de modèle:

Type de modèle GPU CoreML
Valeur à virgule flottante (32 bits) Oui Oui
Quantification float16 post-entraînement Oui Oui
Quantification de la plage dynamique post-entraînement Oui Non
Quantification par nombres entiers post-entraînement Oui Non
Entraînement tenant compte de la quantification Oui Non

Valider les performances

Les informations contenues dans cette section servent de base pour sélectionner qui pourraient améliorer votre application. Toutefois, il est important de noter que chaque délégué prend en charge un ensemble prédéfini d'opérations fonctionnent différemment selon le modèle et l'appareil. Par conséquent, il est généralement recommandé d'effectuer une analyse comparative pour évaluer l'utilité d'un délégué en fonction de vos besoins. Cela permet également de justifier l'augmentation de la taille binaire associée à en associant un délégué à l'environnement d'exécution LiteRT.

LiteRT dispose d'outils complets d'évaluation des performances et de la justesse peut permettre aux développeurs d'utiliser en toute confiance des délégués dans leur application. Ces outils sont abordés dans la section suivante.

Outils d'évaluation

Latence et espace mémoire utilisé

L'outil d'analyse comparative de LiteRT peut être utilisé avec paramètres appropriés pour estimer les performances du modèle, y compris une moyenne d'inférence la latence, le coût d'initialisation, l'espace mémoire utilisé, etc. Cet outil plusieurs indicateurs pour déterminer la meilleure configuration de délégation pour votre modèle. Pour instance, --gpu_backend=gl peut être spécifié avec --use_gpu pour mesurer le GPU avec OpenGL. La liste complète des paramètres délégués pris en charge est définis dans la documentation documentation.

Voici un exemple d'exécution pour un modèle quantifié avec GPU via adb:

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

Vous pouvez télécharger la version prédéfinie de cet outil pour Android, ARM 64 bits. de l'architecture cliquez ici (plus détails).

Précision et exactitude

Les délégués effectuent généralement des calculs avec une précision différente de celle de leur processeur vos homologues. Par conséquent, il existe un compromis de précision (généralement mineur) associé à l'utilisation d'un délégué pour l'accélération matérielle. Notez que cette n'est pas toujours vrai. par exemple, puisque le GPU utilise la précision à virgule flottante pour exécuter des modèles quantifiés, vous constaterez peut-être une légère amélioration de la précision (par exemple, < 1% d'amélioration de la classification d'images ILSVRC.

LiteRT dispose de deux types d'outils pour mesurer la précision d'un délégué se comporte pour un modèle donné: basée sur la tâche et agnétique sur la tâche. Tous les outils décrits dans cette section prennent en charge la délégation avancée paramètres utilisé par l'outil d'analyse comparative de la section précédente. Notez que Les sous-sections ci-dessous traitent de l'évaluation par le délégué (le délégué effectue-t-il la que le processeur ?) plutôt que pour l'évaluation du modèle (le modèle lui-même est-il bon pour tâche ?).

Évaluation basée sur les tâches

LiteRT dispose d'outils permettant d'évaluer l'exactitude de deux tâches basées sur des images:

Binaires prédéfinis de ces outils (Android, architecture ARM 64 bits), ainsi que la documentation est disponible ici:

L'exemple ci-dessous illustre la classification d'images évaluation avec le GPU sur un 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

Le résultat attendu est une liste de métriques top-K de 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

Évaluation agile des tâches

Pour les tâches pour lesquelles il n'existe pas d'outil d'évaluation établi sur l'appareil, ou si vous testent des modèles personnalisés, LiteRT dispose de la fonction d'inférence Diff. . (Android, binaire d'architecture binaire ARM 64 bits) cliquez ici).

La différence d'inférence compare l'exécution LiteRT (en termes de latence et l'écart de la valeur de sortie) dans deux paramètres:

  • Inférence pour les processeurs monothread
  • Inférence définie par l'utilisateur - définie par ces paramètres

Pour ce faire, l'outil génère des données gaussiennes aléatoires et les transmet Interpréteurs TFLite : l'un exécute des noyaux CPU monothread et l'autre paramétrés par les arguments de l'utilisateur.

Il mesure la latence des deux métriques, ainsi que la différence absolue entre les les Tensors de sortie de chaque interpréteur, par élément.

Pour un modèle avec un seul Tensor de sortie, la sortie peut se présenter comme suit:

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

Cela signifie que pour le Tensor de sortie à l'indice 0, les éléments issus la sortie du processeur est différente de la sortie du délégué de 1.96e-05 en moyenne.

Notez que l'interprétation de ces chiffres nécessite une connaissance plus approfondie du modèle. ce que signifie chaque Tensor de sortie. S'il s'agit d'une simple régression qui détermine un score ou une représentation vectorielle continue, la différence doit être faible (sinon, il s'agit d'un avec le délégué). Toutefois, des sorties telles que la "classe de détection" une de Les modèles SSD sont un peu plus difficiles à interpréter. Par exemple, il peut afficher une différence d'utilisation de cet outil, mais cela ne signifie pas forcément que quelque chose ne va pas le délégué : envisagez deux classes (fictives) : "TV (ID: 10)", "Monitor (ID:20)" (Écran (ID : 20)). - Si un délégué qui ne respecte pas la vérité et fait appel à un moniteur au lieu de la télévision, La diff de sortie pour ce Tensor peut atteindre 20-10 = 10.