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

  • Článek

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

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í do Dockeru

Když ve službě Azure Machine Learning nasadíte model do jiných než místních výpočetních prostředků, dojde k následujícím věcem:

  1. Soubor Dockerfile, který jste zadali v objektu Environment v inferenceConfig, se společně s obsahem zdrojového adresáře odešle do cloudu.
  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 vašeho 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, takže máte 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, zpracuje ho vaše run() funkce.

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, což je důvod, proč musíte mít pro místní nasazení nainstalovaný Docker.

Pochopení těchto podrobných kroků by vám mělo pomoct pochopit, kde dochází k chybám.

Získání protokolů nasazení

Prvním krokem při ladění chyb je získání protokolů nasazení. Nejdřív se podle pokynů tady 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, udělejte toto:

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íží. Informace o řešení potíží s místním nasazením najdete v článku o řešení potíží s místním prostředím.

Server HTTP pro odvozovací službu Azure Machine Learning

Místní server pro odvozování umožňuje rychlé ladění zaváděcího skriptu (score.py). V případě chyby v podkladovém skriptu skóre se serveru nepodaří inicializovat nebo obsloužit model. Místo toho vyvolá výjimku & v umístění, kde k problémům došlo. Další informace o odvozovacím SERVERU HTTP ve službě 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 jako vstupní skript:

    azmlinfsrv --entry_script score.py

  3. Odešlete na server žádost o bodování pomocí curlpříkazu :

    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 objektu Azure Kubernetes Service se služba Azure Machine Learning pokusí pro službu naplánovat požadované množství prostředků. Pokud v clusteru nejsou po 5 minutách k dispozici žádné uzly s odpovídajícím množstvím prostředků, nasazení selže. Chybová zpráva 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ů vaší služby na prostředky.

Chybová zpráva obvykle indikuje, kterého prostředku potřebujete více – například pokud se zobrazí chybová zpráva, 0/3 nodes are available: 3 Insufficient nvidia.com/gpu která znamená, že služba vyžaduje GPU a že v clusteru jsou tři uzly, které nemají k dispozici 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 ji nemáte, nebo změnou prostředí tak, aby gpu nevyžaduje.

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 pro požadavek na odvozování. Pokud azureml-fe-aci dojde k chybě, zobrazí se protokoly spuštěním příkazu az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. Pokud chcete provést opravu, postupujte podle chybové zprávy v protokolech.

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

Selhání funkce: get_model_path()

Často se ve init() funkci v hodnoticího skriptu volá funkce Model.get_model_path(), která v kontejneru vyhledá soubor modelu nebo složku se soubory modelu. Pokud soubor nebo složku modelu nelze najít, funkce selže. Nejjednodušší způsob, jak tuto chybu ladit, je spustit následující kód Pythonu v prostředí Container Shell:

PLATÍ PRO:Sada 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 (relativní k /var/azureml-app) v kontejneru, kde váš hodnoticí skript očekává, že najde soubor nebo složku 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 LADIT může způsobit protokolování dalších informací, což může být užitečné při identifikaci selhání.

Selhání funkce: run(input_data)

Pokud je služba úspěšně nasazená, ale při odesílání dat do bodujícího koncového bodu dojde k chybě, můžete do funkce run(input_data) přidat příkaz pro zachytávání chyb, aby místo toho vrátila 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 v produkčním prostředí neměli vracet chybové zprávy tímto způsobem.

Stavový kód HTTP 502

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

Stavový kód HTTP 503

Azure Kubernetes Service nasazení podporují automatické škálování, které umožňuje přidat repliky pro podporu dodatečného zatížení. Automatické škálování je navržené tak, aby zvládlo postupné změny zatížení. Pokud dojde k velkým špičkám v požadavcích za sekundu, klienti můžou obdržet stavový kód HTTP 503. I když automatické škálování rychle reaguje, trvá AKS poměrně dlouho, než vytvoří více kontejnerů.

Rozhodnutí o vertikálním navýšení/snížení kapacity vychází z využití aktuálních replik kontejneru. 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 tento počet překročí autoscale_target_utilization, vytvoří se další repliky. 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 využití cíle automatického škálování nastavené na 70 %, což znamená, že služba dokáže zpracovat špičky v žádostech za sekundu (RPS) až o 30 %.

Stavové kódy 503 můžou pomoct zabránit dvěma věcem:

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 vytvářejí při nižší prahové hodnotě využití. Místo čekání na 70% využití služby změna hodnoty na 30 % způsobí vytvoření replik, když dojde k 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, aby se zvýšil maximální počet replik.

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

    Pokud chcete zvýšit minimální počet replik, nastavte autoscale_min_replicas 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ž jsou nové minimální repliky, můžete znovu obdržet 503. Například s nárůstem provozu do vaší služby může být potřeba zvýšit minimální počet replik.

Další informace o nastavení autoscale_target_utilization, autoscale_max_replicasa autoscale_min_replicas pro najdete 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 prodloužit nebo se pokusit službu urychlit úpravou score.py, aby se odebrala nepotřebná volání. Pokud tyto akce problém nevyřeší, použijte informace v tomto článku k ladění score.py souboru. Kód může být v nereagivním stavu nebo v nekonečné smyčce.

Další chybové zprávy

V případě následujících chyb proveďte tyto akce:

Chyba Řešení
Chyba 409 – konflikt Pokud už nějaká operace probíhá, každá nová operace ve stejné webové službě bude reagovat konfliktní chybou 409. Pokud například probíhá operace vytvoření nebo aktualizace webové služby a aktivujete novou operaci Odstranění, vyvolá se chyba.
Selhání vytváření image při nasazování webové služby Přidání pynacl==1.2.1 jako závislosti 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žívané ve vašem nasazení na skladovou položku, která má více paměti.
Selhání FPGA Dokud nepožádáte o kvótu FPGA, nebudete moct nasazovat modely na FPGA. Pokud chcete požádat o přístup, vyplňte formulář žádosti o kvótu: https://aka.ms/aml-real-time-ai

Pokročilé ladění

Možná budete muset interaktivně ladit kód Pythonu ve vašem nasazení modelu. Například pokud zaváděcí skript selhává a důvod nelze určit dodatečným protokolováním. Pomocí editoru Visual Studio Code a nástroje debugpy se můžete připojit ke kódu spuštěného uvnitř kontejneru Dockeru.

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

Uživatelské fórum pro nasazení modelu

Další kroky

Další informace o nasazení: