Távoli modell üzembe helyezésének hibaelhárítása
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 Learning használatával történő üzembe helyezésekor előforduló gyakori hibákat.
Feljegyzé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:
- Az AKS-fürtöt befolyásoló erőforrásállapot-események keresése
- Azure Kubernetes Service – Diagnosztika
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
Egy Azure-előfizetés. Próbálja ki az Azure Machine Learning ingyenes vagy fizetős verzióját.
Az Azure CLI.
Az Azure Machine Learning cli-bővítménye 1.
Fontos
A cikkben szereplő Azure CLI-parancsok némelyike az
azure-cli-ml
Azure Machine Learning bővítményét vagy v1-et használja. A v1-bővítmény támogatása 2025. szeptember 30-án megszűnik. Addig a dátumig telepítheti és használhatja a v1-bővítményt.Javasoljuk, hogy 2025. szeptember 30-a előtt váltsa át a
ml
(vagy v2) bővítményt. További információ a v2-es bővítményről: Azure ML CLI-bővítmény és Python SDK v2.
A gépi tanulási modellek Docker-üzembe helyezésének lépései
Amikor nem helyi számításra helyez üzembe egy modellt az Azure Machine Learningben, a következő dolgok történnek:
- Az InferenceConfig környezetobjektumában megadott Dockerfile a forráskönyvtár tartalmával együtt a felhőbe kerül
- 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.
- A rendszer letölti a tárolóregisztrációs adatbázis Docker-rendszerképét a számítási célra.
- 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
- A webkiszolgáló inicializálása a bejegyzésszkript függvényének
init()
futtatásával történik - 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 Learning-következtetés 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 Learning következtetési HTTP-kiszolgálójáról
Telepítse a csomagot a
azureml-inference-server-http
pypi-hírcsatornából :python -m pip install azureml-inference-server-http
Indítsa el a kiszolgálót, és állítsa be
score.py
belépési szkriptként:azmlinfsrv --entry_script score.py
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
Feljegyzés
Megismerheti az Azure Machine Learning Inference HTTP-kiszolgálóval kapcsolatos gyakori kérdéseket .
A tároló nem ütemezhető
Amikor üzembe helyez egy szolgáltatást egy Azure Kubernetes Service számítási célon, az Azure Machine Learning 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 Learning 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-aci
lá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:
A KÖVETKEZŐKRE VONATKOZIK: 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-app
viszonyí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élda:
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)
Feljegyzé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_utilization
autoscale_max_replicas
autoscale_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.
Egyéb hibaüzenetek
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://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR2nac9-PZhBDnNSV2ITz0LNUN0U5S0hXRkNITk85QURTWk9ZUUFUWkkyTC4u |
Speciális hibakeresés
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
Következő lépések
További információk az üzembe helyezésről: