Přehled vlastních modelů

Tento článek popisuje podporu vlastních modelůvyužívajících službu modelů Mosaic AI. Poskytuje 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 očekávání pro vytváření a škálování koncových bodů.

Co jsou vlastní modely?

Obsluha modelů může nasadit libovolný model Pythonu nebo vlastní kód jako rozhraní API na úrovni produkčního prostředí s využitím výpočetních prostředků procesoru nebo GPU. 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 nasazení základních modelů pro generativní aplikace umělé inteligence, viz rozhraní API základních modelů a externí modely pro podporované modely a nabídky výpočetních prostředků.

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)
  

• Logování pomocí vestavěných modulů 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())
  

• Stáhnout z HuggingFace. Model si můžete stáhnout přímo z webu Hugging Face a protokol, který slouží. Příklady najdete v příkladech poznámkového bloku.

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ů

Rozhraní AI Model Serving poskytuje celou řadu možností procesoru a GPU pro nasazení modelu. Při nasazování pomocí GPU se musíte ujistit, že je 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	Memory
CPU		4 GB na souběžnost
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80 GB
GPU_LARGE_2	2x A100	160 GB
GPU_LARGE_4	4xA100	320 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. Základní image může obsahovat některé závislosti na úrovni systému, ale závislosti na úrovni aplikace musí být explicitně zadány v modelu MLflow.

Pokud do modelu nejsou zahrnuté všechny požadované závislosti, můžete během nasazování narazit na chyby závislostí. 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. Podrobné informace o požadavcích na protokolování a osvědčených postupech najdete v dokumentaci k modelům MLflow a referenční informace k rozhraní PYTHON API MLflow.

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

Informace o ověřování a aktualizaci závislostí před nasazením najdete v tématu Ověření před nasazením pro obsluhu modelů.

Očekávání a omezení

Poznámka:

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

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

Očekávání pro vytvoření a aktualizaci koncových bodů

• Čas nasazení: 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, ale může trvat déle v závislosti na složitosti modelu, velikosti a závislostech.
• Aktualizace nulového výpadku: 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í. Během tohoto procesu aktualizace se vám budou fakturovat staré i nové konfigurace koncových bodů, dokud se přechod neskončí.
• Časový limit požadavku: Pokud výpočet modelu trvá déle než 297 sekund, vyprší časový limit požadavků.

Důležité

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. Pokud se modelu nepodaří znovu načíst, aktualizace koncového bodu se označí jako neúspěšná a stávající konfigurace koncového bodu bude dál obsluhovat požadavky. 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ů

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). Pokud chcete ověřit konfiguraci souběžnosti, přečtěte si téma Zátěžové testování pro obsluhu koncových bodů.
• 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: Škálování na nulu je volitelná funkce pro koncové body, která jim umožňuje snížit kapacitu na nulu po 30 minutách nečinnosti. U prvního požadavku po škálování na nulu dojde k "studenému startu", což vede k vyšší latenci. Vertikální navýšení kapacity z nuly obvykle trvá 10 až 20 sekund, ale někdy může trvat několik minut. Neexistuje žádná SLA začínající od nulové latence.
• Optimalizace trasy: V případě vysokého využití QPS a nízké latence je optimalizace trasy optimální a doporučenou možností pro zvýšení výkonu.
• Bezserverová optimalizovaná nasazení: Pro rychlejší nasazení koncových bodů používejte bezserverová optimalizovaná nasazení.

Výstraha

Škálování na nulu by se nemělo používat pro produkční úlohy, které vyžadují konzistentní dobu provozu nebo garantovanou dobu odezvy. U aplikací nebo koncových bodů citlivých na latenci vyžadujících nepřetržitou dostupnost zakažte škálování na nulu.

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

Oznámení o licencování Anaconda pro starší modely

Poznámka:

Tato část se vztahuje pouze na modely protokolované pomocí MLflow verze 1.17 nebo starší (Databricks Runtime 8.3 ML nebo starší). Pokud používáte novější verzi, můžete tuto část přeskočit.

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

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í conda.yaml kanálu může například defaults 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

• Vytvoření vlastních modelů obsluhujících koncové body
• Dotaz obsluhující koncové body pro vlastní modely
• Průvodce laděním pro obsluhy modelů
• 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
• Optimalizace trasy pro obsluhu koncových bodů
• Bezserverové optimalizované nasazení pro model sloužící koncovým bodům
• Konfigurace přístupu k prostředkům z modelů obsluhujících koncové body