Omówienie modeli niestandardowych

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

Co to są modele niestandardowe?

Obsługa modelu może wdrażać dowolny model Python lub kod niestandardowy jako interfejs API klasy produkcyjnej przy użyciu zasobów obliczeniowych CPU lub GPU. 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,

1. Zarejestruj model lub kod w formacie MLflow, używając natywnych wbudowanych wariantó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 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.

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.

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. Obraz podstawowy może zawierać pewne zależności na poziomie systemu, ale zależności na poziomie aplikacji muszą być jawnie określone w modelu MLflow.

Jeśli nie wszystkie wymagane zależności są uwzględnione w modelu, podczas wdrażania mogą wystąpić błędy zależności. 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. Aby uzyskać szczegółowe informacje na temat wymagań dotyczących rejestrowania i najlepszych rozwiązań, zobacz dokumentację modeli MLflow i dokumentację interfejsu API języka Python MLflow.

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"],)

Aby uzyskać informacje na temat sprawdzania poprawności i aktualizowania zależności przed wdrożeniem, zobacz Sprawdzanie poprawności przed wdrożeniem dla obsługi modelu.

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

• Czas wdrożenia: 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, ale może trwać dłużej w zależności od złożoności, rozmiaru i zależności modelu.
• Aktualizacje bez przestojów: 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. Podczas tego procesu aktualizacji opłaty są naliczane zarówno za stare, jak i nowe konfiguracje punktu końcowego do momentu zakończenia przejścia.
• Przekroczenie limitu czasu żądania: jeśli obliczanie modelu trwa dłużej niż 297 sekund, żądania zostaną anulowane z powodu przekroczenia limitu czasu.

Oczekiwania dotyczące skalowania punktu końcowego

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). Aby zweryfikować konfigurację współbieżności, zobacz Testowanie obciążenia pod kątem obsługi punktów końcowych.
• 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: Skalowanie do zera to opcjonalna funkcja dla punktów końcowych, która umożliwia skalowanie ich 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. Skalowanie w górę z zera zwykle trwa od 10 do 20 sekund, ale czasami może potrwać kilka minut. Nie ma umowy SLA na dużą skalę z zerowym opóźnieniem.
• Optymalizacja tras: W przypadku przypadków użycia o wysokim poziomie QPS i małych opóźnieniach optymalizacja tras jest optymalną i zalecaną opcją poprawy wydajności.
• Bezserwerowe zoptymalizowane wdrożenia: Aby przyspieszyć wdrażanie punktów końcowych, użyj bezserwerowych zoptymalizowanych wdrożeń.

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 przekroczy 60-minutowy czas trwania lub kompilacja kontenera może zakończyć się niepowodzeniem z powodu błędu "Brak miejsca pozostawionego na urządzeniu" z powodu ograniczeń magazynu. W przypadku dużych modeli językowych zamiast tego użyj interfejsów API modeli bazowych.
• 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.

Powiadomienie o licencjonowaniu rozwiązania Anaconda dla starszych modeli

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

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

Dodatkowe zasoby

• Tworzenie niestandardowych punktów końcowych obsługujących model
• Wykonywanie zapytań dotyczących punktów końcowych dla modeli niestandardowych
• Przewodnik debugowania dotyczący obsługi modeli
• Używanie niestandardowych bibliotek języka Python z obsługą modelu
• Tworzenie pakietów artefaktów niestandardowych na potrzeby obsługi modelu
• Wdrażanie kodu w języku Python przy użyciu usługi Model Serving
• Optymalizacja tras w przypadku obsługi punktów końcowych
• Bezserwerowe zoptymalizowane wdrożenia dla punktów końcowych obsługujących model
• Konfigurowanie dostępu do zasobów z poziomu punktów końcowych obsługujących model