Przedstawiciele LiteRT

Przedstawiciele włączają akcelerację sprzętową modeli LiteRT przez wykorzystując dostępne w urządzeniu akceleratory, takie jak GPU i procesor sygnału cyfrowego (DSP).

Domyślnie LiteRT korzysta z jąder CPU zoptymalizowanych pod kątem ARM Neonowy zestawu instrukcji. Jest to jednak wielofunkcyjny procesor, koniecznie zoptymalizowane pod kątem intensywnych działań arytmetycznych, które zazwyczaj występują modele uczenia się (np. matematyka macierzysta zaangażowana w splot i gęstość) warstwy).

Z drugiej strony większość nowoczesnych telefonów komórkowych zawiera układy scalone, które lepiej w obszarze tych ciężkich operacji. Wykorzystywanie ich do operacji w sieci neuronowej zapewnia ogromne korzyści w zakresie czasu oczekiwania i oszczędności energii. Przykład: Procesory graficzne mogą zapewnić do 5x przyspieszenie czas oczekiwania.

Każdy z tych akceleratorów ma powiązane interfejsy API, które umożliwiają niestandardowe obliczenia takie jak OpenCL lub OpenGL ES w przypadku GPU. Zwykle na napisanie dużego niestandardowego kodu do uruchomienia sieci neuronowej przez te interfejsy. Sprawa komplikuje się jeszcze, gdy weźmie się pod uwagę, że każdy akcelerator ma swoje profesjonaliści i i nie można wykonywać wszystkich operacji w sieci neuronowej. TensorFlow Interfejs Delegate API Lite rozwiązuje ten problem, działając jako most między TFLite środowiska wykonawczego i interfejsów API niższego poziomu.

środowisko wykonawcze z przedstawicielami

Wybór przedstawiciela

LiteRT obsługuje wielu przedstawicieli, z których każdy jest zoptymalizowany pod kątem określonych platform i modeli. Zazwyczaj wielu przedstawicieli odpowiednich do Twojego przypadku użycia, w zależności od 2 głównych kryteriów: Platformę (Android czy iOS?), na którą kierujesz reklamy, i Typ modelu. (zmiennoprzecinkowych czy kwantyzowanych?), który chcesz przyspieszyć.

Delegaci według platformy

Wiele platform (Android i iOS)

  • Delegacja GPU – może być używany zarówno w przypadku urządzeń z Androidem, jak i iOS. it jest zoptymalizowana do uruchamiania 32- i 16-bitowych modeli zmiennoprzecinkowych, w których procesor graficzny i dostępności informacji. Obsługuje również 8-bitowe kwantyzowane modele i obsługuje GPU wydajnością porównywalną do wersji zmiennoprzecinkowych. Szczegółowe informacje o GPU można znaleźć w artykule na temat LiteRT on GPU.

iOS

  • Przekazywanie dostępu do Core ML na nowszych iPhone'ach i iPadach – w przypadku nowszych iPhone'ów i na iPadach, na których dostępny jest mechanizm Neural Engine, możesz użyć przedstawiciela Core ML do Przyspiesz wnioskowanie w 32- lub 16-bitowych modelach zmiennoprzecinkowych. Neural Silnik jest dostępny na urządzeniach mobilnych Apple z układem SoC A12 lub nowszym. Dla z omówieniem przedstawiciela Core ML i z instrukcjami krok po kroku. Przedstawiciel platformy LiteRT Core ML.

Delegacje według typu modelu

Każdy akcelerator został zaprojektowany z myślą o określonej szerokości bitów. Jeśli udostępnić delegatowi model zmiennoprzecinkowy, który obsługuje tylko 8-bitowe dane kwantyzowane odrzuca wszystkie swoje operacje, a model będzie działać wyłącznie na procesor. Aby uniknąć takich niespodzianek, w tabeli poniżej znajdziesz omówienie przekaż pomoc na podstawie typu modelu:

Typ modelu GPU CoreML
Liczba zmiennoprzecinkowa (32-bitowa) Tak Tak
Kwantyzacja obiektu float16 po zakończeniu trenowania Tak Tak
Kwantyzacja zakresu dynamicznego po trenowaniu Tak Nie
Kwantyzacja liczb całkowitych po trenowaniu Tak Nie
Szkolenie z myślą o kwantyzacji Tak Nie

Sprawdzanie skuteczności

Informacje podane w tej sekcji stanowią ogólne wskazówki podczas tworzenia listy aby mogli ulepszyć Twoją aplikację. Należy jednak pamiętać, że każdy przedstawiciel ma wstępnie zdefiniowany zestaw operacji, które obsługuje. Może działają różnie w zależności od modelu i urządzenia. Dlatego zwykle warto przeprowadzić kilka testów porównawczych, aby ocenić przydatność przedstawiciela dostosowane do Twoich potrzeb. Pomaga to również uzasadnić zwiększenie rozmiaru pliku binarnego powiązanego z przez dodanie przedstawiciela do środowiska wykonawczego LiteRT.

LiteRT dysponuje rozbudowanym narzędziem do oceny wydajności i dokładności, pozwala programistom pewnie korzystać z przekazanych przedstawicieli w swoich aplikacjach. Omówimy te narzędzia w następnej sekcji.

Narzędzia do oceny

Czas oczekiwania i wykorzystanie pamięci

Narzędzia analizy porównawczej LiteRT można używać w przypadku: parametry odpowiednie do szacowania wydajności modelu, w tym średnie wnioskowanie czas oczekiwania, narzut inicjowania, ilość pamięci itd. To narzędzie obsługuje wiele flag w celu znalezienia najlepszej konfiguracji delegacji dla modelu. Dla: w instancji --gpu_backend=gl można określić za pomocą --use_gpu, aby mierzyć GPU w trybie OpenGL. Pełna lista obsługiwanych parametrów delegowania to zdefiniowane w szczegółowym dokumentacji.

Oto przykład uruchomienia modelu kwantyzowanego z użyciem GPU w adb:

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

Możesz pobrać gotową wersję tego narzędzia na Androida z 64-bitową architekturą ARM architektura tutaj (więcej ).

Dokładność poprawność

Przedstawiciele zwykle wykonują obliczenia z inną precyzją niż ich procesor i jego odpowiedniki. W efekcie występuje (zwykle nieznaczna) różnica w dokładności. związane z przekazywaniem dostępu do akceleracji sprzętowej. Pamiętaj, że to nie zawsze jest prawdą; na przykład, bo GPU używa precyzji zmiennoprzecinkowej do uruchamiania modeli kwantowych, może wystąpić niewielka poprawa precyzji (np. <1% – poprawa klasyfikacji obrazów ILSVRC o najwyższych 5 punktach).

LiteRT oferuje 2 rodzaje narzędzi do mierzenia precyzji przedstawicieli działa w przypadku danego modelu: zadania i niezależne od zadania. Wszystkie narzędzia opisane w tej sekcji obsługują zaawansowane przekazywanie dostępu za pomocą narzędzia analizy porównawczej z poprzedniej sekcji. Pamiętaj, że parametr mowa w podsekcjach poniżej, jaka jest ocena przekazywania dostępu (czy delegat wykonuje taki sam jak procesor?), a nie przez ocenę modelu (czy sam model jest odpowiedni dla zadanie?).

Ocena oparta na zadaniu

LiteRT oferuje narzędzia do oceny poprawności w 2 zadaniach graficznych:

Gotowe pliki binarne tych narzędzi (Android, 64-bitowa architektura ARM) wraz z dokumentacja jest dostępna tutaj:

Poniższy przykład pokazuje klasyfikację obrazów ocena z GPU w Pixelu 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

Oczekiwanym wynikiem jest lista danych Top-K z zakresu od 1 do 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

Ocena niezależna od zadania

W przypadku zadań, dla których nie ma gotowego narzędzia do oceny na urządzeniu lub jeśli eksperymentuje z modelami niestandardowymi, LiteRT oferuje zależność Różnice . (Android, 64-bitowy plik binarny architektury ARM tutaj)

Różnica wnioskowania porównuje wykonanie LiteRT (pod względem czasu oczekiwania odchylenie od wartości wyjściowej) w 2 ustawieniach:

  • Jednowątkowa wnioskowanie o procesor
  • Wniosek zdefiniowany przez użytkownika – definiowany przez te parametry.

W tym celu narzędzie generuje losowe dane Gaussa i przekazuje je Interpretery TFLite – jeden z jądrem procesora jednowątkowym, a drugi; z parametrami będącymi parametrami użytkownika.

Mierzy czas oczekiwania w obu przypadkach, a także bezwzględną różnicę między tensory wyjściowe z każdego tłumacza, w podziale na elementy.

W przypadku modelu z pojedynczym tensorem wyjściowym dane wyjściowe mogą wyglądać tak:

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

Oznacza to, że dla tensora wyjściowego w pozycji 0 elementy dane wyjściowe procesora różniące się o średnią wartość 1.96e-05 od danych wyjściowych delegowanego.

Pamiętaj, że interpretacja tych liczb wymaga głębszej znajomości modelu oraz znaczenie każdego tensora wyjściowego. Jeśli jest to prosta regresja, która określa wyniku lub wektora dystrybucyjnego, różnica powinna być niewielka (w przeciwnym razie jest to u przedstawiciela). Dane wyjściowe, takie jak „klasa wykrywania” jeden od Modele SSD są nieco trudniejsze do zinterpretowania. Na przykład może wyświetlić się przy korzystaniu z tego narzędzia, ale nie oznacza to, że coś jest nie tak osoba z przekazanym dostępem: rozważ dwie (fałszywe) klasy: „TV (ID: 10)” i „Monitor (ID:20)” - Jeśli przedstawiciel odbiega nieco od złotej prawdy i zamiast telewizora pokazuje monitor różnica wyjściowa tego tensora może wynosić około 20–10 = 10.