Nasazení vlastních modelů

Tento článek popisuje podporu nasazení vlastního modelu pomocí služby Databricks Model Serving. Poskytuje také podrobnosti o podporovaných možnostech protokolování modelu a typech výpočetních prostředků, o tom, jak zabalit závislosti modelu pro obsluhu a vytváření a škálování koncových bodů.

Co jsou vlastní modely?

Obsluha modelů může nasadit libovolný model Pythonu jako rozhraní API na úrovni produkčního prostředí. Databricks odkazuje na takové modely, jako jsou vlastní modely. Tyto modely ML je možné trénovat pomocí standardních knihoven ML, jako jsou scikit-learn, XGBoost, PyTorch a Transformátory HuggingFace a můžou obsahovat libovolný kód Pythonu.

Pokud chcete nasadit vlastní model,

1. Zapište model nebo kód ve formátu MLflow pomocí nativních předdefinovaných příchutí MLflow nebo pyfunc.
2. Po zaprotokolování modelu ho zaregistrujte v katalogu Unity (doporučeno) nebo v registru pracovního prostoru.
3. Tady můžete vytvořit model obsluhující koncový bod pro nasazení a dotazování modelu.
   1. Viz Vytvoření vlastních modelů obsluhujících koncové body.
   2. Viz Dotaz obsluhující koncové body pro vlastní modely.

Kompletní kurz o tom, jak obsluhovat vlastní modely v Databricks, najdete v tématu Kurz obsluhy modelů.

Databricks také podporuje poskytování základních modelů pro generování aplikací umělé inteligence, viz rozhraní API modelu foundation a externí modely pro podporované modely a nabídky výpočetních prostředků.

Důležité

Pokud se spoléháte na Anaconda, přečtěte si další informace v oznámení o podmínkách služby .

Modely Log ML

Existují různé metody protokolování modelu ML pro obsluhu modelu. Následující seznam shrnuje podporované metody a příklady.

• Automatické zalogování Tato metoda je automaticky povolena při použití Databricks Runtime pro 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)
  

• Protokolování pomocí předdefinovaných příchutí MLflow Tuto metodu můžete použít, pokud chcete model ručně protokolovat pro podrobnější řízení.

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

• Vlastní protokolování pomocí pyfunc. Tuto metodu můžete použít k nasazení libovolných modelů kódu Pythonu nebo k nasazení dalšího kódu společně s vaším modelem.

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

Příklady podpisu a vstupu

Přidání podpisu a příkladu vstupu do MLflow se doporučuje. Podpisy jsou nezbytné pro protokolování modelů do katalogu Unity.

Následuje příklad podpisu:

from mlflow.models.signature import infer_signature

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

Následuje příklad vstupu:

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

Typ výpočetních prostředků

Poznámka:

Obsluha modelu GPU je ve verzi Public Preview.

Obsluha modelu Databricks poskytuje celou řadu možností procesoru a GPU pro nasazení modelu. Při nasazování pomocí GPU je nezbytné zajistit, aby byl váš kód nastavený tak, aby se předpovědi spouštěly na GPU pomocí metod poskytovaných vaší architekturou. MLflow to dělá automaticky pro modely protokolované s příchutěmi PyTorch nebo Transformers.

typ úlohy	Instance GPU	paměť
CPU		4 GB na souběžnost
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80 GB
GPU_LARGE_2	2xA100	160 GB

Kontejner nasazení a závislosti

Během nasazování se kontejner na produkční úrovni sestaví a nasadí jako koncový bod. Tento kontejner zahrnuje knihovny automaticky zachycené nebo zadané v modelu MLflow.

Kontejner obsluhující model neobsahuje předinstalované závislosti, což může vést k chybám závislostí, pokud nejsou součástí modelu všechny požadované závislosti. Když narazíte na problémy s nasazením modelu, Databricks doporučuje model otestovat místně.

Závislosti balíčků a kódu

Do nasazení můžete přidat vlastní nebo privátní knihovny. Viz Použití vlastních knihoven Pythonu s obsluhou modelů.

U nativních modelů příchutě MLflow se automaticky zaznamenávají potřebné závislosti balíčků.

Pro vlastní pyfunc modely je možné explicitně přidat závislosti.

Závislosti balíčků můžete přidat pomocí:

• Parametr pip_requirements :

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

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

• Pokud chcete zahrnout další požadavky nad rámec toho, co se automaticky zaznamenává, použijte extra_pip_requirements.

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

Pokud máte závislosti kódu, můžete je zadat pomocí code_path.

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

Ověřování závislostí

Před nasazením vlastního modelu MLflow je vhodné ověřit, že je model schopný obsluhovat. MLflow poskytuje rozhraní API, které umožňuje ověření artefaktu modelu, který simuluje prostředí nasazení a umožňuje testování upravených závislostí.

Existují dvě rozhraní API pro ověřování před nasazením, rozhraní API pythonu MLflow a rozhraní příkazového řádku MLflow.

Pomocí některého z těchto rozhraní API můžete zadat následující údaje.

• Model model_uri , který se nasadí do obsluhy modelu.
• Jedna z následujících možností:
  • Očekávaný input_data formát volání mlflow.pyfunc.PyFuncModel.predict() modelu.
  • Ten input_path definuje soubor obsahující vstupní data, která budou načtena a použita pro volání predict.
• Formát content_type nebo incsv.json
• Volitelné output_path pro zápis předpovědí do souboru. Pokud tento parametr vynecháte, předpovědi se vytisknou na stdout.
• Správce prostředí, env_managerkterý se používá k sestavení prostředí pro obsluhu:
  • Výchozí hodnota je virtualenv. Doporučuje se pro obsluhu ověření.
  • local je k dispozici, ale potenciálně náchylná k chybám pro obsluhu ověřování. Obecně se používá pouze pro rychlé ladění.
• Zda nainstalovat aktuální verzi MLflow, která je ve vašem prostředí s virtuálním prostředím pomocí install_mlflow. Toto nastavení je ve výchozím nastavení nastaveno na Falsehodnotu .
• Ať už chcete aktualizovat a otestovat různé verze závislostí balíčků pro řešení potíží nebo ladění. Můžete to zadat jako seznam přepsání závislostí řetězců nebo sčítání pomocí argumentu přepsání, pip_requirements_override.

Příklad:

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

Aktualizace závislostí

Pokud dojde k nějakým problémům se závislostmi zadanými v protokolovaném modelu, můžete požadavky aktualizovat pomocí rozhraní příkazového řádku MLflow nebo mlflow.models.model.update_model_requirements() v rozhraní PYTHON API MLflow, aniž byste museli protokolovat jiný model.

Následující příklad ukazuje, jak aktualizovat pip_requirements.txt přihlášený model na místě.

Existující definice můžete aktualizovat pomocí zadaných verzí balíčků nebo do pip_requirements.txt souboru přidat neexistující požadavky. Tento soubor se nachází v artefaktu modelu MLflow v zadaném model_uri umístění.

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

Očekávání a omezení

Následující části popisují známá očekávání a omezení pro obsluhu vlastních modelů pomocí služby Model Serving.

Vytvoření a aktualizace koncových bodů – očekávání

Poznámka:

Informace v této části se nevztahují na koncové body, které obsluhují základní modely.

Nasazení nově registrované verze modelu zahrnuje zabalení modelu a jeho prostředí modelu a zřízení samotného koncového bodu modelu. Tento proces může trvat přibližně 10 minut.

Azure Databricks provádí aktualizaci koncových bodů s nulovými výpadky tím, že udržuje stávající konfiguraci koncového bodu v provozu, dokud nebude nová aktualizace připravená. Tím se snižuje riziko přerušení koncových bodů, které se používají.

Pokud výpočet modelu trvá déle než 120 sekund, vyprší časový limit požadavků. Pokud se domníváte, že výpočet modelu bude trvat déle než 120 sekund, obraťte se na svůj tým účtů Azure Databricks.

Databricks provádí občasné aktualizace systému nulového výpadku a údržbu u stávajících koncových bodů služby Model Serving. Během údržby databricks znovu načte modely a označí koncový bod jako neúspěšný, pokud se modelu nepodaří znovu načíst. Ujistěte se, že vaše přizpůsobené modely jsou robustní a kdykoli se dají znovu načíst.

Očekávání škálování koncových bodů

Poznámka:

Informace v této části se nevztahují na koncové body, které obsluhují základní modely.

Obsluha koncových bodů se automaticky škáluje na základě provozu a kapacity zřízených jednotek souběžnosti.

• Zřízená souběžnost: Maximální počet paralelních požadavků, které může systém zpracovat. Odhad požadované souběžnosti pomocí vzorce: zřízená souběžnost = dotazy za sekundu (QPS) * doba provádění modelu (s).
• Chování škálování: Koncové body se vertikálně navyšují téměř okamžitě se zvýšeným provozem a každých pět minut vertikálně sníží kapacitu tak, aby odpovídaly omezenému provozu.
• Škálování na nulu: Koncové body se můžou po 30 minutách nečinnosti vertikálně snížit na nulu. U prvního požadavku po škálování na nulu dojde k "studenému startu", což vede k vyšší latenci. U aplikací citlivých na latenci zvažte strategie efektivní správy této funkce.

Omezení úloh GPU

Níže jsou uvedená omezení pro obsluhu koncových bodů s úlohami GPU:

• Vytvoření image kontejneru pro obsluhu GPU trvá déle než vytvoření image pro obsluhu procesoru kvůli velikosti modelu a zvýšeným požadavkům na instalaci pro modely obsluhované na GPU.
• Pokud nasazení kontejneru a nasazení modelu překročí 60minutovou dobu, proces nasazení může při nasazování velmi velkých modelů časového limitu časového limitu. Pokud k tomu dojde, spuštění opakování procesu by mělo model úspěšně nasadit.
• Automatické škálování pro obsluhu GPU trvá déle než obsluha procesoru.
• Při škálování na nulu není zaručená kapacita GPU. Koncové body GPU můžou po škálování na nulu očekávat vyšší latenci prvního požadavku.
• Tato funkce není k dispozici v northcentralussouboru .

Aktualizace licencování Anaconda

Následující oznámení platí pro zákazníky, kteří se spoléhají na Anaconda.

Důležité

Anaconda Inc. aktualizoval své podmínky služby pro kanály anaconda.org. Na základě nových podmínek služby můžete vyžadovat komerční licenci, pokud spoléháte na balení a distribuci Anaconda. Další informace najdete v tématu Anaconda Commercial Edition – nejčastější dotazy . Vaše používání všech kanálů Anaconda se řídí jejich podmínkami služby.

Modely MLflow protokolované před verzí 1.18 (Databricks Runtime 8.3 ML nebo starší) byly ve výchozím nastavení protokolovány pomocí kanálu Conda defaults (https://repo.anaconda.com/pkgs/) jako závislosti. Kvůli této změně licence služba Databricks zastavila používání defaults kanálu pro modely protokolované pomocí MLflow verze 1.18 a vyšší. Výchozí protokolovaný kanál je nyní conda-forge, který odkazuje na komunitu spravovanou https://conda-forge.org/.

Pokud jste model zaprotokolovali před MLflow verze 1.18 bez vyloučení defaults kanálu z prostředí Conda pro model, může mít tento model závislost na defaults kanálu, který jste možná nezamýšleli. Pokud chcete ručně ověřit, jestli má model tuto závislost, můžete prozkoumat channel hodnotu v conda.yaml souboru, který je zabalený s protokolovaným modelem. Model s závislostí defaults kanálu může například conda.yaml vypadat takto:

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

Protože Databricks nedokáže určit, jestli vaše použití úložiště Anaconda k interakci s vašimi modely je povoleno v rámci vašeho vztahu s Anaconda, Databricks nevynucuje svým zákazníkům provádět žádné změny. Pokud je vaše použití Anaconda.com úložiště prostřednictvím použití Databricks povolené podle podmínek Anaconda, nemusíte nic dělat.

Pokud chcete změnit kanál použitý v prostředí modelu, můžete model znovu zaregistrovat do registru modelů pomocí nového conda.yaml. Můžete to provést zadáním kanálu v parametru conda_env .log_model()

Další informace o log_model() rozhraní API najdete v dokumentaci MLflow pro variantu modelu, se kterou pracujete, například log_model pro scikit-learn.

Další informace o conda.yaml souborech najdete v dokumentaci K MLflow.

Další materiály

• Kurz: Nasazení a dotazování vlastního modelu
• Vytvoření vlastních modelů obsluhujících koncové body
• Dotaz obsluhující koncové body pro vlastní modely
• Použití vlastních knihoven Pythonu s obsluhou modelů
• Zabalení vlastních artefaktů pro obsluhu modelů
• Nasazení kódu Pythonu s využitím služby Model Serving
• Obsluha více modelů do koncového bodu obsluhy modelů
• Konfigurace přístupu k prostředkům z modelů obsluhujících koncové body