Wdrażanie modeli niestandardowych

2025-04-30

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 jako 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,

Zarejestruj model lub kod w formacie MLflow, używając natywnych wbudowanych wariantów MLflow lub pyfunc.
Po zarejestrowaniu modelu zarejestruj go w wykazie aparatu Unity (zalecane) lub rejestrze obszarów roboczych.
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 Punkty końcowe obsługujące zapytania 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ż modele podstawowe do generatywnych aplikacji sztucznej inteligencji; zobacz Interfejsy API modeli podstawowych 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łączana 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)

Rejestruj operacje przy użyciu wbudowanych formatów 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 z użyciem 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

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 należy upewnić się, że kod został skonfigurowany, 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 do sprawdzania poprawności przed wdrożeniem: API języka Python MLflow i CLI 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 csv w formacie json .
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 poleceniaAPI 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 ani modele zewnętrzne.

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 ani modele zewnętrzne.

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 po zwiększeniu ruchu oraz zmniejszane co pięć minut, aby dopasować się do mniejszego ruchu.
Skalowanie do zera: Punkty końcowe mogą być skalowane w dół do zera po upływie 30 minut 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 należy zainicjować ponowną próbę procesu. Ponowne próby powinny 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 użytkowania usług dla kanałów anaconda.org. Na podstawie nowych warunków świadczenia usług może być konieczne uzyskanie licencji komercyjnej, jeśli polegasz na pakietowaniu 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.

Udostępnij za pośrednictwem