Aangepaste modellen implementeren

In dit artikel wordt ondersteuning beschreven voor het implementeren van een aangepast model met behulp van Mosaic AI Model Serving. Het biedt ook informatie over ondersteunde opties voor modelregistratie en rekentypen, het verpakken van modelafhankelijkheden voor het leveren van en het maken en schalen van eindpunten.

Wat zijn aangepaste modellen?

Model Serving kan elk Python-model implementeren als een API op productieniveau. Databricks verwijst naar dergelijke modellen als aangepaste modellen. Deze ML-modellen kunnen worden getraind met behulp van standaard ML-bibliotheken zoals scikit-learn, XGBoost, PyTorch en HuggingFace-transformaties en kunnen elke Python-code bevatten.

Een aangepast model implementeren:

1. Registreer het model of de code in de MLflow-indeling met behulp van ingebouwde MLflow-smaken of pyfunc.
2. Nadat het model is geregistreerd, registreert u het in de Unity Catalog (aanbevolen) of het werkruimteregister.
3. Hier kunt u een model voor eindpunt maken om uw model te implementeren en er query's op uit te voeren.
   1. Zie Aangepaste modellen maken voor eindpunten
   2. Zie Query's voor eindpunten voor aangepaste modellen.

Voor een volledige zelfstudie over het bedienen van aangepaste modellen in Databricks, raadpleegt u de zelfstudie Model voor het leveren van modellen.

Databricks biedt ook ondersteuning voor het leveren van generatieve AI-modellen voor generatieve AI-toepassingen, zie Foundation Model-API's en externe modellen voor ondersteunde modellen en rekenaanbiedingen.

Belangrijk

Als u afhankelijk bent van Anaconda, raadpleegt u de servicevoorwaarden voor aanvullende informatie.

ML-modellen vastleggen

Er zijn verschillende methoden om uw ML-model te registreren voor het leveren van modellen. De volgende lijst bevat een overzicht van de ondersteunde methoden en voorbeelden.

• Autologging Deze methode wordt automatisch ingeschakeld wanneer u Databricks Runtime voor ML gebruikt.

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

• Meld u aan met behulp van de ingebouwde smaken van MLflow. U kunt deze methode gebruiken als u het model handmatig wilt registreren voor gedetailleerdere controle.

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

• Aangepaste logboekregistratie met pyfunc. U kunt deze methode gebruiken voor het implementeren van willekeurige Python-codemodellen of het implementeren van extra code naast uw model.

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

• Download van HuggingFace. U kunt een model rechtstreeks downloaden van Hugging Face en dat model vastleggen voor de bediening. Zie Notebook-voorbeelden voor voorbeelden.

Voorbeelden van handtekeningen en invoer

Het is raadzaam om een handtekening en invoervoorbeeld toe te voegen aan MLflow. Handtekeningen zijn nodig voor het vastleggen van modellen in de Unity-catalogus.

Hier volgt een voorbeeld van een handtekening:

from mlflow.models.signature import infer_signature

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

Hier volgt een invoervoorbeeld:

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

Rekentype

Mozaïek AI Model Serving biedt een verscheidenheid aan CPU- en GPU-opties voor het implementeren van uw model. Wanneer u implementeert met een GPU, is het essentieel om ervoor te zorgen dat uw code is ingesteld, zodat voorspellingen worden uitgevoerd op de GPU, met behulp van de methoden die door uw framework worden geleverd. MLflow doet dit automatisch voor modellen die zijn geregistreerd met de PyTorch- of Transformers-smaken.

workloadtype	GPU-exemplaar	geheugen
CPU		4 GB per gelijktijdigheid
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80 GB
GPU_LARGE_2	2xA100	160 GB

Implementatiecontainer en afhankelijkheden

Tijdens de implementatie wordt een container op productieniveau gebouwd en geïmplementeerd als het eindpunt. Deze container bevat bibliotheken die automatisch zijn vastgelegd of opgegeven in het MLflow-model.

Het model dat de container verwerkt, bevat geen vooraf geïnstalleerde afhankelijkheden, wat kan leiden tot afhankelijkheidsfouten als niet alle vereiste afhankelijkheden zijn opgenomen in het model. Wanneer u problemen ondervindt met modelimplementatie, raadt Databricks u aan het model lokaal te testen.

Pakket- en codeafhankelijkheden

Aangepaste of persoonlijke bibliotheken kunnen worden toegevoegd aan uw implementatie. Zie Aangepaste Python-bibliotheken gebruiken met Model Serving.

Voor systeemeigen MLflow-smaakmodellen worden de benodigde pakketafhankelijkheden automatisch vastgelegd.

Voor aangepaste pyfunc modellen kunnen afhankelijkheden expliciet worden toegevoegd.

U kunt pakketafhankelijkheden toevoegen met behulp van:

• De pip_requirements parameter:

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

• De conda_env parameter:

  
  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)
  

• Als u aanvullende vereisten wilt opnemen buiten wat automatisch wordt vastgelegd, gebruikt u extra_pip_requirements.

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

Als u codeafhankelijkheden hebt, kunnen deze worden opgegeven met behulp van code_path.

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

Afhankelijkheidsvalidatie

Voordat u een aangepast MLflow-model implementeert, is het handig om te controleren of het model kan worden geleverd. MLflow biedt een API waarmee het modelartefact kan worden gevalideerd die zowel de implementatieomgeving simuleert als waarmee gewijzigde afhankelijkheden kunnen worden getest.

Er zijn twee validatie-API's vóór de implementatie de MLflow Python-API en de MLflow CLI.

U kunt het volgende opgeven met behulp van een van deze API's.

• Het model_uri model dat is geïmplementeerd voor het leveren van modellen.
• Een van de volgende opties:
  • De input_data in de verwachte indeling voor de mlflow.pyfunc.PyFuncModel.predict() aanroep van het model.
  • Hiermee input_path definieert u een bestand met invoergegevens die worden geladen en gebruikt voor de aanroep.predict
• De content_type in csv - of json notatie.
• Een optioneel output_path om de voorspellingen naar een bestand te schrijven. Als u deze parameter weglaat, worden de voorspellingen afgedrukt naar stdout.
• Een omgevingsmanager, env_managerdie wordt gebruikt om de omgeving te bouwen voor het leveren van:
  • De standaardwaarde is virtualenv. Aanbevolen voor validatie.
  • local is beschikbaar, maar mogelijk foutgevoelig voor het uitvoeren van validatie. Over het algemeen alleen gebruikt voor snelle foutopsporing.
• Of u de huidige versie van MLflow wilt installeren die zich in uw omgeving bevindt met behulp van install_mlflowde virtuele omgeving. Deze instelling wordt standaard ingesteld op False.
• Of u nu verschillende versies van pakketafhankelijkheden wilt bijwerken en testen voor probleemoplossing of foutopsporing. U kunt dit opgeven als een lijst met afhankelijkheidsoverschrijvingen of toevoegingen van tekenreeksen met behulp van het argument onderdrukking, pip_requirements_override.

Voorbeeld:

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

Updates voor afhankelijkheden

Als er problemen zijn met de afhankelijkheden die zijn opgegeven met een geregistreerd model, kunt u de vereisten bijwerken met behulp van de MLflow CLI of mlflow.models.model.update_model_requirements() in de MLflow Python-API zonder dat u een ander model hoeft te registreren.

In het volgende voorbeeld ziet u hoe u het pip_requirements.txt bijwerken van een geregistreerd model ter plaatse kunt uitvoeren.

U kunt bestaande definities bijwerken met opgegeven pakketversies of niet-bestaande vereisten toevoegen aan het pip_requirements.txt bestand. Dit bestand bevindt zich in het MLflow-modelartefact op de opgegeven model_uri locatie.

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

Verwachtingen en beperkingen

In de volgende secties worden bekende verwachtingen en beperkingen beschreven voor het leveren van aangepaste modellen met behulp van Model Serving.

Verwachtingen voor het maken en bijwerken van eindpunten

Notitie

De informatie in deze sectie is niet van toepassing op eindpunten die basismodellen of externe modellen dienen.

Het implementeren van een nieuw geregistreerde modelversie omvat het verpakken van het model en de modelomgeving en het inrichten van het modeleindpunt zelf. Dit proces kan ongeveer 10 minuten duren.

Azure Databricks voert een update van eindpunten zonder downtime uit door de bestaande eindpuntconfiguratie bij te houden totdat de nieuwe gereed is. Dit vermindert het risico op onderbrekingen voor eindpunten die in gebruik zijn.

Als modelberekening langer duurt dan 120 seconden, treedt er een time-out op voor aanvragen. Als u denkt dat uw modelberekening langer dan 120 seconden duurt, neemt u contact op met uw Azure Databricks-accountteam.

Databricks voert af en toe systeemupdates en onderhoud van systeemupdates zonder downtime uit op bestaande Model Serving-eindpunten. Tijdens het onderhoud laadt Databricks modellen opnieuw en markeert het een eindpunt als Mislukt als een model niet opnieuw kan worden geladen. Zorg ervoor dat uw aangepaste modellen robuust zijn en op elk gewenst moment opnieuw kunnen laden.

Verwachtingen voor het schalen van eindpunten

Notitie

De informatie in deze sectie is niet van toepassing op eindpunten die basismodellen of externe modellen dienen.

Het leveren van eindpunten wordt automatisch geschaald op basis van verkeer en de capaciteit van ingerichte gelijktijdigheidseenheden.

• Ingerichte gelijktijdigheid: het maximum aantal parallelle aanvragen dat het systeem kan verwerken. Maak een schatting van de vereiste gelijktijdigheid met behulp van de formule: ingerichte gelijktijdigheid = query's per seconde (QPS) * uitvoeringstijd (s) van model.
• Schaalgedrag: Eindpunten worden bijna onmiddellijk omhoog geschaald met meer verkeer en om de vijf minuten omlaag geschaald om het gereduceerde verkeer te vinden.
• Schalen naar nul: eindpunten kunnen na 30 minuten inactiviteit omlaag worden geschaald naar nul. De eerste aanvraag na het schalen naar nul ervaart een 'koude start', wat leidt tot een hogere latentie. Voor latentiegevoelige toepassingen kunt u strategieën overwegen om deze functie effectief te beheren.

Beperkingen voor GPU-workload

Hier volgen beperkingen voor het leveren van eindpunten met GPU-workloads:

• Het maken van een containerinstallatiekopie voor GPU-server duurt langer dan het maken van installatiekopieën voor CPU-server vanwege de modelgrootte en verhoogde installatievereisten voor modellen die op GPU worden geleverd.
• Bij het implementeren van zeer grote modellen kan er een time-out optreden bij het implementatieproces als de implementatie van de container-build en -model langer is dan 60 minuten. Als dit het geval is, moet het model worden geïmplementeerd wanneer een nieuwe poging van het proces wordt gestart.
• Automatisch schalen voor GPU-server duurt langer dan voor CPU-server.
• GPU-capaciteit wordt niet gegarandeerd bij het schalen naar nul. GPU-eindpunten verwachten mogelijk extra hoge latentie voor de eerste aanvraag na het schalen naar nul.
• Deze functionaliteit is niet beschikbaar in northcentralus.

Anaconda-licentie-update

De volgende kennisgeving is bedoeld voor klanten die afhankelijk zijn van Anaconda.

Belangrijk

Anaconda Inc. heeft hun servicevoorwaarden voor anaconda.org kanalen bijgewerkt. Op basis van de nieuwe servicevoorwaarden hebt u mogelijk een commerciële licentie nodig als u afhankelijk bent van de verpakking en distributie van Anaconda. Zie Veelgestelde vragen over Anaconda Commercial Edition voor meer informatie. Uw gebruik van anaconda-kanalen is onderhevig aan hun servicevoorwaarden.

MLflow-modellen die zijn geregistreerd vóór v1.18 (Databricks Runtime 8.3 ML of eerder) zijn standaard vastgelegd met het conda-kanaal defaults (https://repo.anaconda.com/pkgs/) als afhankelijkheid. Vanwege deze licentiewijziging heeft Databricks het gebruik van het defaults kanaal gestopt voor modellen die zijn geregistreerd met MLflow v1.18 en hoger. Het standaardkanaal dat is geregistreerd, is nu conda-forge, die verwijst naar de door de community beheerde https://conda-forge.org/.

Als u een model hebt geregistreerd vóór MLflow v1.18 zonder het defaults kanaal uit te sluiten van de Conda-omgeving voor het model, heeft dat model mogelijk een afhankelijkheid van het defaults kanaal dat u mogelijk niet hebt bedoeld. Als u handmatig wilt controleren of een model deze afhankelijkheid heeft, kunt u de waarde onderzoeken channel in het conda.yaml bestand dat is verpakt met het geregistreerde model. Een model conda.yaml met een defaults kanaalafhankelijkheid kan er bijvoorbeeld als volgt uitzien:

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

Omdat Databricks niet kan bepalen of uw gebruik van de Anaconda-opslagplaats om te communiceren met uw modellen is toegestaan in uw relatie met Anaconda, dwingt Databricks klanten niet om wijzigingen aan te brengen. Als uw gebruik van de Anaconda.com opslagplaats via het gebruik van Databricks is toegestaan volgens de voorwaarden van Anaconda, hoeft u geen actie te ondernemen.

Als u het kanaal wilt wijzigen dat wordt gebruikt in de omgeving van een model, kunt u het model opnieuw registreren bij het modelregister met een nieuw conda.yaml. U kunt dit doen door het kanaal op te geven in de conda_env parameter van log_model().

Zie de MLflow-documentatie voor de modelsmaak waarmee u werkt, bijvoorbeeld log_model voor scikit-learn voor meer informatie over de log_model() API.

Zie de MLflow-documentatie voor meer informatie over conda.yaml bestanden.

Aanvullende bronnen

• Aangepaste model-service-eindpunten maken
• Query's uitvoeren op eindpunten voor aangepaste modellen
• Aangepaste Python-bibliotheken gebruiken met Model Serving
• Aangepaste artefacten verpakken voor modelservering
• Python-code implementeren met Model Serving
• Routeoptimalisatie configureren voor het leveren van eindpunten
• Toegang tot resources configureren vanuit het model dat eindpunten bedient