Share via

Távoli modell üzembe helyezésének hibaelhárítása

  • Cikk

Megtudhatja, hogyan háríthatja el és oldhatja meg vagy háríthatja el a modellek Azure Container Instancesben (ACI) és Azure Kubernetes Service-ben (AKS) az Azure Machine Tanulás használatával történő üzembe helyezésekor előforduló gyakori hibákat.

Megjegyzés:

Ha az Azure Kubernetes Service-ben (AKS-ben) helyez üzembe modellt, javasoljuk, hogy engedélyezze az Azure Monitort a fürt esetében. Ez segít értelmezni a fürt általános állapotát és erőforrás-használatát. A következő forrásanyagokat is hasznosnak találhatja:

Ha a modellt nem megfelelő állapotú vagy túlterhelt fürtön próbál üzembe helyezni, várhatóan problémákat fog tapasztalni. Ha segítségre van szüksége az AKS-fürt problémáinak elhárításához, forduljon az AKS ügyfélszolgálatához.

Előfeltételek

A gépi tanulási modellek Docker-üzembe helyezésének lépései

Amikor nem helyi számítási környezetben helyez üzembe modellt az Azure Machine Tanulás, a következő dolgok történnek:

  1. Az InferenceConfig környezetobjektumában megadott Dockerfile a forráskönyvtár tartalmával együtt a felhőbe kerül
  2. Ha egy korábban létrehozott rendszerkép nem érhető el a tárolóregisztrációs adatbázisban, a rendszer egy új Docker-rendszerképet hoz létre a felhőben, és a munkaterület alapértelmezett tárolóregisztrációs adatbázisában tárolja.
  3. A rendszer letölti a tárolóregisztrációs adatbázis Docker-rendszerképét a számítási célra.
  4. A munkaterület alapértelmezett blobtárolója a számítási célhoz van csatlakoztatva, így hozzáférést biztosít a regisztrált modellekhez
  5. A webkiszolgáló inicializálása a bejegyzésszkript függvényének init() futtatásával történik
  6. Amikor az üzembe helyezett modell kérést kap, a run() függvény kezeli a kérést

A helyi telepítés használatakor a fő különbség az, hogy a tárolólemezkép a helyi gépre épül, ezért telepítenie kell a Dockert egy helyi üzembe helyezéshez.

Ezeknek a magas szintű lépéseknek a megértése segít megérteni, hogy hol fordulnak elő hibák.

Üzembehelyezési naplók lekérése

A hibakeresési hibák első lépése az üzembehelyezési naplók lekérése. Először kövesse az itt leírt utasításokat a munkaterülethez való csatlakozáshoz.

A KÖVETKEZŐre vonatkozik: Azure CLI ml-bővítmény 1-es verzió

A naplók üzembe helyezett webszolgáltatásból való lekéréséhez tegye a következőt:

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

Helyi hibakeresés

Ha problémákat tapasztal egy modell ACI-ben vagy AKS-ben való üzembe helyezésekor, telepítse azt helyi webszolgáltatásként. Helyi webszolgáltatás használatával könnyebben háríthatók el a problémák. Az üzembe helyezés helyi hibaelhárításáról a helyi hibaelhárítási cikkből olvashat.

Azure Machine Tanulás következtetési HTTP-kiszolgáló

A helyi következtetési kiszolgáló lehetővé teszi a bejegyzésszkript (score.py) gyors hibakeresését. Ha a mögöttes pontszámszkript hibát észlelt, a kiszolgáló nem tudja inicializálni vagy kiszolgálni a modellt. Ehelyett kivételt jelez – a probléma helyének helyét. További információ az Azure Machine Tanulás következtetési HTTP-kiszolgálóról

  1. Telepítse a csomagot a azureml-inference-server-httppypi-hírcsatornából :

    python -m pip install azureml-inference-server-http

  2. Indítsa el a kiszolgálót, és állítsa be score.py belépési szkriptként:

    azmlinfsrv --entry_script score.py

  3. Pontozási kérés küldése a kiszolgálónak a következő használatával curl:

    curl -p 127.0.0.1:5001/score

Megjegyzés:

Megismerheti az Azure Machine Learning Inference HTTP-kiszolgálóval kapcsolatos gyakori kérdéseket .

A tároló nem ütemezhető

Amikor egy szolgáltatást üzembe helyez egy Azure Kubernetes Service számítási célon, az Azure Machine Tanulás megpróbálja ütemezni a szolgáltatást a kért mennyiségű erőforrással. Ha a fürtben 5 perc után nem érhetők el csomópontok a megfelelő mennyiségű erőforrással, az üzembe helyezés sikertelen lesz. A hibaüzenet a következő Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00: . Ezt a hibát több csomópont hozzáadásával, a csomópontok termékváltozatának módosításával vagy a szolgáltatás erőforrás-követelményeinek módosításával oldhatja meg.

A hibaüzenet általában azt jelzi, hogy melyik erőforrásra van nagyobb szüksége – például ha hibaüzenet jelenik meg, amely azt jelzi 0/3 nodes are available: 3 Insufficient nvidia.com/gpu , hogy a szolgáltatás gpu-kat igényel, és a fürtben három csomópont van, amelyek nem rendelkeznek elérhető GPU-kkal. Ez úgy oldható meg, hogy további csomópontokat ad hozzá GPU-termékváltozat használata esetén, ha nem, vagy ha nem módosítja a környezetet, hogy ne igényeljen GPU-t.

A szolgáltatás elindítása meghiúsul

A rendszerkép sikeres létrehozása után a rendszer megpróbál elindítani egy tárolót az üzembe helyezési konfigurációval. A tároló indítási folyamatának részeként a rendszer a pontozószkript init() függvényét hívja meg. Ha a függvény nem tartalmaz kivételeketinit(), előfordulhat, hogy a hibaüzenetben CrashLoopBackOff hiba jelenik meg.

Használja a Docker-napló vizsgálatával foglalkozó cikkben található információkat.

Az azureml-fe-aci tároló elindítása meghiúsul

Amikor egy szolgáltatást üzembe helyez egy Azure Container Instance számítási célon, az Azure Machine Tanulás megpróbál létrehozni egy olyan előtér-tárolót, amely a következtetési kérelem nevével azureml-fe-aci rendelkezik. Ha azureml-fe-aci összeomlik, a naplók a futtatásukkal az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aciláthatók. A javítás elvégzéséhez kövesse a naplókban megjelenő hibaüzenetet.

A leggyakoribb hiba azureml-fe-aci az, hogy a megadott SSL-tanúsítvány vagy kulcs érvénytelen.

A függvény meghiúsul: get_model_path()

A pontozószkript függvényében init() gyakran Model.get_model_path() függvényt hív meg egy modellfájl vagy egy modellfájlok mappájának megkereséséhez a tárolóban. Ha a modellfájl vagy mappa nem található, a függvény meghiúsul. A hiba hibakeresésének legegyszerűbb módja az alábbi Python-kód futtatása a Container Shellben:

ÉRVÉNYES: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'))

Ez a példa a helyi elérési utat nyomtatja ki (ahhoz /var/azureml-appviszonyítva) abban a tárolóban, ahol a pontozószkript a modellfájl vagy -mappa megkeresésére számít. Ezután ellenőrizheti, hogy a fájl vagy mappa valóban ott van-e, ahol az elvárt.

Ha a naplózási szintet HIBAKERESÉSre állítja, további információk naplózhatók, ami hasznos lehet a hiba azonosításához.

A függvény meghiúsul: run(input_data)

Ha a szolgáltatás sikeresen üzembe lett helyezve, de összeomlik, amikor adatokat küld a pontozási végpontra, hozzáadhat hibalefogó utasítást a run(input_data) függvényhez, hogy ehelyett részletes hibaüzenetet adjon vissza. Például:

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

Megjegyzés: A hívásból érkező run(input_data) hibaüzeneteket csak hibakeresési célból szabad visszaadni. Biztonsági okokból nem szabad így hibaüzeneteket küldeni éles környezetben.

502-es HTTP-állapotkód

Az 502-ben megadott állapotkód azt jelzi, hogy a szolgáltatás kivételt okozott vagy összeomlott a run() score.py fájl metódusában. A cikkben található információk segítségével hibakeresést végezhet a fájlban.

503-as HTTP-állapotkód

Az Azure Kubernetes Service üzembe helyezései támogatják az automatikus skálázást, amely lehetővé teszi a replikák hozzáadását a többletterhelés támogatásához. Az automatikus skálázási funkció a terhelés fokozatos változásainak kezelésére lett kialakítva. Ha másodpercenként nagy számú kérelem jelenik meg, az ügyfelek 503-ra szóló HTTP-állapotkódot kaphatnak. Annak ellenére, hogy az automatikus skálázási eszköz gyorsan reagál, az AKS jelentős mennyiségű időt vesz igénybe, hogy több tárolót hozzon létre.

A vertikális fel- és leskálázási döntések az aktuális tárolóreplikák kihasználtságán alapulnak. Az elfoglalt replikák száma (kérés feldolgozása) és az aktuális replikák teljes száma osztva az aktuális kihasználtság. Ha ez a szám meghaladja autoscale_target_utilization, több replika jön létre. Ha alacsonyabb, akkor a replikák csökkennek. A replikák hozzáadására vonatkozó döntések lelkesek és gyorsak (körülbelül 1 másodperc). A replikák eltávolítására vonatkozó döntések konzervatívak (körülbelül 1 perc). Alapértelmezés szerint az automatikus skálázási célkihasználtság 70%-ra van állítva, ami azt jelenti, hogy a szolgáltatás akár 30%-os másodpercenkénti kérelmek (RPS) kiugró számát is képes kezelni.

Két dolog segíthet megelőzni az 503-at:

Tipp.

Ez a két megközelítés külön-külön vagy együttesen is használható.

  • Módosítsa azt a kihasználtsági szintet, amelyen az automatikus skálázás új replikákat hoz létre. A kihasználtsági célt alacsonyabb értékre állíthatja autoscale_target_utilization .

    Fontos

    Ez a módosítás nem eredményezi a replikák gyorsabb létrehozását. Ehelyett alacsonyabb kihasználtsági küszöbértéknél jönnek létre. Ahelyett, hogy megvárja a szolgáltatás 70%-os kihasználtságát, az érték 30%-ra történő módosítása replikákat hoz létre 30%-os kihasználtság esetén.

    Ha a webszolgáltatás már használja az aktuális maximális replikákat, és továbbra is 503 állapotkód jelenik meg, növelje az autoscale_max_replicas értéket a replikák maximális számának növeléséhez.

  • Módosítsa a replikák minimális számát. A minimális replikák számának növelése nagyobb készletet biztosít a bejövő kiugró értékek kezeléséhez.

    A replikák minimális számának növeléséhez állítsa magasabb autoscale_min_replicas értékre. A szükséges replikákat a következő kóddal számíthatja ki, és az értékeket a projektre jellemző értékekre cserélheti:

    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)

    Megjegyzés:

    Ha az új minimális replikák által kezeltnél nagyobb kérelmeket kap, előfordulhat, hogy ismét 503-as érték jelenik meg. A szolgáltatás felé irányuló forgalom növekedésével például előfordulhat, hogy növelnie kell a minimális replikákat.

A beállítással és a beállítással autoscale_target_utilizationautoscale_max_replicasautoscale_min_replicas kapcsolatos további információkért tekintse meg az AksWebservice modul referenciáit.

504-es HTTP-állapotkód

Az 504-ben megadott állapotkód azt jelzi, hogy a kérés túllépte az időkorlátot. Az alapértelmezett időtúllépés 1 perc.

Növelheti az időtúllépést, vagy felgyorsíthatja a szolgáltatást a szükségtelen hívások eltávolításához szükséges score.py módosításával. Ha ezek a műveletek nem javítják a problémát, a cikkben található információk segítségével hibakeresést végezhet a score.py fájlban. A kód lehet nem válaszkész állapotban vagy végtelen ciklusban.

Other error messages

Hajtsa végre az alábbi műveleteket a következő hibák esetén:

Hiba Resolution (Osztás)
409-ütközési hiba Ha egy művelet már folyamatban van, ugyanazon a webszolgáltatáson lévő új műveletek 409 ütközési hibával válaszolnak. Ha például a webszolgáltatás létrehozása vagy frissítése folyamatban van, és ha új törlési műveletet indít el, az hibát jelez.
Képkészítési hiba a webszolgáltatás üzembe helyezésekor Adja hozzá a "pynacl==1.2.1" értéket pipfüggőségként a Conda-fájlhoz a képkonfigurációhoz
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Módosítsa az üzembe helyezés során használt virtuális gépek termékváltozatát olyanra, amely több memóriával rendelkezik.
FPGA-hiba Nem helyezhet üzembe modelleket az FPGA-kon, amíg nem kérte és nem hagyta jóvá az FPGA-kvótát. A hozzáférés kéréséhez töltse ki a kvótakérelmet: https://aka.ms/aml-real-time-ai

Advanced debugging

Előfordulhat, hogy interaktív hibakeresést kell végeznie a modell üzemelő példányában található Python-kódon. Ha például a belépési szkript meghiúsul, és az ok nem határozható meg további naplózással. A Visual Studio Code és a hibakereső használatával csatolhatja a Docker-tárolóban futó kódhoz.

További információért tekintse meg a VS Code-ban való interaktív hibakeresés útmutatóját.

Modell üzembehelyezési felhasználói fóruma

További lépések

További információk az üzembe helyezésről: