Loggmodellberoenden

I den här artikeln får du lära dig hur du loggar en modell och dess beroenden som modellartefakter, så att de är tillgängliga i din miljö för produktionsaktiviteter som modellservering.

Logga Beroenden för Python-paketmodell

MLflow har inbyggt stöd för vissa Python ML-bibliotek, där MLflow på ett tillförlitligt sätt kan logga beroenden för modeller som använder dessa bibliotek. Se inbyggda modellsmaker.

MLflow stöder till exempel scikit-learn i modulen mlflow.sklearn och kommandot mlflow.sklearn.log_model loggar sklearnversionen. Detsamma gäller för automatisk loggning med dessa ML-bibliotek. Se MLflow github-lagringsplatsen för ytterligare exempel.

Kommentar

För att aktivera spårningsloggning för generativa AI-arbetsbelastningar stöder MLflow automatisk loggning av OpenAI.

För ML-bibliotek som kan installeras med pip install PACKAGE_NAME==VERSION, men som inte har inbyggda MLflow-modellsmaker, kan du logga dessa paket med hjälp av metoden mlflow.pyfunc.log_model . Se till att logga kraven med den exakta biblioteksversionen, till exempel i f"nltk=={nltk.__version__}" stället för bara nltk.

mlflow.pyfunc.log_model stöder loggning för:

• Offentliga och anpassade bibliotek paketerade som Python-ägg- eller Python-hjulfiler.
• Offentliga paket på PyPI och privat värdbaserade paket på din egen PyPI-server.

Med mlflow.pyfunc.log_model försöker MLflow härleda beroendena automatiskt. MLflow härleder beroendena med hjälp av mlflow.models.infer_pip_requirements och loggar dem till en requirements.txt fil som en modellartefakt.

I äldre versioner identifierar MLflow ibland inte alla Python-krav automatiskt, särskilt om biblioteket inte är en inbyggd modellsmak. I dessa fall kan du ange ytterligare beroenden med parametern extra_pip_requirements i log_model kommandot . Se ett exempel på hur du använder parametern extra_pip_requirements.

Viktigt!

Du kan också skriva över hela uppsättningen med krav med parametrarna conda_env och pip_requirements , men det rekommenderas vanligtvis eftersom detta åsidosätter de beroenden som MLflow hämtar automatiskt. Se ett exempel på hur du använder parametern pip_requirements för att skriva över krav.

Anpassad modellloggning

För scenarier där mer anpassad modellloggning krävs kan du antingen:

• Skriv en anpassad Python-modell. På så sätt kan du underklassen mlflow.pyfunc.PythonModel anpassa initiering och förutsägelse. Den här metoden fungerar bra för anpassning av python-modeller.
  • Ett enkelt exempel finns i exemplet lägg till N-modell.
  • Ett mer komplext exempel finns i exemplet med den anpassade XGBoost-modellen.
• Skriv en anpassad smak. I det här scenariot kan du anpassa loggning mer än den allmänna pyfunc smaken, men om du gör det krävs mer arbete för att implementera.

Anpassad Python-kod

Du kan ha Python-kodberoenden som inte kan installeras med kommandot %pip install , till exempel en eller flera .py filer.

När du loggar en modell kan du berätta för MLflow att modellen kan hitta dessa beroenden på en angiven sökväg med hjälp av parametern code_path i mlflow.pyfunc.log_model. MLflow lagrar alla filer eller kataloger som skickas med som code_path artefakter tillsammans med modellen i en kodkatalog. När du läser in modellen lägger MLflow till dessa filer eller kataloger i Python-sökvägen. Den här vägen fungerar också med anpassade Python-hjulfiler, som kan ingå i modellen med , code_pathprecis som .py filer.

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

Logga icke-Python-paketmodellberoenden

MLflow hämtar inte automatiskt icke-Python-beroenden, till exempel Java-paket, R-paket och interna paket (till exempel Linux-paket). För dessa paket måste du logga ytterligare data.

• Beroendelista: Databricks rekommenderar att du loggar en artefakt med modellen som anger dessa icke-Python-beroenden. Det kan vara en enkel .txt fil eller .json fil. mlflow.pyfunc.log_model kan du ange den här ytterligare artefakten med argumentet artifacts .
• Anpassade paket: Precis som för anpassade Python-beroenden ovan måste du se till att paketen är tillgängliga i distributionsmiljön. För paket på en central plats, till exempel Maven Central eller din egen lagringsplats, kontrollerar du att platsen är tillgänglig vid bedömning eller serveringstid. För privata paket som inte finns någon annanstans kan du logga paket tillsammans med modellen som artefakter.

Distribuera modeller med beroenden

När du distribuerar en modell från MLflow Tracking Server eller Model Registry måste du se till att distributionsmiljön har rätt beroenden installerade. Den enklaste sökvägen kan bero på ditt distributionsläge: batch/streaming eller online-servering, och på vilka typer av beroenden.

För alla distributionslägen rekommenderar Databricks att du kör slutsatsdragning på samma körningsversion som du använde under träningen, eftersom Databricks Runtime där du skapade din modell redan har olika bibliotek installerade. MLflow i Databricks sparar automatiskt den körningsversionen i MLmodel metadatafilen i ett databricks_runtime fält, till exempel databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Online-servering: Mosaic AI Model Serving

Databricks erbjuder modellservering, där dina MLflow-maskininlärningsmodeller exponeras som skalbara REST API-slutpunkter.

För Python-beroenden requirements.txt i filen hanterar Databricks och MLflow allt för offentliga PyPI-beroenden. Om du har angett .py filer eller Python-hjulfiler när du loggar modellen med hjälp code_path av argumentet läser MLflow in dessa beroenden automatiskt.

För de här modellbetjäningsscenarierna kan du läsa följande:

• Använda anpassade Python-bibliotek med modellservering
• Paketera anpassade artefakter och filer för modellservering

För Python-beroenden requirements.txt i filen hanterar Databricks och MLflow allt för offentliga PyPI-beroenden. Om du har angett .py filer eller Python-hjulfiler när du loggar modellen med hjälp code_path av argumentet läser MLflow in dessa beroenden automatiskt.

Onlineservering: system från tredje part eller Docker-containrar

Om ditt scenario kräver servering av lösningar från tredje part eller en egen Docker-baserad lösning kan du exportera din modell som en Docker-container.

Databricks rekommenderar följande för tredjepartsservering som automatiskt hanterar Python-beroenden. Men för icke-Python-beroenden måste containern ändras för att inkludera dem.

• MLflows Docker-integrering för Docker-baserad serverlösning: MLflow-modeller build-docker

• Azure Machine Learnings MLflow-integrering:

  • Distribuera till Azure Container Instance (ACI)
  • Distribuera till Azure Kubernetes Service (AKS)

Batch- och strömningsjobb

Batch- och strömningsbedömning ska köras som Databricks-jobb. Ett notebook-jobb räcker ofta, och det enklaste sättet att förbereda kod är att använda Databricks Model Registry för att generera en bedömningsanteckningsbok.

Följande beskriver processen och de steg som ska följas för att säkerställa att beroenden installeras och tillämpas i enlighet med detta:

1. Starta ditt bedömningskluster med samma Databricks Runtime-version som användes under träningen. Läs fältet databricks_runtime från MLmodel metadatafilen och starta ett kluster med den körningsversionen.

   • Detta kan göras manuellt i klusterkonfigurationen eller automatiseras med anpassad logik. För automatisering är det körningsversionsformat som du läser från metadatafilen i API:et jobb och kluster-API:et.

2. Installera sedan eventuella icke-Python-beroenden. För att säkerställa att dina icke-Python-beroenden är tillgängliga för distributionsmiljön kan du antingen:

   • Installera modellens icke-Python-beroenden manuellt i Databricks-klustret som en del av klusterkonfigurationen innan du kör slutsatsdragning.
   • Du kan också skriva anpassad logik i distributionen av bedömningsjobbet för att automatisera installationen av beroendena i klustret. Förutsatt att du sparade dina icke-Python-beroenden som artefakter enligt beskrivningen i Log non-Python package model dependencies (Logga icke-Python-paketmodellberoenden) kan den här automatiseringen installera bibliotek med hjälp av biblioteks-API:et. Eller så kan du skriva specifik kod för att generera ett klusteromfattande initieringsskript för att installera beroendena.

3. Ditt bedömningsjobb installerar Python-beroendena i jobbkörningsmiljön. I Databricks kan du med modellregistret generera en notebook-fil för slutsatsdragning som gör detta åt dig.

   • När du använder Databricks Model Registry för att generera en bedömningsanteckningsbok innehåller notebook-filen kod för att installera Python-beroenden i modellens requirements.txt fil. För ditt notebook-jobb för batch- eller strömningsbedömning initierar den här koden din notebook-miljö så att modellberoendena är installerade och redo för din modell.

4. MLflow hanterar all anpassad Python-kod som ingår i parametern code_path i log_model. Den här koden läggs till i Python-sökvägen när modellens metod anropas predict() . Du kan också göra detta manuellt genom att antingen:

   • Anropar mlflow.pyfunc.spark_udf med env_manager=['virtualenv'/'conda'] argumentet .
   • Extrahera kraven med hjälp av mlflow.pyfunc.get_model_dependencies och installera dem med hjälp av %pip install.

   Kommentar

   Om du har angett .py filer eller Python-hjulfiler när du loggar modellen med argumentet code_path läser MLflow in dessa beroenden automatiskt.