Overzicht van aangepaste modellen

In dit artikel wordt ondersteuning beschreven voor aangepaste modellen met behulp van Mosaic AI Model Serving. Het bevat informatie over ondersteunde opties voor model logging en rekentypen, hoe u modelafhankelijkheden verpakt voor het aanbieden van modellen, en verwachtingen over het creëren en schalen van endpoints.

Wat zijn aangepaste modellen?

Model serving kan elk Python-model of aangepaste code implementeren als een API op productieniveau met behulp van CPU- of GPU-rekenresources. 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 bedienen van basismodellen voor generatieve AI-toepassingen. Zie Foundation Model-API's en Externe modellen voor ondersteunde modellen en rekenaanbiedingen.

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)
  

• Log met MLflow's ingebouwde flavors. 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, moet u ervoor 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.

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. De basisinstallatiekopieën kunnen enkele afhankelijkheden op systeemniveau bevatten, maar afhankelijkheden op toepassingsniveau moeten expliciet worden opgegeven in uw MLflow-model.

Als niet alle vereiste afhankelijkheden zijn opgenomen in het model, kunnen er afhankelijkheidsfouten optreden tijdens de implementatie. 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. Zie de documentatie voor MLflow-modellen en de documentatie over MLflow Python API voor gedetailleerde informatie over vereisten voor logboekregistratie en best practices.

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

Zie Voordat de validatiecontroles voor modelimplementatie worden gecontroleerd voor informatie over het valideren en bijwerken van afhankelijkheden vóór de implementatie.

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 bij het aanmaken en bijwerken van eindpunten

• Implementatietijd: 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, maar kan langer duren, afhankelijk van de complexiteit, grootte en afhankelijkheden van het model.
• Updates zonder downtime: Azure Databricks voert een update van eindpunten zonder downtime uit door de bestaande eindpuntconfiguratie bij te houden totdat de nieuwe klaar is. Dit vermindert het risico op onderbrekingen voor eindpunten die in gebruik zijn. Tijdens dit updateproces worden zowel de oude als de nieuwe eindpuntconfiguraties gefactureerd totdat de overgang naar de nieuwe configuratie is voltooid.
• Time-out van aanvraag: als modelberekening langer duurt dan 297 seconden, treedt er een time-out op voor aanvragen.

Verwachtingen voor het schalen van eindpunten

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. Zie Belastingstests voor eindpuntservices om uw gelijktijdigheidsconfiguratie te valideren.
• 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: Schalen naar nul is een optionele functie voor eindpunten waarmee ze na 30 minuten inactiviteit omlaag kunnen schalen naar nul. De eerste aanvraag na het schalen naar nul ervaart een 'koude start', wat leidt tot een hogere latentie. Omhoog schalen van nul duurt meestal 10-20 seconden, maar kan soms minuten duren. Er is geen SLA op schaal van nul latentie.
• Optimalisatie van route: Voor gebruiksscenario's met hoge QPS- en lage latentie is routeoptimalisatie de optimale en aanbevolen optie om de prestaties te verbeteren.

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

Anaconda-licentiemelding voor verouderde modellen

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

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

Aanvullende bronnen

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