Översikt över anpassade modeller

Den här artikeln beskriver stöd för anpassade modeller med hjälp av Mosaic AI Model Serving. Den innehåller information om alternativ för modellloggning som stöds och beräkningstyper, hur du paketerar modellberoenden för servering och förväntningar på skapande och skalning av slutpunkter.

Vad är anpassade modeller?

Modellservern kan distribuera valfri Python-modell eller anpassad kod som ett API i produktionsklass med cpu- eller GPU-beräkningsresurser. 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 MLflow-flavors 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 slutpunkter för modellserving
   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.

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

• Ladda ned från HuggingFace. Du kan ladda ned en modell direkt från Hugging Face och logga modellen för servering. Exempel finns i Notebook-exempel.

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

Mosaic AI Model Serving innehåller en mängd olika cpu- och GPU-alternativ för att distribuera din modell. När du distribuerar med en GPU måste du 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 ramverket. MLflow gör detta automatiskt för modeller som loggas med PyTorch- eller Transformers-smakerna.

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. Basavbildningen kan innehålla vissa beroenden på systemnivå, men beroenden på programnivå måste uttryckligen anges i MLflow-modellen.

Om inte alla nödvändiga beroenden ingår i modellen kan det uppstå beroendefel under distributionen. 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. Detaljerad information om loggningskrav och metodtips finns i MLflow Models-dokumentationen och MLflow Python API-referensen.

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

Information om hur du verifierar och uppdaterar beroenden före distributionen finns i Verifieringskontroller av före modelldistribution.

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 avseende skapande och uppdatering av slutpunkter

• Distributionstid: 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, men kan ta längre tid beroende på modellens komplexitet, storlek och beroenden.
• Uppdateringar av noll stilleståndstid: Azure Databricks utför en uppdatering med noll stilleståndstid för slutpunkter genom att hålla den befintliga slutpunktskonfigurationen uppe tills den nya blir klar. Detta minskar risken för avbrott för slutpunkter som används. Under den här uppdateringsprocessen debiteras du för både de gamla och nya slutpunktskonfigurationerna tills övergången är klar.
• Tidsgräns för begäran: Om modellberäkningen tar längre tid än 297 sekunder kommer begäranden att avslutas på grund av tidsgräns.

Förväntningar på slutpunktsskalning

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). Information om hur du verifierar samtidighetskonfigurationen finns i Lasta tester för att betjäna slutpunkter.
• 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: Skala till noll är en valfri funktion för slutpunkter som gör att de kan skala 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. Det tar vanligtvis 10–20 sekunder att skala upp från noll, men det kan ibland ta några minuter. Det finns inget serviceavtal på skala från noll svarstid.
• Routningsoptimering: För användningsfall med hög QPS och låg latens är routningsoptimering det optimala och rekommenderade alternativet för att förbättra prestanda.

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.
• 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.

Anaconda-licensieringsmeddelande för äldre modeller

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

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

Ytterligare resurser

• Skapa anpassade modellserverslutpunkter
• Frågeserverslutpunkter för anpassade modeller
• Felsökningsguide för modellservering
• Använda anpassade Python-bibliotek med modellservering
• Paketera anpassade artefakter för modellhantering
• Distribuera Python-kod med modellservering
• Routningsoptimering för tjänstslutpunkter
• Konfigurera åtkomst till resurser från modelltjänsteslutpunkter