Felsöka distribution av fjärrmodell

Lär dig hur du felsöker och löser eller 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 förväntas det uppleva problem. Kontakta AKS-supporten om du behöver hjälp med att felsöka AKS-klusterproblem.

Förutsättningar

Steg för Docker-distribution av maskininlärningsmodeller

När du distribuerar en modell till en icke-lokal Azure Machine Learning sker följande:

  1. Den Dockerfile som du angav i environments-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, byggs en ny Docker-avbildning i molnet och lagras i arbetsytans standardcontainerregister.
  3. Docker-avbildningen från containerregistret laddas ned till beräkningsmålet.
  4. Arbetsytans standardbloblager är monterat på beräkningsmålet, vilket ger dig åtkomst till registrerade modeller
  5. Webbservern initieras genom att köra inmatningsskriptets init() -funktion
  6. När den distribuerade modellen tar emot en begäran hanterar run() funktionen den begäran

Den största skillnaden när du använder en lokal distribution är att containeravbildningen är byggd 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 avancerade stegen bör hjälpa dig att förstå var fel uppstår.

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.

Om du vill hämta loggarna från en distribuerad webbtjänst gör du så här:

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-slutsatsledning

Med den lokala inferensservern kan du snabbt felsöka inmatningsskriptet ( score.py ). Om det underliggande poängskriptet har en bugg kommer servern inte att initiera eller betjäna modellen. I stället lösts ett undantagsfel & platsen där problemen inträffade. Läs mer om http Azure Machine Learning härledning

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

    python -m pip install azureml-inference-server-http
    
  2. Starta servern och ange score.py som startskript:

    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
    

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 att tjänsten kräver GPU:er och det finns tre noder i klustret som inte har tillgängliga 0/3 nodes are available: 3 Insufficient nvidia.com/gpu GPU:er. Detta kan åtgärdas genom att lägga till fler noder om du använder en GPU-SKU och växlar till en GPU-aktiverad SKU om du inte ändrar 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 processen för att starta containrar init() anropas funktionen i ditt bedömningsskript av systemet. Om det finns undantag utan fel i init() funktionen kan du se CrashLoopBackOff-fel i felmeddelandet.

Använd informationen i artikeln Granska Docker-loggen.

Funktionen misslyckas: get_model_path()

I funktionen i bedömningsskriptet anropas ofta Model.get_model_path() för att hitta en modellfil eller en mapp med init() modellfiler i containern. Om inte modellfilen eller mappen hittas misslyckas funktionen. Det enklaste sättet att felsöka det här felet är att köra Python-koden nedan i Container Shell:

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 (i förhållande till ) i containern där bedömningsskriptet förväntar /var/azureml-app sig att hitta modellfilen eller mappen. Sedan kan du kontrollera om filen eller mappen verkligen är där den förväntas vara.

Om du ställer in loggningsnivån på DEBUG 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 ett felinfångat uttryck i funktionen så att den returnerar run(input_data) detaljerade felmeddelanden i stället. Ett 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 endast returnera run(input_data) felmeddelanden från anropet för felsökning. 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 utlöst 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 att stödja ytterligare 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 ytterligare containrar.

Beslut om att skala upp/ned baseras på användningen av de aktuella containerreplikerna. Antalet repliker som är upptagna (bearbetning av en begäran) dividerat med det totala antalet aktuella repliker är den aktuella användningen. Om det här antalet autoscale_target_utilization överskrider skapas fler repliker. Om den är lägre minskas replikerna. Beslut om att lägga till repliker är otåliga och snabba (cirka 1 sekund). Beslut om att ta bort repliker är försiktigare (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 den användningsnivå 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 tröskelvärde för användning. I stället för att vänta tills tjänsten används till 70 % och värdet ändras till 30 % skapas repliker när 30 % användning sker.

    Om webbtjänsten redan använder det aktuella maxantalet repliker och du fortfarande ser 503 statuskoder ökar du värdet för att öka det autoscale_max_replicas maximala antalet repliker.

  • Ändra det minsta antalet repliker. Om du ökar de minsta replikerna 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 nödvändiga replikerna med hjälp av följande kod och ersätta värden med värden som är specifika för ditt projekt:

    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äran som är större än de nya minsta replikerna kan hantera kan du få 503 återigen. När trafiken till tjänsten till exempel ökar kan du behöva öka det minsta antalet repliker.

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

HTTP-statuskod 504

Statuskoden 504 anger att begäran har tagit för lång tid. Standardtidsinställningen ä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

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

Fel Lösning
Fel vid avbildningsskapande vid distribution av webbtjänst Lägg till "pynacl==1.2.1" som ett pip-beroende till Conda-filen för bildkonfiguration
['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 av ytterligare loggning. Genom att Visual Studio Code och felsökningspyen kan du ansluta till koden som körs i Docker-containern.

Mer information finns i den interaktiva felsökningsguiden i VS Code.

Användarforum för modelldistribution

Nästa steg

Lär dig mer om distribution: