Share via


Problemen met externe modelimplementatie oplossen

Meer informatie over het oplossen van veelvoorkomende fouten die kunnen optreden bij het implementeren van een model naar Azure Container Instances (ACI) en Azure Kubernetes Service (AKS) met behulp van Azure Machine Learning.

Notitie

Als u een model implementeert naar Azure Kubernetes Service (AKS), wordt u aangeraden Azure Monitor voor dat cluster in te schakelen. Dit helpt u inzicht te krijgen in de algehele clusterstatus en het resourcegebruik. Mogelijk vindt u de volgende resources ook nuttig:

Als u een model wilt implementeren in een cluster dat niet in orde of overbelast is, levert dit waarschijnlijk problemen op. Als u hulp nodig hebt bij het oplossen van problemen met AKS-clusters, neemt u contact op met de ondersteuning van AKS.

Vereisten

Stappen voor docker-implementatie van machine learning-modellen

Wanneer u een model implementeert op niet-lokale berekeningen in Azure Machine Learning, gebeurt het volgende:

  1. Het Dockerfile dat u hebt opgegeven in uw Environments-object in uw InferenceConfig, wordt verzonden naar de cloud, samen met de inhoud van uw bronmap
  2. Als een eerder gemaakte installatiekopie niet beschikbaar is in uw containerregister, wordt een nieuwe Docker-installatiekopie gebouwd in de cloud en opgeslagen in het standaardcontainerregister van uw werkruimte.
  3. De Docker-installatiekopieën van uw containerregister worden gedownload naar uw rekendoel.
  4. De standaard blobopslag van uw werkruimte is gekoppeld aan uw rekendoel, zodat u toegang hebt tot geregistreerde modellen
  5. Uw webserver wordt geïnitialiseerd door de functie van init() uw invoerscript uit te voeren
  6. Wanneer uw geïmplementeerde model een aanvraag ontvangt, verwerkt uw run() functie die aanvraag

Het belangrijkste verschil bij het gebruik van een lokale implementatie is dat de containerinstallatiekopie is gebouwd op uw lokale computer. Daarom moet u Docker hebben geïnstalleerd voor een lokale implementatie.

Als u deze stappen op hoog niveau begrijpt, kunt u beter begrijpen waar fouten optreden.

Implementatielogboeken ophalen

De eerste stap bij foutopsporingsfouten is het ophalen van uw implementatielogboeken. Volg eerst de instructies hier om verbinding te maken met uw werkruimte.

VAN TOEPASSING OP:Azure CLI ml-extensie v1

Ga als volgende te werk om de logboeken van een geïmplementeerde webservice op te halen:

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Lokaal fouten opsporen

Als u problemen ondervindt bij het implementeren van een model in ACI of AKS, implementeert u het als een lokale webservice. Het gebruik van een lokale webservice maakt het gemakkelijker om problemen op te lossen. Als u lokaal problemen met een implementatie wilt oplossen, raadpleegt u het artikel over lokale probleemoplossing.

HTTP-server voor Azure Machine Learning-deductie

Met de lokale deductieserver kunt u snel fouten opsporen in uw invoerscript (score.py). Als er een fout optreedt in het onderliggende scorescript, kan de server het model niet initialiseren of bedienen. In plaats daarvan wordt er een uitzondering & gegenereerd op de locatie waar de problemen zijn opgetreden. Meer informatie over http-server voor Azure Machine Learning-deductie

  1. Installeer het azureml-inference-server-http pakket vanuit de pypi-feed :

    python -m pip install azureml-inference-server-http
    
  2. Start de server en stel in score.py als het invoerscript:

    azmlinfsrv --entry_script score.py
    
  3. Verzend een scoreaanvraag naar de server met behulp van curl:

    curl -p 127.0.0.1:5001/score
    

Notitie

Meer informatie over veelgestelde vragen over Deductie-HTTP-server voor Azure Machine Learning.

Container kan niet worden gepland

Wanneer een service wordt geïmplementeerd in een Azure Kubernetes Service-rekendoel, wordt getracht de service te plannen met de aangevraagde hoeveelheid resources. Als er na vijf minuten geen knooppunten beschikbaar zijn in het cluster met de juiste hoeveelheid resources, mislukt de implementatie. Het foutbericht is Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. U kunt deze fout oplossen door meer knooppunten toe te voegen, de SKU van uw knooppunten te wijzigen of de resourcevereisten van uw service te wijzigen.

Het foutbericht geeft meestal aan van welke resource u meer nodig hebt, bijvoorbeeld als u een foutbericht ziet dat aangeeft 0/3 nodes are available: 3 Insufficient nvidia.com/gpu dat de service GPU's vereist en dat er drie knooppunten in het cluster zijn die geen beschikbare GPU's hebben. Dit kan worden verholpen door meer knooppunten toe te voegen als u een GPU-SKU gebruikt, over te schakelen naar een SKU met GPU als dat niet het geval is of door uw omgeving te wijzigen zodat er geen GPU's nodig zijn.

Het starten van de service mislukt

Nadat de installatiekopie is gemaakt, probeert het systeem een container te starten met behulp van uw implementatieconfiguratie. Als onderdeel van het opstartproces van de container wordt de functie init() in uw scorescript door het systeem aangeroepen. Als er niet-betrapte uitzonderingen in de init() functie zijn, ziet u mogelijk de crashLoopBackOff-fout in het foutbericht.

Gebruik de informatie in het artikel Het Docker-logboek controleren .

Starten van container azureml-fe-aci mislukt

Wanneer u een service implementeert in een Azure Container Instance-rekendoel, probeert Azure Machine Learning een front-endcontainer te maken met de naam azureml-fe-aci voor de deductieaanvraag. Als azureml-fe-aci het vastloopt, kunt u logboeken bekijken door uit te voeren az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. U kunt het foutbericht in de logboeken volgen om de oplossing te maken.

De meest voorkomende fout voor azureml-fe-aci is dat het opgegeven SSL-certificaat of de opgegeven SSL-sleutel ongeldig is.

Functie mislukt: get_model_path()

Vaak wordt in de init() functie in het scoring-script Model.get_model_path() aangeroepen om een modelbestand of een map met modelbestanden in de container te zoeken. Als het modelbestand of de map niet kan worden gevonden, mislukt de functie. De eenvoudigste manier om deze fout op te sporen, is door de onderstaande Python-code uit te voeren in de containershell:

VAN TOEPASSING OP: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'))

In dit voorbeeld wordt het lokale pad (ten opzichte /var/azureml-appvan ) afgedrukt in de container waar het scorescript verwacht het modelbestand of de map te vinden. Vervolgens kunt u controleren of het bestand of de map zich inderdaad op de verwachte locatie bevindt.

Als u het logboekregistratieniveau instelt op FOUTOPSPORING, wordt er mogelijk aanvullende informatie geregistreerd, wat handig kan zijn bij het identificeren van de fout.

Functie mislukt: uitvoeren(input_data)

Als de service is geïmplementeerd, maar vastloopt wanneer u gegevens naar het score-eindpunt post, kunt u de instructie voor het ondervangen van fouten toevoegen aan uw run(input_data) functie, zodat deze in plaats daarvan een gedetailleerd foutbericht retourneert. Bijvoorbeeld:

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})

Opmerking: het retourneren van foutberichten van de run(input_data) aanroep mag alleen worden uitgevoerd voor foutopsporing. Om veiligheidsredenen moet u in een productieomgeving geen foutberichten op deze manier retourneren.

HTTP-statuscode 502

Een 502-statuscode geeft aan dat de service een uitzondering heeft gegenereerd of is vastgelopen in de run() methode van het score.py-bestand. Gebruik de informatie in dit artikel om fouten in het bestand op te sporen.

HTTP-statuscode 503

Azure Kubernetes Service implementaties ondersteunen automatisch schalen, waardoor replica's kunnen worden toegevoegd om extra belasting te ondersteunen. De automatische schaalaanpassing is ontworpen voor het afhandelen van geleidelijke wijzigingen in de belasting. Als u grote pieken in aanvragen per seconde ontvangt, ontvangen clients mogelijk een HTTP-statuscode 503. Hoewel de automatische schaalaanpassing snel reageert, kost het AKS een aanzienlijke hoeveelheid tijd om meer containers te maken.

Beslissingen voor omhoog/omlaag schalen zijn gebaseerd op het gebruik van de huidige containerreplica's. Het aantal replica's dat bezet is (een aanvraag verwerken) gedeeld door het totale aantal huidige replica's is het huidige gebruik. Als dit aantal groter is dan autoscale_target_utilization, worden er meer replica's gemaakt. Als de replica lager is, worden de replica's verminderd. Beslissingen voor het toevoegen van replica's zijn enthousiast en snel (ongeveer 1 seconde). Beslissingen voor het verwijderen van replica's zijn conservatief (ongeveer 1 minuut). Standaard is het doelgebruik voor automatisch schalen ingesteld op 70%, wat betekent dat de service pieken in aanvragen per seconde (RPS) van maximaal 30% kan verwerken.

Er zijn twee dingen die kunnen helpen bij het voorkomen van 503-statuscodes:

Tip

Deze twee benaderingen kunnen afzonderlijk of in combinatie worden gebruikt.

  • Het gebruiksniveau wijzigen waarop met automatisch schalen nieuwe replica's worden gemaakt. U kunt het gebruiksdoel aanpassen door de autoscale_target_utilization in te stellen op een lagere waarde.

    Belangrijk

    Deze wijziging zorgt er niet voor dat replica's sneller worden gemaakt. In plaats daarvan worden ze gemaakt met een lagere gebruiksdrempel. In plaats van te wachten totdat de service 70% wordt gebruikt, zorgt het wijzigen van de waarde in 30% ervoor dat replica's worden gemaakt wanneer 30% gebruik plaatsvindt.

    Als de webservice al gebruikmaakt van het huidige maximumaantal replica's en u nog steeds statuscodes van 503 ziet, verhoogt u de autoscale_max_replicas waarde om het maximum aantal replica's te verhogen.

  • Wijzig het minimum aantal replica's. Het verhogen van de minimumreplica's biedt een grotere pool om de binnenkomende pieken af te handelen.

    Als u het minimum aantal replica's wilt verhogen, stelt u in autoscale_min_replicas op een hogere waarde. U kunt de vereiste replica's berekenen met behulp van de volgende code, waarbij u waarden vervangt door waarden die specifiek zijn voor uw project:

    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)
    

    Notitie

    Als u aanvraagpieken ontvangt die groter zijn dan de nieuwe minimumreplica's kunnen verwerken, ontvangt u mogelijk opnieuw 503's. Als het verkeer naar uw service bijvoorbeeld toeneemt, moet u mogelijk de minimale replica's verhogen.

Zie de naslaginformatie over de AksWebservice-module voor meer informatie over het instellen autoscale_target_utilizationautoscale_max_replicasvan , en autoscale_min_replicas voor.

HTTP-statuscode 504

Een 504-statuscode geeft aan dat er een time-out is opgetreden voor de aanvraag. De standaardtime-out is 1 minuut.

U kunt de time-out verhogen of de service versnellen door de score.py te wijzigen om onnodige aanroepen te verwijderen. Als deze acties het probleem niet oplossen, gebruikt u de informatie in dit artikel om fouten op te sporen in het score.py-bestand. De code kan zich in een niet-responsieve status of een oneindige lus bevinden.

Andere foutberichten

Voer de volgende acties uit voor de volgende fouten:

Fout Oplossing
409-conflictfout Wanneer een bewerking al wordt uitgevoerd, reageert elke nieuwe bewerking op dezelfde webservice met een 409-conflictfout. Als er bijvoorbeeld een webservicebewerking wordt gemaakt of bijgewerkt en u een nieuwe verwijderbewerking activeert, treedt er een fout op.
Fout bij het bouwen van installatiekopieën bij het implementeren van de webservice Voeg 'pynacl==1.2.1' toe als pip-afhankelijkheid aan conda-bestand voor installatiekopieconfiguratie
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Wijzig de SKU voor VM's die in uw implementatie worden gebruikt in een SKU met meer geheugen.
FPGA-fout U kunt pas modellen implementeren op FPGA's als u een FPGA-quotum hebt aangevraagd en goedgekeurd. Als u toegang wilt aanvragen, vult u het formulier quotumaanvraag in: https://aka.ms/aml-real-time-ai

Geavanceerde foutopsporing

Mogelijk moet u interactief fouten opsporen in de Python-code die in uw modelimplementatie is opgenomen. Bijvoorbeeld als het invoerscript mislukt en de reden niet kan worden bepaald door extra logboekregistratie. Met behulp van Visual Studio Code en de foutopsporing kunt u koppelen aan de code die wordt uitgevoerd in de Docker-container.

Ga naar de interactieve foutopsporing in de Visual Studio Code-handleiding voor meer informatie.

Gebruikersforum voor modelimplementatie

Volgende stappen

Meer informatie over implementatie: