Pierwsze kroki z modułem Nvidia Jetson Orin NX

[Elvis]

Dzięki uprzejmości firmy Botland otrzymałem solidny rabat na płytki wyposażone w najnowsze układy NVIDIA Jetson Orin, więc w niniejszym worklogu postaram się podzielić wrażeniami z poznawania ich możliwości. Głównymi bohaterami tego wpisu są dwie poniższe płytki (ceny z czerwca 2023):

• reComputer J4012 - 6 999 zł
• AGX Orin Developer Kit - 14 999 zł

Już po samych cenach można łatwo dojść do wniosku, że są to potężne układy, które raczej wykraczają poza hobbystyczną elektronikę. Warto jednak wiedzieć jakie są aktualnie trendy i nowości

Komputery jednopłytkowe wyposażone w układy firmy Nvidia pojawiały się już na forum oraz blogu kilkukrotnie:

• NVIDIA Jetson TK1 - https://forbot.pl/blog/jetson-tk1-okiem-robotyka-1-slowo-wstepne-id12113
• NVIDIA Jetson TX2 - https://forbot.pl/blog/nvidia-jetson-tx2-jeszcze-wiecej-mocy-id20208
• NVIDIA Jetson Nano - https://forbot.pl/blog/nvidia-jetson-nano-to-maly-sbc-o-wielkich-mozliwosciach-id35939

Układy TK1 zostały po raz pierwszy zaprezentowane w 2014, co czyni je konstrukcjami już dość wiekowymi. Posiadają 32-bitowe rdzenie Cortex-A15 oraz 192 rdzenie CUDA. Ich moc obliczeniowa jest szacowana na 326 GFLOPS - dla porównania Raspberry Pi 4B oferuje niecałe 14 GFLOPS.

Możliwości układów TX2 najlepiej pokazuje ich wykorzystanie w konsolach Nintendo Switch. Układy TX2 są produkowane od 2017 roku, posiadają 64-bitowe rdzenie Cortex-A57 oraz 256 rdzeni CUDA. Pozwala im to dostarczyć 1.33 TFLOPS mocy obliczeniowej.

Natomiast Jetson Nano jest niejako niskobudżetową wersją TX2. Ma mniejszą moc obliczeniową, bo "raptem" 472 GFLOPS ale jest też o wiele tańsza. Płytki rozwojowe z tymi układami są dość popularne wśród hobbystów: https://botland.com.pl/moduly-nvidia/16536-nvidia-jetson-nano-b01-arm-cortex-a57-4x-143ghz-nvidia-maxwell-4gb-ram-5903351241519.html 

Ostatnio Nvidia zaprezentowała nową rodzinę układów nazwaną Orin i dedykowaną rozwiązaniom AI. To sprawia, że zamiast porównywać liczbę operacji zmiennopozycyjnych (GFLOPS), głównym parametrem stały się operacje tensorowe (TOPS).

Układy Orin dzielą się na trzy grupy:

• NVIDIA Jetson Orin Nano - najtańsze układy oferujące 20-40 TOPS
• NVIDIA Jetson Orin NX - średnia półka dostarczająca 70-100 TOPS
• NVIDIA Jetson Orin AGX - najwydajniejsze układy osiągające 200-275 TOPS

TOPS oznacza biliony operacji na sekundę (ang. Trillion operations per second). Nawet 20 TOPS to ogromna moc - typowe akceleratory, jak chociażby opisywany na Forbocie Google Edge TPU (https://forbot.pl/blog/praktyczny-wstep-do-ai-z-plytka-asus-tinker-edge-t-id44909) oferują 4-5 TOPS.

Nowe układy zapowiadają się więc bardzo interesująco, a jak ich parametry przekładają się na rzeczywiste możliwości planuję sprawdzić oraz opisać w niniejszym worklogu.

Do testów wybrałem dwie płytki:

• reComputer J4012 firmy SeeedStudio - https://botland.com.pl/moduly-nvidia/22764-recomputer-j4012-nvidia-jetson-orin-nx-16gb-ram-128gb-nvme-seeedstudio-110110145.html
• AGX Orin Developer Kit od Nvidii - https://botland.com.pl/moduly-nvidia/22925-agx-orin-developer-kit-64gb-zestaw-programistyczny-nvidia-jetson-agx-orin-seeedstudio-102110842.html

Obie płytki są wyposażone w topowe układy, pierwsza z grupy NVIDIA Jetson Orin NX, druga Orin AGX. To oznacza, że teoretycznie powinny oferować odpowiednio 100 oraz 275 TOPS - ciekawe jakie to będzie to miało przełożenie na rzeczywiste działanie.

Zachęcam do śledzenia workloga

[Elvis]

Rozpakowywanie płytek

Płytki zostały dostarczone już kilka dni temu, ale ich uruchomienie wymagało pokonania drobnych problemów o czym za chwilę. Obie prezentują się bardzo okazale, chociaż trzeba przyznać, że pudełko z Jetson Orin AGX jest dużo większe i cięższe. Można wręcz powiedzieć, że w przeliczeniu na kilogram, cena obu płytek jest podobna:

Po otwarciu pudełek widzimy wreszcie płytki Orin:

A po wyjęciu z pudełek widać je jeszcze lepiej:

Obudowę reComputer J4012 można łatwo otworzyć i zobaczyć samą płytkę z modułem Jetson Orin NX. Natomiast AGX Orin Developer Kit pozwala na dostęp do niektórych elementów od spodu płytki, z boku obudowy znajdziemy również znane z komputerów PC złącze PCI-express.

Płytka AGX Orin jest szczelnie zakryta radiatorem, więc robienie jej zdjęć nie było zbyt ciekawe. Natomiast płytka z Orin NX może być łatwo wyjęta z obudowy. Na szczególną uwagę zasługuje jej spodnia strona - znajdziemy tam zainstalowany dysk SSD o pojemności 128GB oraz miejsce na moduł WiFi.

Jeszcze jedno zdjęcie - porównanie taniej płytki Jetson Nano z nową werjsją Orin NX. Jak widać obie są bardzo podobne.

 

Na zakończenie przykra niespodzianka. W pudełkach, poza samymi płytkami znajdziemy niezbędne zasilacze. Niestety w przypadku Orin NX zasilacze są dostarczane bez przewodu zasilającego:

Natomiast Orin AGX jest co prawda wyposażony w 3 wersje, ale żadna nie pasuje do polskich gniazdek:

Sprawy nie ułatwia to że nie jest to typowy przewód zasilający dla komputerów PC, ale "koniczynka" (https://botland.com.pl/przewody-i-przejsciowki/2561-przewod-sieciowy-do-zasilaczy-3-pin-koniczynka-dlugosc-15m-5901720130525.html). Możemy brakujący przewód oczywiście dokupić, koszt 6,90zł raczej nie będzie miał dla nas znaczenia po wydaniu kilku lub kilkunastu tysięcy na płytkę ewaluacyjną - jednak na dostawę kolejnego zamówienia trzeba poczekać, co jest nieco irytujące i mocno zaskakuje w przypadku dość drogich układów.

Odpowiednia informacja jest na stronie produktu, przyznam jednak że jej nie zauważyłem podczas składania zamówienia i moduły musiały trochę poczekać na pierwsze uruchomienie.

 

Edytowano Czerwiec 25, 2023 przez Elvis

[Treker (Damian Szymański)]

@Elvis dzięki za podjęcie tego tematu  Liczę, że do dyskusji włączą inne zainteresowane osoby. Może ktoś z Was korzystał już z tych płytek?

[Harnas]

Czy dobrze liczę że RTX 3050 ma 2560 rdzeni CUDA, 80 Tensor Cores i taktowanie 1.5GHz, czyli pod każdym względem jest szybszy od Jetson Orin AGX?
 

[Elvis]

@Harnas Masz w 100% rację, jak chodzi o wydajność karty graficzne są o wiele szybsze i tańsze niż układy Jetson. Warto jednak popatrzeć na inny parametr - moc pobieraną przez układ. W przypadku urządzeń mobilnych może to mieć bardzo duże znaczenie. Wyobraźmy sobie przykładowo budowę drona, który będzie w czasie rzeczywistym przetwarzał obraz. Zainstalowanie na nim ogromnych akumulatorów potrzebnych do zasilania karty graficznej może nie być idealnym rozwiązaniem.

Jeszcze jeden przykład, może nieco bardziej przyziemny, gdzie moduły Jetson są używane:

Co ciekawe jest to produkt komercyjny i każdy może sobie takiego robo-psa sprawić: https://botland.com.pl/roboty-kroczace/21624-czworonozna-platforma-kroczaca-robo-pies-unitree-go1-air.html

Edytowano Czerwiec 26, 2023 przez Elvis

[Elvis]

Pierwsze uruchomienie

Poprzednio pisałem o niespodziankach związanych z brakiem przewodów zasilających. Jednak po zdobyciu brakujących elementów samo uruchomienie płytek okazało się banalnie proste. Obie mają już zainstalowany system operacyjny, więc po włączeniu zasilania wystarczy nieco poczekać, a następnie odpowiedzieć na kilka pytań odnośnie konfiguracji systemu (przepraszam za niską jakość obrazków, w kolejnych wpisach obiecuję już nie robić zdjęć ekranu):

 

Po ponownym uruchomieniu systemu płytka jest gotowa do pracy:

Jak widać instalacja jest bardzo prosta, a sam system oparty jest o Ubuntu. Nawet osoby dopiero zaczynające przygodę z Linuxem nie powinny mieć najmniejszych problemów z uruchomieniem płytki.

Z ciekawostek, które zauważyłem przy pierwszym uruchomieniu:

• płytki, podobnie jak komputery PC, są wyposażone są w UEFI (następca BIOS-u)
• użytkownik może wybierać profil mocy, a wybór profilu ma wpływ nie tylko na wydajność, ale i liczbę rdzeni Cortex-A78 dostępnych dla użytkownika
• obie płytki pracują zaskakująco cicho
• system działa bardzo płynnie, widoczna jest znaczna poprawa względem Jetson Nano
• Jetson Orin NX nie posiada karty WiFi. Można podłączyć odpowiedni moduł do złącza PCIe lub poprzez USB (niestety, nie każdy działa poprawnie)

Jak widać uruchomienie płytek jest bardzo proste, czas więc przejść dalej i sprawdzić je w działaniu.

Od tej chwili będę koncentrował się na tańszej płytce, czyli Jetson Orin NX. Do droższej zamierzam wrócić później i przeprowadzić testy porównawcze. Na początek Orin NX powinien być więcej niż wystarczającym wyzwaniem.

 

Edytowano Czerwiec 26, 2023 przez Elvis

[FlyingDutch]

Cześć @Elvis,

temat bardzo ciekawy. Czy zamierzasz na którymś z tych zestawów uruchomić jakiś konkretny projekt?

Pozdrawiam

Edytowano Czerwiec 27, 2023 przez FlyingDutch
update

[Treker (Damian Szymański)]

@FlyingDutch na pewno @Elvis napisze coś więcej w tej kwestii, ale dla formalności daje znać, że w momencie, gdy pisałeś swoją wiadomość to najnowszy wpis Elvisa nie był jeszcze widoczny publicznie - właśnie go opublikowałem (post wyżej)

[Elvis]

@FlyingDutch Pomysły ciągle się zmieniają, więc wolę za dużo nie obiecywać.

Miałem trochę inne zamiary, ale teraz planuję przejść tutorial dostarczany przez Nvidię: https://developer.nvidia.com/embedded/learn/jetson-ai-certification-programs#course_outline

Bardzo ciekawie wygląda "Epizod #3":

Zachęcam do oglądania filmu, w kolejnym wpisie postaram się przedstawić jak mi poszło uruchamianie przykładów

[matsobdev]

Dnia 26.06.2023 o 01:43, Harnas napisał:

Czy dobrze liczę że RTX 3050 ma 2560 rdzeni CUDA, 80 Tensor Cores i taktowanie 1.5GHz, czyli pod każdym względem jest szybszy od Jetson Orin AGX?
 

 

23 godziny temu, Elvis napisał:

Warto jednak popatrzeć na inny parametr - moc pobieraną przez układ. W przypadku urządzeń mobilnych może to mieć bardzo duże znaczenie.

Jakiś półśrodek to płyta z lapka wyjęta. Coś używanego (albo nowego) z Nvidią. Już jest wtedy zintegrowane GPU, żeby karta nie musiała zajmować się interfejsem (to był problem - tak sądzę, wydajnościowy - jak się bawiłen na Ubuntu 20.04 z GT1030 to przykłady z jakiegoś poradnika działały wolniej, niż u nich na Macu ze słabszą GT). Choć można by wyłączyć interfejs, żeby karta tylko program liczyła.

Choć ma to swoje ograniczenia, wiadomo, choć mogą być one nieistotne.

Edytowano Czerwiec 27, 2023 przez matsobdev

[Elvis]

Wygląda na to, że nie należy pisać co się planuje bo wtedy na pewno coś pójdzie nie tak. Teoretycznie wszystko wyglądało idealnie - tutorial firmy Nvidia jest na pewno sprawdzony,  używa Docker-a, więc wszystko powinno działać bez problemu.

Niestety jak zwykle teoria rozmija się z praktyką. Próbowałem na różne sposoby przejść tutorial, ale nic mi z tego nie wyszło. Już na samym początku pojawia się problem:

A później wcale nie jest lepiej i przykłady nie dają się uruchomić. Spędziłem całkiem sporo czasu podczas ostatnich kilku dni i niestety poddałem się

Na koniec uświadomiłem sobie jednak gdzie jest problem. Postąpiłem podobnie do wielu czytelników kursu STM32 - wybrałem "lepszą" płytkę i próbowałem uruchomić na niej tutorial przeznaczony dla nieco innej wersji. Pomyślałem, że przecież Jetson Orin NX i Jetson Nano pewnie niewiele się różnią, to tylko trochę lepszy model... Łatwo jest krytykować innych, ale jeszcze łatwiej jest samemu taki sam błąd popełnić.

Następnie spróbowałem uruchomić przykłady na płytce Jetson Nano i tym razem nie było najmniejszych problemów, wszystko zadziałało idealnie. Więc jeśli ktoś jest zainteresowany tym tutorialem, to polecam go uruchamiać na dedykowanej płytce.

 

[Elvis]

Skoro z tutorialami nie poszło najlepiej, nie pozostało nic innego niż spróbować uruchomić własny przykład.

Trenowanie sieci na płytkach Orin nie ma raczej sensu, do tego są porządne akceleratory graficzne potrzebne, a nie platforma mobilna. Postanowiłem więc wypróbować dobrze znaną sieć Resnet50 (https://arxiv.org/abs/1512.03385).

Jest to już klasyczna sieć zbudowana z 50 warstw, która może być używana do rozpoznawania obrazów (klasyfikacji)

(Gorlapraveen123, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons)

Przed rozpoczęciem zabawy z płytką Jetson, warto najpierw przetestować samą sieć oraz możliwości jej używania. Jednym z najprostszych sposobów jest wykorzystanie darmowego dostępu do Google Colab: https://colab.research.google.com

Osoby zaznajomione z Jupyter Lab (https://jupyter.org) na pewno od razu rozpoznają dostępne środowisko, natomiast dla osób które potrzebują nieco wprowadzenia dostępny jest tutorial (nie wiem jak wkleić link, więc najprościej zapytać wujka google o "google colab tutorial").

Na początek warto utworzyć kod który pobierze obrazki do testowania. Ja wybrałem 3 przykładowe z Forbotowego kursu programowania STM32L4 (https://forbot.pl/blog/kurs-stm32-l4-wstep-spis-tresci-dla-kogo-jest-ten-kurs-id48575 )

Kod programu pochodzi w większości z internetu i wygląda następująco:

import requests
from PIL import Image
import io

def load_image(url):
    res = requests.get(url).content
    return Image.open(io.BytesIO(res))

#img = load_image("https://forbot.pl/blog/wp-content/uploads/2021/07/FORBOT_kurs_STM32L4_IR_NEC_liczniki.jpg")
#img = load_image("https://cdn.forbot.pl/blog/wp-content/uploads/2021/04/FORBOT_kurs_STM32L4_watchdog.jpg")
img = load_image("https://cdn.forbot.pl/blog/wp-content/uploads/2021/05/FORBOT_kurs_STM32L4_przerwania_procedury.jpg")

Można go bezpośrednio skopiować do Colab-a i uruchomić. A przetestować najprościej wyświetlając zawartość zmiennej img:

Teraz można przystąpić do rozpoznawania obrazu. Na początek importujemy gotową i wytrenowaną sieć Resnet50:

from torchvision.models import resnet50, ResNet50_Weights

weights = ResNet50_Weights.IMAGENET1K_V1
model = resnet50(weights=weights)
model.eval()

Wagi (zmienna "weights") odpowiadają wartościom ustalonym podczas trenowania. Jako baza obrazów został wykorzystany zestaw ImageNet (https://www.image-net.org). Więcej informacji naszym modelu znajdziemy pod adresem: https://pytorch.org/vision/stable/models/generated/torchvision.models.resnet50.html#torchvision.models.resnet50

Najważniejsze dane są w tabelce poniżej:

Warto zauważyć, że model używa 25557032 parametrów (ponad 25 milionów liczb float32), a podczas obliczeń wykonywanych jest ponad 4 miliardy operacji zmiennopozycyjnych (4.09 GFLOPS). Wielkość pliku to 97.8 MB, więc raczej nie mamy co liczyć, że użyjemy Resnet50 na mikrokontrolerze.

Obrazek wejściowy musi zostać nieco przekształcony przed przekazaniem go do sieci neuronowej. Przekształecenie powinno być identyczne z tym, które było stosowane podczas treningu sieci. Możemy to uzyskać bardzo prostym kodem:

preprocess = weights.transforms()
input = preprocess(img).unsqueeze(0)

Teraz gdy mamy nasz model oraz dane wejściowe, możemy go uruchomić:

output = model(input)

Jedna linijka kodu wygląda niepozornie, ale to właśnie w niej wykonywana jest cała magia oraz 4.09 GFLOPS obliczeń.

Na koniec wystarczy wśród wyników (output) wyszukać wartości o najwyższym prawdopodobieństwie i je wyświetlić:

results = output.squeeze(0).softmax(0)
for i in results.topk(3).indices:
    id = i.item()
    cat = weights.meta["categories"][id]
    rate = results[id].item()
    print("{}: {:.2f}%".format(cat, 100*rate))

Całość po uruchomieniu prezentuje się następująco:

 

Sieć rozpoznała na obrazku pizzę z prawdopodobieństwem 99.76% i chyba miała rację. 

Dla zdjęcia z pilotami RC uzyskałam wyniki:

remote control: 61.63%
hand-held computer: 18.32%
photocopier: 10.46%

Natomiast dla Watch-doga wyszło:

beagle: 15.33%
muzzle: 14.46%
tennis ball: 8.81%

Jak widać sieć nie była pewna rezultatów, ale nie można mieć do niej pretensji - nieczęsto widzimy psa w okularach używającego laptopa.

W każdym razie wyniki są raczej zadowalające, w kolejnym wpisie opiszę jak powyższe skrypty uruchomić na płytce NVIDIA Jetson Orin NX oraz spróbuję porównać wydajność różnych rozwiązań.

Edytowano Lipiec 2, 2023 przez Elvis

[Elvis]

Testy porównawcze to temat rzeka, więc na początek może warto dodać bardzo prosty test i zmierzyć ile czas zajmuje inferencja, czyli obliczanie wyników przez sieć:

import time

t1 = time.time()
output = model(input)
t2 = time.time()
print("Result: {:.2f} ms\n".format((t2-t1)*1000))

Kod jest bardzo prosty, ale daje chociaż ogólne oszacowanie czasu potrzebnego na wykonanie 4.09 GFLOPS obliczeń. 

Podczas testów zauważyłem, że pierwszy wynik dość mocno odbiega od pozostałych. Dodałem więc kod, który najpierw uruchamia sieć na losowych danych. W przypadku danych np. z kamery i tak przetwarzanych jest wiele obrazów przez tę samą sieć, więc nawet jeśli pierwsza klatka będzie miała inny czas obliczeń, nie powinno to być problemem. Mam więc następujący kod testowy:

from torchvision.models import resnet50, ResNet50_Weights
import time
import torch

weights = ResNet50_Weights.IMAGENET1K_V1
model = resnet50(weights=weights)
model.eval()

dummy_input = torch.randn(1,3,244,244)
output = model(dummy_input)

preprocess = weights.transforms()
input = preprocess(img).unsqueeze(0)

t1 = time.time()
output = model(input)
t2 = time.time()
print("Result: {:.2f} ms\n".format((t2-t1)*1000))

results = output.squeeze(0).softmax(0)
for i in results.topk(3).indices:
    id = i.item()
    cat = weights.meta["categories"][id]
    rate = results[id].item()
    print("{}: {:.2f}%".format(cat, 100*rate))

Po uruchomieniu za pomocą Colaba uzyskuję wynik:

Czyli niecałe 300ms. Wychodzi więc jakieś 3 klatki na sekundę, to raczej za mało żeby przetwarzać obraz z kamery w czasie rzeczywistym.

Domyślnie Colab uruchomił wszystkie obliczenia na CPU, można nawet sprawdzić na jakim. Polecenia zaczynające się od ! zostają wykonane jak typowe komendy w terminalu - więc można odczytać zawartość pliku /proc/cpuinfo i zobaczyć z jakiej maszyny korzystamy:

Na szczęście nie jesteśmy skazani na CPU i nawet w darmowej wersji Colab-a istnieje możliwość użycia GPU. Darmowa wersja jest ograniczona do układów Nvidia Tesla-T4 (https://www.nvidia.com/en-us/data-center/tesla-t4/). Jeśli będziemy chcieli w przyszłości skorzystać z wydajniejszych układów (V100/A100), możemy skorzystać z płatnego abonamentu.

Aby zmienić typ urządzenia wybieramy z menu Runtime opcję Change runtime type:

Teraz możemy wybrać odpowiedni akcelerator: 

I uruchamiamy ponownie nasz test:

Jest trochę lepiej bo niecałe 170 ms, czyli prawie 6 klatek na sekundę. Chyba liczyliśmy na więcej...

Okazuje się, że samo podłączenie GPU to nie wszystko, musimy go jeszcze wykorzystać w programie. Na początek zdefiniujemy zmienną wskazującą na urządzenie, z którego będziemy chcieli skorzystać:

device = torch.device('cuda')

 

CUDA to biblioteka o której więcej znajdziemy na Wikipedii: https://pl.wikipedia.org/wiki/CUDA Jak łatwo się domyślić ta sama biblioteka jest dostępna dla płytki Jetson, ale nie wyprzedzajmy faktów...

Na razie dokonamy zmian w programie wywołując metodę o nazwie .to() możemy przenieść model sieci oraz dane obrazu na GPU. Przykładowo linijkę:

model = resnet50(weights=weights)

Wystarczy zamienić na:

model = resnet50(weights=weights).to(device)

I już nasza sieć będzie działała w pamięci GPU. Dane obrazu przeniesiemy podobnie, po prostu wywołamy .to() dla zmiennych input i dummy_input.

Nowy program wygląda następująco:

from torchvision.models import resnet50, ResNet50_Weights
import time
import torch

device = torch.device('cuda')

weights = ResNet50_Weights.IMAGENET1K_V1
model = resnet50(weights=weights).to(device)
model.eval()

dummy_input = torch.randn(1,3,244,244).to(device)
output = model(dummy_input)

preprocess = weights.transforms()
input = preprocess(img).unsqueeze(0).to(device)

t1 = time.time()
output = model(input)
t2 = time.time()
print("Result: {:.2f} ms\n".format((t2-t1)*1000))

results = output.squeeze(0).softmax(0)
for i in results.topk(3).indices:
    id = i.item()
    cat = weights.meta["categories"][id]
    rate = results[id].item()
    print("{}: {:.2f}%".format(cat, 100*rate))

Czas przetestować nowy program:

Za pomocą GPU nasza sieć uzyskuje wynik w raptem 7.39 ms! Teoretycznie bylibyśmy więc w stanie przetworzyć 135 klatek na sekundę.

Opisana metoda optymalizacji jest bardzo daleka od ideału ale mamy już pewien punkt odniesienia dla dalszych testów. Teraz możemy sprawdzić jak z tym zadaniem poradzą sobie inne urządzenia - i oczywiście NVIDIA Jetson Orin NX. 

 

 

[Elvis]

Mój skrypt połączenie kodu testowanego wcześnie w Colab-ie w jedną całość. Na wszelki wypadek jego treść jest poniżej:

import requests
from PIL import Image
import io

def load_image(url):
    res = requests.get(url).content
    return Image.open(io.BytesIO(res))

#img = load_image("https://forbot.pl/blog/wp-content/uploads/2021/07/FORBOT_kurs_STM32L4_IR_NEC_liczniki.jpg")
#img = load_image("https://cdn.forbot.pl/blog/wp-content/uploads/2021/04/FORBOT_kurs_STM32L4_watchdog.jpg")
img = load_image("https://cdn.forbot.pl/blog/wp-content/uploads/2021/05/FORBOT_kurs_STM32L4_przerwania_procedury.jpg")

from torchvision.models import resnet50, ResNet50_Weights
import time
import torch

device = torch.device('cuda')

weights = ResNet50_Weights.IMAGENET1K_V1
model = resnet50(weights=weights).to(device)
model.eval()

dummy_input = torch.randn(1,3,244,244).to(device)
output = model(dummy_input)

preprocess = weights.transforms()
input = preprocess(img).unsqueeze(0).to(device)

t1 = time.time()
output = model(input)
t2 = time.time()
print("Result: {:.2f} ms\n".format((t2-t1)*1000))

results = output.squeeze(0).softmax(0)
for i in results.topk(3).indices:
    id = i.item()
    cat = weights.meta["categories"][id]
    rate = results[id].item()
    print("{}: {:.2f}%".format(cat, 100*rate))

Najpierw sprawdzę jak działa na komputerze stacjonarnym (z kartą RTX 3060 Ti):

Result: 23.47 ms

pizza: 99.74%
meat loaf: 0.04%
French loaf: 0.03%

Udowodniłem sobie, że mam gorszą kartę graficzną niż Google oferuje za darmo - mówi się trudno, ważne że działa.

Jako kolejny etap sprawdzę na laptopie, na którym piszę niniejszy wpis. Niestety próba uruchomienia kończy się niepowodzeniem. Nie mam karty firmy Nvidia, więc CUDA nie jest dostępna. Na szczęście mogę zmienić typ urządzenia na 'mps', czyli:

 device = torch.device('mps')

Teraz skrypt działa i daje wynik:

Result: 112.72 ms

pizza: 99.74%
meat loaf: 0.04%
French loaf: 0.03%

Szału nie ma, jak widać GPU w MacBookPro jest jednak mniej wydajny niż RTX3060.

Zobaczmy jednak jak poradzą sobie układy, które moglibyśmy wykorzystać we własnych projektach - np. robotycznego psa, micro-mouse, czy drona. Pewnie pierwszym wyborem będzie Raspberry Pi 4. 

Jak łatwo się domyślić malinka nie ma akceleratora Nvidii, więc nie można użyć biblioteki CUDA, przetestujmy więc obliczenia na CPU. Niestety okazało się, że problemem jest również funkcja preprocess() - ale do testów wydajności wybrany obraz nie powinien mieć znaczenia, użyję więc podobnie jak dla dummy_image losowych danych. Wynik:

Result: 2126.55 ms

chain mail: 24.60%
window screen: 21.79%
binder: 2.25%

Przyznaję że mój test jest bardzo niedoskonały. Dla Resnet50 można na Rpi4 uzyskać ok 4 FPS, czyli 250ms (https://pytorch.org/tutorials/intermediate/realtime_rpi.html). Ale na razie nie chciałbym optymalizować kodu i dokończyć wstępne testy.

Na koniec to co najważniejsze, czyli test na Jetson Orin NX. Wracam do używania GPU i uruchamiam test:

Result: 146.31 ms

pizza: 99.74%
meat loaf: 0.04%
French loaf: 0.03%

Przyznam, że trochę mnie ten wynik rozczarował, bo wcześniej wykonywałem wielokrotną inferencję jednego obrazu i uzyskiwałem czasy obliczeń rzędu 20-25ms. Ale wynik wyszedł jaki wyszedł - jest na poziomie MacBookPro z procesorem M1Pro, słabiej od RTX3060, ale o wiele lepiej od Raspberry Pi 4.

Jak zwykle napisałem o wiele dłuższy tekst niż planowałem, a miał to być dopiero wstęp do dalszej optymalizacji. Chciałem pokazać, że nawet bardzo nieoptymalny kod może być uruchomiony na Jetson Orin NX i nie tylko działa, ale działa z całkiem przyzwoitą prędkością.

Warto zwrócić uwagę na pobieraną moc - Jetson ma limit 25W, to o wiele mniej niż 200W dla RTX3060Ti.  W dalszej części będę próbował nieco poprawić wynik uzyskany dla inferencji Resnet50. Mam nadzieję, że uda mi się zejść znacznie poniżej początkowych 150ms.

[Harnas]

Chciałbym wrzucić swoje 5 groszy.

Dnia 2.07.2023 o 19:21, Elvis napisał:

Warto zauważyć, że model używa 25557032 parametrów (ponad 25 milionów liczb float32), a podczas obliczeń wykonywanych jest ponad 4 miliardy operacji zmiennopozycyjnych (4.09 GFLOPS). Wielkość pliku to 97.8 MB, więc raczej nie mamy co liczyć, że użyjemy Resnet50 na mikrokontrolerze.

Przy samej inferencji można zejść z precyzją do float16 albo nawet float8 https://github.com/ray-project/llm-numbers#2x-number-of-parameters-typical-gpu-memory-requirements-of-an-llm-for-serving . Co dawałoby rozmiar modelu odpowiednio 50MB i 25MB. Jest to też o tyle ważne, że rośnie wtedy szybkość przetwarzania https://resources.nvidia.com/en-us-tensor-core/nvidia-tensor-core-gpu-datasheet strona 2.

 

Dnia 2.07.2023 o 21:51, Elvis napisał:

Za pomocą GPU nasza sieć uzyskuje wynik w raptem 7.39 ms! Teoretycznie bylibyśmy więc w stanie przetworzyć 135 klatek na sekundę.

Można powiedzieć że "to zależy". Tak jest gdy rozmiar batcha podczas inferencji jest równy 1, czyli gdy mamy typowo przetwarzanie obrazu w czasie rzeczywistym (nie interesuje nas co kamera widziała 1 klatkę temu tylko to co widzimy obecnie).

Natomiast dałoby się teoretycznie zwiększyć ilość przetwarzanych zdjęć zbierając je w większe batche. Tylko to ma zastosowanie w aplikacjach typu: mam 1000 zdjęć, wygeneruj dla każdego tagi. Nieco na ten temat w kolejnym punkcie https://github.com/ray-project/llm-numbers#10x-throughput-improvement-from-batching-llm-requests