Distribuera anpassade modeller

I den här artikeln beskrivs stöd för att distribuera en anpassad modell med Databricks Model Serving. Den innehåller också information om alternativ för modellloggning som stöds och beräkningstyper, hur du paketerar modellberoenden för servering och skapande och skalning av slutpunkter.

Vad är anpassade modeller?

Modellservern kan distribuera valfri Python-modell som ett API i produktionsklass. Databricks refererar till sådana modeller som anpassade modeller. Dessa ML-modeller kan tränas med ml-standardbibliotek som scikit-learn, XGBoost, PyTorch och HuggingFace-transformatorer och kan innehålla valfri Python-kod.

Om du vill distribuera en anpassad modell

1. Logga modellen eller koden i MLflow-formatet med antingen inbyggda inbyggda MLflow-smaker eller pyfunc.
2. När modellen har loggats registrerar du den i Unity-katalogen (rekommenderas) eller arbetsytans register.
3. Härifrån kan du skapa en modell som betjänar slutpunkten för att distribuera och fråga din modell.
   1. Se Skapa anpassade modell som betjänar slutpunkter
   2. Se Frågeserverslutpunkter för anpassade modeller.

En fullständig självstudie om hur du hanterar anpassade modeller på Databricks finns i Självstudie om modellhantering.

Databricks har också stöd för att hantera grundmodeller för generativa AI-program, se Foundation Model API:er och externa modeller för modeller och beräkningserbjudanden som stöds.

Viktigt!

Om du förlitar dig på Anaconda läser du meddelandet om användarvillkor för ytterligare information.

Log ML-modeller

Det finns olika metoder för att logga ML-modellen för modellservering. I följande lista sammanfattas de metoder och exempel som stöds.

• Automatisk loggning Den här metoden aktiveras automatiskt när du använder Databricks Runtime för ML.

  import mlflow
  from sklearn.ensemble import RandomForestRegressor
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestRegressor()
  model.fit(iris.data, iris.target)
  

• Logga med MLflows inbyggda smaker. Du kan använda den här metoden om du vill logga modellen manuellt för mer detaljerad kontroll.

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

• Anpassad loggning med pyfunc. Du kan använda den här metoden för att distribuera godtyckliga python-kodmodeller eller distribuera ytterligare kod tillsammans med din modell.

    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())
  

Exempel på signatur och indata

Vi rekommenderar att du lägger till ett signatur- och indataexempel i MLflow. Signaturer krävs för loggning av modeller till Unity-katalogen.

Följande är ett signaturexempel:

from mlflow.models.signature import infer_signature

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

Följande är ett indataexempel:

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

Typ av beräkning

Kommentar

GPU-modellservern finns i offentlig förhandsversion.

Databricks Model Serving innehåller en mängd olika processor- och GPU-alternativ för att distribuera din modell. När du distribuerar med en GPU är det viktigt att se till att koden har konfigurerats så att förutsägelser körs på GPU:n med hjälp av de metoder som tillhandahålls av ditt ramverk. MLflow gör detta automatiskt för modeller som loggas med PyTorch- eller Transformers-smakerna.

arbetsbelastningstyp	GPU-instans	minne
CPU		4 GB per samtidighet
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80 GB
GPU_LARGE_2	2xA100	160 GB

Distributionscontainer och beroenden

Under distributionen skapas och distribueras en container i produktionsklass som slutpunkt. Den här containern innehåller bibliotek som registreras eller anges automatiskt i MLflow-modellen.

Den modell som betjänar containern innehåller inte förinstallerade beroenden, vilket kan leda till beroendefel om inte alla nödvändiga beroenden ingår i modellen. När du stöter på problem med modelldistribution rekommenderar Databricks att du testar modellen lokalt.

Paket- och kodberoenden

Anpassade eller privata bibliotek kan läggas till i distributionen. Se Använda anpassade Python-bibliotek med modellservering.

För MLflow-inbyggda smakmodeller registreras de nödvändiga paketberoendena automatiskt.

För anpassade pyfunc modeller kan beroenden uttryckligen läggas till.

Du kan lägga till paketberoenden med hjälp av:

• Parametern pip_requirements :

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

• Parametern 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)
  

• Om du vill inkludera ytterligare krav utöver vad som samlas in automatiskt använder du extra_pip_requirements.

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

Om du har kodberoenden kan dessa anges med hjälp av code_path.

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

Beroendeverifiering

Innan du distribuerar en anpassad MLflow-modell är det fördelaktigt att kontrollera att modellen kan hanteras. MLflow tillhandahåller ett API som möjliggör validering av modellartefakten som både simulerar distributionsmiljön och möjliggör testning av ändrade beroenden.

Det finns två API:er för verifiering före distribution som MLflow Python API och MLflow CLI.

Du kan ange följande med någon av dessa API:er.

• Den model_uri modell som distribueras till modellservern.
• Något av följande:
  • I input_data det förväntade formatet för anropet mlflow.pyfunc.PyFuncModel.predict() av modellen.
  • Som input_path definierar en fil som innehåller indata som ska läsas in och användas för anropet till predict.
• I content_typecsv - eller-formatet json .
• Ett valfritt output_path alternativ för att skriva förutsägelserna till en fil. Om du utelämnar den här parametern skrivs förutsägelserna ut till stdout.
• En miljöhanterare, env_manager, som används för att skapa miljön för att betjäna:
  • Standardvärdet är virtualenv. Rekommenderas för att hantera validering.
  • local är tillgänglig, men potentiellt felbenägen för att hantera validering. Används vanligtvis endast för snabb felsökning.
• Om du vill installera den aktuella versionen av MLflow som finns i din miljö med den virtuella miljön med hjälp av install_mlflow. Den här inställningen är Falsesom standard .
• Om du vill uppdatera och testa olika versioner av paketberoenden för felsökning eller felsökning. Du kan ange detta som en lista över åsidosättningar eller tillägg för strängberoende med hjälp av åsidosättningsargumentet . pip_requirements_override

Till exempel:

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

Beroendeuppdateringar

Om det finns några problem med de beroenden som angetts med en loggad modell kan du uppdatera kraven med hjälp av MLflow CLI eller mlflow.models.model.update_model_requirements() i python-API:et för MLflow utan att behöva logga en annan modell.

I följande exempel visas hur du uppdaterar pip_requirements.txt en loggad modell på plats.

Du kan uppdatera befintliga definitioner med angivna paketversioner eller lägga till icke-existerande krav i pip_requirements.txt filen. Den här filen finns i MLflow-modellartefakten på den angivna model_uri platsen.

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

Förväntningar och begränsningar

I följande avsnitt beskrivs kända förväntningar och begränsningar för att hantera anpassade modeller med hjälp av modellservering.

Förväntningar på att skapa och uppdatera slutpunkter

Kommentar

Informationen i det här avsnittet gäller inte för slutpunkter som hanterar grundmodeller.

När du distribuerar en nyligen registrerad modellversion måste du paketera modellen och dess modellmiljö och etablera själva modellslutpunkten. Den här processen kan ta cirka 10 minuter.

Azure Databricks utför en uppdatering av slutpunkter utan avbrott genom att behålla den befintliga slutpunktskonfigurationen tills den nya blir klar. Detta minskar risken för avbrott för slutpunkter som används.

Om modellberäkning tar längre tid än 120 sekunder överskrids tidsgränsen för begäranden. Om du tror att din modellberäkning tar längre tid än 120 sekunder kontaktar du ditt Azure Databricks-kontoteam.

Databricks utför enstaka systemuppdateringar och underhåll utan avbrott på befintliga modellserverslutpunkter. Under underhållet läser Databricks in modeller igen och markerar en slutpunkt som Misslyckad om en modell inte kan läsas in igen. Kontrollera att dina anpassade modeller är robusta och kan läsas in igen när som helst.

Förväntningar på slutpunktsskalning

Kommentar

Informationen i det här avsnittet gäller inte för slutpunkter som hanterar grundmodeller.

Serverdelsslutpunkter skalas automatiskt baserat på trafik och kapaciteten för etablerade samtidighetsenheter.

• Etablerad samtidighet: Det maximala antalet parallella begäranden som systemet kan hantera. Beräkna den nödvändiga samtidigheten med hjälp av formeln: etablerad samtidighet = frågor per sekund (QPS) * modellkörningstid (s).
• Skalningsbeteende: Slutpunkter skalas upp nästan omedelbart med ökad trafik och skalas ned var femte minut för att matcha minskad trafik.
• Skala till noll: Slutpunkter kan skalas ned till noll efter 30 minuters inaktivitet. Den första begäran efter skalning till noll upplever en "kall start", vilket leder till högre svarstid. För svarstidskänsliga program bör du överväga strategier för att hantera den här funktionen effektivt.

Begränsningar för GPU-arbetsbelastning

Följande är begränsningar för att betjäna slutpunkter med GPU-arbetsbelastningar:

• Skapande av containeravbildningar för GPU-servering tar längre tid än att skapa avbildningar för CPU-servering på grund av modellstorlek och ökade installationskrav för modeller som hanteras på GPU.
• När du distribuerar mycket stora modeller kan distributionsprocessen överskrida tidsgränsen om containerversionen och modelldistributionen överskrider en varaktighet på 60 minuter. Om detta inträffar bör du distribuera modellen genom att initiera ett nytt försök av processen.
• Automatisk skalning för GPU-servering tar längre tid än för CPU-servering.
• GPU-kapacitet garanteras inte vid skalning till noll. GPU-slutpunkter kan förvänta sig extra hög svarstid för den första begäran efter skalning till noll.
• Den här funktionen är inte tillgänglig i northcentralus.

Anaconda-licensieringsuppdatering

Följande meddelande gäller för kunder som förlitar sig på Anaconda.

Viktigt!

Anaconda Inc. uppdaterade sina tjänstvillkor för anaconda.org kanaler. Baserat på de nya tjänstvillkoren kan du kräva en kommersiell licens om du förlitar dig på Anacondas paketering och distribution. Mer information finns i Vanliga frågor och svar om Anaconda Commercial Edition. Din användning av Anaconda-kanaler styrs av deras användarvillkor.

MLflow-modeller som loggades före v1.18 (Databricks Runtime 8.3 ML eller tidigare) loggades som standard med conda-kanalen defaults (https://repo.anaconda.com/pkgs/) som ett beroende. På grund av den här licensändringen defaults har Databricks stoppat användningen av kanalen för modeller som loggats med MLflow v1.18 och senare. Standardkanalen som loggas är nu conda-forge, som pekar på den communityhanterade https://conda-forge.org/.

Om du loggade en modell före MLflow v1.18 utan att utesluta defaults kanalen från conda-miljön för modellen, kan den modellen ha ett beroende av den defaults kanal som du kanske inte har tänkt dig. För att manuellt bekräfta om en modell har det här beroendet kan du undersöka channel värdet i conda.yaml filen som är paketerad med den loggade modellen. En modell med conda.yaml ett defaults kanalberoende kan till exempel se ut så här:

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

Eftersom Databricks inte kan avgöra om din användning av Anaconda-lagringsplatsen för att interagera med dina modeller är tillåten under din relation med Anaconda, tvingar Databricks inte sina kunder att göra några ändringar. Om din användning av Anaconda.com lagringsplats genom användning av Databricks är tillåten enligt Anacondas villkor behöver du inte vidta några åtgärder.

Om du vill ändra den kanal som används i en modells miljö kan du registrera om modellen till modellregistret med en ny conda.yaml. Du kan göra detta genom att ange kanalen i parametern conda_envlog_model()för .

Mer information om API:et finns i log_model() MLflow-dokumentationen för modellsmaken som du arbetar med, till exempel log_model för scikit-learn.

Mer information om conda.yaml filer finns i MLflow-dokumentationen.

Ytterligare resurser

• Självstudie: Distribuera och fråga en anpassad modell
• Skapa anpassade modellserverslutpunkter
• Frågeserverslutpunkter för anpassade modeller
• Använda anpassade Python-bibliotek med modellservering
• Paketera anpassade artefakter för modellservering
• Distribuera Python-kod med modellservering
• Hantera flera modeller till en modellserverslutpunkt
• Konfigurera åtkomst till resurser från modell som betjänar slutpunkter