Share via


Problemen met externe modelimplementatie oplossen

Meer informatie over het oplossen en oplossen van veelvoorkomende fouten die kunnen optreden bij het implementeren van een model in 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. Neem contact op met AKS-ondersteuning als u hulp nodig hebt bij het oplossen van problemen met AKS-clusters.

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 het omgevingsobject 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 er een nieuwe Docker-installatiekopie in de cloud gebouwd en opgeslagen in het standaardcontainerregister van uw werkruimte.
  3. De Docker-installatiekopieën uit 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() het 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 Docker zijn 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 op te halen van een geïmplementeerde webservice:

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. Raadpleeg het lokale artikel over probleemoplossing om lokaal problemen met een implementatie op te lossen.

HTTP-server voor azure Machine Learning-deductie

Met de lokale deductieserver kunt u snel fouten opsporen in uw invoerscript (score.py). Als het onderliggende scorescript een fout heeft, kan de server het model niet initialiseren of leveren. In plaats daarvan genereert het een uitzondering en de locatie waar de problemen zich hebben voorgedaan. 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 score.py deze in 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 u een service implementeert in een Rekendoel van Azure Kubernetes Service, probeert Azure Machine Learning 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 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 opgelost door meer knooppunten toe te voegen als u een GPU-SKU gebruikt, overschakelt naar een SKU met GPU als u niet of als u uw omgeving niet wijzigt om GPU's te vereisen.

Starten van 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 onopgeslagen uitzonderingen in de init() functie zijn, ziet u mogelijk de fout CrashLoopBackOff 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 op een Rekendoel van Azure Container Instance, 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 zien 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 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 scorescript 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 fouten in deze fout op te sporen, is door de onderstaande Python-code uit te voeren in de Container Shell:

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 van /var/azureml-app) afgedrukt in de container waarin het scorescript verwacht het modelbestand of de map te vinden. Vervolgens kunt u controleren of het bestand of de map inderdaad de locatie is waar het naar verwachting is.

Als u het logboekregistratieniveau instelt op DEBUG, kan er extra informatie worden vastgelegd. Dit kan handig zijn bij het identificeren van de fout.

Functie mislukt: uitvoeren (input_data)

Als de service is geïmplementeerd, maar deze vastloopt wanneer u gegevens naar het score-eindpunt plaatst, kunt u in uw run(input_data) functie foutopname-instructie toevoegen, zodat er in plaats daarvan een gedetailleerd foutbericht wordt geretourneerd. Voorbeeld:

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 moet alleen worden uitgevoerd voor foutopsporing. Om veiligheidsredenen moet u op deze manier geen foutberichten retourneren in een productieomgeving.

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 ter ondersteuning van extra belasting. 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, duurt het 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 autoscale_target_utilization, worden er meer replica's gemaakt. Als deze lager is, worden replica's verminderd. Beslissingen om replica's toe te voegen zijn gretig en snel (ongeveer 1 seconde). Beslissingen om replica's te verwijderen zijn conservatief (ongeveer 1 minuut). Het doelgebruik voor automatisch schalen is standaard 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.

  • Wijzig het gebruiksniveau waarop automatisch schalen nieuwe replica's maakt. U kunt het gebruiksdoel aanpassen door de autoscale_target_utilization waarde 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 het gebruik van 30% plaatsvindt.

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

  • Het minimum aantal replica's wijzigen. Het verhogen van de minimumreplica's biedt een grotere groep voor het afhandelen van de binnenkomende pieken.

    Als u het minimum aantal replica's wilt verhogen, stelt u deze 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_max_replicasen voor meer informatie over het instellenautoscale_target_utilization, en autoscale_min_replicas voor meer informatie.

HTTP-statuscode 504

Een 504-statuscode geeft aan dat er een time-out optreedt 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 verhelpen, gebruikt u de informatie in dit artikel om fouten op te sporen in het score.py-bestand. De code heeft mogelijk een niet-responsieve status of een oneindige lus.

Andere foutberichten

Voer deze acties uit voor de volgende fouten:

Error Oplossing
Fout 409-conflict Wanneer er al een bewerking wordt uitgevoerd, reageert elke nieuwe bewerking op diezelfde webservice met een conflictfout van 409. 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 een 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 vm met meer geheugen.
FPGA-fout U kunt geen modellen implementeren op FPGA's totdat u hebt aangevraagd en goedgekeurd voor het FPGA-quotum. Als u toegang wilt aanvragen, vult u het aanvraagformulier voor quota in: https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR2nac9-PZhBDnNSV2ITz0LNUN0U5S0hXRkNITk85QURTWk9ZUUFUWkkyTC4u

Geavanceerde foutopsporing

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

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

Gebruikersforum voor modelimplementatie

Volgende stappen

Meer informatie over implementatie: