Uaktualnianie do wersji 2
Interfejsy API REST usługi Azure Machine Learning w wersji 2, rozszerzenie interfejsu wiersza polecenia platformy Azure i zestaw PYTHON SDK wprowadzają spójność i zestaw nowych funkcji w celu przyspieszenia cyklu życia uczenia maszynowego w środowisku produkcyjnym. Ten artykuł zawiera omówienie uaktualniania do wersji 2 z zaleceniami, które ułatwiają podjęcie decyzji o wersji 1, wersji 2 lub obu tych wersji.
Wymagania wstępne
- Ogólna znajomość usługi Azure Machine Learning i zestawu SDK języka Python w wersji 1.
- Dowiedz się , co to jest wersja 2?
Czy należy używać wersji 2?
Jeśli uruchamiasz nowy projekt lub przepływ pracy uczenia maszynowego, użyj wersji 2. Jeśli chcesz używać nowych funkcji oferowanych w wersji 2, należy użyć wersji 2. Dostępne funkcje to:
- Wnioskowanie zarządzane
- Składniki wielokrotnego użytku w potokach
- Ulepszone planowanie potoków
- Pulpit nawigacyjny odpowiedzialnej sztucznej inteligencji
- Rejestr zasobów
Nowy projekt w wersji 2 może ponownie używać istniejących zasobów w wersji 1, takich jak obszary robocze i zasoby obliczeniowe i istniejące, takie jak modele i środowiska utworzone przy użyciu wersji 1.
Niektóre luki w funkcjach w wersji 2 obejmują:
- Obsługa platformy Spark w zadaniach — jest to obecnie w wersji zapoznawczej w wersji 2.
- Zadania publikowania (potoki w wersji 1) jako punkty końcowe. Można jednak zaplanować potoki bez publikowania.
- Obsługa magazynów danych SQL/database.
- Możliwość używania klasycznych wstępnie utworzonych składników w projektancie w wersji 2.
Następnie należy upewnić się, że potrzebne funkcje w wersji 2 spełniają wymagania organizacji, takie jak ogólnie dostępne.
Ważne
Nowe funkcje w usłudze Azure Machine Learning zostaną uruchomione tylko w wersji 2.
Którego interfejsu API w wersji 2 należy użyć?
W interfejsach w wersji 2 za pośrednictwem interfejsu API REST, interfejsu wiersza polecenia i zestawu PYTHON SDK są dostępne. Interfejs, którego należy użyć, zależy od scenariusza i preferencji.
| interfejs API | Uwagi |
|---|---|
| REST | Najmniejsza zależność i obciążenie. Służy do tworzenia aplikacji w usłudze Azure Machine Learning jako platformy, bezpośrednio w językach programowania bez zestawu SDK lub preferencji osobistych. |
| CLI | Zalecane do automatyzacji przy użyciu ciągłej integracji/ciągłego wdrażania lub preferencji osobistych. Umożliwia szybszą iterację przy użyciu plików YAML i prostego rozdzielenia między usługą Azure Machine Learning i kodem modelu uczenia maszynowego. |
| Zestaw SDK dla języka Python | Zalecane w przypadku skomplikowanych skryptów (na przykład programowego generowania dużych zadań potoku) lub preferencji osobistych. Umożliwia szybką iterację przy użyciu plików YAML lub programowania wyłącznie w języku Python. |
Mapowanie zestawu Python SDK w wersji 1 na 2
Zapoznaj się z każdym z poniższych artykułów, aby zapoznać się z mapowaniem kodu porównania dla zestawu SDK w wersji 1 a wersja 2.
| Zasoby i zasoby | Artykuł |
|---|---|
| Obszar roboczy | Zarządzanie obszarami roboczymi w zestawie SDK w wersji 1 i zestawu SDK w wersji 2 |
| Magazyn danych | Zarządzanie magazynem danych w zestawie SDK w wersji 1 i zestawu SDK w wersji 2 |
| Data | Zasoby danych w zestawie SDK w wersji 1 i w wersji 2 |
| Compute | Zarządzanie obliczeniami w zestawie SDK w wersji 1 i zestawu SDK w wersji 2 |
| Szkolenia | Uruchamianie skryptu |
| Szkolenia | Uruchomienia lokalne |
| Szkolenia | Dostrajanie hiperparametrów |
| Szkolenia | Równoległe uruchamianie |
| Szkolenia | Pipelines |
| Szkolenia | AutoML |
| Modele | Zarządzanie modelami w zestawie SDK w wersji 1 i zestawu SDK w wersji 2 |
| Wdrożenie | Uaktualnianie punktów końcowych wdrożenia do zestawu SDK w wersji 2 |
Zasoby i zasoby w wersji 1 i 2
Ta sekcja zawiera omówienie określonych zasobów i zasobów w usłudze Azure Machine Learning. Zobacz artykuł koncepcyjny dla każdej jednostki, aby uzyskać szczegółowe informacje na temat ich użycia w wersji 2.
Obszar roboczy
Obszary robocze nie muszą być uaktualniane przy użyciu wersji 2. Możesz użyć tego samego obszaru roboczego, niezależnie od tego, czy używasz wersji 1, czy 2.
Jeśli tworzysz obszary robocze przy użyciu automatyzacji, rozważ uaktualnienie kodu do tworzenia obszaru roboczego do wersji 2. Zazwyczaj zasoby platformy Azure są zarządzane za pośrednictwem usługi Azure Resource Manager (i Bicep) lub podobnych narzędzi aprowizacji zasobów. Alternatywnie możesz użyć interfejsu wiersza polecenia (wersja 2) i plików YAML.
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zarządzanie obszarami roboczymi w zestawie SDK w wersji 1 i zestaw SDK w wersji 2.
Ważne
Jeśli obszar roboczy używa prywatnego punktu końcowego, zostanie v1_legacy_mode automatycznie włączona flaga uniemożliwiająca użycie interfejsów API w wersji 2. Aby uzyskać szczegółowe informacje, zobacz , jak skonfigurować izolację sieci przy użyciu wersji 2 .
Połączenie (połączenie obszaru roboczego w wersji 1)
Połączenia obszaru roboczego z wersji 1 są utrwalane w obszarze roboczym i w pełni dostępne w wersji 2.
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zarządzanie obszarami roboczymi w zestawie SDK w wersji 1 i zestaw SDK w wersji 2.
Magazyn danych
Typy magazynu danych magazynu obiektów utworzone za pomocą wersji 1 są w pełni dostępne do użycia w wersji 2. Magazyny danych bazy danych nie są obsługiwane; Eksportowanie do magazynu obiektów (zazwyczaj azure Blob) jest zalecaną ścieżką migracji.
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zarządzanie magazynem danych w zestawie SDK w wersji 1 i zestaw SDK w wersji 2.
Dane (zestawy danych w wersji 1)
Nazwy zestawów danych są zmieniane na zasoby danych. Zapewniana jest zgodność z poprzednimi wersjami, co oznacza, że można używać zestawów danych w wersji 1 w wersji 2. Gdy korzystasz z zestawu danych w wersji 1 w zadaniu w wersji 2, zauważysz, że są one automatycznie mapowane na typy V2 w następujący sposób:
- V1 FileDataset = V2 Folder (
uri_folder) - Tabelaryczny zestaw danych w wersji 1 = tabela V2 (
mltable)
Należy zauważyć, że nie podano zgodności przekazywania dalej, co oznacza, że nie można używać zasobów danych w wersji 2 w wersji 1.
Ten artykuł zawiera więcej informacji na temat obsługi danych w wersji 2 — odczytywanie i zapisywanie danych w zadaniu
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zasoby danych w zestawie SDK w wersji 1 i w wersji 2.
Compute
Obliczenia typu AmlCompute i ComputeInstance są w pełni dostępne do użycia w wersji 2.
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zarządzanie obliczeniami w zestawie SDK w wersji 1 i zestaw SDK w wersji 2.
Zadania (eksperymenty, uruchomienia, potoki w wersji 1)
W „eksperymentach” w wersji 2 „przebiegi” i „potoki” są konsolidowane jako zadania. Zadanie ma typ. Większość zadań to command zadania, które uruchamiają polecenie, takie jak python main.py. To, co działa w zadaniu, jest niezależne od dowolnego języka programowania, więc można uruchamiać bash skrypty, wywoływać python interpretery, uruchamiać kilka curl poleceń lub cokolwiek innego. Innym typowym typem zadania jest pipeline, który definiuje zadania podrzędne, które mogą mieć relacje wejściowe/wyjściowe, tworząc skierowany graf acykliczny (DAG).
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz
- Uruchamianie skryptu
- Uruchomienia lokalne
- Dostrajanie hiperparametrów
- Równoległe uruchamianie
- Pipelines
- AutoML
Projektant
Za pomocą projektanta można tworzyć potoki przy użyciu własnych składników niestandardowych w wersji 2 i nowych wstępnie utworzonych składników z rejestru. W takiej sytuacji możesz użyć zasobów danych w wersji 1 lub 2 w potoku.
Możesz nadal używać projektanta do kompilowania potoków przy użyciu klasycznych wstępnie utworzonych składników i typów zestawów danych w wersji 1 (tabelaryczny, plik). Nie można używać istniejących wstępnie utworzonych składników projektanta z zasobem danych w wersji 2.
Nie można utworzyć potoku przy użyciu istniejących wstępnie utworzonych składników projektanta i składników niestandardowych w wersji 2.
Model
Modele utworzone na podstawie wersji 1 mogą być używane w wersji 2.
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Zarządzanie modelami w zestawie SDK w wersji 1 i zestaw SDK w wersji 2
Punkt końcowy i wdrożenie (punkt końcowy i usługa internetowa w wersji 1)
Za pomocą zestawu SDK/interfejsu wiersza polecenia w wersji 1 można wdrażać modele w usłudze ACI lub AKS jako usługi internetowe. Istniejące wdrożenia modelu w wersji 1 i usługi internetowe będą nadal działać tak, jak są, ale wdrażanie modeli w usłudze ACI lub AKS przy użyciu zestawu SDK/interfejsu wiersza polecenia w wersji 1 jest teraz uznawane za starsze. W przypadku nowych wdrożeń modelu zalecamy uaktualnienie do wersji 2. W wersji 2 oferujemy zarządzane punkty końcowe lub punkty końcowe kubernetes. W poniższej tabeli przedstawiono zalecenia:
| Typ punktu końcowego w wersji 2 | Uaktualnianie z | Uwagi |
|---|---|---|
| Lokalny | ACI | Szybki test wdrożenia modelu lokalnie; nie dla środowiska produkcyjnego. |
| Zarządzany punkt końcowy online | ACI, AKS | Infrastruktura wdrażania modelu zarządzanego klasy korporacyjnej z odpowiedziami niemal w czasie rzeczywistym i ogromnym skalowaniem w środowisku produkcyjnym. |
| Zarządzany punkt końcowy wsadowy | ParallelRunStep w potoku na potrzeby oceniania wsadowego | Infrastruktura wdrażania modelu zarządzanego klasy korporacyjnej z masowo równoległym przetwarzaniem wsadowym na potrzeby produkcji. |
| Azure Kubernetes Service (AKS) | ACI, AKS | Zarządzanie własnymi klastrami usługi AKS na potrzeby wdrażania modelu, zapewniając elastyczność i szczegółową kontrolę kosztem obciążeń IT. |
| Platforma Kubernetes z usługą Azure Arc | Nie dotyczy | Zarządzaj własnymi klastrami Kubernetes w innych chmurach lub lokalnie, zapewniając elastyczność i szczegółową kontrolę kosztem obciążeń it. |
Aby zapoznać się z porównaniem kodu zestawu SDK w wersji 1 i 2, zobacz Uaktualnianie punktów końcowych wdrożenia do zestawu SDK w wersji 2. Aby uzyskać instrukcje migracji z istniejących usług internetowych ACI do zarządzanych punktów końcowych online, zobacz nasz artykuł i blog z przewodnika po uaktualnieniu.
Środowisko
Środowiska utworzone na podstawie wersji 1 mogą być używane w wersji 2. W wersji 2 środowiska mają nowe funkcje, takie jak tworzenie z lokalnego kontekstu platformy Docker.
Zarządzanie wpisami tajnymi
Zarządzanie wpisami tajnymi usługi Key Vault różni się znacznie w wersji 2 w porównaniu z wersją V1. Metody zestawu SDK set_secret i get_secret w wersji 1 nie są dostępne w wersji 2. Zamiast tego należy używać bezpośredniego dostępu przy użyciu bibliotek klienckich usługi Key Vault. Podczas uzyskiwania dostępu do wpisów tajnych ze skryptu szkoleniowego można użyć tożsamości zarządzanej zasobów obliczeniowych lub tożsamości.
Aby uzyskać szczegółowe informacje na temat usługi Key Vault, zobacz Używanie wpisów tajnych poświadczeń uwierzytelniania w zadaniach szkoleniowych usługi Azure Machine Learning.
Scenariusze w całym cyklu życia uczenia maszynowego
Istnieje kilka scenariuszy, które są wspólne w całym cyklu życia uczenia maszynowego przy użyciu usługi Azure Machine Learning. Przyjrzymy się kilku i przedstawimy ogólne zalecenia dotyczące uaktualniania do wersji 2.
Konfiguracja platformy Azure
Platforma Azure zaleca tworzenie zasobów za pomocą szablonów usługi Azure Resource Manager (często za pośrednictwem aplikacji Bicep). To samo jest dobrym podejściem do tworzenia zasobów usługi Azure Machine Learning.
Jeśli twój zespół korzysta tylko z usługi Azure Machine Learning, możesz rozważyć aprowizowanie obszaru roboczego i innych zasobów za pośrednictwem plików YAML i interfejsu wiersza polecenia.
Modele prototypowania
Zalecamy tworzenie prototypów modeli w wersji 2. Możesz rozważyć użycie interfejsu wiersza polecenia w celu interaktywnego korzystania z usługi Azure Machine Learning, podczas gdy kod trenowania modelu to Python lub inny język programowania. Alternatywnie możesz zastosować podejście pełnego stosu w języku Python wyłącznie przy użyciu zestawu SDK usługi Azure Machine Learning lub mieszanego podejścia z zestawem SDK języka Python usługi Azure Machine Learning i plikami YAML.
Trenowanie modelu produkcyjnego
Zalecamy trenowanie modelu produkcyjnego w wersji 2. Zadania konsolidują terminologię i zapewniają zestaw spójności, który umożliwia łatwiejsze przechodzenie między typami (na przykład command do sweep) oraz przyjazny dla metodyki GitOps proces serializacji zadań w plikach YAML.
W wersji 2 należy oddzielić kod uczenia maszynowego od kodu płaszczyzny sterowania. Ta separacja umożliwia łatwiejsze iterację i umożliwia łatwiejsze przejście między środowiskiem lokalnym a chmurą. Zalecamy również używanie biblioteki MLflow do śledzenia i rejestrowania modeli. Aby uzyskać szczegółowe informacje, zobacz artykuł dotyczący koncepcji platformy MLflow.
Wdrażanie modelu produkcyjnego
Zalecamy wdrożenie modelu produkcyjnego w wersji 2. Zarządzane punkty końcowe stanowią abstrakcję obciążeń it i zapewniają wydajne rozwiązanie do wdrażania i oceniania modeli, zarówno w przypadku scenariuszy online (niemal w czasie rzeczywistym), jak i wsadowych (masowo równoległych).
Wdrożenia platformy Kubernetes są obsługiwane w wersji 2 za pośrednictwem usługi AKS lub Usługi Azure Arc, umożliwiając wdrażanie chmury platformy Azure i wdrożeń lokalnych zarządzanych przez organizację.
Operacje uczenia maszynowego (MLOps)
Przepływ pracy metodyki MLOps zwykle obejmuje ciągłą integrację/ciągłe wdrażanie za pośrednictwem narzędzia zewnętrznego. Zazwyczaj interfejs wiersza polecenia jest używany w ciągłej integracji/ciągłego wdrażania, ale alternatywnie można wywołać język Python lub bezpośrednio użyć interfejsu REST.
Akcelerator rozwiązań dla metodyki MLOps z wersją 2 jest opracowywany w wersji https://github.com/Azure/mlops-v2 2 i może być używany jako odwołanie lub przyjęty do konfigurowania i automatyzacji cyklu życia uczenia maszynowego.
Uwaga dotycząca metodyki GitOps w wersji 2
Kluczowym paradygmatem w wersji 2 jest serializowanie jednostek uczenia maszynowego jako plików YAML na potrzeby kontroli źródła za pomocą gitmetody , co umożliwia lepsze podejścia GitOps niż w wersji 1. Na przykład można wymusić zasady, za pomocą których tylko jednostka usługi używana w potokach ciągłej integracji/ciągłego wdrażania może tworzyć/aktualizować/usuwać niektóre lub wszystkie jednostki, zapewniając przejście zmian przez proces zarządzany, taki jak żądania ściągnięcia z wymaganymi recenzentami. Ponieważ pliki w kontroli źródła to YAML, łatwo je różnicować i śledzić zmiany w czasie. Ty i Twój zespół mogą rozważyć przejście do tego paradygmatu podczas uaktualniania do wersji 2.
Możesz uzyskać reprezentację YAML dowolnej jednostki za pomocą interfejsu wiersza polecenia za pomocą polecenia az ml <entity> show --output yaml. Należy pamiętać, że te dane wyjściowe będą miały właściwości generowane przez system, które można zignorować lub usunąć.
Czy uaktualniję istniejący kod w wersji 1 do wersji 2
Istniejące zasoby w wersji 1 można użyć ponownie w przepływach pracy w wersji 2. Na przykład model utworzony w wersji 1 może służyć do wykonywania wnioskowania zarządzanego w wersji 2.
Opcjonalnie, jeśli chcesz uaktualnić określone części istniejącego kodu w wersji 1 do wersji 2, zapoznaj się z linkami porównania podanymi w tym dokumencie.
Czy można używać razem wersji 1 i 2?
Wersja 1 i wersja 2 mogą współistnieć w obszarze roboczym. Istniejące zasoby można użyć ponownie w przepływach pracy w wersji 2. Na przykład model utworzony w wersji 1 może służyć do wykonywania wnioskowania zarządzanego w wersji 2. Zasoby, takie jak obszar roboczy, obliczenia i magazyn danych, działają w różnych regionach w wersji 1 i 2 z wyjątkami. Użytkownik może wywołać zestaw SDK języka Python w wersji 1, aby zmienić opis obszaru roboczego, a następnie ponownie zmienić go za pomocą rozszerzenia interfejsu wiersza polecenia w wersji 2. Zadania (eksperymenty/przebiegi/potoki w wersji 1) można przesłać do tego samego obszaru roboczego z zestawu SDK języka Python w wersji 1 lub 2. Obszar roboczy może mieć punkty końcowe wdrożenia modelu w wersji 1 i 2.
Używanie razem kodu w wersji 1 i 2
Nie zalecamy używania zestawów SDK w wersji 1 i 2 razem w tym samym kodzie. Technicznie można używać wersji 1 i 2 w tym samym kodzie, ponieważ używają różnych przestrzeni nazw platformy Azure. Istnieje jednak wiele klas o tej samej nazwie w tych przestrzeniach nazw (takich jak Workspace, Model), które mogą powodować nieporozumienie i utrudnić czytelność kodu oraz możliwość debugowania.
Ważne
Jeśli obszar roboczy używa prywatnego punktu końcowego, zostanie v1_legacy_mode automatycznie włączona flaga uniemożliwiająca użycie interfejsów API w wersji 2. Aby uzyskać szczegółowe informacje, zobacz , jak skonfigurować izolację sieci przy użyciu wersji 2 .