Dela via

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 azure Mašinsko učenje.

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:

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 Mašinsko učenje händer följande:

  1. Den Dockerfile som du angav i miljöobjektet i inferenskonfigurationen 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 standardbloblager är monterad på beräkningsmålet, vilket ger dig åtkomst till registrerade modeller
  5. Webbservern initieras genom att köra postskriptets init() funktion
  6. 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 Mašinsko učenje-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 Mašinsko učenje-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

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 Mašinsko učenje 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 Mašinsko učenje 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 å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_utilizationskapas 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_replicasautoscale_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: