Zależności modelu dzienników

Artykuł
03/25/2024

W tym artykule dowiesz się, jak rejestrować model i jego zależności jako artefakty modelu, dzięki czemu są one dostępne w środowisku dla zadań produkcyjnych, takich jak obsługa modelu.

Zależności modelu pakietów języka Python w dzienniku

Platforma MLflow ma natywną obsługę niektórych bibliotek uczenia maszynowego języka Python, w których platforma MLflow może niezawodnie rejestrować zależności dla modeli korzystających z tych bibliotek. Zobacz wbudowane smaki modelu.

Na przykład biblioteka MLflow obsługuje bibliotekę scikit-learn w module mlflow.sklearn, a polecenie mlflow.sklearn.log_model rejestruje wersję sklearn. Dotyczy to automatycznego rejestrowania przy użyciu tych bibliotek uczenia maszynowego. Aby uzyskać dodatkowe przykłady, zobacz repozytorium github MLflow.

W przypadku bibliotek uczenia maszynowego, które można zainstalować za pomocą pip install PACKAGE_NAME==VERSIONprogramu , ale nie mają wbudowanych wersji modelu MLflow, można rejestrować te pakiety przy użyciu metody mlflow.pyfunc.log_model . Pamiętaj, aby zarejestrować wymagania z dokładną wersją biblioteki, f"nltk=={nltk.__version__}" na przykład zamiast tylko nltk.

mlflow.pyfunc.log_model program obsługuje rejestrowanie dla:

Publiczne i niestandardowe biblioteki spakowane jako pliki python egg lub Python wheel.
Publiczne pakiety na PyPI i prywatnie hostowane pakiety na własnym serwerze PyPI.

W przypadku mlflow.pyfunc.log_model MLflow próbuje automatycznie wywnioskować zależności. Narzędzie MLflow wywnioskuje zależności przy użyciu mlflow.models.infer_pip_requirements i rejestruje je w requirements.txt pliku jako artefakt modelu.

W starszych wersjach biblioteka MLflow czasami nie identyfikuje automatycznie wszystkich wymagań języka Python, zwłaszcza jeśli biblioteka nie jest wbudowaną wersją modelu. W takich przypadkach można określić dodatkowe zależności za pomocą parametru extra_pip_requirements w poleceniu log_model . Zobacz przykład użycia parametru extra_pip_requirements.

Ważne

Można również zastąpić cały zestaw wymagań parametrami conda_env i pip_requirements , ale zazwyczaj jest to zniechęcane, ponieważ zastępuje to zależności, które narzędzie MLflow pobiera automatycznie. Zobacz przykład użycia parametru pip_requirements do zastępowania wymagań.

Rejestrowanie dostosowanego modelu

W przypadku scenariuszy, w których konieczne jest bardziej dostosowane rejestrowanie modeli, można wykonać następujące czynności:

Pisanie niestandardowego modelu języka Python. Dzięki temu można podklasy mlflow.pyfunc.PythonModel dostosować inicjowanie i przewidywanie. Takie podejście dobrze sprawdza się w przypadku dostosowywania modeli tylko w języku Python.
- Aby zapoznać się z prostym przykładem, zobacz przykład dodawania modelu N.
- Bardziej złożony przykład można znaleźć w przykładzie niestandardowego modelu XGBoost.
Napisz niestandardowy smak. W tym scenariuszu można dostosować rejestrowanie bardziej niż ogólny pyfunc smak, ale wymaga to więcej pracy do zaimplementowania.

Niestandardowy kod w języku Python

Być może masz zależności kodu w języku Python, których nie można zainstalować za pomocą %pip install polecenia, takiego jak co najmniej jeden .py plik.

Podczas rejestrowania modelu można poinformować MLflow, że model może znaleźć te zależności w określonej ścieżce przy użyciu parametru code_path w mlflow.pyfunc.log_model. Platforma MLflow przechowuje wszystkie pliki lub katalogi przekazywane przy użyciu code_path jako artefakty wraz z modelem w katalogu kodu. Podczas ładowania modelu platforma MLflow dodaje te pliki lub katalogi do ścieżki języka Python. Ta trasa działa również z niestandardowymi plikami koła języka Python, które można uwzględnić w modelu przy użyciu polecenia code_path, podobnie jak .py pliki.

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Rejestrowanie zależności modelu pakietów innych niż Python

Platforma MLflow nie pobiera automatycznie zależności innych niż Python, takich jak pakiety Języka Java, pakiety języka R i pakiety natywne (takie jak pakiety systemu Linux). W przypadku tych pakietów należy rejestrować dodatkowe dane.

Lista zależności: usługa Databricks zaleca rejestrowanie artefaktu za pomocą modelu określającego te zależności inne niż Python. Może to być prosty plik lub .json prosty.txt. mlflow.pyfunc.log_model umożliwia określenie tego dodatkowego artefaktu przy użyciu argumentu artifacts .
Pakiety niestandardowe: podobnie jak w przypadku niestandardowych zależności języka Python powyżej należy upewnić się, że pakiety są dostępne w środowisku wdrażania. W przypadku pakietów w centralnej lokalizacji, takiej jak Maven Central lub własne repozytorium, upewnij się, że lokalizacja jest dostępna podczas oceniania lub obsługi. W przypadku pakietów prywatnych, które nie są hostowane w innym miejscu, można rejestrować pakiety wraz z modelem jako artefaktami.

Wdrażanie modeli z zależnościami

Podczas wdrażania modelu z serwera śledzenia MLflow lub rejestru modeli należy upewnić się, że środowisko wdrażania ma zainstalowane odpowiednie zależności. Najprostsza ścieżka może zależeć od trybu wdrażania: wsadowego/przesyłania strumieniowego lub obsługującego online oraz od typów zależności.

W przypadku wszystkich trybów wdrażania usługa Databricks zaleca uruchamianie wnioskowania w tej samej wersji środowiska uruchomieniowego, która była używana podczas trenowania, ponieważ środowisko Databricks Runtime, w którym utworzono model, ma już zainstalowane różne biblioteki. Środowisko MLflow w usłudze Databricks automatycznie zapisuje wersję środowiska uruchomieniowego w MLmodel pliku metadanych w databricks_runtime polu, takim jak databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Obsługa online: obsługa modelu usługi Databricks

Usługa Databricks oferuje obsługę modelu, w której modele uczenia maszynowego MLflow są udostępniane jako skalowalne punkty końcowe interfejsu API REST.

W przypadku zależności języka Python w requirements.txt pliku usługa Databricks i MLflow obsługują wszystko dla publicznych zależności PyPI. Podobnie, jeśli podczas rejestrowania modelu określono .py pliki lub pliki wheel języka Python przy użyciu argumentu code_path , narzędzie MLflow ładuje te zależności automatycznie.

W przypadku tych scenariuszy obsługi modeli zobacz następujące kwestie:

Obsługa online: systemy innych firm lub kontenery platformy Docker

Jeśli twój scenariusz wymaga obsługi rozwiązań innych firm lub własnego rozwiązania opartego na platformie Docker, możesz wyeksportować model jako kontener platformy Docker.

Usługa Databricks zaleca następujące elementy w przypadku obsługi innych firm, które automatycznie obsługują zależności języka Python. Jednak w przypadku zależności innych niż Python należy zmodyfikować kontener w celu ich uwzględnienia.

Integracja platformy Docker platformy MLflow dla rozwiązania obsługującego platformę Docker: modele MLflow build-docker
Integracja platformy MLflow z usługą Azure Machine Edukacja:
- Wdrażanie w usłudze Azure Container Instance (ACI)
- Wdrażanie w usłudze Azure Kubernetes Service (AKS)

Zadania usługi Batch i przesyłania strumieniowego

Ocenianie wsadowe i przesyłanie strumieniowe powinno być uruchamiane jako zadania usługi Databricks. Zadanie notesu często wystarczy, a najprostszym sposobem przygotowania kodu jest użycie rejestru modeli usługi Databricks w celu wygenerowania notesu oceniania.

Poniżej opisano proces i kroki, które należy wykonać, aby upewnić się, że zależności są zainstalowane i zastosowane odpowiednio:

Uruchom klaster oceniania przy użyciu tej samej wersji środowiska Databricks Runtime używanej podczas trenowania. Odczytaj databricks_runtimeMLmodel pole z pliku metadanych i uruchom klaster przy użyciu tej wersji środowiska uruchomieniowego.
- Można to zrobić ręcznie w konfiguracji klastra lub zautomatyzować za pomocą logiki niestandardowej. W przypadku automatyzacji format wersji środowiska uruchomieniowego odczytywany z pliku metadanych w interfejsie API zadań i interfejsie API klastrów.
Następnie zainstaluj wszystkie zależności inne niż Python. Aby upewnić się, że zależności inne niż Python są dostępne dla środowiska wdrażania, możesz wykonać następujące czynności:
- Ręcznie zainstaluj zależności innych niż Python modelu w klastrze usługi Databricks w ramach konfiguracji klastra przed uruchomieniem wnioskowania.
- Alternatywnie możesz napisać niestandardową logikę we wdrożeniu zadania oceniania, aby zautomatyzować instalację zależności w klastrze. Przy założeniu, że zależności innych niż Python zostały zapisane jako artefakty zgodnie z opisem w temacie Log non-Python package dependencies (Zależności modelu pakietów innych niż Python), ta automatyzacja może instalować biblioteki przy użyciu interfejsu API bibliotek. Możesz też napisać określony kod w celu wygenerowania skryptu inicjowania w zakresie klastra w celu zainstalowania zależności.
Zadanie oceniania instaluje zależności języka Python w środowisku wykonywania zadania. W usłudze Databricks rejestr modeli umożliwia wygenerowanie notesu na potrzeby wnioskowania, co robi to za Ciebie.
- Gdy używasz rejestru modeli usługi Databricks do generowania notesu oceniania, notes zawiera kod służący do instalowania zależności języka Python w pliku modelu requirements.txt . W przypadku zadania notesu na potrzeby oceniania wsadowego lub przesyłania strumieniowego ten kod inicjuje środowisko notesu, aby zależności modelu zostały zainstalowane i gotowe do użycia w modelu.
Platforma MLflow obsługuje dowolny niestandardowy kod języka Python uwzględniony w parametrze code_path w pliku log_model. Ten kod jest dodawany do ścieżki języka Python po wywołaniu metody modelu predict() . Można to również zrobić ręcznie, wykonując jedną z następujących czynności:
- Wywoływanie mlflow.pyfunc.spark_udf z argumentem env_manager=['virtualenv'/'conda'] .
- Wyodrębnianie wymagań przy użyciu mlflow.pyfunc.get_model_dependencies i instalowanie ich przy użyciu instalacji narzędzia %pip.
Uwaga

Jeśli określone .py pliki lub pliki wheel języka Python podczas rejestrowania modelu przy użyciu argumentu code_path , narzędzie MLflow ładuje te zależności automatycznie.