Punkty końcowe i wdrożenia online na potrzeby wnioskowania w czasie rzeczywistym

DOTYCZY: Rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji 2 (current)Zestaw PYTHON SDK azure-ai-ml v2 (bieżąca)

Usługa Azure Machine Edukacja umożliwia wnioskowanie w czasie rzeczywistym na danych przy użyciu modeli wdrożonych w punktach końcowych online. Wnioskowanie to proces stosowania nowych danych wejściowych do modelu uczenia maszynowego w celu wygenerowania danych wyjściowych. Chociaż te dane wyjściowe są zwykle określane jako "przewidywania", wnioskowanie może służyć do generowania danych wyjściowych dla innych zadań uczenia maszynowego, takich jak klasyfikacja i klastrowanie.

Punkty końcowe online

Punkty końcowe online wdrażają modele na serwerze internetowym, który może zwracać przewidywania w ramach protokołu HTTP. Użyj punktów końcowych online, aby operacjonalizować modele na potrzeby wnioskowania w czasie rzeczywistym w synchronicznych żądaniach o małych opóźnieniach. Zalecamy ich używanie w przypadku:

  • Wymagania dotyczące małych opóźnień
  • Model może odpowiedzieć na żądanie w stosunkowo krótkim czasie
  • Dane wejściowe modelu mieszczą się w ładunku HTTP żądania
  • Musisz skalować w górę pod względem liczby żądań

Aby zdefiniować punkt końcowy, należy określić:

  • Nazwa punktu końcowego: ta nazwa musi być unikatowa w regionie świadczenia usługi Azure. Aby uzyskać więcej informacji na temat reguł nazewnictwa, zobacz Limity punktów końcowych.
  • Tryb uwierzytelniania: możesz wybrać tryb uwierzytelniania opartego na kluczach, tryb uwierzytelniania oparty na tokenach usługi Azure Machine Edukacja lub uwierzytelnianie oparte na tokenach firmy Microsoft (wersja zapoznawcza) dla punktu końcowego. Aby uzyskać więcej informacji na temat uwierzytelniania, zobacz Uwierzytelnianie w punkcie końcowym online.

Usługa Azure Machine Edukacja zapewnia wygodę korzystania z zarządzanych punktów końcowych online do wdrażania modeli uczenia maszynowego w sposób klucz. Jest to zalecany sposób korzystania z punktów końcowych online w usłudze Azure Machine Edukacja. Zarządzane punkty końcowe online współpracują z maszynami o zaawansowanych procesorach CPU i GPU na platformie Azure w sposób skalowalny i w pełni zarządzany. Te punkty końcowe dbają również o obsługę, skalowanie, zabezpieczanie i monitorowanie modeli, aby uwolnić Cię od obciążeń związanych z konfigurowaniem podstawowej infrastruktury i zarządzaniem nią. Aby dowiedzieć się, jak zdefiniować zarządzany punkt końcowy online, zobacz Definiowanie punktu końcowego.

Dlaczego warto wybrać zarządzane punkty końcowe online za pośrednictwem usługi ACI lub AKS(v1)?

Korzystanie z zarządzanych punktów końcowych online jest zalecanym sposobem korzystania z punktów końcowych online w usłudze Azure Machine Edukacja. W poniższej tabeli przedstawiono najważniejsze atrybuty zarządzanych punktów końcowych online w porównaniu z rozwiązaniami azure Machine Edukacja SDK/CLI w wersji 1 (ACI i AKS(v1).

Atrybuty Zarządzane punkty końcowe online (wersja 2) ACI lub AKS(wersja 1)
Zabezpieczenia/izolacja sieci Łatwa kontrola ruchu przychodzącego/wychodzącego z szybkim przełącznikiem Sieć wirtualna nie jest obsługiwana lub wymaga złożonej konfiguracji ręcznej
Usługa zarządzana — W pełni zarządzana aprowizacja/skalowanie zasobów obliczeniowych
— Konfiguracja sieci na potrzeby zapobiegania eksfiltracji danych
— Uaktualnianie systemu operacyjnego hosta, kontrolowane wdrażanie aktualizacji w miejscu
— Skalowanie jest ograniczone w wersji 1
— Konfiguracja sieci lub uaktualnienie muszą być zarządzane przez użytkownika
Koncepcja punktu końcowego/wdrożenia Rozróżnienie między punktem końcowym a wdrożeniem umożliwia wykonywanie złożonych scenariuszy, takich jak bezpieczne wdrażanie modeli Brak pojęcia punktu końcowego
Diagnostyka i monitorowanie - Lokalne debugowanie punktu końcowego możliwe za pomocą platformy Docker i programu Visual Studio Code
— Zaawansowane metryki i analiza dzienników za pomocą wykresu/zapytania w celu porównania między wdrożeniami
— Podział kosztów na poziom wdrożenia
Brak łatwego debugowania lokalnego
Skalowalność Nieograniczone, elastyczne i automatyczne skalowanie — Usługa ACI nie jest skalowalna
— Usługa AKS (wersja 1) obsługuje tylko skalowanie w klastrze i wymaga konfiguracji skalowalności
Gotowość przedsiębiorstwa Usługa Private Link, klucze zarządzane przez klienta, identyfikator entra firmy Microsoft, zarządzanie limitami przydziału, integracja rozliczeń, umowa SLA Nieobsługiwane
Zaawansowane funkcje uczenia maszynowego - Zbieranie danych modelu
- Monitorowanie modelu
- Model champion-challenger, bezpieczne wprowadzanie, dublowanie ruchu
- Rozszerzalność odpowiedzialnej sztucznej inteligencji
Nieobsługiwane

Alternatywnie, jeśli wolisz używać platformy Kubernetes do wdrażania modeli i obsługi punktów końcowych, a także dobrze zarządzasz wymaganiami dotyczącymi infrastruktury, możesz użyć punktów końcowych online platformy Kubernetes. Te punkty końcowe umożliwiają wdrażanie modeli i obsługę punktów końcowych online w w pełni skonfigurowanym i zarządzanym klastrze Kubernetes w dowolnym miejscu z procesorami CPU lub procesorami GPU.

Dlaczego warto wybrać zarządzane punkty końcowe online za pośrednictwem usługi AKS(v2)?

Zarządzane punkty końcowe online mogą pomóc usprawnić proces wdrażania i zapewnić następujące korzyści w przypadku punktów końcowych online platformy Kubernetes:

  • Infrastruktura zarządzana

    • Automatycznie aprowizuje obliczenia i hostuje model (wystarczy określić typ maszyny wirtualnej i ustawienia skalowania)
    • Automatycznie aktualizuje i poprawia podstawowy obraz systemu operacyjnego hosta
    • Automatycznie wykonuje odzyskiwanie węzła w przypadku awarii systemu
  • Monitorowanie i dzienniki

    Zrzut ekranu przedstawiający wykres opóźnienia punktu końcowego w usłudze Azure Monitor.

  • Wyświetlanie kosztów

    Zrzut ekranu przedstawiający wykres kosztów punktu końcowego i wdrożenia.

    Uwaga

    Zarządzane punkty końcowe online są oparte na usłudze Azure Machine Edukacja obliczeniowych. W przypadku korzystania z zarządzanego punktu końcowego online płacisz za opłaty za obliczenia i sieć. Nie ma dodatkowej opłaty. Aby uzyskać więcej informacji na temat cen, zobacz kalkulator cen platformy Azure.

    Jeśli używasz sieci wirtualnej usługi Azure Machine Edukacja do zabezpieczania ruchu wychodzącego z zarządzanego punktu końcowego online, opłaty są naliczane za prywatne łącze platformy Azure i reguły ruchu wychodzącego FQDN, które są używane przez zarządzaną sieć wirtualną. Aby uzyskać więcej informacji, zobacz Cennik zarządzanej sieci wirtualnej.

Zarządzane punkty końcowe online a punkty końcowe online kubernetes

W poniższej tabeli przedstawiono najważniejsze różnice między zarządzanymi punktami końcowymi online i punktami końcowymi online platformy Kubernetes.

Zarządzane punkty końcowe online Punkty końcowe online platformy Kubernetes (AKS(wersja 2))
Zalecani użytkownicy Użytkownicy, którzy potrzebują zarządzanego wdrażania modeli i ulepszonego środowiska MLOps Użytkownicy, którzy preferują platformę Kubernetes i mogą samodzielnie zarządzać wymaganiami infrastruktury
Aprowizowanie węzłów Aprowizowanie, aktualizowanie, usuwanie zarządzanych zasobów obliczeniowych Odpowiedzialność użytkowników
Konserwacja węzła Aktualizacje obrazów systemu operacyjnego hosta zarządzanego i wzmacnianie zabezpieczeń Odpowiedzialność użytkowników
Ustalanie rozmiaru klastra (skalowanie) Zarządzana ręczna i automatyczna skalowanie, obsługa dodatkowych węzłów aprowizacji Ręczne i automatyczne skalowanie obsługujące skalowanie liczby replik w stałych granicach klastra
Typ obliczeniowy Zarządzane przez usługę Klaster Kubernetes zarządzany przez klienta (Kubernetes)
Tożsamość zarządzana Obsługiwane Obsługiwane
Sieć wirtualna (VNET) Obsługiwane za pośrednictwem zarządzana izolacja sieci Odpowiedzialność użytkowników
Wbudowane monitorowanie i rejestrowanie Obsługiwane usługi Azure Monitor i Log Analytics (łącznie z kluczowymi metrykami i tabelami dzienników dla punktów końcowych i wdrożeń) Odpowiedzialność użytkowników
Rejestrowanie przy użyciu Szczegółowe informacje aplikacji (starsza wersja) Obsługiwane Obsługiwane
Wyświetlanie kosztów Szczegółowy dla punktu końcowego/poziomu wdrożenia Na poziomie klastra
Koszt zastosowany do Maszyny wirtualne przypisane do wdrożeń Maszyny wirtualne przypisane do klastra
Ruch dublowany Obsługiwane Nieobsługiwane
Wdrażanie bez kodu Obsługiwane (modele MLflow i Triton ) Obsługiwane (modele MLflow i Triton )

Wdrożenia online

Wdrożenie to zestaw zasobów i obliczeń wymaganych do hostowania modelu, który wykonuje rzeczywiste wnioskowanie. Pojedynczy punkt końcowy może zawierać wiele wdrożeń z różnymi konfiguracjami. Ta konfiguracja ułatwia oddzielenie interfejsu przedstawionego przez punkt końcowy ze szczegółów implementacji znajdujących się we wdrożeniu. Punkt końcowy online ma mechanizm routingu, który może kierować żądania do określonych wdrożeń w punkcie końcowym.

Na poniższym diagramie przedstawiono punkt końcowy online z dwoma wdrożeniami, niebieskim i zielonym. Niebieskie wdrożenie używa maszyn wirtualnych z jednostkami SKU procesora CPU i uruchamia wersję 1 modelu. Zielone wdrożenie używa maszyn wirtualnych z jednostkami SKU procesora GPU i uruchamia wersję 2 modelu. Punkt końcowy jest skonfigurowany do kierowania 90% ruchu przychodzącego do niebieskiego wdrożenia, podczas gdy zielone wdrożenie otrzymuje pozostałe 10%.

Diagram przedstawiający punkt końcowy dzielący ruch do dwóch wdrożeń.

Aby wdrożyć model, musisz mieć następujące elementy:

  • Pliki modelu (lub nazwa i wersja modelu, który jest już zarejestrowany w obszarze roboczym).
  • Skrypt oceniania, czyli kod, który wykonuje model na danym żądaniu wejściowym. Skrypt oceniania odbiera dane przesłane do wdrożonej usługi internetowej i przekazuje je do modelu. Następnie skrypt wykonuje model i zwraca jego odpowiedź na klienta. Skrypt oceniania jest specyficzny dla modelu i musi zrozumieć dane oczekiwane przez model jako dane wejściowe i zwracane jako dane wyjściowe.
  • Środowisko, w którym działa model. Środowisko może być obrazem platformy Docker z zależnościami conda lub plikiem Dockerfile.
  • Ustawienia określić typ wystąpienia i pojemność skalowania.

Kluczowe atrybuty wdrożenia

W poniższej tabeli opisano kluczowe atrybuty wdrożenia:

Atrybut Opis
Nazwa/nazwisko Nazwa wdrożenia.
Nazwa punktu końcowego Nazwa punktu końcowego do utworzenia wdrożenia w obszarze.
Model1 Model do użycia na potrzeby wdrożenia. Ta wartość może być odwołaniem do istniejącego modelu w wersji w obszarze roboczym lub specyfikacji wbudowanego modelu. Aby uzyskać więcej informacji na temat śledzenia i określania ścieżki do modelu, zobacz Identyfikowanie ścieżki modelu w odniesieniu do AZUREML_MODEL_DIRelementu .
Ścieżka kodu Ścieżka do katalogu w lokalnym środowisku projektowym zawierającym cały kod źródłowy języka Python do oceniania modelu. Można użyć katalogów i pakietów zagnieżdżonych.
Skrypt oceniania Ścieżka względna do pliku oceniania w katalogu kodu źródłowego. Ten kod w języku Python musi mieć init() funkcję i run() funkcję. Funkcja init() zostanie wywołana po utworzeniu lub zaktualizowaniu modelu (można jej użyć do buforowania modelu w pamięci, na przykład). Funkcja run() jest wywoływana przy każdym wywołaniu punktu końcowego w celu wykonania rzeczywistego oceniania i przewidywania.
Środowisko1 Środowisko do hostowania modelu i kodu. Ta wartość może być odwołaniem do istniejącego środowiska w wersji w obszarze roboczym lub specyfikacji środowiska wbudowanego. Uwaga: firma Microsoft regularnie poprawia obrazy podstawowe pod kątem znanych luk w zabezpieczeniach. Aby użyć poprawionego obrazu, należy ponownie wdrożyć punkt końcowy. Jeśli podasz własny obraz, ponosisz odpowiedzialność za jego aktualizowanie. Aby uzyskać więcej informacji, zobacz Stosowanie poprawek obrazów.
Typ wystąpienia Rozmiar maszyny wirtualnej do użycia na potrzeby wdrożenia. Aby uzyskać listę obsługiwanych rozmiarów, zobacz Lista jednostek SKU zarządzanych punktów końcowych online.
Liczba wystąpień Liczba wystąpień do użycia na potrzeby wdrożenia. W oparciu o oczekiwaną wartość obciążenia. W przypadku wysokiej dostępności zalecamy ustawienie wartości na wartość co najmniej 3. Firma Microsoft zastrzega sobie dodatkowe 20% na potrzeby przeprowadzania uaktualnień. Aby uzyskać więcej informacji, zobacz Alokacja przydziału maszyn wirtualnych dla wdrożeń.

1 Niektóre kwestie, które należy zwrócić uwagę na model i środowisko:

  • Obraz modelu i kontenera (zgodnie z definicją w środowisku) można odwoływać się ponownie w dowolnym momencie przez wdrożenie, gdy wystąpienia za wdrożeniem przechodzą przez poprawki zabezpieczeń i/lub inne operacje odzyskiwania. W przypadku użycia zarejestrowanego modelu lub obrazu kontenera w usłudze Azure Container Registry do wdrożenia i usunięcia modelu lub obrazu kontenera wdrożenia oparte na tych zasobach mogą zakończyć się niepowodzeniem po ponownym utworzeniu obrazu. Jeśli usuniesz model lub obraz kontenera, upewnij się, że wdrożenia zależne zostaną ponownie utworzone lub zaktualizowane przy użyciu alternatywnego modelu lub obrazu kontenera.
  • Rejestr kontenerów, do którego odwołuje się środowisko, może być prywatny tylko wtedy, gdy tożsamość punktu końcowego ma uprawnienia dostępu do niego za pośrednictwem uwierzytelniania microsoft Entra i kontroli dostępu opartej na rolach platformy Azure. Z tego samego powodu prywatne rejestry platformy Docker inne niż usługa Azure Container Registry nie są obsługiwane.

Aby dowiedzieć się, jak wdrażać punkty końcowe online przy użyciu interfejsu wiersza polecenia, zestawu SDK, programu Studio i szablonu usługi ARM, zobacz Wdrażanie modelu uczenia maszynowego przy użyciu punktu końcowego online.

Identyfikowanie ścieżki modelu w odniesieniu do AZUREML_MODEL_DIR

Podczas wdrażania modelu w usłudze Azure Machine Edukacja należy określić lokalizację modelu, który chcesz wdrożyć w ramach konfiguracji wdrożenia. W usłudze Azure Machine Edukacja ścieżka do modelu jest śledzona za pomocą zmiennej środowiskowejAZUREML_MODEL_DIR. Identyfikując ścieżkę modelu w odniesieniu do AZUREML_MODEL_DIRprogramu , można wdrożyć jeden lub więcej modeli przechowywanych lokalnie na maszynie lub wdrożyć model zarejestrowany w obszarze roboczym usługi Azure Machine Edukacja.

Na ilustracji odwołujemy się do następującej lokalnej struktury folderów dla pierwszych dwóch przypadków, w których wdrażasz pojedynczy model lub wdrażasz wiele modeli przechowywanych lokalnie:

Zrzut ekranu przedstawiający strukturę folderów zawierającą wiele modeli.

Używanie pojedynczego modelu lokalnego we wdrożeniu

Aby użyć pojedynczego modelu na maszynie lokalnej we wdrożeniu, określ wartość parametru pathmodel w pliku YAML wdrożenia. Oto przykład kodu YAML wdrożenia ze ścieżką /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

Po utworzeniu wdrożenia zmienna środowiskowa AZUREML_MODEL_DIR wskaże lokalizację magazynu na platformie Azure, w której jest przechowywany model. Na przykład /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 będzie zawierać model sample_m1.pkl.

W skryfcie oceniania (score.py) możesz załadować model (w tym przykładzie sample_m1.pklinit() ) w funkcji :

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path) 

Używanie wielu modeli lokalnych we wdrożeniu

Mimo że interfejs wiersza polecenia platformy Azure, zestaw SDK języka Python i inne narzędzia klienckie umożliwiają określenie tylko jednego modelu na wdrożenie w definicji wdrożenia, nadal można używać wielu modeli we wdrożeniu, rejestrując folder modelu zawierający wszystkie modele jako pliki lub podkatalogi.

W poprzedniej przykładowej strukturze folderów zauważysz, że w folderze models znajduje się wiele modeli. We wdrożeniu YAML można określić ścieżkę do models folderu w następujący sposób:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

Po utworzeniu wdrożenia zmienna środowiskowa AZUREML_MODEL_DIR wskaże lokalizację magazynu na platformie Azure, w której są przechowywane modele. Na przykład /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 będzie zawierać modele i strukturę plików.

W tym przykładzie AZUREML_MODEL_DIR zawartość folderu będzie wyglądać następująco:

Zrzut ekranu przedstawiający strukturę folderów lokalizacji przechowywania dla wielu modeli.

Za pomocą skryptu oceniania (score.py) można załadować modele w init() funkcji . Poniższy kod ładuje sample_m1.pkl model:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path) 

Aby zapoznać się z przykładem wdrażania wielu modeli w jednym wdrożeniu, zobacz Wdrażanie wielu modeli w jednym wdrożeniu (przykład interfejsu wiersza polecenia) i Wdrażanie wielu modeli w jednym wdrożeniu (przykład zestawu SDK).

Napiwek

Jeśli masz więcej niż 1500 plików do zarejestrowania, rozważ skompresowanie plików lub podkatalogów jako .tar.gz podczas rejestrowania modeli. Aby korzystać z modeli, możesz usunąć z funkcji pliki lub podkatalogi z init() skryptu oceniania. Alternatywnie podczas rejestrowania modeli ustaw azureml.unpack właściwość na True, aby automatycznie usunąć z plików lub podkatalogów. W obu przypadkach nieskompresja odbywa się raz na etapie inicjowania.

Używanie modeli zarejestrowanych w obszarze roboczym usługi Azure Machine Edukacja we wdrożeniu

Aby użyć co najmniej jednego modelu zarejestrowanego w obszarze roboczym usługi Azure Machine Edukacja, we wdrożeniu określ nazwę zarejestrowanych modeli we wdrożeniu YAML. Na przykład następująca konfiguracja wdrożenia YAML określa zarejestrowaną model nazwę jako azureml:local-multimodel:3:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

W tym przykładzie należy wziąć pod uwagę, że local-multimodel:3 zawiera następujące artefakty modelu, które można wyświetlić na karcie Modele w usłudze Azure Machine Edukacja Studio:

Zrzut ekranu przedstawiający strukturę folderów przedstawiającą artefakty modelu zarejestrowanego modelu.

Po utworzeniu wdrożenia zmienna środowiskowa AZUREML_MODEL_DIR wskaże lokalizację magazynu na platformie Azure, w której są przechowywane modele. Na przykład /var/azureml-app/azureml-models/local-multimodel/3 będzie zawierać modele i strukturę plików. AZUREML_MODEL_DIR wskaże folder zawierający katalog główny artefaktów modelu. Na podstawie tego przykładu AZUREML_MODEL_DIR zawartość folderu będzie wyglądać następująco:

Zrzut ekranu przedstawiający strukturę folderów z wieloma modelami.

Za pomocą skryptu oceniania (score.py) można załadować modele w init() funkcji . Na przykład załaduj diabetes.sav model:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path) 

Alokacja przydziału maszyny wirtualnej na potrzeby wdrożenia

W przypadku zarządzanych punktów końcowych online usługa Azure Machine Edukacja rezerwuje 20% zasobów obliczeniowych na potrzeby przeprowadzania uaktualnień na niektórych jednostkach SKU maszyn wirtualnych. Jeśli żądasz określonej liczby wystąpień dla tych jednostek SKU maszyny wirtualnej we wdrożeniu, musisz mieć limit przydziału ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU dostępny, aby uniknąć wystąpienia błędu. Jeśli na przykład zażądasz 10 wystąpień maszyny wirtualnej Standard_DS3_v2 (która jest dostarczana z czterema rdzeniami) we wdrożeniu, musisz mieć limit przydziału dla 48 rdzeni (12 instances * 4 cores) dostępnych. Ten dodatkowy limit przydziału jest zarezerwowany dla operacji inicjowanych przez system, takich jak uaktualnienia systemu operacyjnego i odzyskiwanie maszyny wirtualnej, i nie będzie ponosić kosztów, chyba że takie operacje zostaną uruchomione.

Istnieją pewne jednostki SKU maszyn wirtualnych, które są zwolnione z dodatkowego limitu przydziału rezerwacji. Aby wyświetlić pełną listę, zobacz Lista jednostek SKU zarządzanych punktów końcowych online.

Aby wyświetlić wzrost użycia i limitu przydziału żądań, zobacz Wyświetlanie użycia i limitów przydziału w witrynie Azure Portal. Aby wyświetlić koszt uruchamiania zarządzanego punktu końcowego online, zobacz Wyświetlanie kosztów zarządzanego punktu końcowego online.

Usługa Azure Machine Edukacja udostępnia udostępnioną pulę przydziałów, z której wszyscy użytkownicy mogą uzyskiwać dostęp do limitu przydziału w celu przeprowadzania testów przez ograniczony czas. Gdy używasz programu Studio do wdrażania modeli Llama (z katalogu modeli) do zarządzanego punktu końcowego online, usługa Azure Machine Edukacja umożliwia dostęp do tego udostępnionego limitu przydziału przez krótki czas.

Aby wdrożyć model Llama-2-70b lub Llama-2-70b-chat, należy jednak mieć subskrypcję Umowa Enterprise przed wdrożeniem przy użyciu udostępnionego limitu przydziału. Aby uzyskać więcej informacji na temat korzystania z udostępnionego limitu przydziału na potrzeby wdrażania punktów końcowych online, zobacz How to deploy foundation models using the studio (Jak wdrażać modele podstawowe przy użyciu programu Studio).

Aby uzyskać więcej informacji na temat przydziałów i limitów zasobów w usłudze Azure Machine Edukacja, zobacz Zarządzanie limitami przydziałów i limitami zasobów przy użyciu usługi Azure Machine Edukacja.

Wdrażanie dla koderów i innych niż koderów

Usługa Azure Machine Edukacja obsługuje wdrażanie modelu w punktach końcowych online dla koderów kodu i innych niż koderów, zapewniając opcje wdrażania bez kodu, wdrażania z małą ilością kodu i wdrożenia byOC (Bring Your Own Container).

  • Wdrożenie bez kodu zapewnia wbudowane wnioskowanie dla typowych struktur (na przykład scikit-learn, TensorFlow, PyTorch i ONNX) za pośrednictwem platform MLflow i Triton.
  • Wdrożenie z małą ilością kodu umożliwia zapewnienie minimalnego kodu wraz z modelem uczenia maszynowego na potrzeby wdrożenia.
  • Wdrożenie byOC umożliwia praktycznie przenoszenie jakichkolwiek kontenerów do uruchamiania punktu końcowego online. Do zarządzania potokami MLOps można używać wszystkich funkcji platformy Azure Machine Edukacja, takich jak skalowanie automatyczne, metodyka GitOps, debugowanie i bezpieczne wdrażanie.

W poniższej tabeli przedstawiono kluczowe aspekty dotyczące opcji wdrażania online:

Brak kodu Niski kod BYOC
Podsumowanie Używa wbudowanego wnioskowania dla popularnych struktur, takich jak scikit-learn, TensorFlow, PyTorch i ONNX, za pośrednictwem MLflow i Triton. Aby uzyskać więcej informacji, zobacz Wdrażanie modeli MLflow w punktach końcowych online. Używa bezpiecznych, publicznie opublikowanych obrazów wyselekcjonowanych dla popularnych struktur, z aktualizacjami co dwa tygodnie w celu rozwiązania luk w zabezpieczeniach. Udostępniasz skrypt oceniania i/lub zależności języka Python. Aby uzyskać więcej informacji, zobacz Azure Machine Edukacja wyselekcjonowane środowiska. Pełny stos można podać za pośrednictwem obsługi obrazów niestandardowych w usłudze Azure Machine Edukacja. Aby uzyskać więcej informacji, zobacz Używanie niestandardowego kontenera do wdrażania modelu w punkcie końcowym online.
Niestandardowy obraz podstawowy Nie, wyselekcjonowane środowisko zapewni to łatwe wdrożenie. Tak i Nie, możesz użyć wyselekcjonowanego obrazu lub dostosowanego obrazu. Tak, przełącz dostępną lokalizację obrazu kontenera (na przykład docker.io, usługę Azure Container Registry (ACR) lub usługę Microsoft Container Registry (MCR) lub plik Dockerfile, który można skompilować/wypchnąć za pomocą usługi ACR dla kontenera.
Zależności niestandardowe Nie, wyselekcjonowane środowisko zapewni to łatwe wdrożenie. Tak, przełącz środowisko usługi Azure Machine Edukacja, w którym działa model; obraz platformy Docker z zależnościami platformy Conda lub plik dockerfile. Tak, zostanie on uwzględniony w obrazie kontenera.
Kod niestandardowy Nie, skrypt oceniania zostanie wygenerowany automatycznie w celu łatwego wdrożenia. Tak, przełącz skrypt oceniania. Tak, zostanie on uwzględniony w obrazie kontenera.

Uwaga

Uruchamianie automatycznego uczenia maszynowego tworzy skrypt oceniania i zależności automatycznie dla użytkowników, dzięki czemu można wdrożyć dowolny model automatycznego uczenia maszynowego bez tworzenia dodatkowego kodu (w przypadku wdrożenia bez kodu) lub zmodyfikować skrypty generowane automatycznie zgodnie z potrzebami biznesowymi (w przypadku wdrożenia z małą ilością kodu). Aby dowiedzieć się, jak wdrażać za pomocą modeli automatycznego uczenia maszynowego, zobacz Wdrażanie modelu automatycznego uczenia maszynowego przy użyciu punktu końcowego online.

Debugowanie punktu końcowego online

Zdecydowanie zalecamy przetestowanie punktu końcowego lokalnie w celu zweryfikowania i debugowania kodu i konfiguracji przed wdrożeniem na platformie Azure. Interfejs wiersza polecenia platformy Azure i zestaw SDK języka Python obsługują lokalne punkty końcowe i wdrożenia, a usługa Azure Machine Edukacja Studio i szablon usługi ARM nie.

Ograniczenia lokalnych punktów końcowych

Lokalne punkty końcowe mają następujące ograniczenia:

  • Nie obsługują reguł ruchu, uwierzytelniania ani ustawień sondy.
  • Obsługują tylko jedno wdrożenie na punkt końcowy.
  • Obsługują lokalne pliki modelu i środowisko tylko z lokalnym plikiem conda. Jeśli chcesz przetestować zarejestrowane modele, najpierw pobierz je przy użyciu interfejsu wiersza polecenia lub zestawu SDK, a następnie użyj path w definicji wdrożenia, aby odwołać się do folderu nadrzędnego. Jeśli chcesz przetestować zarejestrowane środowiska, sprawdź kontekst środowiska w usłudze Azure Machine Edukacja Studio i przygotuj lokalny plik conda do użycia.

Usługa Azure Machine Edukacja oferuje różne sposoby lokalnego debugowania punktów końcowych online i przy użyciu dzienników kontenerów.

Lokalne debugowanie za pomocą serwera HTTP wnioskowania usługi Azure Machine Edukacja

Skrypt oceniania można debugować lokalnie przy użyciu serwera HTTP wnioskowania usługi Azure Machine Edukacja. Serwer HTTP to pakiet języka Python, który uwidacznia funkcję oceniania jako punkt końcowy HTTP i opakowuje kod serwera Flask i zależności w pojedynczy pakiet. Jest on uwzględniony we wstępnie utworzonych obrazach platformy Docker na potrzeby wnioskowania, które są używane podczas wdrażania modelu za pomocą usługi Azure Machine Edukacja. Korzystając z samego pakietu, możesz wdrożyć model lokalnie na potrzeby środowiska produkcyjnego, a także łatwo zweryfikować skrypt oceniania (wpisu) w lokalnym środowisku deweloperskim. Jeśli wystąpi problem ze skryptem oceniania, serwer zwróci błąd i lokalizację, w której wystąpił błąd. Możesz również użyć programu Visual Studio Code do debugowania za pomocą serwera HTTP wnioskowania usługi Azure Machine Edukacja.

Napiwek

Aby debugować skrypt oceniania lokalnie bez aparatu platformy Docker, możesz użyć pakietu języka Python serwera HTTP wnioskowania usługi Azure Edukacja Machine. Debugowanie za pomocą serwera wnioskowania ułatwia debugowanie skryptu oceniania przed wdrożeniem w lokalnych punktach końcowych, dzięki czemu można debugować bez wpływu na konfiguracje kontenera wdrożenia.

Aby dowiedzieć się więcej na temat debugowania przy użyciu serwera HTTP, zobacz Debugowanie skryptu oceniania za pomocą usługi Azure Machine Edukacja wnioskowania serwera HTTP.

Debugowanie lokalne

W przypadku debugowania lokalnego potrzebne jest wdrożenie lokalne, czyli model wdrożony w lokalnym środowisku platformy Docker. Tego lokalnego wdrożenia można użyć do testowania i debugowania przed wdrożeniem w chmurze. Aby wdrożyć lokalnie, musisz mieć zainstalowany i uruchomiony aparat platformy Docker. Usługa Azure Machine Edukacja następnie tworzy lokalny obraz platformy Docker, który naśladuje obraz usługi Azure Machine Edukacja. Usługa Azure Machine Edukacja skompiluje i uruchomi wdrożenia lokalnie i buforuje obraz w celu uzyskania szybkich iteracji.

Napiwek

Aparat platformy Docker zwykle uruchamia się po uruchomieniu komputera. Jeśli tak nie jest, możesz rozwiązać problemy z aparatem platformy Docker.

Kroki debugowania lokalnego zwykle obejmują:

  • Sprawdzanie, czy wdrożenie lokalne zakończyło się pomyślnie
  • Wywoływanie lokalnego punktu końcowego na potrzeby wnioskowania
  • Przeglądanie dzienników pod kątem danych wyjściowych operacji wywołania

Aby dowiedzieć się więcej na temat debugowania lokalnego, zobacz Wdrażanie i debugowanie lokalnie przy użyciu lokalnego punktu końcowego.

Lokalne debugowanie za pomocą programu Visual Studio Code (wersja zapoznawcza)

Ważne

Ta funkcja jest obecnie w publicznej wersji zapoznawczej. Ta wersja zapoznawcza jest udostępniana bez umowy dotyczącej poziomu usług i nie zalecamy korzystania z niej w przypadku obciążeń produkcyjnych. Niektóre funkcje mogą być nieobsługiwane lub ograniczone.

Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

Podobnie jak w przypadku debugowania lokalnego, należy najpierw zainstalować i uruchomić aparat platformy Docker, a następnie wdrożyć model w lokalnym środowisku platformy Docker. Po wdrożeniu lokalnym usługa Azure Machine Edukacja lokalnych punktów końcowych używa kontenerów deweloperskich platformy Docker i programu Visual Studio Code (kontenerów deweloperskich) do kompilowania i konfigurowania lokalnego środowiska debugowania. Dzięki kontenerom deweloperskim można korzystać z funkcji programu Visual Studio Code, takich jak debugowanie interakcyjne, z poziomu kontenera platformy Docker.

Aby dowiedzieć się więcej na temat interaktywnego debugowania punktów końcowych online w programie VS Code, zobacz Debugowanie punktów końcowych online lokalnie w programie Visual Studio Code.

Debugowanie przy użyciu dzienników kontenera

W przypadku wdrożenia nie można uzyskać bezpośredniego dostępu do maszyny wirtualnej, na której wdrożono model. Jednak można pobrać dzienniki z niektórych kontenerów, które są uruchomione na maszynie wirtualnej. Istnieją dwa typy kontenerów, z których można pobrać dzienniki:

  • Serwer wnioskowania: dzienniki obejmują dziennik konsoli (z serwera wnioskowania), który zawiera dane wyjściowe funkcji drukowania/rejestrowania ze skryptu oceniania (score.py kod).
  • Inicjator magazynu: dzienniki zawierają informacje o tym, czy dane kodu i modelu zostały pomyślnie pobrane do kontenera. Kontener jest uruchamiany przed uruchomieniem kontenera serwera wnioskowania.

Aby dowiedzieć się więcej na temat debugowania za pomocą dzienników kontenerów, zobacz Pobieranie dzienników kontenerów.

Routing ruchu i dublowanie do wdrożeń online

Pamiętaj, że jeden punkt końcowy online może mieć wiele wdrożeń. Ponieważ punkt końcowy odbiera ruch przychodzący (lub żądania), może kierować procent ruchu do każdego wdrożenia, co jest używane w natywnej strategii wdrażania niebieskiego/zielonego. Może również dublować (lub kopiować) ruch z jednego wdrożenia do innego, nazywany również dublowaniem ruchu lub cieniowaniem.

Routing ruchu dla wdrożenia niebieskiego/zielonego

Wdrożenie niebieskie/zielone to strategia wdrażania, która umożliwia wdrożenie nowego wdrożenia (wdrożenie zielone) w małym podzestawie użytkowników lub żądań przed całkowitym wdrożeniem. Punkt końcowy może zaimplementować równoważenie obciążenia w celu przydzielenia pewnych wartości procentowych ruchu do każdego wdrożenia, a łączna alokacja we wszystkich wdrożeniach wynosi 100%.

Napiwek

Żądanie może pominąć skonfigurowane równoważenie obciążenia ruchu, dołączając nagłówek HTTP .azureml-model-deployment Ustaw wartość nagłówka na nazwę wdrożenia, do którego ma być kierowane żądanie.

Na poniższej ilustracji przedstawiono ustawienia w usłudze Azure Machine Edukacja Studio na potrzeby przydzielania ruchu między wdrożeniem niebieskim i zielonym.

Zrzut ekranu przedstawiający interfejs suwaka umożliwiający ustawienie alokacji ruchu między wdrożeniami.

Ta alokacja ruchu kieruje ruch, jak pokazano na poniższej ilustracji, przy 10% ruchu przechodzącego do zielonego wdrożenia i 90% ruchu przechodzącego do niebieskiego wdrożenia.

Diagram przedstawiający punkt końcowy dzielący ruch do dwóch wdrożeń.

Dublowanie ruchu do wdrożeń online

Punkt końcowy może również dublować (lub kopiować) ruch z jednego wdrożenia do innego wdrożenia. Dublowanie ruchu (nazywane również testowaniem w tle) jest przydatne, gdy chcesz przetestować nowe wdrożenie z ruchem produkcyjnym bez wpływu na wyniki otrzymywane przez klientów z istniejących wdrożeń. Na przykład podczas implementowania wdrożenia niebieskiego/zielonego, w którym 100% ruchu jest kierowane do niebieskiego, a 10% jest dublowane do zielonego wdrożenia, wyniki dublowanego ruchu do zielonego wdrożenia nie są zwracane do klientów, ale metryki i dzienniki są rejestrowane.

Diagram przedstawiający ruch dublujący punkt końcowy do wdrożenia.

Aby dowiedzieć się, jak używać funkcji dublowania ruchu, zobacz Sejf wdrażanie punktów końcowych online.

Więcej możliwości punktów końcowych online w usłudze Azure Machine Edukacja

Uwierzytelnianie i szyfrowanie

  • Uwierzytelnianie: klucz i tokeny usługi Azure Machine Edukacja
  • Tożsamość zarządzana: przypisano użytkownika i przypisano system
  • Protokół SSL domyślnie dla wywołania punktu końcowego

Skalowanie automatyczne

Automatyczne skalowanie uruchamia odpowiednią ilość zasobów na potrzeby obsługi obciążenia aplikacji. Zarządzane punkty końcowe obsługują skalowanie automatyczne za pośrednictwem integracji z funkcją automatycznego skalowania usługi Azure Monitor. Można skonfigurować skalowanie oparte na metrykach (na przykład użycie >procesora CPU 70%), skalowanie oparte na harmonogramie (na przykład reguły skalowania dla godzin pracy szczytu) lub kombinację.

Zrzut ekranu przedstawiający elastyczne skalowanie między minimalną a maksymalną skalę wystąpieniami w zależności od reguł.

Aby dowiedzieć się, jak skonfigurować skalowanie automatyczne, zobacz Jak skalować automatyczne punkty końcowe online.

Izolacja sieci zarządzanej

Podczas wdrażania modelu uczenia maszynowego w zarządzanym punkcie końcowym online można zabezpieczyć komunikację z punktem końcowym online przy użyciu prywatnych punktów końcowych.

Zabezpieczenia dla żądań oceniania ruchu przychodzącego i komunikacji wychodzącej można skonfigurować oddzielnie z obszarem roboczym i innymi usługami. Komunikacja przychodząca używa prywatnego punktu końcowego obszaru roboczego usługi Azure Machine Edukacja. Komunikacja wychodząca używa prywatnych punktów końcowych utworzonych dla zarządzanej sieci wirtualnej obszaru roboczego.

Aby uzyskać więcej informacji, zobacz Izolacja sieciowa z zarządzanymi punktami końcowymi online.

Monitorowanie punktów końcowych i wdrożeń online

Monitorowanie punktów końcowych usługi Azure Machine Edukacja jest możliwe za pośrednictwem integracji z usługą Azure Monitor. Ta integracja umożliwia wyświetlanie metryk na wykresach, konfigurowanie alertów, wykonywanie zapytań z tabel dzienników, używanie Szczegółowe informacje aplikacji do analizowania zdarzeń z kontenerów użytkowników itd.

  • Metryki: użyj usługi Azure Monitor, aby śledzić różne metryki punktów końcowych, takie jak opóźnienie żądania, i przechodzenie do szczegółów na poziomie wdrożenia lub stanu. Możesz również śledzić metryki na poziomie wdrożenia, takie jak użycie procesora CPU/procesora GPU i przechodzenie do szczegółów na poziomie wystąpienia. Usługa Azure Monitor umożliwia śledzenie tych metryk na wykresach oraz konfigurowanie pulpitów nawigacyjnych i alertów w celu dalszej analizy.

  • Dzienniki: wysyłaj metryki do obszaru roboczego usługi Log Analytics, w którym można wykonywać zapytania dotyczące dzienników przy użyciu składni zapytań Kusto. Możesz również wysyłać metryki do konta magazynu i/lub usługi Event Hubs w celu dalszego przetwarzania. Ponadto można używać dedykowanych tabel dzienników dla zdarzeń związanych z punktami końcowymi online, ruchu i dzienników kontenerów. Zapytanie Kusto umożliwia złożoną analizę łączącą wiele tabel.

  • Application Insights: środowiska nadzorowane obejmują integrację z usługą Application Szczegółowe informacje i można ją włączyć/wyłączyć podczas tworzenia wdrożenia online. Wbudowane metryki i dzienniki są wysyłane do usługi Application Insights i można używać wbudowanych funkcji, takich jak metryki na żywo, wyszukiwanie transakcji, niepowodzenia i wydajność w celu dalszej analizy.

Aby uzyskać więcej informacji na temat monitorowania, zobacz Monitorowanie punktów końcowych online.

Wstrzykiwanie wpisów tajnych we wdrożeniach online (wersja zapoznawcza)

Wstrzyknięcie wpisu tajnego w kontekście wdrożenia online to proces pobierania wpisów tajnych (takich jak klucze interfejsu API) z magazynów wpisów tajnych i wstrzykiwania ich do kontenera użytkownika działającego wewnątrz wdrożenia online. Wpisy tajne będą w końcu dostępne za pośrednictwem zmiennych środowiskowych, zapewniając bezpieczny sposób na ich użycie przez serwer wnioskowania, na którym jest uruchamiany skrypt oceniania lub przez stos wnioskowania, który jest używany przy użyciu metody wdrażania BYOC (bring your own container).

Istnieją dwa sposoby wstrzykiwania wpisów tajnych. Możesz samodzielnie wstrzyknąć wpisy tajne przy użyciu tożsamości zarządzanych lub użyć funkcji iniekcji wpisu tajnego. Aby dowiedzieć się więcej o sposobach wstrzykiwania wpisów tajnych, zobacz Wstrzykiwanie wpisów tajnych w punktach końcowych online (wersja zapoznawcza).

Następne kroki