Wskazówki dotyczące wdrażania modeli MLflow
DOTYCZY: Rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji 2 (bieżąca)
W tym artykule dowiesz się więcej o wdrażaniu modeli MLflow w usłudze Azure Machine Edukacja na potrzeby wnioskowania w czasie rzeczywistym i wsadowego. Dowiedz się również o różnych narzędziach, których można użyć do zarządzania wdrożeniem.
Wdrażanie modeli MLflow a modeli niestandardowych
W przeciwieństwie do wdrażania modelu niestandardowego w usłudze Azure Machine Edukacja podczas wdrażania modeli MLflow na maszynie azure Edukacja nie trzeba udostępniać skryptu oceniania ani środowiska do wdrożenia. Zamiast tego usługa Azure Machine Edukacja automatycznie generuje skrypt oceniania i środowisko. Ta funkcja jest nazywana wdrożeniem bez kodu.
W przypadku wdrożenia bez kodu usługa Azure Machine Edukacja:
- Gwarantuje, że wszystkie zależności pakietów wskazane w modelu MLflow są spełnione.
- Udostępnia obraz podstawowy MLflow lub wyselekcjonowane środowisko zawierające następujące elementy:
- Pakiety wymagane przez usługę Azure Machine Edukacja do wnioskowania, w tym
mlflow-skinny
. - Skrypt oceniania do wykonania wnioskowania.
- Pakiety wymagane przez usługę Azure Machine Edukacja do wnioskowania, w tym
Napiwek
Obszary robocze bez dostępu do sieci publicznej: przed wdrożeniem modeli MLflow w punktach końcowych online bez łączności wychodzącej należy spakować modele (wersja zapoznawcza). Korzystając z tworzenia pakietów modeli, można uniknąć potrzeby połączenia internetowego, którego usługa Azure Machine Edukacja w przeciwnym razie wymagałaby dynamicznego instalowania niezbędnych pakietów języka Python dla modeli MLflow.
Pakiety i zależności języka Python
Usługa Azure Machine Edukacja automatycznie generuje środowiska do uruchamiania wnioskowania na modelach MLflow. Aby skompilować środowiska, usługa Azure Machine Edukacja odczytuje zależności conda określone w modelu MLflow i dodaje wszystkie pakiety wymagane do uruchomienia serwera wnioskowania. Te dodatkowe pakiety różnią się w zależności od typu wdrożenia.
Poniższy plik conda.yaml przedstawia przykład zależności conda określonych w modelu MLflow.
conda.yaml
channels:
- conda-forge
dependencies:
- python=3.10.11
- pip<=23.1.2
- pip:
- mlflow==2.7.1
- cloudpickle==1.6.0
- dataclasses==0.6
- lz4==4.0.0
- numpy==1.23.5
- packaging==23.0
- psutil==5.9.0
- pyyaml==6.0
- scikit-learn==1.1.2
- scipy==1.10.1
- uuid==1.30
name: mlflow-env
Ostrzeżenie
Narzędzie MLflow automatycznie wykrywa pakiety podczas rejestrowania modelu i przypina wersje pakietów w zależnościach conda modelu. Jednak to automatyczne wykrywanie pakietów może nie zawsze odzwierciedlać twoje intencje lub wymagania. W takich przypadkach rozważ rejestrowanie modeli z niestandardową definicją zależności conda.
Implikacje dotyczące używania modeli z podpisami
Modele MLflow mogą zawierać podpis, który wskazuje oczekiwane dane wejściowe i ich typy. Gdy takie modele są wdrażane w punktach końcowych online lub wsadowych, usługa Azure Machine Edukacja wymusza, że liczba i typy danych wejściowych są zgodne z podpisem. Jeśli nie można przeanalizować danych wejściowych zgodnie z oczekiwaniami, wywołanie modelu zakończy się niepowodzeniem.
Możesz sprawdzić podpis modelu MLflow, otwierając plik MLmodel skojarzony z modelem. Aby uzyskać więcej informacji na temat sposobu działania podpisów w usłudze MLflow, zobacz Podpisy w usłudze MLflow.
Poniższy plik przedstawia plik MLmodel skojarzony z modelem MLflow.
Model ML
artifact_path: model
flavors:
python_function:
env:
conda: conda.yaml
virtualenv: python_env.yaml
loader_module: mlflow.sklearn
model_path: model.pkl
predict_fn: predict
python_version: 3.10.11
sklearn:
code: null
pickled_model: model.pkl
serialization_format: cloudpickle
sklearn_version: 1.1.2
mlflow_version: 2.7.1
model_uuid: 3f725f3264314c02808dd99d5e5b2781
run_id: 70f15bab-cf98-48f1-a2ea-9ad2108c28cd
signature:
inputs: '[{"name": "age", "type": "double"}, {"name": "sex", "type": "double"},
{"name": "bmi", "type": "double"}, {"name": "bp", "type": "double"}, {"name":
"s1", "type": "double"}, {"name": "s2", "type": "double"}, {"name": "s3", "type":
"double"}, {"name": "s4", "type": "double"}, {"name": "s5", "type": "double"},
{"name": "s6", "type": "double"}]'
outputs: '[{"type": "double"}]'
Napiwek
Podpisy w modelach MLflow są opcjonalne, ale zdecydowanie zalecane, ponieważ zapewniają wygodny sposób wczesnego wykrywania problemów ze zgodnością danych. Aby uzyskać więcej informacji na temat rejestrowania modeli przy użyciu podpisów, zobacz Rejestrowanie modeli z podpisem niestandardowym, środowiskiem lub przykładami.
Modele wdrożone na platformie Azure Machine Edukacja a modele wdrożone na wbudowanym serwerze MLflow
Rozwiązanie MLflow zawiera wbudowane narzędzia wdrażania, których deweloperzy modelu mogą używać do lokalnego testowania modeli. Na przykład można uruchomić lokalne wystąpienie modelu zarejestrowanego w rejestrze serwerów MLflow przy użyciu mlflow models serve -m my_model
interfejsu wiersza polecenia platformy MLflow lub za pomocą interfejsu wiersza polecenia mlflow models predict
platformy MLflow.
Wnioskowanie za pomocą punktów końcowych wsadowych a punktów końcowych online
Usługa Azure Machine Edukacja obsługuje wdrażanie modeli zarówno w punktach końcowych online, jak i wsadowych. Te punkty końcowe uruchamiają różne technologie wnioskowania, które mogą mieć różne funkcje.
Punkty końcowe online są podobne do wbudowanego serwera MLflow, który zapewnia skalowalny, synchroniczny i lekki sposób uruchamiania modeli na potrzeby wnioskowania.
Z drugiej strony punkty końcowe wsadowe mogą uruchamiać asynchroniczne wnioskowanie w przypadku długotrwałych procesów wnioskowania, które mogą być skalowane do dużych ilości danych. Serwer MLflow obecnie nie ma tej możliwości, chociaż można osiągnąć podobną funkcję przy użyciu zadań platformy Spark. Aby dowiedzieć się więcej na temat punktów końcowych wsadowych i modeli MLflow, zobacz Używanie modeli MLflow we wdrożeniach wsadowych.
Poniższe sekcje koncentrują się bardziej na modelach platformy MLflow wdrożonych w usłudze Azure Machine Edukacja punktach końcowych online.
Formaty danych wejściowych
Input type | Wbudowany serwer MLflow | Punkty końcowe usługi Azure Machine Edukacja Online |
---|---|---|
JSON serializowane ramki danych pandas w orientacji podzielonej | ✓ | ✓ |
JSON serializowane ramki danych pandas w orientacji rekordów | Przestarzały | |
Ramki danych biblioteki pandas serializowane w formacie CSV | ✓ | Używanie partii1 |
Format wejściowy tensor jako listy serializowane w formacie JSON (tensor) i słownik list (nazwanych tensor) | ✓ | ✓ |
Dane wejściowe tensor sformatowane jako w interfejsie API obsługi serwera TF | ✓ |
1 Rozważ użycie wnioskowania wsadowego do przetwarzania plików. Aby uzyskać więcej informacji, zobacz Wdrażanie modeli MLflow w punktach końcowych wsadowych.
Struktura danych wejściowych
Niezależnie od używanego typu danych wejściowych usługa Azure Machine Edukacja wymaga podania danych wejściowych w ładunku JSON w kluczu input_data
słownika . Ponieważ ten klucz nie jest wymagany w przypadku używania polecenia mlflow models serve
do obsługi modeli, ładunki nie mogą być używane zamiennie dla punktów końcowych online usługi Azure Machine Edukacja i wbudowanego serwera MLflow.
Ważne
Porady dotyczące platformy MLflow 2.0: Zwróć uwagę, że struktura ładunku zmieniła się w rozwiązaniu MLflow 2.0.
W tej sekcji przedstawiono różne przykłady ładunków i różnice dotyczące modelu wdrożonego na wbudowanym serwerze MLflow w porównaniu z serwerem wnioskowania usługi Azure Machine Edukacja.
Przykład ładunku dla ramki danych pandas serializowanej w formacie JSON w orientacji podzielonej
{
"input_data": {
"columns": [
"age", "sex", "trestbps", "chol", "fbs", "restecg", "thalach", "exang", "oldpeak", "slope", "ca", "thal"
],
"index": [1],
"data": [
[1, 1, 145, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
]
}
}
Przykład ładunku dla danych wejściowych tensor
{
"input_data": [
[1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2],
[1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
[1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2],
[1, 1, 145, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
]
}
Przykład ładunku dla danych wejściowych o nazwie-tensor
{
"input_data": {
"tokens": [
[0, 655, 85, 5, 23, 84, 23, 52, 856, 5, 23, 1]
],
"mask": [
[0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0]
]
}
}
Aby uzyskać więcej informacji na temat wbudowanych narzędzi wdrażania MLflow, zobacz Wbudowane narzędzia wdrażania w dokumentacji platformy MLflow.
Dostosowywanie wnioskowania podczas wdrażania modeli MLflow
Tworzenie skryptów oceniania może służyć do dostosowywania sposobu wykonywania wnioskowania dla modeli niestandardowych. Jednak podczas wdrażania modeli MLflow w usłudze Azure Machine Edukacja decyzja o sposobie wykonywania wnioskowania jest wykonywana przez konstruktora modelu (osobę, która utworzyła model), a nie przez inżyniera DevOps (osobę, która próbuje go wdrożyć). Każda struktura modelu może automatycznie stosować określone procedury wnioskowania.
Jeśli w dowolnym momencie musisz zmienić sposób wykonywania wnioskowania modelu MLflow, możesz wykonać jedną z dwóch czynności:
- Zmień sposób rejestrowania modelu w procedurze trenowania.
- Dostosowywanie wnioskowania za pomocą skryptu oceniania w czasie wdrażania.
Zmienianie sposobu rejestrowania modelu podczas trenowania
Podczas rejestrowania modelu przy użyciu metody mlflow.autolog
lub mlflow.<flavor>.log_model
, smak używany dla modelu decyduje o tym, jak należy wykonać wnioskowanie i jakie wyniki zwraca model. Rozwiązanie MLflow nie wymusza żadnego konkretnego zachowania w zakresie generowania wyników przez predict()
funkcję.
W niektórych przypadkach jednak warto wykonać wstępne przetwarzanie lub przetwarzanie końcowe przed wykonaniem modelu i po jego wykonaniu. Czasami warto zmienić zwracaną wartość (na przykład prawdopodobieństwa i klasy). Jednym z rozwiązań jest zaimplementowanie potoków uczenia maszynowego, które przechodzą bezpośrednio z danych wejściowych do danych wyjściowych. Na przykład sklearn.pipeline.Pipeline
lub pyspark.ml.Pipeline
są popularnymi sposobami implementowania potoków i czasami są zalecane do rozważenia wydajności. Inną alternatywą jest dostosowanie sposobu wnioskowania modelu przy użyciu niestandardowego smaku modelu.
Dostosowywanie wnioskowania za pomocą skryptu oceniania
Mimo że modele MLflow nie wymagają skryptu oceniania, nadal można go podać, jeśli jest to konieczne. Możesz użyć skryptu oceniania, aby dostosować sposób wykonywania wnioskowania dla modeli MLflow. Aby uzyskać więcej informacji na temat dostosowywania wnioskowania, zobacz Dostosowywanie wdrożeń modelu MLflow (punktów końcowych online) i Dostosowywanie wdrożeń modelu MLflow (punktów końcowych wsadowych) .
Ważne
Jeśli zdecydujesz się określić skrypt oceniania dla wdrożenia modelu MLflow, musisz również udostępnić środowisko wdrożenia.
Narzędzia wdrażania
Usługa Azure Machine Edukacja oferuje wiele sposobów wdrażania modeli MLflow w punktach końcowych online i wsadowych. Modele można wdrażać przy użyciu następujących narzędzi:
- MLflow SDK
- Interfejs wiersza polecenia usługi Azure Machine Learning
- Zestaw SDK usługi Azure Machine Learning dla języka Python
- Azure Machine Learning Studio
Każdy przepływ pracy ma różne możliwości, szczególnie w przypadku tego typu obliczeń, które mogą być przeznaczone. W poniższej tabeli przedstawiono różne możliwości.
Scenariusz | MLflow SDK | Interfejs wiersza polecenia/zestaw SDK usługi Azure Machine Edukacja | Azure Machine Learning Studio |
---|---|---|---|
Wdrażanie w zarządzanych punktach końcowych online | Zobacz przykład1 | Zobacz przykład1 | Zobacz przykład1 |
Wdrażanie w zarządzanych punktach końcowych online (za pomocą skryptu oceniania) | Nieobsługiwane3 | Zobacz przykład | Zobacz przykład |
Wdrażanie w punktach końcowych wsadowych | Nieobsługiwane3 | Zobacz przykład | Zobacz przykład |
Wdrażanie w punktach końcowych wsadowych (ze skryptem oceniania) | Nieobsługiwane3 | Zobacz przykład | Zobacz przykład |
Wdrażanie w usługach internetowych (ACI/AKS) | Starsza wersja pomocy technicznej2 | Nieobsługiwane2 | Nieobsługiwane2 |
Wdrażanie w usługach internetowych (ACI/AKS — za pomocą skryptu oceniania) | Nieobsługiwane3 | Starsza wersja pomocy technicznej2 | Starsza wersja pomocy technicznej2 |
1 Wdrożenie do punktów końcowych online, które znajdują się w obszarach roboczych z włączonym łączem prywatnym, wymaga spakowania modeli przed wdrożeniem (wersja zapoznawcza).
2 Zalecamy przełączenie do zarządzanych punktów końcowych online.
3 MLflow (OSS) nie ma pojęcia skryptu oceniania i obecnie nie obsługuje wykonywania wsadowego.
Którego narzędzia wdrażania użyć?
Użyj zestawu SDK platformy MLflow, jeśli mają zastosowanie oba te warunki:
- Znasz platformę MLflow lub używasz platformy obsługującej natywnie platformę MLflow (na przykład Azure Databricks).
- Chcesz nadal używać tego samego zestawu metod z biblioteki MLflow.
Jeśli którykolwiek z tych warunków ma zastosowanie, użyj interfejsu wiersza polecenia usługi Azure Machine Edukacja w wersji 2:
- Znasz już interfejs wiersza polecenia usługi Azure Machine Edukacja w wersji 2.
- Chcesz zautomatyzować wdrożenia przy użyciu potoków automatyzacji.
- Chcesz zachować konfigurację wdrożenia w repozytorium git.
Użyj wdrożenia interfejsu użytkownika usługi Azure Machine Edukacja Studio, jeśli chcesz szybko wdrażać i testować modele trenowane za pomocą platformy MLflow.