Felsöka distribution av fjärrmodeller

  • Artikel

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.

Anteckning

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:

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

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:

  1. Den Dockerfile som du angav i miljöobjektet i inferenceConfig skickas till molnet, tillsammans med innehållet i källkatalogen
  2. Om en tidigare skapad avbildning inte är tillgänglig i containerregistret skapas en ny Docker-avbildning i molnet och lagras i arbetsytans standardcontainerregister.
  3. Docker-avbildningen från containerregistret laddas ned till beräkningsmålet.
  4. Din arbetsytas standardbloblagring är monterad på beräkningsmålet, vilket ger dig åtkomst till registrerade modeller
  5. Webbservern initieras genom att köra startskriptets init() funktion
  6. När den distribuerade modellen 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å dessa övergripande steg 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ägg v1

Så här hämtar du 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 med att distribuera 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 den lokala felsökningsartikeln.

HTTP-server för Azure Machine Learning-slutsatsdragning

Med den lokala slutsatsdragningsservern kan du snabbt felsöka ditt inmatningsskript (score.py). Om det underliggande poängskriptet har ett fel kan servern inte initiera eller hantera modellen. I stället utlöser det ett undantag & på den plats där problemen uppstod. Läs mer om HTTP-server för Azure Machine Learning-slutsatsdragning

  1. azureml-inference-server-http Installera paketet från pypi-feeden:

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

  2. Starta servern och ange score.py som inmatningsskript:

    azmlinfsrv --entry_script score.py

  3. Skicka en bedömningsbegäran till servern med hjälp av curl:

    curl -p 127.0.0.1:5001/score

Anteckning

Läs vanliga frågor och svar om HTTP-servern för Azure Machine Learning-slutsatsdragning.

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 det begärda antalet resurser. Om det inte finns några noder tillgängliga 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ö så att den inte kräver 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 Inspektera Docker-loggen .

Det går inte att starta containern azureml-fe-aci

När du distribuerar en tjänst till ett beräkningsmål för Azure Container Instance försöker Azure Machine Learning skapa en klientdelscontainer som har namnet azureml-fe-aci på slutsatsdragningsbegä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 göra korrigeringen.

Det vanligaste felet för azureml-fe-aci är att det angivna SSL-certifikatet eller SSL-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'))

I det här exemplet skrivs den lokala sökvägen (relativt /var/azureml-app) ut i containern där bedömningsskriptet 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 detaljerade felmeddelanden i stället. 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! Du bör bara returnera felmeddelanden från anropet run(input_data) 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

Statuskoden 502 anger att tjänsten har genererat ett undantag eller kraschat i metoden för run() den 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 antalet överskrider autoscale_target_utilizationskapas fler repliker. Om den är lägre minskas replikerna. Beslut om att lägga till repliker är snabba 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:

Tips

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 till 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änds om värdet ändras till 30 %.

    Om webbtjänsten redan använder de aktuella maximala replikerna 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. Genom att öka 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)

    Anteckning

    Om du får toppar i begäranden som är större än de nya minsta replikerna kan hantera kan du få 503-fel igen. När trafiken till tjänsten till exempel ökar kan du behöva öka de minsta replikerna.

Mer information om hur du anger autoscale_target_utilization, autoscale_max_replicasoch autoscale_min_replicas för finns i modulreferensen för AksWebservice .

HTTP-statuskod 504

Statuskoden 504 anger att tidsgränsen för begäran har överskrids. Standardtidsgränsen ä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 de här åtgärderna 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-responsivt tillstånd eller en oändlig loop.

Andra felmeddelanden

Utför följande åtgärder för följande fel:

Fel Lösning
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.
Det gick inte att skapa avbildningar när webbtjänsten distribueras 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 kommer inte att kunna 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://aka.ms/aml-real-time-ai

Avancerad felsökning

Du kan behöva felsöka Python-koden i modelldistributionen interaktivt. Om till exempel inmatningsskriptet misslyckas och orsaken inte kan fastställas genom extra loggning. Genom att använda Visual Studio Code och felsökningen 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: