Jakie kroki są wymagane, aby przeprowadzić migrację algorytmów Assembly Vision do Ascend NPU?

Artykuł techniczny

Migracja algorytmu wizji złożenia do Ascend NPU nie oznacza kopiowania oryginalnych plików modelu na urządzenie Atlas, ale zakończenie dostosowywania systemu do formatu modelu, operatorów, danych wejściowych i wyjściowych, interfejsu wykonawczego i kryteriów akceptacji. Typowy sposób to: skorygowanie oryginalnej linii bazowej modelu, wyeksportowanie ONNX, sprawdzenie struktury wykresu i operatorów, użycie ATC do wygenerowania modelu OM dla docelowego procesora Ascend, uzyskanie dostępu do wnioskowania poprzez AscendCL, a następnie zakończenie weryfikacji spójności przed i po przetworzeniu, wyników wykrywania, wydajności działania i wdrożenia wersji.

Oprogramowanie Winge Technology do kontroli wizualnej i aplikacje algorytmiczne dla zespołów działają już na Huawei Ascend Atlas 200I DK A2. W przypadku projektów wykorzystujących modele klasyfikacji, wykrywania obiektów lub segmentacji można dodać łącza wnioskowania modelu Ascend NPU w oparciu o dostęp do istniejącej kamery, konfigurację ROI, rejestrację wyników i wdrożenie lokalne.

Które wpisy należy poprawić przed migracją?

Przed rozpoczęciem migracji należy przygotować powtarzalny pakiet podstawowy, który będzie zawierał co najmniej następujące elementy:

Autorski framework szkoleniowy, struktura modelu, wagi i skrypty eksportowe;
Nazwa wejściowa, rozmiar wejściowy, typ danych i wymagania dotyczące wymiarów dynamicznych dla modeli ONNX;
Metody porządkowania, skalowania, kadrowania, normalizowania i tensorowania kolorów obrazu;
Etykiety klasyfikacyjne, dekodowanie ramki rozpoznawania, progi ufności, NMS lub reguły przetwarzania post-segmentacyjnego;
Ustalony zestaw próbek OK, NG i granicznych oraz ich oczekiwane wyniki;
Docelowe urządzenie Atlas, model procesora Ascend, system operacyjny, CANN i wersja pakietu operatora;
Wskaźniki akceptacji projektu, takie jak dokładność, fałszywe alarmy, fałszywe alarmy, unikalne zużycie czasu, przepustowość i przechowywanie.

Jeśli te dane wejściowe nie zostaną uwzględnione, nawet jeśli konwersja modelu zakończy się pomyślnie, nie można określić, czy różnica przed i po migracji wynika z modelu, przetwarzania wstępnego, przetwarzania końcowego lub środowiska wersjonowania.

Krok 1: Utwórz linię bazową oryginalnych wyników modelu

Użyj tego samego zestawu obrazów akceptacyjnych, aby uruchomić oryginalny model i zapisać tensory wejściowe, oryginalne dane wyjściowe, wyniki przetwarzania końcowego i ostateczne decyzje biznesowe. Projekt wykrywania obiektów powinien także zapisać ramkę detekcji, kategorię, pewność i wyniki NMS; Projekt segmentacji powinien przechowywać rozmiar maski, mapowanie kategorii i wyniki konturu.

Rolą linii bazowej nie jest zapewnienie jednolitego współczynnika dokładności, ale raczej zapewnienie przykładowej podstawy do porównania kolejnych wyników ONNX i OM. Wskaźniki projektu należy określić na podstawie próbek klientów, definicji wad i warunków w miejscu pracy.

Krok 2: Wyeksportuj i zweryfikuj model ONNX

Po wyeksportowaniu ONNX ze struktury szkoleniowej należy sprawdzić, co następuje:

Czy nazwy węzłów wejściowych i wyjściowych są stabilne?
Czy rozmiar wejściowy jest rozmiarem stałym, czy dynamicznym;
Czy wersja operatora i struktura wykresu odpowiadają docelowemu środowisku konwersji;
Czy uwzględnić węzły, które są używane tylko w fazie uczenia;
Czy wyniki serii ONNX i wyniki oryginalnego modelu mieszczą się w ustalonym zakresie błędów.

W tym kroku należy najpierw rozwiązać problem eksportu samego modelu, a następnie wykonać konwersję po stronie Ascend, aby uniknąć przeniesienia różnic w modelu źródłowym na stronę urządzenia.

Krok 3: Sprawdź zgodność operatora i strukturę wykresu

Przed konwersją ATC należy sprawdzić operatory, atrybuty, typy danych i ograniczenia kształtu stosowane w modelu. Jeśli istnieją nieobsługiwane operatory lub kombinacje, możesz wybrać pomiędzy przepisaniem wykresu, zastąpieniem równoważnego operatora, podziałem i przetwarzaniem końcowym lub operatorami niestandardowymi opartymi na strukturze modelu. Jako kryterium zakończenia dostosowywania nie powinieneś używać wyłącznie komunikatu „zakończono wykonanie polecenia konwersji”.

W przypadku stosów dynamicznych, dynamicznego rozmiaru obrazu lub wymiarów dynamicznych odpowiednie przekładnie należy skonfigurować zgodnie z rzeczywistymi danymi wejściowymi stacji roboczej. Stanowiska montażowe ze stałymi kamerami i stałymi wymiarami przechwytywania mogą zazwyczaj początkowo wykorzystywać stałe kształty, aby ograniczyć rozgałęzienia w czasie wykonywania i ułatwić akceptację.

Krok 4: Użyj ATC do wygenerowania modelu OM

Oficjalna dokumentacja Ascend firmy Huawei stwierdza, że ATC służy do konwertowania modeli frameworku open source, takich jak ONNX, do modeli offline OM, które mogą być rozpoznawane przez procesor Ascend AI. Typowa struktura poleceń jest następująca:

„Bash

atc --model=model.onnx

--framework=5

--output=atlas_modelu

--input_shape="obrazy:1,3,wys.,szer"

--soc_version=<docelowy model procesora Ascend>

Rzeczywiste parametry muszą odpowiadać wejściu modelu, docelowemu procesorowi i środowisku projektu. Podczas konwersji należy zapisać polecenie ATC SHA-256, wersję środowiska, dziennik konwersji, raport z inspekcji i wygenerowany plik, aby śledzić i odtworzyć proces tworzenia modelu OM.

Krok 5: Połącz się z łączem wnioskowania AscendCL

Po wygenerowaniu modelu OM aplikacja po stronie urządzenia musi zakończyć inicjalizację zasobów, wybrać urządzenie, załadować model, zarządzać pamięcią wejściową i wyjściową, wykonać model, odczytać wyniki i zwolnić zasoby. Pełna ścieżka danych dla systemu wizyjnego montażu to zazwyczaj:

Kamera przemysłowa lub pliki obrazów

-> Dekodowanie, kadrowanie i sprawdzanie jakości obrazu

-> Zmiana rozmiaru, konwersja kolorów, normalizacja i układ tensorów

-> Rozumowanie modelu OM

-> Dekodowanie klasyfikacji, struktury wykrywania lub wyniku segmentacji

-> ROI z regułami biznesowymi montażu

-> ZALICZONY / FAIL / NIEZNANY

-> Wykres dowodów, dziennik wyników i interfejs stacji roboczej

Interfejs wnioskowania jest odpowiedzialny jedynie za obliczenia modelu, a ostateczne określenie stacji roboczej obejmuje również deduplikację wyzwalaczy, jakość obrazu, sprawdzanie wyników, nieprawidłowy stan, interfejs PLC lub we/wy oraz śledzenie danych.

Krok 6: Sprawdź spójność przetwarzania wstępnego i końcowego

Wspólne różnice w projektach migracyjnych niekoniecznie wynikają z samego modelu. Kolejność kolorów, metoda interpolacji, współczynnik normalizacji, metoda kwantyzacji, układ tensora, skalowanie współrzędnych i parametry NMS mogą zmieniać wynik.

Zaleca się porównanie na następujących poziomach:

- Warstwa wejściowa: Porównaj dane wejściowe tensorów z modelem oryginalnym i modelem OM. - Warstwa wyjściowa: Porównaj kształt, zakres wartości i kolejność węzłów oryginalnego wyniku modelu. - Poziom algorytmu: porównaj kategorie, pola detekcji, maski i pewność; - Warstwa biznesowa: Porównaj wyniki PASS, FAIL lub UNKNOWN dla każdej próbki. - Poziom dowodu: Porównaj lokalizacje defektów, mapy adnotacji i zapisy wyników, aby określić, czy odpowiadają one temu samemu przedmiotowi obrabianemu.

Tylko poprzez wskazanie różnic warstwa po warstwie możemy ocenić, czy należy dostosować konwersję modelu, przetwarzanie danych lub reguły biznesowe.

Krok 7: Przeprowadź kontrolę wydajności i stabilności urządzenia

Testy wydajności należy przeprowadzić na urządzeniach docelowych Atlas, formalnych rozmiarach obrazu i rzeczywistych połączeniach przetwarzających, rozróżniając:

- czas przechwytywania lub dekodowania obrazu; - czas wstępnego przetwarzania; - Czas wnioskowania dla pojedynczego modelu; - Czas na postprocessing i reguły biznesowe; - Czas na zapisanie obrazów dowodowych i plików wyników; - Kompleksowy czas reakcji stacji roboczej.

Wyniki testu powinny również rejestrować wersję modelu, skrót pliku OM, wersję CANN, model procesora, rozmiar danych wejściowych, partię, tryb precyzji, liczbę rozgrzewek i liczbę próbek. Dokładność, czas cyklu produkcyjnego i długoterminową stabilność potwierdzają niezależne kontrole konkretnych projektów i ciągłych warunków pracy.

Krok 8: Utwórz dostawę w wersji rolowanej

Oficjalna przesyłka powinna zawierać co najmniej:

- Oryginalny model lub pliki źródłowe modelu w uzgodnionym zakresie; - ONNX model i instrukcje eksportu; - model OM, polecenie ATC, protokół konwersji i wartość kontrolna; - Przetwarzanie wstępne, wnioskowanie, przetwarzanie końcowe i kod interfejsu biznesowego; - System operacyjny, CANN, pakiet operatora i lista wersji zależnych; - Wyniki weryfikacji próbek, zapisy różnic i raporty z testów wydajności; - Instrukcje dotyczące konfiguracji, uruchamiania usług, rejestrowania, aktualizacji, tworzenia kopii zapasowych i przywracania zmian.

Winge Technology może wykonywać prace związane z migracją modelu wraz z kamerami, optyką, ROI,

Jakie kwestie najprawdopodobniej wpłyną na wyniki migracji?

| Pytanie | Typowe objawy | Kierunek przetwarzania | |---|---|---| | Definicje wejściowe są niespójne | Ogólna zmiana wyników lub nieprawidłowy poziom ufności | Poprawiono kolor, rozmiar, normalizację i układ tensora | | Operator lub formularz nie jest kompatybilny | Konwersja ATC nie powiedzie się lub zmieni się struktura wyjściowa | Przepisywanie wykresów, wymiana operatorów, przekładni dynamicznych lub niestandardowych operatorów | | Niespójne przetwarzanie końcowe | Liczba, lokalizacja lub kategoria ramek rozpoznawania są różne | Ujednolicone dekodowanie, progowanie, NMS i odzyskiwanie współrzędnych | | Kombinacja wersji nie jest ustalona | Ten sam model zachowuje się inaczej w różnych środowiskach | System stały, CANN, pakiet operatora i rekord budowy OM | | Samo testowanie modelu wymaga czasu | Beat na żywo nadal nie spełnia wymagań | Pełne powiązanie od wykonania pomiaru do wyniku | | Brak niezależnego zbioru walidacyjnego | Nie ma możliwości określenia, czy migracja podtrzyma rezultaty biznesowe | Użyj próbek OK, NG i limitów, które nie są zaangażowane w optymalizację parametrów |

Często zadawane pytania

### Czy modele ONNX mogą działać bezpośrednio na Ascend NPU?

Zwykle konieczne jest użycie ATC do konwersji modelu ONNX na model offline OM w oparciu o docelowy procesor Ascend i środowisko CANN, a następnie załadowanie go i wykonanie za pośrednictwem interfejsów po stronie urządzenia, takich jak AscendCL.

### Czy konwersja w celu wygenerowania plików OM oznacza, że migracja została zakończona?

Nie od razu. Konieczne jest także dokowanie danych wejściowych i wyjściowych, spójność przed i po przetwarzaniu, losowe porównanie wyników, testowanie wydajności po stronie urządzenia, obsługa wyjątków i weryfikacja dostarczenia wersji.

### Czy wszystkie tradycyjne zasady widzenia muszą zostać przekonwertowane na sieci neuronowe?

Nie ma potrzeby. Nadal można zachować zasady ROI ze stałymi pozycjami i wyraźnymi granicami; Modele klasyfikacji, wykrywania obiektów i segmentacji służą do obsługi zmian kategorii, złożonych środowisk i zadań rozpoznawania semantycznego. Obydwa modele można połączyć w tej samej aplikacji Atlas.

### Czy ten sam model OM może być używany bezpośrednio we wszystkich urządzeniach Atlas?

Parametry konwersji modelu OM odnoszą się do docelowego procesora Ascend i środowiska oprogramowania. Podczas realizacji projektu należy potwierdzić model procesora, CANN i wersję pakietu operatora zgodnie z urządzeniem docelowym oraz prowadzić odpowiednią dokumentację budowy.

### Jak ocenić, czy wyniki przed i po migracji są spójne?

Do porównania tensora wejściowego, oryginalnych danych wyjściowych modelu, wyników algorytmu i ostatecznej oceny biznesowej warstwa po warstwie należy zastosować próbkowanie stałe. Akceptacja powinna opierać się na potwierdzonych przez obie strony błędach, dokładności i zasadach stanowiska pracy. Nie można po prostu porównać małej liczby obrazów demonstracyjnych.

źródła oficjalne

- Huawei Ascend: model ONNX przełączony na model OM https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html - Huawei Ascend: parametry wiersza poleceń ATC i ograniczenia operatora https://www.hiascend.com/document/detail/pl/canncommercial/850/devaids/atctool/atlasatc_16_0039.html - Huawei Ascend: budowa modelu AscendCL i rozwój aplikacji https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL i nazwy pokrewne należą do ich właścicieli praw autorskich. W tym artykule wyjaśniono metody dostosowywania projektów Assembly Vision dostarczonych przez Winge Technology. Nie oznacza to, że odpowiedni posiadacze praw uczestniczą w konkretnym projekcie lub go wspierają. Możliwości sprzętu i narzędzi podlegają odpowiednim oficjalnym dokumentom wydania, a wyniki projektu podlegają rzeczywistym modelom, próbkom, wyposażeniu i warunkom akceptacji.