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.

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 predictplatformy 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_datasł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ć?