Felsöka distribution av fjärrmodeller
Lär dig hur du felsöker och löser vanliga fel som kan uppstå när du distribuerar en modell till Azure Container Instances (ACI) och Azure Kubernetes Service (AKS) med hjälp av Azure Machine Learning.
Kommentar
Om du distribuerar en modell till Azure Kubernetes Service (AKS) rekommenderar vi att du aktiverar Azure Monitor för klustret. Detta hjälper dig att förstå övergripande klusterhälsa och resursanvändning. Följande resurser kan också vara användbara:
- Sök efter Resource Health-händelser som påverkar ditt AKS-kluster
- Azure Kubernetes Service-diagnostik
Om du försöker distribuera en modell till ett felaktigt eller överbelastat kluster är det väntat att det uppstår problem. Kontakta AKS-supporten om du behöver hjälp med att felsöka problem med AKS-kluster.
Förutsättningar
En Azure-prenumeration. Prova den kostnadsfria eller betalda versionen av Azure Machine Learning.
CLI-tillägget v1 för Azure Machine Learning.
Viktigt!
Några av Azure CLI-kommandona i den här artikeln använder
azure-cli-ml
tillägget , eller v1, för Azure Machine Learning. Stödet för v1-tillägget upphör den 30 september 2025. Du kommer att kunna installera och använda v1-tillägget fram till det datumet.Vi rekommenderar att du övergår till
ml
tillägget , eller v2, före den 30 september 2025. Mer information om v2-tillägget finns i Azure ML CLI-tillägget och Python SDK v2.
Steg för Docker-distribution av maskininlärningsmodeller
När du distribuerar en modell till icke-lokal beräkning i Azure Machine Learning händer följande:
- Den Dockerfile som du angav i miljöobjektet i inferenskonfigurationen skickas till molnet, tillsammans med innehållet i källkatalogen
- Om en tidigare skapad avbildning inte är tillgänglig i containerregistret skapas en ny Docker-avbildning i molnet och lagras i arbetsytans standardcontainerregister.
- Docker-avbildningen från containerregistret laddas ned till beräkningsmålet.
- Din arbetsytas standardbloblager är monterad på beräkningsmålet, vilket ger dig åtkomst till registrerade modeller
- Webbservern initieras genom att köra postskriptets
init()
funktion - När din distribuerade modell tar emot en begäran hanterar funktionen
run()
den begäran
Den största skillnaden när du använder en lokal distribution är att containeravbildningen bygger på den lokala datorn, vilket är anledningen till att du måste ha Docker installerat för en lokal distribution.
Att förstå de här stegen på hög nivå bör hjälpa dig att förstå var fel inträffar.
Hämta distributionsloggar
Det första steget i felsökningsfel är att hämta distributionsloggarna. Följ först anvisningarna här för att ansluta till din arbetsyta.
GÄLLER FÖR: Azure CLI ml-tillägget v1
Gör så här för att hämta loggarna från en distribuerad webbtjänst:
az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>
Felsöka lokalt
Om du har problem när du distribuerar en modell till ACI eller AKS distribuerar du den som en lokal webbtjänst. Med en lokal webbtjänst blir det enklare att felsöka problem. Information om hur du felsöker en distribution lokalt finns i artikeln om lokal felsökning.
HTTP-server för Azure Machine Learning-slutsatsdragning
Med den lokala slutsatsdragningsservern kan du snabbt felsöka ditt postskript (score.py
). Om det underliggande poängskriptet har en bugg kan servern inte initiera eller hantera modellen. I stället genereras ett undantag och platsen där problemen uppstod. Läs mer om HTTP Server för Azure Machine Learning-slutsatsdragning
azureml-inference-server-http
Installera paketet från pypi-feeden:python -m pip install azureml-inference-server-http
Starta servern och ange
score.py
som inmatningsskript:azmlinfsrv --entry_script score.py
Skicka en bedömningsbegäran till servern med hjälp av
curl
:curl -p 127.0.0.1:5001/score
Kommentar
Lär dig vanliga frågor och svar om Azure Machine Learning Inference HTTP-server.
Det går inte att schemalägga containern
När du distribuerar en tjänst till ett Azure Kubernetes Service-beräkningsmål försöker Azure Machine Learning schemalägga tjänsten med den begärda mängden resurser. Om det inte finns några tillgängliga noder i klustret med rätt mängd resurser efter 5 minuter misslyckas distributionen. Felmeddelandet är Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00
. Du kan åtgärda det här felet genom att antingen lägga till fler noder, ändra SKU:n för dina noder eller ändra resurskraven för din tjänst.
Felmeddelandet anger vanligtvis vilken resurs du behöver mer av, till exempel om du ser ett felmeddelande som anger 0/3 nodes are available: 3 Insufficient nvidia.com/gpu
att tjänsten kräver GPU:er och att det finns tre noder i klustret som inte har tillgängliga GPU:er. Detta kan åtgärdas genom att lägga till fler noder om du använder en GPU SKU, växla till en GPU-aktiverad SKU om du inte är det eller ändra din miljö för att inte kräva GPU:er.
Det går inte att starta tjänsten
När avbildningen har skapats försöker systemet starta en container med hjälp av distributionskonfigurationen. Som en del av containerns startprocess anropas funktionen init()
i bedömningsskriptet av systemet. Om det finns ohanterade undantag i init()
funktionen kan felet CrashLoopBackOff visas i felmeddelandet.
Använd informationen i artikeln Granska Docker-loggen .
Det går inte att starta containern azureml-fe-aci
När du distribuerar en tjänst till ett Azure Container Instance-beräkningsmål försöker Azure Machine Learning skapa en klientdelscontainer som har namnet azureml-fe-aci
på inferensbegäran. Om azureml-fe-aci
kraschar kan du se loggar genom att köra az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci
. Du kan följa felmeddelandet i loggarna för att åtgärda problemet.
Det vanligaste felet för azureml-fe-aci
är att det angivna SSL-certifikatet eller nyckeln är ogiltigt.
Funktionen misslyckas: get_model_path()
I funktionen i init()
bedömningsskriptet anropas ofta funktionen Model.get_model_path() för att hitta en modellfil eller en mapp med modellfiler i containern. Om modellfilen eller mappen inte kan hittas misslyckas funktionen. Det enklaste sättet att felsöka det här felet är att köra Python-koden nedan i Container Shell:
GÄLLER FÖR: 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'))
Det här exemplet skriver ut den lokala sökvägen (relativt /var/azureml-app
) i containern där ditt bedömningsskript förväntar sig att hitta modellfilen eller mappen. Sedan kan du kontrollera om filen eller mappen verkligen är där den förväntas vara.
Om loggningsnivån anges till FELSÖKNING kan ytterligare information loggas, vilket kan vara användbart för att identifiera felet.
Funktionen misslyckas: run(input_data)
Om tjänsten har distribuerats, men den kraschar när du publicerar data till bedömningsslutpunkten, kan du lägga till instruktionen felfångst i funktionen run(input_data)
så att den returnerar ett detaljerat felmeddelande i stället. Till exempel:
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})
Obs! Att returnera felmeddelanden från anropet run(input_data)
bör endast utföras i felsökningssyfte. Av säkerhetsskäl bör du inte returnera felmeddelanden på det här sättet i en produktionsmiljö.
HTTP-statuskod 502
En 502-statuskod anger att tjänsten har genererat ett undantag eller kraschat i metoden för run()
score.py-filen. Använd informationen i den här artikeln för att felsöka filen.
HTTP-statuskod 503
Azure Kubernetes Service-distributioner stöder automatisk skalning, vilket gör att repliker kan läggas till för extra belastning. Autoskalningen är utformad för att hantera gradvisa belastningsändringar. Om du får stora toppar i begäranden per sekund kan klienterna få http-statuskoden 503. Även om autoskalningen reagerar snabbt tar det lång tid för AKS att skapa fler containrar.
Beslut om att skala upp/ned baseras på användningen av de aktuella containerreplikerna. Antalet repliker som är upptagna (bearbetar en begäran) dividerat med det totala antalet aktuella repliker är den aktuella användningen. Om det här antalet överskrider autoscale_target_utilization
skapas fler repliker. Om den är lägre minskas replikerna. Beslut om att lägga till repliker är ivriga och snabba (cirka 1 sekund). Beslut om att ta bort repliker är konservativa (cirka 1 minut). Som standard är målanvändningen för automatisk skalning inställd på 70 %, vilket innebär att tjänsten kan hantera toppar i begäranden per sekund (RPS) på upp till 30 %.
Det finns två saker som kan hjälpa dig att förhindra 503-statuskoder:
Dricks
Dessa två metoder kan användas individuellt eller i kombination.
Ändra användningsnivån där autoskalning skapar nya repliker. Du kan justera användningsmålet genom att ange
autoscale_target_utilization
ett lägre värde.Viktigt!
Den här ändringen gör inte att repliker skapas snabbare. I stället skapas de med ett lägre användningströskelvärde. I stället för att vänta tills tjänsten används till 70 % skapas repliker när 30 % användning sker när värdet ändras till 30 %.
Om webbtjänsten redan använder de aktuella maxreplikerna och du fortfarande ser 503 statuskoder ökar
autoscale_max_replicas
du värdet för att öka det maximala antalet repliker.Ändra det minsta antalet repliker. Om du ökar minimireplikerna får du en större pool för att hantera inkommande toppar.
Om du vill öka det minsta antalet repliker anger du
autoscale_min_replicas
till ett högre värde. Du kan beräkna de repliker som krävs med hjälp av följande kod och ersätta värden med värden som är specifika för projektet: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)
Kommentar
Om du får toppar för begäranden som är större än de nya minsta replikerna kan hantera kan du få 503:or igen. När trafiken till tjänsten till exempel ökar kan du behöva öka de minsta replikerna.
Mer information om hur du anger , och autoscale_min_replicas
för finns i referensen för AksWebservice-modulen. autoscale_max_replicas
autoscale_target_utilization
HTTP-statuskod 504
En 504-statuskod anger att begäran har överskriden tidsgräns. Standardtimeouten är 1 minut.
Du kan öka tidsgränsen eller försöka påskynda tjänsten genom att ändra score.py för att ta bort onödiga anrop. Om dessa åtgärder inte åtgärdar problemet använder du informationen i den här artikeln för att felsöka score.py-filen. Koden kan vara i ett icke-dynamiskt tillstånd eller en oändlig loop.
Andra felmeddelanden
Utför följande åtgärder för följande fel:
Fel | Åtgärd |
---|---|
409-konfliktfel | När en åtgärd redan pågår svarar alla nya åtgärder på samma webbtjänst med 409-konfliktfel. Om till exempel åtgärden skapa eller uppdatera webbtjänsten pågår och om du utlöser en ny borttagningsåtgärd utlöser den ett fel. |
Fel vid avbildningsskapande vid distribution av webbtjänst | Lägg till "pynacl==1.2.1" som ett pip-beroende till Conda-filen för avbildningskonfiguration |
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> |
Ändra SKU:n för virtuella datorer som används i distributionen till en som har mer minne. |
FPGA-fel | Du kan inte distribuera modeller på FPGA förrän du har begärt och godkänts för FPGA-kvoten. Om du vill begära åtkomst fyller du i formuläret för kvotbegäran: https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR2nac9-PZhBDnNSV2ITz0LNUN0U5S0hXRkNITk85QURTWk9ZUUFUWkkyTC4u |
Avancerad felsökning
Du kan behöva felsöka Python-koden i modelldistributionen interaktivt. Om till exempel postskriptet misslyckas och orsaken inte kan fastställas med extra loggning. Genom att använda Visual Studio Code och felsökningsverktyget kan du ansluta till koden som körs i Docker-containern.
Mer information finns i den här guiden för interaktiv felsökning i VS Code.
Användarforum för modelldistribution
Nästa steg
Lär dig mer om distribution: