Wsadowe ocenianie modeli uczenia głębokiego

Logic Apps
Usługa Machine Learning
Kontrola dostępu na podstawie ról na platformie Azure
Storage

Ta architektura referencyjna pokazuje, jak zastosować transfer stylów neuronowych do wideo przy użyciu Azure Machine Learning. Transfer stylów to technika uczenia głębokiego, która tworzy istniejący obraz w stylu innego obrazu. Ta architektura może być uogólniona dla każdego scenariusza, który używa oceny wsadowej z uczeniem głębokiej. Wdróż to rozwiązanie.

Diagram architektury dla modeli uczenia głębokiego przy użyciu Azure Machine Learning

Scenariusz: organizacja multimedialna ma film wideo, którego styl chce zmienić, aby wyglądał jak określony malowanie. Organizacja chce mieć możliwość zastosowania tego stylu do wszystkich klatek wideo w odpowiednim czasie i w zautomatyzowany sposób. Aby uzyskać więcej informacji na temat algorytmów transferu stylów neuronowych, zobacz transfer stylów obrazu przy użyciu Splotowych neuronowych Networks (PDF).

Obraz stylu: Film wideo dotyczący danych wejściowych/zawartości: Wideo wyjściowe:
Picture of a painting in particular art style. Picture of an animal in a tree in realistic style.kliknij, aby wyświetlić wideo Picture of an animal in a tree, stylized to match a painting.kliknij, aby wyświetlić wideo

Ta architektura referencyjna jest przeznaczona dla obciążeń wyzwalanych przez obecność nowych nośników w usłudze Azure Storage.

Przetwarzanie obejmuje następujące kroki:

  1. Przekaż plik wideo do magazynu.
  2. Plik wideo wyzwala aplikację logiki w celu wysłania żądania do punktu końcowego opublikowanego Azure Machine Learning potoku.
  3. Potok przetwarza wideo, stosuje transfer stylów z MPI i postprocesses wideo.
  4. Dane wyjściowe są zapisywane z powrotem do magazynu obiektów BLOB po zakończeniu potoku.

Architektura

Niniejsza architektura zawiera następujące składniki.

Compute

Azure Machine Learning używa potoków do tworzenia powtarzalnych i łatwych w zarządzaniu sekwencji obliczeń. Oferuje również zarządzany obiekt docelowy obliczeń (na którym można uruchomić przetwarzanie potoku), nazywany Azure Machine Learning obliczeń na potrzeby szkoleń, wdrażania i oceniania modeli uczenia maszynowego.

Magazyn

Magazyn obiektów BLOB jest używany do przechowywania wszystkich obrazów (obrazów wejściowych, obrazów stylów i obrazów wyjściowych). Azure Machine Learning integruje się z usługą BLOB Storage, dzięki czemu użytkownicy nie muszą ręcznie przenosić danych między platformami obliczeniowymi i magazynem obiektów BLOB. Magazyn obiektów BLOB jest również bardzo opłacalny dla wydajności wymaganej przez to obciążenie.

Wyzwalacz/planowanie

Azure Logic Apps jest używany do wyzwalania przepływu pracy. Gdy aplikacja logiki wykryje, że obiekt BLOB został dodany do kontenera, wyzwala potok Azure Machine Learning. Logic Apps to dobra architektura referencyjna, ponieważ jest to prosty sposób wykrywania zmian w magazynie obiektów blob i zapewnia łatwy proces zmieniania wyzwalacza.

Przetwarzanie wstępne i dostosujesz naszych danych

Ta architektura referencyjna używa materiału wideo orangutan w drzewie. Film można pobrać z tego miejsca.

  1. Użyj Narzędzia FFmpeg , aby wyodrębnić plik audio z filmu wideo, dzięki czemu plik audio można umieścić z powrotem w wyjściowym wideo w późniejszym czasie.
  2. Użyj narzędzia FFmpeg, aby przerwać wideo w poszczególnych ramkach. Ramki będą przetwarzane niezależnie, równolegle.
  3. W tym momencie można równolegle zastosować transfer stylów neuronowych do każdej pojedynczej klatki.
  4. Jedna klatka została przetworzona, dlatego musimy używać narzędzia FFmpeg, aby ponownie połączyć ramki ze sobą.
  5. Na koniec dołączymy plik audio do dołączonego materiału.

Zagadnienia dotyczące wydajności

Procesor GPU a procesor CPU

W przypadku obciążeń głębokiego uczenia procesora GPU ogólnie przeprowadzimy procesor CPU przez znaczną ilość czasu, w jakim pokaźną klaster procesorów CPU jest zwykle wymagany do uzyskania porównywalnej wydajności. Chociaż jest to opcja użycia tylko procesorów CPU w tej architekturze, procesory GPU zapewniają znacznie lepszy profil kosztów/wydajności. Zalecamy używanie najnowszych maszyn wirtualnych o rozmiarze [seria NCV3 Series] — procesorze GPU zoptymalizowanych pod kątem procesora GPU.

Procesory GPU nie są domyślnie włączone we wszystkich regionach. Upewnij się, że wybrano region z włączonymi procesorami GPU. Ponadto subskrypcje mają domyślny przydział równy zero rdzeni dla maszyn wirtualnych zoptymalizowanych pod kątem procesora GPU. Ten limit przydziału można podnieść, otwierając żądanie pomocy technicznej. Upewnij się, że Twoja subskrypcja ma wystarczający limit przydziału, aby uruchomić obciążenie.

Przekształcają między maszynami wirtualnymi a rdzeniami

Podczas uruchamiania procesu transferu w stylu jako zadanie wsadowe zadania, które są uruchamiane głównie na procesorach GPU, muszą być równoległe dla maszyn wirtualnych. Możliwe są dwa podejścia: można utworzyć większy klaster przy użyciu maszyn wirtualnych z pojedynczym procesorem GPU lub utworzyć mniejszy klaster przy użyciu maszyn wirtualnych z wieloma procesorami GPU.

W przypadku tego obciążenia te dwie opcje będą mieć porównywalną wydajność. Użycie mniej maszyn wirtualnych z większą liczbą procesorów GPU na maszynę wirtualną może pomóc w zmniejszeniu przenoszenia danych. Jednak ilość danych na zadanie dla tego obciążenia nie jest bardzo duża, dlatego nie będzie można obsłużyć wielu ograniczeń w przypadku usługi BLOB Storage.

MPI — krok

Podczas tworzenia potoku Azure Machine Learningjednym z kroków służących do wykonywania obliczeń równoległych jest MPI. Krok MPI pomoże równomiernie podzielić dane między dostępnymi węzłami. Krok MPI nie zostanie wykonany, dopóki wszystkie żądane węzły nie będą gotowe. Jeśli jeden węzeł ulegnie awarii lub zostanie przeniesiona (jeśli jest to maszyna wirtualna o niskim priorytecie), należy ponownie uruchomić krok MPI.

Zagadnienia dotyczące bezpieczeństwa

Ograniczanie dostępu do usługi Azure Blob Storage

W tej architekturze referencyjnej magazyn obiektów blob platformy Azure jest głównym składnikiem magazynu, który musi być chroniony. Wdrożenie linii bazowej widoczne w repozytorium GitHub używa kluczy konta magazynu do uzyskiwania dostępu do magazynu obiektów BLOB. W celu przeprowadzenia dalszej kontroli i ochrony należy rozważyć użycie sygnatury dostępu współdzielonego (SAS). To przyznaje ograniczony dostęp do obiektów w magazynie, bez konieczności wprowadzania twardych kodów kluczy konta lub zapisywania ich w postaci zwykłego tekstu. To podejście jest szczególnie przydatne, ponieważ klucze kont są widoczne w postaci zwykłego tekstu w interfejsie projektanta aplikacji logiki. Za pomocą sygnatury dostępu współdzielonego można również upewnić się, że konto magazynu ma odpowiednie zarządzanie i że dostęp jest udzielany tylko osobom, które zapewnią tę możliwość.

W przypadku scenariuszy z bardziej poufnymi danymi upewnij się, że wszystkie klucze magazynu są chronione, ponieważ te klucze zapewniają pełny dostęp do wszystkich danych wejściowych i wyjściowych z obciążenia.

Szyfrowanie i przenoszenie danych

Ta architektura referencyjna używa transferu stylu jako przykładowego procesu oceniania partii. W przypadku większej liczby scenariuszy z danymi dane przechowywane w magazynie powinny być szyfrowane w stanie spoczynku. Za każdym razem, gdy dane są przenoszone z jednej lokalizacji do następnej, należy użyć protokołu SSL w celu zabezpieczenia transferu danych. Aby uzyskać więcej informacji, zobacz Przewodnik po zabezpieczeniach usługi Azure Storage.

Zabezpieczanie obliczeń w sieci wirtualnej

Podczas wdrażania klastra obliczeniowego Machine Learning można skonfigurować klaster do obsługi administracyjnej w podsieci sieci wirtualnej. Dzięki temu węzły obliczeniowe w klastrze mogą bezpiecznie komunikować się z innymi maszynami wirtualnymi.

Ochrona przed złośliwymi działaniami

W scenariuszach, w których istnieje wielu użytkowników, należy się upewnić, że poufne dane są chronione przed złośliwymi działaniami. Jeśli inni użytkownicy uzyskują dostęp do tego wdrożenia w celu dostosowania danych wejściowych, należy wziąć pod uwagę następujące środki ostrożności i zagadnienia:

  • Użyj usługi Azure RBAC, aby ograniczyć dostęp użytkowników tylko do zasobów, których potrzebują.
  • Zainicjuj obsługę dwóch oddzielnych kont magazynu. Przechowuj dane wejściowe i wyjściowe na pierwszym koncie. Użytkownikom zewnętrznym można udzielić dostępu do tego konta. Przechowuj skrypty wykonywalne i pliki dziennika wyjściowego na drugim koncie. Użytkownicy zewnętrzni nie powinni mieć dostępu do tego konta. Zapewni to, że użytkownicy zewnętrzni nie będą mogli modyfikować plików wykonywalnych (w celu dodania złośliwego kodu) i nie mają dostępu do plików dziennika, które mogą zawierać poufne informacje.
  • Złośliwi użytkownicy mogą DDoS kolejkę zadań lub wprowadzać wadliwe skażone komunikaty w kolejce zadań, co sprawia, że system jest blokowany lub powodował błędy usuwania z usługi.

Monitorowanie i rejestrowanie

Monitorowanie zadań wsadowych

Podczas wykonywania zadania ważne jest monitorowanie postępu i upewnienie się, że elementy działają zgodnie z oczekiwaniami. Może jednak być wyzwaniem do monitorowania w klastrze aktywnych węzłów.

Aby sprawdzić stan ogólny klastra, przejdź do bloku Machine Learning Azure Portal, aby sprawdzić stan węzłów w klastrze. Jeśli węzeł jest nieaktywny lub zadanie zakończyło się niepowodzeniem, dzienniki błędów są zapisywane w usłudze BLOB Storage i są również dostępne w Azure Portal.

Monitorowanie może być bardziej wzbogacone przez połączenie dzienników do Application Insights lub przez uruchomienie oddzielnych procesów w celu sondowania stanu klastra i jego zadań.

Rejestrowanie przy użyciu Azure Machine Learning

Azure Machine Learning automatycznie będzie rejestrować wszystkie strumienia stdout/stderr na skojarzonym koncie magazynu obiektów BLOB. O ile nie określono inaczej, obszar roboczy Azure Machine Learning automatycznie udostępni konto magazynu i spowoduje zrzut do niego dzienników. Można również użyć narzędzia do nawigacji magazynu, takiego jak Eksplorator usługi Storage, które ułatwią przechodzenie do plików dziennika.

Kwestie związane z kosztami

W porównaniu ze składnikami magazynu i planowania zasoby obliczeniowe używane w tej architekturze referencyjnej są znacznie przeważające pod względem kosztów. Jednym z głównych wyzwań jest efektywne przekształcają pracy w klastrze maszyn z obsługą procesora GPU.

Rozmiar klastra obliczeniowego Azure Machine Learning można automatycznie skalować w górę i w dół w zależności od zadań w kolejce. Automatyczne skalowanie można włączyć programowo, ustawiając minimalną i maksymalną liczbę węzłów.

W przypadku pracy, która nie wymaga natychmiastowego przetwarzania, skonfiguruj automatyczne skalowanie, tak aby stan domyślny (minimalny) był klastrem z zerowymi węzłami. W przypadku tej konfiguracji klaster rozpoczyna się od zerowych węzłów i skaluje się w górę tylko wtedy, gdy wykryje zadania w kolejce. Jeśli proces oceniania partii odbywa się tylko kilka razy dziennie lub mniej, to ustawienie umożliwia znaczne oszczędności kosztów.

Skalowanie automatyczne może nie być odpowiednie dla zadań wsadowych, które są zbyt blisko siebie. Czas, jaki zajmuje klaster, i zmniejszy się także koszt, więc jeśli obciążenie usługi Batch rozpocznie się dopiero po kilku minutach od momentu zakończenia poprzedniego zadania, może być bardziej opłacalne, aby utrzymywać klaster między zadaniami.

Azure Machine Learning COMPUTE obsługuje również maszyny wirtualne o niskim priorytecie. Dzięki temu można uruchamiać obliczenia na maszynach wirtualnych z rabatami, z zastrzeżeniem, że mogą zostać zastąpione w dowolnym momencie. Maszyny wirtualne o niskim priorytecie są idealne dla niekrytycznych obciążeń oceniania partii.

Wdrażanie rozwiązania

Aby wdrożyć tę architekturę referencyjną, wykonaj kroki opisane w repozytorium GitHub.

Uwaga

Możesz również wdrożyć architekturę oceniania partii dla modeli uczenia głębokiego za pomocą usługi Azure Kubernetes. Wykonaj kroki opisane w tym repozytorium GitHub.