Udostępnij za pośrednictwem

Wdrażanie modeli niestandardowych

  • Artykuł

W tym artykule opisano obsługę wdrażania modelu niestandardowego przy użyciu usługi Mozaika AI Model Serving. Zawiera również szczegółowe informacje o obsługiwanych opcjach rejestrowania modeli i typach obliczeniowych, sposobie tworzenia pakietów zależności modelu na potrzeby obsługi oraz tworzenia i skalowania punktów końcowych.

Co to są modele niestandardowe?

Obsługa modeli może wdrażać dowolny model języka Python jako interfejs API klasy produkcyjnej. Usługa Databricks odnosi się do takich modeli jak modele niestandardowe. Te modele uczenia maszynowego można wytrenować przy użyciu standardowych bibliotek uczenia maszynowego, takich jak scikit-learn, XGBoost, PyTorch i HuggingFace, i mogą zawierać dowolny kod języka Python.

Aby wdrożyć model niestandardowy,

  1. Zarejestruj model lub kod w formacie MLflow przy użyciu natywnych wbudowanych smaków MLflow lub pyfunc.
  2. Po zarejestrowaniu modelu zarejestruj go w wykazie aparatu Unity (zalecane) lub rejestrze obszarów roboczych.
  3. W tym miejscu możesz utworzyć punkt końcowy obsługujący model w celu wdrożenia modelu i wykonywania zapytań względem modelu.
    1. Zobacz Tworzenie niestandardowych punktów końcowych obsługujących model
    2. Zobacz Tworzenie zapytań obsługujących punkty końcowe dla modeli niestandardowych.

Aby zapoznać się z kompletnym samouczkiem dotyczącym obsługi modeli niestandardowych w usłudze Databricks, zobacz Samouczek dotyczący obsługi modeli.

Usługa Databricks obsługuje również obsługę modeli podstawowych dla generowania aplikacji sztucznej inteligencji, zobacz Podstawowe interfejsy API modelu i modele zewnętrzne dla obsługiwanych modeli i ofert obliczeniowych.

Ważne

Jeśli korzystasz z platformy Anaconda, zapoznaj się z warunkami świadczenia usługi , aby uzyskać dodatkowe informacje.

Modele uczenia maszynowego w dzienniku

Istnieją różne metody rejestrowania modelu uczenia maszynowego na potrzeby obsługi modeli. Poniższa lista zawiera podsumowanie obsługiwanych metod i przykładów.

  • Automatyczne rejestrowanie Ta metoda jest automatycznie włączona podczas korzystania z środowiska Databricks Runtime dla uczenia maszynowego.

    import mlflow
from sklearn.ensemble import RandomForestRegressor
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestRegressor()
model.fit(iris.data, iris.target)

  • Zaloguj się przy użyciu wbudowanych smaków platformy MLflow. Tej metody można użyć, jeśli chcesz ręcznie zarejestrować model w celu uzyskania bardziej szczegółowej kontroli.

    import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestClassifier()
model.fit(iris.data, iris.target)

with mlflow.start_run():
    mlflow.sklearn.log_model(model, "random_forest_classifier")

  • Rejestrowanie niestandardowe za pomocą polecenia pyfunc. Tej metody można użyć do wdrażania dowolnych modeli kodu w języku Python lub wdrażania dodatkowego kodu obok modelu.

      import mlflow
  import mlflow.pyfunc

  class Model(mlflow.pyfunc.PythonModel):
      def predict(self, context, model_input):
          return model_input * 2

  with mlflow.start_run():
      mlflow.pyfunc.log_model("custom_model", python_model=Model())

  • Pobierz z witryny HuggingFace. Model można pobrać bezpośrednio z obszaru Przytulanie twarzy i rejestrowania tego modelu do obsługi. Przykłady można znaleźć w temacie Przykłady notesów.

Przykłady podpisów i danych wejściowych

Zalecane jest dodanie przykładu podpisu i danych wejściowych do biblioteki MLflow. Podpisy są niezbędne do rejestrowania modeli w wykazie aparatu Unity.

Poniżej przedstawiono przykład podpisu:

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

Oto przykład danych wejściowych:


input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Typ środowiska obliczeniowego

Uwaga

Obsługa modelu procesora GPU jest dostępna w publicznej wersji zapoznawczej.

Obsługa modelu mozaiki sztucznej inteligencji udostępnia różne opcje procesora CPU i procesora GPU na potrzeby wdrażania modelu. Podczas wdrażania przy użyciu procesora GPU niezbędne jest upewnienie się, że kod został skonfigurowany tak, aby przewidywania działały na procesorze GPU przy użyciu metod dostarczonych przez platformę. Rozwiązanie MLflow wykonuje to automatycznie w przypadku modeli zarejestrowanych przy użyciu smaków PyTorch lub Transformers.

typ obciążenia Wystąpienie procesora GPU pamięć
CPU 4 GB na współbieżność
GPU_SMALL 1xT4 16 GB
GPU_LARGE 1xA100 80 GB
GPU_LARGE_2 2xA100 160 GB

Kontener wdrażania i zależności

Podczas wdrażania kontener klasy produkcyjnej jest kompilowany i wdrażany jako punkt końcowy. Ten kontener zawiera biblioteki przechwycone automatycznie lub określone w modelu MLflow.

Kontener obsługujący model nie zawiera wstępnie zainstalowanych zależności, co może prowadzić do błędów zależności, jeśli nie wszystkie wymagane zależności są uwzględnione w modelu. W przypadku problemów z wdrażaniem modelu usługa Databricks zaleca testowanie modelu lokalnie.

Zależności pakietów i kodu

Niestandardowe lub prywatne biblioteki można dodać do wdrożenia. Zobacz Używanie niestandardowych bibliotek języka Python z obsługą modelu.

W przypadku modeli natywnych smaków MLflow wymagane zależności pakietów są automatycznie przechwytywane.

W przypadku modeli niestandardowych pyfunc można jawnie dodać zależności.

Zależności pakietów można dodawać przy użyciu:

  • Parametr pip_requirements :

    mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])

  • Parametr conda_env :

    
conda_env = {
    'channels': ['defaults'],
    'dependencies': [
        'python=3.7.0',
        'scikit-learn=0.21.3'
    ],
    'name': 'mlflow-env'
}

mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)

  • Aby uwzględnić dodatkowe wymagania wykraczające poza to, co jest przechwytywane automatycznie, użyj polecenia extra_pip_requirements.

    mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])

Jeśli masz zależności kodu, można je określić przy użyciu polecenia code_path.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Walidacja zależności

Przed wdrożeniem niestandardowego modelu MLflow warto sprawdzić, czy model jest w stanie obsłużyć. Platforma MLflow udostępnia interfejs API, który umożliwia walidację artefaktu modelu, który zarówno symuluje środowisko wdrażania, jak i umożliwia testowanie zmodyfikowanych zależności.

Istnieją dwa interfejsy API sprawdzania poprawności przed wdrożeniem interfejsu API języka Python MLflow i interfejs wiersza polecenia platformy MLflow.

Możesz określić następujące elementy przy użyciu jednego z tych interfejsów API.

  • Model model_uri wdrożony w usłudze modelowej.
  • Jedną z następujących czynności:
    • Wartość input_data w oczekiwanym formacie wywołania mlflow.pyfunc.PyFuncModel.predict() modelu.
    • Element input_path definiujący plik zawierający dane wejściowe, które zostaną załadowane i użyte do wywołania metody predict.
  • Format content_type lub json w formacie csv .
  • Opcjonalne output_path zapisywanie przewidywań w pliku. Jeśli ten parametr zostanie pominięty, przewidywania zostaną wydrukowane na .stdout
  • Menedżer środowiska , env_managersłużący do kompilowania środowiska do obsługi:
    • Wartość domyślna to virtualenv. Zalecane do sprawdzania poprawności.
    • local jest dostępny, ale potencjalnie podatny na błąd służący do sprawdzania poprawności. Ogólnie używane tylko do szybkiego debugowania.
  • Czy zainstalować bieżącą wersję biblioteki MLflow, która znajduje się w twoim środowisku przy użyciu środowiska wirtualnego przy użyciu polecenia install_mlflow. To ustawienie jest domyślnie ustawione na False.
  • Czy zaktualizować i przetestować różne wersje zależności pakietów na potrzeby rozwiązywania problemów lub debugowania. Można to określić jako listę przesłonięć lub dodatków zależności ciągów przy użyciu argumentu zastąpienia, pip_requirements_override.

Na przykład:

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Aktualizacje zależności

Jeśli występują jakiekolwiek problemy z zależnościami określonymi przy użyciu zarejestrowanego modelu, możesz zaktualizować wymagania przy użyciu interfejsu wiersza polecenia platformy MLflow lub mlflow.models.model.update_model_requirements() interfejsu API języka Python th MLflow bez konieczności rejestrowania innego modelu.

W poniższym przykładzie pokazano, jak zaktualizować pip_requirements.txt zarejestrowany model w miejscu.

Istniejące definicje można zaktualizować przy użyciu określonych wersji pakietu lub dodać do pliku nieistniejące wymagania pip_requirements.txt . Ten plik znajduje się w artefaktie modelu MLflow w określonej model_uri lokalizacji.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

Oczekiwania i ograniczenia

W poniższych sekcjach opisano znane oczekiwania i ograniczenia dotyczące obsługi modeli niestandardowych przy użyciu obsługi modelu.

Oczekiwania dotyczące tworzenia i aktualizowania punktu końcowego

Uwaga

Informacje przedstawione w tej sekcji nie dotyczą punktów końcowych obsługujących modele podstawowe.

Wdrożenie nowo zarejestrowanej wersji modelu obejmuje pakowanie modelu i jego środowiska modelu oraz aprowizowanie samego punktu końcowego modelu. Ten proces może potrwać około 10 minut.

Usługa Azure Databricks wykonuje aktualizację punktów końcowych bez przestojów, utrzymując istniejącą konfigurację punktu końcowego do momentu, aż nowy stanie się gotowy. Zmniejsza to ryzyko przerw w działaniu punktów końcowych, które są używane.

Jeśli obliczanie modelu trwa dłużej niż 120 sekund, żądania upłynął limit czasu. Jeśli uważasz, że obliczenia modelu potrwają dłużej niż 120 sekund, skontaktuj się z zespołem konta usługi Azure Databricks.

Usługa Databricks wykonuje okazjonalne aktualizacje systemu bez przestojów i konserwację istniejących punktów końcowych obsługujących model. Podczas konserwacji usługa Databricks ponownie ładuje modele i oznacza punkt końcowy jako Niepowodzenie, jeśli nie można ponownie załadować modelu. Upewnij się, że dostosowane modele są niezawodne i można je ponownie załadować w dowolnym momencie.

Oczekiwania dotyczące skalowania punktu końcowego

Uwaga

Informacje przedstawione w tej sekcji nie dotyczą punktów końcowych obsługujących modele podstawowe.

Automatyczne skalowanie punktów końcowych na podstawie ruchu i pojemności aprowizowanych jednostek współbieżności.

  • Aprowizowana współbieżność: maksymalna liczba żądań równoległych, które może obsłużyć system. Szacowanie wymaganej współbieżności przy użyciu formuły: aprowizowana współbieżność = zapytania na sekundę (QPS) * czas wykonywania modelu (s).
  • Zachowanie skalowania: Punkty końcowe są skalowane w górę niemal natychmiast ze zwiększonym ruchem i skalują w dół co pięć minut, aby dopasować do mniejszego ruchu.
  • Skalowanie do zera: punkty końcowe mogą być skalowane w dół do zera po 30 minutach braku aktywności. Pierwsze żądanie po skalowaniu do zera doświadcza "zimnego startu", co prowadzi do większego opóźnienia. W przypadku aplikacji wrażliwych na opóźnienia należy rozważyć strategie efektywnego zarządzania tą funkcją.

Ograniczenia obciążenia procesora GPU

Poniżej przedstawiono ograniczenia dotyczące obsługi punktów końcowych z obciążeniami procesora GPU:

  • Tworzenie obrazu kontenera na potrzeby obsługi procesora GPU trwa dłużej niż tworzenie obrazu dla obsługi procesora CPU z powodu rozmiaru modelu i zwiększonych wymagań dotyczących instalacji modeli obsługiwanych na procesorze GPU.
  • Podczas wdrażania bardzo dużych modeli proces wdrażania może przekroczyć limit czasu, jeśli kompilacja kontenera i wdrożenie modelu przekraczają 60-minutowy czas trwania. W takim przypadku inicjowanie ponawiania procesu powinno pomyślnie wdrożyć model.
  • Skalowanie automatyczne dla obsługi procesora GPU trwa dłużej niż w przypadku obsługi procesora CPU.
  • Pojemność procesora GPU nie jest gwarantowana podczas skalowania do zera. Punkty końcowe procesora GPU mogą oczekiwać dodatkowego dużego opóźnienia dla pierwszego żądania po skalowaniu do zera.
  • Ta funkcja nie jest dostępna w programie northcentralus.

Aktualizacja licencjonowania rozwiązania Anaconda

Poniższe powiadomienie dotyczy klientów korzystających z platformy Anaconda.

Ważne

Anaconda Inc. zaktualizowała swoje warunki świadczenia usług dla kanałów anaconda.org. Na podstawie nowych warunków świadczenia usług możesz wymagać licencji komercyjnej, jeśli korzystasz z opakowania i dystrybucji anaconda. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące wersji komercyjnej Anaconda. Korzystanie z jakichkolwiek kanałów Anaconda podlega warunkom świadczenia usług.

Modele MLflow zarejestrowane przed wersją 1.18 (Databricks Runtime 8.3 ML lub starsze) były domyślnie rejestrowane przy użyciu kanału Conda defaults (https://repo.anaconda.com/pkgs/) jako zależności. Ze względu na tę zmianę licencji usługa Databricks zatrzymała korzystanie z kanału defaults dla modeli zarejestrowanych przy użyciu platformy MLflow w wersji 1.18 lub nowszej. Zarejestrowany kanał domyślny to teraz conda-forge, co wskazuje na zarządzaną https://conda-forge.org/przez społeczność.

Jeśli zarejestrowano model przed MLflow w wersji 1.18 bez wykluczania defaults kanału ze środowiska conda dla modelu, ten model może mieć zależność od kanału defaults , którego być może nie zamierzasz. Aby ręcznie potwierdzić, czy model ma tę zależność, możesz sprawdzić channel wartość w conda.yaml pliku spakowanym przy użyciu zarejestrowanego modelu. Na przykład model conda.yaml z zależnością kanału defaults może wyglądać następująco:

channels:
- defaults
dependencies:
- python=3.8.8
- pip
- pip:
    - mlflow
    - scikit-learn==0.23.2
    - cloudpickle==1.6.0
      name: mlflow-env

Ponieważ usługa Databricks nie może określić, czy korzystanie z repozytorium Anaconda do interakcji z modelami jest dozwolone w ramach relacji z platformą Anaconda, usługa Databricks nie zmusza swoich klientów do wprowadzania żadnych zmian. Jeśli korzystanie z repozytorium Anaconda.com za pośrednictwem korzystania z usługi Databricks jest dozwolone zgodnie z warunkami platformy Anaconda, nie musisz podejmować żadnych działań.

Jeśli chcesz zmienić kanał używany w środowisku modelu, możesz ponownie zarejestrować model w rejestrze modeli przy użyciu nowego conda.yamlelementu . Można to zrobić, określając kanał w parametrze conda_envlog_model().

Aby uzyskać więcej informacji na temat interfejsu log_model() API, zobacz dokumentację platformy MLflow dotyczącą odmiany modelu, z którą pracujesz, na przykład log_model dla biblioteki scikit-learn.

Aby uzyskać więcej informacji na conda.yaml temat plików, zobacz dokumentację platformy MLflow.

Dodatkowe zasoby