Sdílet prostřednictvím


Řešení potíží s nasazením vzdáleného modelu

Zjistěte, jak řešit a řešit běžné chyby, se kterými se můžete setkat při nasazování modelu do služby Azure Container Instances (ACI) a Azure Kubernetes Service (AKS) pomocí služby Azure Machine Learning.

Poznámka:

Pokud nasazujete model do služby Azure Kubernetes Service (AKS), doporučujeme pro příslušný cluster povolit Azure Monitor. Pomůže vám to pochopit celkový stav clusteru a využití prostředků. Užitečné by pro vás mohly být také následující zdroje informací:

Pokud se snažíte model nasadit do přetíženého clusteru nebo clusteru, který není v pořádku, očekává se, že dojde k problémům. Pokud potřebujete pomoc s řešením potíží s clusterem AKS, obraťte se na podporu AKS.

Požadavky

Postup nasazení modelů strojového učení dockeru

Když v Azure Machine Learning nasadíte model do jiného než místního výpočetního prostředí, dojde k následujícím věcem:

  1. Soubor Dockerfile, který jste zadali v objektu Prostředí v inferenceConfig, se odešle do cloudu spolu s obsahem zdrojového adresáře.
  2. Pokud v registru kontejneru není k dispozici dříve sestavená image, vytvoří se nová image Dockeru v cloudu a uloží se do výchozího registru kontejneru vašeho pracovního prostoru.
  3. Image Dockeru z registru kontejneru se stáhne do cílového výpočetního objektu.
  4. Výchozí úložiště objektů blob vašeho pracovního prostoru je připojené k cílovému výpočetnímu objektu a poskytuje vám přístup k registrovaným modelům.
  5. Webový server se inicializuje spuštěním funkce vstupního init() skriptu.
  6. Když nasazený model obdrží požadavek, vaše run() funkce tento požadavek zpracuje.

Hlavní rozdíl při použití místního nasazení spočívá v tom, že image kontejneru je postavená na místním počítači, a proto musíte mít Docker nainstalovaný pro místní nasazení.

Porozumíte těmto krokům vysoké úrovně, které vám pomůžou pochopit, kde se chyby dějí.

Získání protokolů nasazení

Prvním krokem při ladění chyb je získání protokolů nasazení. Nejprve se podle pokynů zde připojte ke svému pracovnímu prostoru.

PLATÍ PRO: Rozšíření Azure CLI ml v1

Pokud chcete získat protokoly z nasazené webové služby, postupujte takto:

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Místní ladění

Pokud máte problémy s nasazením modelu do ACI nebo AKS, nasaďte ho jako místní webovou službu. Použití místní webové služby usnadňuje řešení potíží. Pokud chcete vyřešit potíže s místním nasazením, projděte si místní článek o řešení potíží.

Odvození serveru HTTP ve službě Azure Machine Learning

Místní server odvozování umožňuje rychle ladit vstupní skript (score.py). Pokud má podkladový skript skóre chybu, server se nepodaří inicializovat nebo obsluhovat model. Místo toho vyvolá výjimku a umístění, kde došlo k problémům. Další informace o odvozovacím serveru HTTP služby Azure Machine Learning

  1. azureml-inference-server-http Nainstalujte balíček z informačního kanálu pypi:

    python -m pip install azureml-inference-server-http
    
  2. Spusťte server a nastavte score.py ho jako vstupní skript:

    azmlinfsrv --entry_script score.py
    
  3. Odeslání žádosti o bodování na server pomocí curl:

    curl -p 127.0.0.1:5001/score
    

Poznámka:

Přečtěte si nejčastější dotazy k serveru HTTP odvozovací služby Azure Machine Learning.

Kontejner nejde naplánovat

Při nasazování služby do cílového výpočetního prostředí Azure Kubernetes Service se Azure Machine Learning pokusí naplánovat službu s požadovaným množstvím prostředků. Pokud v clusteru nejsou k dispozici žádné uzly s odpovídajícím množstvím prostředků po 5 minutách, nasazení selže. Zpráva o selhání je Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Tuto chybu můžete vyřešit přidáním dalších uzlů, změnou skladové položky uzlů nebo změnou požadavků na prostředky vaší služby.

Chybová zpráva obvykle značí, který prostředek potřebujete více – například pokud se zobrazí chybová zpráva označující 0/3 nodes are available: 3 Insufficient nvidia.com/gpu , že služba vyžaduje GPU a v clusteru jsou tři uzly, které nemají dostupné GPU. Tento problém je možné vyřešit přidáním dalších uzlů, pokud používáte skladovou položku GPU, přepnutím na skladovou položku s podporou GPU, pokud nejste nebo změníte prostředí tak, aby nepožadování GPU vyžadovalo.

Selhání spuštění služby

Po úspěšném sestavení image se systém pokusí spustit kontejner pomocí konfigurace nasazení. Při spouštění kontejneru systém v hodnoticím skriptu volá funkci init(). Pokud jsou ve init() funkci nezachycené výjimky, může se v chybové zprávě zobrazit chyba CrashLoopBackOff .

Použijte informace v článku Kontrola protokolu Dockeru.

Selhání spuštění kontejneru azureml-fe-aci

Při nasazování služby do cílového výpočetního objektu služby Azure Container Instance se Azure Machine Learning pokusí vytvořit front-endový kontejner, který má název azureml-fe-aci požadavku na odvozování. Pokud azureml-fe-aci dojde k chybě, můžete zobrazit protokoly spuštěním az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. Opravu můžete provést podle chybové zprávy v protokolech.

Nejběžnějším selháním azureml-fe-aci je, že zadaný certifikát nebo klíč SSL je neplatný.

Funkce selže: get_model_path()

init() Ve funkci ve skriptu bodování se často volá funkce Model.get_model_path() k vyhledání souboru modelu nebo složky souborů modelu v kontejneru. Pokud soubor modelu nebo složka nelze najít, funkce selže. Nejjednodušší způsob, jak tuto chybu ladit, je spustit následující kód Pythonu v kontejnerovém prostředí:

PLATÍ PRO: Python SDK azureml v1

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

Tento příklad vytiskne místní cestu (vzhledem k /var/azureml-app) v kontejneru, kde skript bodování očekává nalezení souboru nebo složky modelu. Pak můžete ověřit, jestli je soubor nebo složka skutečně tam, kde se očekává.

Nastavení úrovně protokolování na DEBUG může způsobit protokolování dalších informací, které můžou být užitečné při identifikaci selhání.

Funkce selže: run(input_data)

Pokud je služba úspěšně nasazená, ale při publikování dat do bodujícího koncového bodu dojde k chybovému ukončení, můžete do funkce run(input_data) přidat příkaz zachytávání chyb, aby místo toho vrátil podrobnou chybovou zprávu. Příklad:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Poznámka: Vrácení chybových zpráv z run(input_data) volání by mělo být provedeno pouze pro účely ladění. Z bezpečnostních důvodů byste neměli v produkčním prostředí vracet chybové zprávy tímto způsobem.

Stavový kód HTTP 502

Stavový kód 502 označuje, že služba vyvolala výjimku nebo došlo k chybě v run() metodě score.py souboru. K ladění souboru použijte informace v tomto článku.

Stavový kód HTTP 503

Nasazení služby Azure Kubernetes Service podporují automatické škálování, což umožňuje přidání replik pro podporu dodatečného zatížení. Automatické škálování je navržené tak, aby zpracovával postupné změny zatížení. Pokud dostáváte velké špičky požadavků za sekundu, klienti můžou obdržet stavový kód HTTP 503. I když automatické škálování rychle reaguje, trvá AKS značné množství času, než vytvoří více kontejnerů.

Rozhodnutí o vertikálním navýšení/snížení kapacity jsou založená na využití aktuálních replik kontejnerů. Počet replik, které jsou zaneprázdněné (zpracování požadavku) vydělené celkovým počtem aktuálních replik, je aktuální využití. Pokud toto číslo překročí autoscale_target_utilization, vytvoří se více replik. Pokud je nižší, repliky se zmenší. Rozhodnutí o přidání replik jsou dychtivá a rychlá (přibližně 1 sekunda). Rozhodnutí o odebrání replik jsou konzervativní (přibližně 1 minuta). Ve výchozím nastavení je cílové využití cíle automatického škálování nastavené na 70 %, což znamená, že služba dokáže zpracovat špičky v požadavcích za sekundu (RPS) až 30 %.

Existují dvě věci, které vám můžou pomoct zabránit stavové kódy 503:

Tip

Tyto dva přístupy lze použít jednotlivě nebo v kombinaci.

  • Změňte úroveň využití, na které automatické škálování vytváří nové repliky. Cíl využití můžete upravit nastavením autoscale_target_utilization na nižší hodnotu.

    Důležité

    Tato změna nezpůsobí rychlejší vytváření replik. Místo toho se vytvoří s nižší prahovou hodnotou využití. Místo čekání na využití služby 70 % způsobí změna hodnoty na 30 % vytvoření replik při 30% využití.

    Pokud webová služba už používá aktuální maximální počet replik a stále se zobrazuje stavové kódy 503, zvyšte autoscale_max_replicas hodnotu, abyste zvýšili maximální počet replik.

  • Změňte minimální počet replik. Zvýšení minimálních replik poskytuje větší fond pro zpracování příchozích špiček.

    Pokud chcete zvýšit minimální počet replik, nastavte autoscale_min_replicas na vyšší hodnotu. Požadované repliky můžete vypočítat pomocí následujícího kódu a nahradit hodnoty hodnotami specifickými pro váš projekt:

    from math import ceil
    # target requests per second
    targetRps = 20
    # time to process the request (in seconds)
    reqTime = 10
    # Maximum requests per container
    maxReqPerContainer = 1
    # target_utilization. 70% in this example
    targetUtilization = .7
    
    concurrentRequests = targetRps * reqTime / targetUtilization
    
    # Number of container replicas
    replicas = ceil(concurrentRequests / maxReqPerContainer)
    

    Poznámka:

    Pokud obdržíte špičky požadavků větší než nové minimální repliky, můžete znovu obdržet 503s. Například při nárůstu provozu do vaší služby možná budete muset zvýšit minimální počet replik.

Další informace o nastavení autoscale_target_utilizationa autoscale_max_replicasautoscale_min_replicas pro naleznete v referenčních informacích k modulu AksWebservice.

Stavový kód HTTP 504

Stavový kód 504 označuje, že vypršel časový limit požadavku. Výchozí časový limit je 1 minuta.

Časový limit můžete zvýšit nebo se pokusit službu urychlit úpravou score.py, aby se odebrala nepotřebná volání. Pokud tyto akce problém neopraví, použijte informace v tomto článku k ladění souboru score.py. Kód může být v nereagování nebo nekonečné smyčce.

Další chybové zprávy

Proveďte tyto akce pro následující chyby:

Chyba Rozlišení
Chyba 409 konfliktu Pokud už operace probíhá, všechny nové operace ve stejné webové službě reagují na chybu 409 konfliktu. Pokud například probíhá operace vytvoření nebo aktualizace webové služby a pokud aktivujete novou operaci odstranění, dojde k chybě.
Selhání vytváření obrázků při nasazování webové služby Přidání "pynacl==1.2.1" jako závislost pip do souboru Conda pro konfiguraci image
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Změňte skladovou položku pro virtuální počítače použité v nasazení na skladovou položku, která má více paměti.
Selhání FPGA Modely nemůžete nasadit na FPGA, dokud nebudete požádáni a schváleni pro kvótu FPGA. Pokud chcete požádat o přístup, vyplňte formulář žádosti o kvótu: https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR2nac9-PZhBDnNSV2ITz0LNUN0U5S0hXRkNITk85QURTWk9ZUUFUWkkyTC4u

Pokročilé ladění

Možná budete muset interaktivně ladit kód Pythonu ve vašem nasazení modelu. Pokud například selhává vstupní skript a důvod není možné určit pomocí dodatečného protokolování. Pomocí editoru Visual Studio Code a ladicího programu se můžete připojit k kódu spuštěného uvnitř kontejneru Dockeru.

Další informace najdete v průvodci interaktivním laděním v editoru VS Code.

Fórum pro uživatele nasazení modelu

Další kroky

Další informace o nasazení: