7.9. TensorFlow Lite for Microcontrollers

TFLM to środowisko wykonawcze, którego większość kamer używa do wykonania załadowanego modelu. Parsuje plik .tflite – FlatBuffer operatorów, wag i kształtów tensorów – i przechodzi listę operatorów po kolei, kierując każdy operator do kernela, który produkuje kolejny tensor pośredni.

Tensory pośrednie żyją w arenie tensorów o stałym rozmiarze, alokowanej w czasie ładowania. Kamera ustala rozmiar areny w dwóch przebiegach: najpierw, jednorazowy interpreter jest budowany względem maksymalnej wolnej sterty, aby model mógł zgłosić, ile pamięci roboczej potrzebuje; trwały interpreter jest następnie alokowany z dokładnie tym rozmiarem plus niewielki margines. Mniejsze modele pozostawiają więcej wolnej sterty dla reszty skryptu.

TFLM to silnik na H7, RT1062 i AE3.

Trzy kolumny obok siebie. Po lewej: H7 i RT1062 uruchamiają TFLM z kernelami CMSIS-NN na Cortex-M7. W środku: AE3 uruchamia TFLM z CMSIS-NN i operatorem Ethos-U na Cortex-M55 z NPU Ethos-U55. Po prawej: N6 uruchamia STAI na NPU Neural-ART.

Silnik w środku predict() to inny stos na każdej rodzinie kamer.

7.9.1. Resolver operatorów

TFLM nie dostarcza każdego kernela. Kamera linkuje resolver, który wymienia operatory, jakie potrafi wykonać, a model załadowany względem resolvera zawodzi w czasie ładowania, jeśli zawiera operator spoza listy. Dostarczany build rejestruje operatory powszechne w sieciach wizyjnych i przetwarzania sygnałów – warstwy konwolucyjne i gęste, warstwy pooling i aktywacji, operatory reshape i concat, operatory quantize i dequantize – tak więc model wytrenowany według jednej ze standardowych architektur (YOLO, MediaPipe, MobileNet) ładuje się bez rozszerzania listy.

Build AE3 dodatkowo rejestruje operator Ethos-U. Model skompilowany przez Vela jest poza tym normalnym plikiem .tflite, a TFLM przechodzi go normalnie; podgrafy oznaczone przez Vela trafiają na operator Ethos-U i są kierowane do NPU.