Online-eindpunten en -implementaties voor realtime deductie

Artikel
05/02/2024

VAN TOEPASSING OP:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (current)

Met Azure Machine Learning kunt u realtime deductie uitvoeren op gegevens met behulp van modellen die zijn geïmplementeerd op online-eindpunten. Deductie is het proces van het toepassen van nieuwe invoergegevens op een machine learning-model om uitvoer te genereren. Hoewel deze uitvoer doorgaans 'voorspellingen' wordt genoemd, kan deductie worden gebruikt om uitvoer te genereren voor andere machine learning-taken, zoals classificatie en clustering.

Online-eindpunten

Online-eindpunten implementeren modellen op een webserver die voorspellingen onder het HTTP-protocol kan retourneren. Gebruik online-eindpunten om modellen operationeel te maken voor realtime deductie in synchrone aanvragen met lage latentie. U wordt aangeraden deze te gebruiken wanneer:

U hebt vereisten voor lage latentie
Uw model kan de aanvraag in relatief korte tijd beantwoorden
De invoer van uw model past bij de HTTP-nettolading van de aanvraag
U moet omhoog schalen met betrekking tot het aantal aanvragen

Als u een eindpunt wilt definiëren, moet u het volgende opgeven:

Eindpuntnaam: deze naam moet uniek zijn in de Azure-regio. Zie eindpuntlimieten voor meer informatie over de naamgevingsregels.
Verificatiemodus: u kunt kiezen uit de verificatiemodus op basis van sleutels, verificatiemodus op basis van Azure Machine Learning-tokens of verificatie op basis van Microsoft Entra-token (preview) voor het eindpunt. Zie Verifiëren bij een online-eindpunt voor meer informatie over verificatie.

Azure Machine Learning biedt het gemak van het gebruik van beheerde online-eindpunten voor het implementeren van uw machine learning-modellen op een kant-en-klare manier. Dit is de aanbevolen manier om online-eindpunten te gebruiken in Azure Machine Learning. Beheerde online-eindpunten werken met krachtige CPU- en GPU-machines in Azure op een schaalbare, volledig beheerde manier. Deze eindpunten zorgen ook voor het leveren, schalen, beveiligen en bewaken van uw modellen, om u te helpen bij het instellen en beheren van de onderliggende infrastructuur. Zie Het eindpunt definiëren voor meer informatie over het definiëren van een beheerd online-eindpunt.

Waarom kiezen voor beheerde online-eindpunten via ACI of AKS(v1)?

Het gebruik van beheerde online-eindpunten is de aanbevolen manier om online-eindpunten te gebruiken in Azure Machine Learning. In de volgende tabel worden de belangrijkste kenmerken van beheerde online-eindpunten vergeleken met Azure Machine Learning SDK/CLI v1-oplossingen (ACI en AKS(v1)).

Kenmerken	Beheerde online-eindpunten (v2)	ACI of AKS(v1)
Netwerkbeveiliging/isolatie	Eenvoudig inkomend/uitgaand besturingselement met snelle wisselknop	Virtueel netwerk wordt niet ondersteund of vereist complexe handmatige configuratie
Beheerde service	- Volledig beheerde compute-inrichting/schaalaanpassing - Netwerkconfiguratie voor preventie van gegevensexfiltratie - Upgrade van hostbesturingssysteem, gecontroleerde implementatie van in-place updates	- Schalen is beperkt in v1 - Netwerkconfiguratie of -upgrade moet worden beheerd door de gebruiker
Eindpunt/implementatieconcept	Onderscheid tussen eindpunt en implementatie maakt complexe scenario's mogelijk, zoals een veilige implementatie van modellen	Geen concept van eindpunt
Diagnose en controle	- Foutopsporing van lokaal eindpunt mogelijk met Docker en Visual Studio Code - Geavanceerde analyse van metrische gegevens en logboeken met grafiek/query om te vergelijken tussen implementaties - Uitsplitsing van kosten naar implementatieniveau	Geen eenvoudige lokale foutopsporing
Schaalbaarheid	Onbeperkt, elastisch en automatisch schalen	- ACI is niet schaalbaar - AKS (v1) ondersteunt alleen in-clusterschaal en vereist schaalbaarheidsconfiguratie
Gereedheid voor bedrijven	Private Link, door de klant beheerde sleutels, Microsoft Entra ID, quotabeheer, factureringsintegratie, SLA	Niet ondersteund
Geavanceerde ML-functies	- Gegevensverzameling modelleren - Modelbewaking - Champion-challenger model, veilige implementatie, verkeersspiegeling - Verantwoordelijke AI-uitbreidbaarheid	Niet ondersteund

Als u Liever Kubernetes gebruikt om uw modellen te implementeren en eindpunten te leveren en u vertrouwd bent met het beheren van de vereisten voor de infrastructuur, kunt u Gebruikmaken van Kubernetes Online-eindpunten. Met deze eindpunten kunt u modellen implementeren en online-eindpunten leveren op uw volledig geconfigureerde en beheerde Kubernetes-cluster, met CPU's of GPU's.

Waarom beheerde online-eindpunten kiezen via AKS(v2)?

Beheerde online-eindpunten kunnen u helpen uw implementatieproces te stroomlijnen en de volgende voordelen te bieden ten opzichte van Kubernetes online-eindpunten:

Beheerde infrastructuur
- Het model automatisch inrichten en hosten (u hoeft alleen het VM-type en de schaalinstellingen op te geven)
- De onderliggende installatiekopie van het host-besturingssysteem automatisch bijwerken en patches uitvoeren
- Automatisch knooppuntherstel uitvoeren als er een systeemfout optreedt
Bewaking en logboeken
- Bewaak de beschikbaarheid, prestaties en SLA van het model met behulp van systeemeigen integratie met Azure Monitor.
- Fouten opsporen in implementaties met behulp van de logboeken en systeemeigen integratie met Azure Log Analytics.
Kosten weergeven
- Met beheerde online-eindpunten kunt u kosten bewaken op eindpunt- en implementatieniveau
Notitie

Beheerde online-eindpunten zijn gebaseerd op Azure Machine Learning Compute. Wanneer u een beheerd online-eindpunt gebruikt, betaalt u voor de reken- en netwerkkosten. Er is geen extra toeslag. Zie de Azure-prijscalculator voor meer informatie over prijzen.

Als u een virtueel Azure Machine Learning-netwerk gebruikt om uitgaand verkeer van het beheerde online-eindpunt te beveiligen, worden kosten in rekening gebracht voor de uitgaande Azure-koppeling en FQDN-regels die worden gebruikt door het beheerde virtuele netwerk. Zie Prijzen voor beheerd virtueel netwerk voor meer informatie.

Beheerde online-eindpunten versus kubernetes online-eindpunten

In de volgende tabel ziet u de belangrijkste verschillen tussen beheerde online-eindpunten en Kubernetes Online-eindpunten.

	Beheerde online-eindpunten	Kubernetes Online-eindpunten (AKS(v2))
Aanbevolen gebruikers	Gebruikers die een implementatie van een beheerd model en een verbeterde MLOps-ervaring willen	Gebruikers die de voorkeur geven aan Kubernetes en zelf infrastructuurvereisten kunnen beheren
Knooppuntinrichting	Beheerde compute-inrichting, update, verwijdering	Verantwoordelijkheid van gebruikers
Knooppuntonderhoud	Updates van installatiekopieën van beheerde hostbesturingssystemen en beveiligingsmaatregelen	Verantwoordelijkheid van gebruikers
Grootte van cluster (schalen)	Beheerde handmatige en automatische schaalaanpassing, waarbij aanvullende knooppunten worden ingericht	Handmatige en automatische schaalaanpassing, waarbij ondersteuning wordt geboden voor het schalen van het aantal replica's binnen vaste clustergrenzen
Rekentype	Beheerd door de service	Door de klant beheerd Kubernetes-cluster (Kubernetes)
Beheerde identiteit	Ondersteund	Ondersteund
Virtual Network (VNet)	Ondersteund via beheerd netwerkisolatie	Verantwoordelijkheid van gebruikers
Out-of-box bewaking en logboekregistratie	Met Azure Monitor en Log Analytics mogelijk gemaakt (inclusief belangrijke metrische gegevens en logboektabellen voor eindpunten en implementaties)	Verantwoordelijkheid van gebruikers
Logboekregistratie met Application Insights (verouderd)	Ondersteund	Ondersteund
Kosten weergeven	Gedetailleerd naar eindpunt/implementatieniveau	Clusterniveau
Kosten toegepast op	VM's die zijn toegewezen aan de implementaties	VM's die zijn toegewezen aan het cluster
Gespiegeld verkeer	Ondersteund	Niet ondersteund
Implementatie zonder code	Ondersteund (MLflow - en Triton-modellen )	Ondersteund (MLflow - en Triton-modellen )

Online implementaties

Een implementatie is een set resources en berekeningen die nodig zijn voor het hosten van het model dat de werkelijke deductie uitvoert. Eén eindpunt kan meerdere implementaties met verschillende configuraties bevatten. Deze installatie helpt bij het loskoppelen van de interface die door het eindpunt wordt gepresenteerd, van de implementatiedetails die aanwezig zijn in de implementatie. Een online-eindpunt heeft een routeringsmechanisme waarmee aanvragen naar specifieke implementaties in het eindpunt kunnen worden omgeleid.

In het volgende diagram ziet u een online-eindpunt met twee implementaties, blauw en groen. De blauwe implementatie maakt gebruik van VM's met een CPU-SKU en voert versie 1 van een model uit. De groene implementatie maakt gebruik van VM's met een GPU-SKU en voert versie 2 van het model uit. Het eindpunt is geconfigureerd om 90% van het binnenkomende verkeer naar de blauwe implementatie te routeren, terwijl de groene implementatie de resterende 10% ontvangt.

Als u een model wilt implementeren, moet u het volgende hebben:

Modelbestanden (of de naam en versie van een model dat al in uw werkruimte is geregistreerd).
Een scorescript, dat wil gezegd, code waarmee het model wordt uitgevoerd op een bepaalde invoeraanvraag. Het scorescript ontvangt gegevens die zijn verzonden naar een geïmplementeerde webservice en geeft deze door aan het model. Het script voert vervolgens het model uit en retourneert de reactie op de client. Het scorescript is specifiek voor uw model en moet inzicht hebben in de gegevens die het model als invoer verwacht en als uitvoer retourneert.
Een omgeving waarin uw model wordt uitgevoerd. De omgeving kan een Docker-installatiekopieën zijn met Conda-afhankelijkheden of een Dockerfile.
Instellingen om het exemplaartype en de schaalcapaciteit op te geven.

Belangrijkste kenmerken van een implementatie

In de volgende tabel worden de belangrijkste kenmerken van een implementatie beschreven:

Kenmerk	Beschrijving
Naam	De naam van de implementatie.
Naam Eeindpunt	De naam van het eindpunt voor het maken van de implementatie onder.
Model¹	Het model dat moet worden gebruikt voor de implementatie. Deze waarde kan een verwijzing zijn naar een bestaand versiemodel in de werkruimte of een inline modelspecificatie. Zie Modelpad identificeren met betrekking tot `AZUREML_MODEL_DIR`voor meer informatie over het bijhouden en opgeven van het pad naar uw model.
Codepad	Het pad naar de map in de lokale ontwikkelomgeving die alle Python-broncode bevat voor het scoren van het model. U kunt geneste mappen en pakketten gebruiken.
Scorescript	Het relatieve pad naar het scorebestand in de broncodemap. Deze Python-code moet een `init()` functie en een `run()` functie hebben. De `init()` functie wordt aangeroepen nadat het model is gemaakt of bijgewerkt (u kunt deze bijvoorbeeld gebruiken om het model in het geheugen op te cachen). De `run()` functie wordt aangeroepen bij elke aanroep van het eindpunt om de werkelijke score en voorspelling uit te voeren.
Omgeving¹	De omgeving voor het hosten van het model en de code. Deze waarde kan een verwijzing zijn naar een bestaande versieomgeving in de werkruimte of een inline-omgevingsspecificatie. Opmerking: Microsoft patcht regelmatig de basisinstallatiekopieën op bekende beveiligingsproblemen. U moet uw eindpunt opnieuw implementeren om de patchinstallatiekopie te gebruiken. Als u uw eigen installatiekopieën opgeeft, bent u verantwoordelijk voor het bijwerken ervan. Zie Installatiekopieën patchen voor meer informatie.
Type instantie	De VM-grootte die moet worden gebruikt voor de implementatie. Zie de lijst met beheerde online-eindpunten voor SKU's voor de lijst met ondersteunde grootten.
Aantal exemplaren	Het aantal exemplaren dat moet worden gebruikt voor de implementatie. Baseer de waarde op de workload die u verwacht. Voor hoge beschikbaarheid raden we u aan om de waarde ten minste `3`in te stellen op . We reserveren een extra 20% voor het uitvoeren van upgrades. Zie quotatoewijzing voor virtuele machines voor implementaties voor meer informatie.

¹ Enkele dingen die u moet weten over het model en de omgeving:

De model- en containerinstallatiekopieën (zoals gedefinieerd in omgeving) kunnen op elk gewenst moment door de implementatie worden verwezen wanneer de exemplaren achter de implementatie beveiligingspatches en/of andere herstelbewerkingen doorlopen. Als u een geregistreerd model of containerinstallatiekopieën in Azure Container Registry gebruikt voor implementatie en het model of de containerinstallatiekopieën verwijdert, kunnen de implementaties die afhankelijk zijn van deze assets mislukken wanneer er opnieuw installatiekopieën worden uitgevoerd. Als u het model of de containerinstallatiekopieën verwijdert, moet u ervoor zorgen dat de afhankelijke implementaties opnieuw worden gemaakt of bijgewerkt met een alternatief model of een containerinstallatiekopieën.

Het containerregister waarnaar de omgeving verwijst, kan alleen privé zijn als de eindpuntidentiteit toegang heeft via Microsoft Entra-verificatie en Azure RBAC. Om dezelfde reden worden andere privé-Docker-registers dan Azure Container Registry niet ondersteund.

Zie Een ML-model implementeren met een online-eindpunt voor meer informatie over het implementeren van online-eindpunten met behulp van de CLI-, SDK-, studio- en ARM-sjabloon.

Modelpad identificeren met betrekking tot `AZUREML_MODEL_DIR`

Wanneer u uw model implementeert in Azure Machine Learning, moet u de locatie opgeven van het model dat u wilt implementeren als onderdeel van uw implementatieconfiguratie. In Azure Machine Learning wordt het pad naar uw model bijgehouden met de AZUREML_MODEL_DIR omgevingsvariabele. Door het modelpad te identificeren met betrekking tot AZUREML_MODEL_DIR, kunt u een of meer modellen implementeren die lokaal zijn opgeslagen op uw computer of een model implementeren dat is geregistreerd in uw Azure Machine Learning-werkruimte.

Ter illustratie verwijzen we naar de volgende lokale mapstructuur voor de eerste twee gevallen waarin u één model implementeert of meerdere modellen implementeert die lokaal zijn opgeslagen:

Eén lokaal model gebruiken in een implementatie

Als u één model wilt gebruiken dat u op uw lokale computer in een implementatie hebt, geeft u de path waarde op in de model YAML van uw implementatie. Hier volgt een voorbeeld van de YAML-implementatie met het pad /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Nadat u de implementatie hebt gemaakt, verwijst de omgevingsvariabele AZUREML_MODEL_DIR naar de opslaglocatie in Azure waar uw model wordt opgeslagen. Bevat bijvoorbeeld /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 het model sample_m1.pkl.

In uw scorescript (score.py) kunt u uw model laden (in dit voorbeeld sample_m1.pkl) in de init() functie:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path)

Meerdere lokale modellen gebruiken in een implementatie

Hoewel u met de Azure CLI, Python SDK en andere clienthulpprogramma's slechts één model per implementatie kunt opgeven in de implementatiedefinitie, kunt u nog steeds meerdere modellen in een implementatie gebruiken door een modelmap te registreren die alle modellen als bestanden of submappen bevat.

In de vorige voorbeeldmapstructuur ziet u dat er meerdere modellen in de models map staan. In uw YAML-implementatie kunt u het pad naar de models map als volgt opgeven:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

In dit voorbeeld ziet de inhoud van de AZUREML_MODEL_DIR map er als volgt uit:

Binnen uw scorescript (score.py) kunt u uw modellen laden in de init() functie. Met de volgende code wordt het sample_m1.pkl model geladen:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path)

Zie Meerdere modellen implementeren in één implementatie (CLI-voorbeeld) en Meerdere modellen implementeren in één implementatie (SDK-voorbeeld) voor een voorbeeld van het implementeren van meerdere modellen in één implementatie.

Tip

Als u meer dan 1500 bestanden wilt registreren, kunt u overwegen de bestanden of submappen te comprimeren als .tar.gz bij het registreren van de modellen. Als u de modellen wilt gebruiken, kunt u de bestanden of submappen in de init() functie uit het scorescript opheffen. Als u de modellen registreert, kunt u de azureml.unpack eigenschap Trueook instellen op , zodat de bestanden of submappen automatisch worden gecomprimeerd. In beide gevallen vindt uncompressie eenmaal plaats in de initialisatiefase.

Modellen gebruiken die zijn geregistreerd in uw Azure Machine Learning-werkruimte in een implementatie

Als u een of meer modellen wilt gebruiken die zijn geregistreerd in uw Azure Machine Learning-werkruimte, geeft u in uw implementatie de naam op van de geregistreerde modellen in uw YAML-implementatie. Met de volgende YAML-implementatieconfiguratie wordt bijvoorbeeld de geregistreerde model naam opgegeven als azureml:local-multimodel:3:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Houd voor dit voorbeeld rekening met local-multimodel:3 de volgende modelartefacten, die kunnen worden weergegeven op het tabblad Modellen in de Azure Machine Learning-studio:

Nadat u de implementatie hebt gemaakt, verwijst de omgevingsvariabele AZUREML_MODEL_DIR naar de opslaglocatie in Azure waar uw modellen worden opgeslagen. Bevat bijvoorbeeld /var/azureml-app/azureml-models/local-multimodel/3 de modellen en de bestandsstructuur. AZUREML_MODEL_DIR verwijst naar de map met de hoofdmap van de modelartefacten. Op basis van dit voorbeeld ziet de inhoud van de AZUREML_MODEL_DIR map er als volgt uit:

Binnen uw scorescript (score.py) kunt u uw modellen laden in de init() functie. Laad bijvoorbeeld het diabetes.sav model:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path)

Quotumtoewijzing voor virtuele machines voor implementatie

Voor beheerde online-eindpunten reserveert Azure Machine Learning 20% van uw rekenresources voor het uitvoeren van upgrades op sommige VM-SKU's. Als u een bepaald aantal exemplaren voor deze VM-SKU's in een implementatie aanvraagt, moet u een quotum hebben dat ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU beschikbaar is om te voorkomen dat er een fout optreedt. Als u bijvoorbeeld 10 exemplaren van een Standard_DS3_v2 VM aanvraagt (die wordt geleverd met vier kernen) in een implementatie, moet u een quotum hebben voor 48 kernen (12 instances * 4 cores) beschikbaar. Dit extra quotum is gereserveerd voor door het systeem geïnitieerde bewerkingen, zoals upgrades van het besturingssysteem en vm-herstel, en er worden geen kosten in rekening gebracht, tenzij dergelijke bewerkingen worden uitgevoerd.

Er zijn bepaalde VM-SKU's die zijn uitgesloten van extra quotumreservering. Als u de volledige lijst wilt bekijken, raadpleegt u de SKU-lijst met beheerde online-eindpunten.

Zie Uw gebruiks- en quotaverhogingen weergeven in Azure Portal om uw gebruik en quota te bekijken. Als u de kosten voor het uitvoeren van een beheerd online-eindpunt wilt bekijken, raadpleegt u De kosten voor een beheerd online-eindpunt weergeven.

Azure Machine Learning biedt een gedeelde quotumgroep waaruit alle gebruikers toegang hebben tot het quotum om gedurende een beperkte tijd tests uit te voeren. Wanneer u de studio gebruikt om Llama-modellen (van de modelcatalogus) te implementeren naar een beheerd online-eindpunt, kunt u met Azure Machine Learning gedurende korte tijd toegang krijgen tot dit gedeelde quotum.

Als u een Llama-2-70b- of Llama-2-70b-chatmodel wilt implementeren, moet u echter een Enterprise Overeenkomst abonnement hebben voordat u het gedeelde quotum kunt implementeren. Zie Basismodellen implementeren met behulp van de studio voor meer informatie over het gebruik van het gedeelde quotum voor online-eindpuntimplementatie.

Zie Quota en limieten beheren en verhogen voor resources met Azure Machine Learning voor meer informatie over quota en limieten voor resources in Azure Machine Learning.

Implementatie voor coders en niet-coders

Azure Machine Learning biedt ondersteuning voor modelimplementatie naar online-eindpunten voor coders en niet-coders, door opties te bieden voor implementatie zonder code, implementatie met weinig code en BYOC-implementatie (Bring Your Own Container).

Implementatie zonder code biedt kant-en-klare deductie voor algemene frameworks (bijvoorbeeld scikit-learn, TensorFlow, PyTorch en ONNX) via MLflow en Triton.
Met implementatie met weinig code kunt u minimale code bieden, samen met uw machine learning-model voor implementatie.
Met BYOC-implementatie kunt u vrijwel alle containers meenemen om uw online-eindpunt uit te voeren. U kunt alle functies van het Azure Machine Learning-platform gebruiken, zoals automatisch schalen, GitOps, foutopsporing en veilige implementatie om uw MLOps-pijplijnen te beheren.

In de volgende tabel worden belangrijke aspecten van de onlineimplementatieopties gemarkeerd:

	Geen code	Weinig code	BYOC
Samenvatting	Maakt gebruik van kant-en-klare deductie voor populaire frameworks zoals scikit-learn, TensorFlow, PyTorch en ONNX, via MLflow en Triton. Zie MLflow-modellen implementeren naar online-eindpunten voor meer informatie.	Maakt gebruik van beveiligde, openbaar gepubliceerde gecureerde installatiekopieën voor populaire frameworks, met updates om de twee weken om beveiligingsproblemen op te lossen. U geeft scorescripts en/of Python-afhankelijkheden op. Zie Azure Machine Learning Gecureerde omgevingen voor meer informatie.	U geeft uw volledige stack op via de ondersteuning van Azure Machine Learning voor aangepaste installatiekopieën. Zie Een aangepaste container gebruiken om een model te implementeren op een online-eindpunt voor meer informatie.
Aangepaste basisinstallatiekopieën	Nee, gecureerde omgeving biedt dit voor eenvoudige implementatie.	Ja en Nee, u kunt een gecureerde afbeelding of uw aangepaste afbeelding gebruiken.	Ja, breng een toegankelijke locatie voor containerinstallatiekopieën (bijvoorbeeld docker.io, Azure Container Registry (ACR) of Microsoft Container Registry (MCR) of een Dockerfile die u kunt bouwen/pushen met ACR voor uw container.
Aangepaste afhankelijkheden	Nee, gecureerde omgeving biedt dit voor eenvoudige implementatie.	Ja, breng de Azure Machine Learning-omgeving waarin het model wordt uitgevoerd; een Docker-installatiekopieën met Conda-afhankelijkheden of een dockerfile.	Ja, dit wordt opgenomen in de containerinstallatiekopieën.
Aangepaste code	Nee, scorescript wordt automatisch gegenereerd voor eenvoudige implementatie.	Ja, breng uw scorescript.	Ja, dit wordt opgenomen in de containerinstallatiekopieën.

Notitie

AutoML-uitvoeringen maken automatisch een scorescript en afhankelijkheden voor gebruikers, zodat u elk AutoML-model kunt implementeren zonder extra code te schrijven (voor implementatie zonder code) of u kunt automatisch gegenereerde scripts aanpassen aan uw bedrijfsbehoeften (voor implementatie met weinig code). Zie Een AutoML-model implementeren met een online-eindpunt voor meer informatie over het implementeren met AutoML-modellen.

Foutopsporing voor online-eindpunten

U wordt ten zeerste aangeraden uw eindpunt lokaal uit te voeren om uw code en configuratie te valideren en fouten op te sporen voordat u in Azure implementeert. Azure CLI en Python SDK ondersteunen lokale eindpunten en implementaties, terwijl Azure Machine Learning-studio en ARM-sjabloon dat niet doen.

Azure Machine Learning biedt verschillende manieren om lokaal fouten in online-eindpunten op te sporen en met behulp van containerlogboeken.

Lokale foutopsporing met HTTP-server voor Azure Machine Learning-deductie
Lokale foutopsporing met lokaal eindpunt
Lokale foutopsporing met lokaal eindpunt en Visual Studio Code
Foutopsporing met containerlogboeken

Lokale foutopsporing met HTTP-server voor Azure Machine Learning-deductie

U kunt lokaal fouten opsporen in uw scorescript met behulp van de HTTP-server van Deductie van Azure Machine Learning. De HTTP-server is een Python-pakket dat uw scorefunctie beschikbaar maakt als een HTTP-eindpunt en de Flask-servercode en afhankelijkheden verpakt in een enkel pakket. Deze wordt opgenomen in de vooraf gemaakte Docker-installatiekopieën voor deductie die worden gebruikt bij het implementeren van een model met Azure Machine Learning. Met behulp van het pakket kunt u het model lokaal implementeren voor productie en kunt u ook eenvoudig uw scorescript (invoerscript) valideren in een lokale ontwikkelomgeving. Als er een probleem is met het scorescript, retourneert de server een fout en de locatie waar de fout is opgetreden. U kunt Visual Studio Code ook gebruiken om fouten op te sporen met de AZURE Machine Learning-deductie-HTTP-server.

Tip

U kunt het Python-pakket azure Machine Learning-deductie http-server gebruiken om lokaal fouten in uw scorescript op te sporen zonder Docker Engine. Foutopsporing met de deductieserver helpt u bij het opsporen van fouten in het scorescript voordat u implementeert op lokale eindpunten, zodat u fouten kunt opsporen zonder dat dit wordt beïnvloed door de configuraties van de implementatiecontainer.

Zie Voor meer informatie over foutopsporing met de HTTP-server debugging scoring script met Azure Machine Learning deductie HTTP-server.

Lokale foutopsporing met lokaal eindpunt

Voor lokale foutopsporing hebt u een lokale implementatie nodig. Dat wil bijvoorbeeld een model dat wordt geïmplementeerd in een lokale Docker-omgeving. U kunt deze lokale implementatie gebruiken voor het testen en opsporen van fouten voordat de implementatie in de cloud wordt uitgevoerd. Als u lokaal wilt implementeren, moet de Docker Engine zijn geïnstalleerd en uitgevoerd. Azure Machine Learning maakt vervolgens een lokale Docker-installatiekopieën die de Azure Machine Learning-installatiekopieën nabootsen. Azure Machine Learning bouwt en voert implementaties voor u lokaal uit en slaat de installatiekopieën in de cache op voor snelle iteraties.

Tip

Docker Engine wordt doorgaans gestart wanneer de computer wordt gestart. Als dat niet het probleem is, kunt u problemen met Docker Engine oplossen. U kunt hulpprogramma's aan de clientzijde, zoals Docker Desktop , gebruiken om fouten op te sporen in wat er in de container gebeurt.

De stappen voor lokale foutopsporing zijn doorgaans:

Controleren of de lokale implementatie is geslaagd
Het lokale eindpunt aanroepen voor deductie
De logboeken voor uitvoer van de aanroepbewerking controleren

Notitie

Lokale eindpunten hebben de volgende beperkingen:

Ze bieden geen ondersteuning voor verkeersregels, verificatie of testinstellingen.
Ze ondersteunen slechts één implementatie per eindpunt.
Ze ondersteunen alleen lokale modelbestanden en omgevingen met lokaal Conda-bestand. Als u geregistreerde modellen wilt testen, moet u ze eerst downloaden met behulp van CLI of SDK en vervolgens in de implementatiedefinitie gebruiken path om naar de bovenliggende map te verwijzen. Als u geregistreerde omgevingen wilt testen, controleert u de context van de omgeving in Azure Machine Learning-studio en bereidt u een lokaal Conda-bestand voor om te gebruiken.

Zie Lokaal implementeren en fouten opsporen met behulp van een lokaal eindpunt voor meer informatie over lokale foutopsporing.

Lokale foutopsporing met lokaal eindpunt en Visual Studio Code (preview)

Belangrijk

Deze functie is momenteel beschikbaar als openbare preview-versie. Deze preview-versie wordt geleverd zonder een service level agreement en we raden deze niet aan voor productieworkloads. Misschien worden bepaalde functies niet ondersteund of zijn de mogelijkheden ervan beperkt.

Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews voor meer informatie.

Net als bij lokale foutopsporing moet eerst de Docker Engine zijn geïnstalleerd en uitgevoerd en vervolgens een model implementeren in de lokale Docker-omgeving. Zodra u een lokale implementatie hebt, gebruiken lokale Azure Machine Learning-eindpunten Docker- en Visual Studio Code-ontwikkelcontainers (dev-containers) om een lokale foutopsporingsomgeving te bouwen en te configureren. Met dev-containers kunt u gebruikmaken van Visual Studio Code-functies, zoals interactieve foutopsporing, vanuit een Docker-container.

Zie Debug online eindpunten lokaal in Visual Studio Code voor meer informatie over interactief foutopsporing van online-eindpunten in VS Code.

Foutopsporing met containerlogboeken

Voor een implementatie kunt u geen directe toegang krijgen tot de VIRTUELE machine waarop het model is geïmplementeerd. U kunt echter logboeken ophalen van enkele van de containers die op de VM worden uitgevoerd. Er zijn twee typen containers waaruit u de logboeken kunt ophalen:

Deductieserver: logboeken bevatten het consolelogboek (van de deductieserver) die de uitvoer van afdruk-/logboekregistratiefuncties van uw scorescript (score.py code) bevat.
Initialisatiefunctie voor opslag: logboeken bevatten informatie over of code- en modelgegevens naar de container zijn gedownload. De container wordt uitgevoerd voordat de container van de deductieserver wordt uitgevoerd.

Zie Containerlogboeken ophalen voor meer informatie over foutopsporing met containerlogboeken.

Verkeersroutering en spiegeling naar onlineimplementaties

Zoals u weet, kan één online-eindpunt meerdere implementaties hebben. Wanneer het eindpunt binnenkomend verkeer (of aanvragen) ontvangt, kan het percentage verkeer naar elke implementatie routeren, zoals wordt gebruikt in de systeemeigen blauw/groene implementatiestrategie. Het kan ook verkeer van de ene implementatie naar de andere spiegelen (of kopiëren), ook wel verkeer spiegelen of schaduwen genoemd.

Verkeersroutering voor blauw/groen implementatie

Blauw/groen-implementatie is een implementatiestrategie waarmee u een nieuwe implementatie (de groene implementatie) kunt implementeren voor een kleine subset van gebruikers of aanvragen voordat u deze volledig uitrolt. Het eindpunt kan taakverdeling implementeren om bepaalde percentages van het verkeer toe te wijzen aan elke implementatie, waarbij de totale toewijzing voor alle implementaties 100% bedraagt.

Tip

Een aanvraag kan de geconfigureerde verkeerstaakverdeling omzeilen door een HTTP-header van azureml-model-deployment. Stel de headerwaarde in op de naam van de implementatie waarnaar u de aanvraag wilt routeren.

In de volgende afbeelding ziet u instellingen in Azure Machine Learning-studio voor het toewijzen van verkeer tussen een blauwe en groene implementatie.

Met deze verkeerstoewijzing wordt verkeer gerouteerd zoals wordt weergegeven in de volgende afbeelding, waarbij 10% van het verkeer naar de groene implementatie gaat en 90% van het verkeer naar de blauwe implementatie gaat.

Verkeer spiegelen naar online-implementaties

Het eindpunt kan ook verkeer van de ene implementatie naar een andere implementatie spiegelen (of kopiëren). Verkeerspiegeling (ook wel schaduwtests genoemd) is handig als u een nieuwe implementatie met productieverkeer wilt testen zonder dat dit van invloed is op de resultaten die klanten ontvangen van bestaande implementaties. Wanneer u bijvoorbeeld een blauw/groene implementatie implementeert waarbij 100% van het verkeer wordt gerouteerd naar blauw en 10% wordt gespiegeld naar de groene implementatie, worden de resultaten van het gespiegelde verkeer naar de groene implementatie niet geretourneerd naar de clients, maar worden de metrische gegevens en logboeken vastgelegd.

Zie Veilige implementatie voor online-eindpunten voor meer informatie over het gebruik van verkeersspiegeling.

Meer mogelijkheden van online-eindpunten in Azure Machine Learning

Verificatie en versleuteling

Verificatie: Sleutel- en Azure Machine Learning-tokens
Beheerde identiteit: Door de gebruiker toegewezen en het systeem toegewezen
SSL standaard voor aanroepen van eindpunten

Automatisch schalen

Automatisch schalen wordt uitgevoerd met de juiste hoeveelheid resources om de belasting van uw toepassing te verwerken. Beheerde eindpunten ondersteunen automatisch schalen via integratie met de functie voor automatische schaalaanpassing van Azure Monitor. U kunt schaalaanpassing op basis van metrische gegevens configureren (bijvoorbeeld CPU-gebruik >70%), schaalaanpassing op basis van planning (bijvoorbeeld schaalregels voor piekuren) of een combinatie.

Schermopname die laat zien dat automatische schaalaanpassing flexibel biedt tussen min- en max-exemplaren, afhankelijk van regels.

Zie Online-eindpunten automatisch schalen voor meer informatie over het configureren van automatische schaalaanpassing.

Beheerde netwerkisolatie

Wanneer u een machine learning-model implementeert in een beheerd online-eindpunt, kunt u de communicatie met het online-eindpunt beveiligen met behulp van privé-eindpunten.

U kunt beveiliging configureren voor binnenkomende scoreaanvragen en uitgaande communicatie met de werkruimte en andere services afzonderlijk. Inkomende communicatie gebruikt het privé-eindpunt van de Azure Machine Learning-werkruimte. Uitgaande communicatie maakt gebruik van privé-eindpunten die zijn gemaakt voor het beheerde virtuele netwerk van de werkruimte.

Zie Netwerkisolatie met beheerde online-eindpunten voor meer informatie.

Online-eindpunten en -implementaties bewaken

Bewaking voor Azure Machine Learning-eindpunten is mogelijk via integratie met Azure Monitor. Met deze integratie kunt u metrische gegevens weergeven in grafieken, waarschuwingen configureren, query's uitvoeren vanuit logboektabellen, Application Insights gebruiken om gebeurtenissen uit gebruikerscontainers te analyseren, enzovoort.

Metrische gegevens: Gebruik Azure Monitor om verschillende metrische eindpuntgegevens bij te houden, zoals latentie van aanvragen en inzoomen op implementatie- of statusniveau. U kunt ook metrische gegevens op implementatieniveau bijhouden, zoals cpu-/GPU-gebruik, en inzoomen op instantieniveau. Met Azure Monitor kunt u deze metrische gegevens bijhouden in grafieken en dashboards en waarschuwingen instellen voor verdere analyse.
Logboeken: Verzend metrische gegevens naar de Log Analytics-werkruimte, waar u logboeken kunt opvragen met behulp van de Kusto-querysyntaxis. U kunt ook metrische gegevens verzenden naar opslagaccounts en/of Event Hubs voor verdere verwerking. Daarnaast kunt u speciale logboektabellen gebruiken voor online-eindpuntgerelateerde gebeurtenissen, verkeer en containerlogboeken. Kusto-query maakt het mogelijk om complexe analyses toe te voegen aan meerdere tabellen.
Application Insights: Gecureerde omgevingen omvatten de integratie met Application Insights en u kunt deze in- of uitschakelen wanneer u een online-implementatie maakt. Ingebouwde metrische gegevens en logboeken worden verzonden naar Application Insights en u kunt de ingebouwde functies zoals Live metrics, Transaction Search, Failures en Performance gebruiken voor verdere analyse.

Zie Online-eindpunten bewaken voor meer informatie over bewaking.

Geheime injectie in online implementaties (preview)

Geheime injectie in de context van een online-implementatie is een proces voor het ophalen van geheimen (zoals API-sleutels) uit geheime archieven en het injecteren ervan in uw gebruikerscontainer die wordt uitgevoerd binnen een online-implementatie. Geheimen zijn uiteindelijk toegankelijk via omgevingsvariabelen, waardoor ze veilig kunnen worden gebruikt door de deductieserver waarop uw scorescript wordt uitgevoerd of door de deductiestack die u met een BYOC-implementatie (Bring Your Own Container) gebruikt.

Er zijn twee manieren om geheimen te injecteren. U kunt geheimen zelf injecteren, beheerde identiteiten gebruiken of u kunt de functie voor geheiminjectie gebruiken. Zie Geheime injectie in online-eindpunten (preview) voor meer informatie over de manieren om geheimen te injecteren.

Online-eindpunten en -implementaties voor realtime deductie

Online-eindpunten

Waarom kiezen voor beheerde online-eindpunten via ACI of AKS(v1)?

Waarom beheerde online-eindpunten kiezen via AKS(v2)?

Beheerde online-eindpunten versus kubernetes online-eindpunten

Online implementaties

Belangrijkste kenmerken van een implementatie

Modelpad identificeren met betrekking tot `AZUREML_MODEL_DIR`

Eén lokaal model gebruiken in een implementatie

Meerdere lokale modellen gebruiken in een implementatie

Modellen gebruiken die zijn geregistreerd in uw Azure Machine Learning-werkruimte in een implementatie

Quotumtoewijzing voor virtuele machines voor implementatie

Implementatie voor coders en niet-coders

Foutopsporing voor online-eindpunten

Lokale foutopsporing met HTTP-server voor Azure Machine Learning-deductie

Lokale foutopsporing met lokaal eindpunt

Lokale foutopsporing met lokaal eindpunt en Visual Studio Code (preview)

Foutopsporing met containerlogboeken

Verkeersroutering en spiegeling naar onlineimplementaties

Verkeersroutering voor blauw/groen implementatie

Verkeer spiegelen naar online-implementaties

Meer mogelijkheden van online-eindpunten in Azure Machine Learning

Verificatie en versleuteling

Automatisch schalen

Beheerde netwerkisolatie

Online-eindpunten en -implementaties bewaken

Geheime injectie in online implementaties (preview)

Volgende stappen

Aanvullende resources

Online-eindpunten en -implementaties voor realtime deductie

Online-eindpunten

Waarom kiezen voor beheerde online-eindpunten via ACI of AKS(v1)?

Waarom beheerde online-eindpunten kiezen via AKS(v2)?

Beheerde online-eindpunten versus kubernetes online-eindpunten

Online implementaties

Belangrijkste kenmerken van een implementatie

Modelpad identificeren met betrekking tot AZUREML_MODEL_DIR

Eén lokaal model gebruiken in een implementatie

Meerdere lokale modellen gebruiken in een implementatie

Modellen gebruiken die zijn geregistreerd in uw Azure Machine Learning-werkruimte in een implementatie

Quotumtoewijzing voor virtuele machines voor implementatie

Implementatie voor coders en niet-coders

Foutopsporing voor online-eindpunten

Lokale foutopsporing met HTTP-server voor Azure Machine Learning-deductie

Lokale foutopsporing met lokaal eindpunt

Lokale foutopsporing met lokaal eindpunt en Visual Studio Code (preview)

Foutopsporing met containerlogboeken

Verkeersroutering en spiegeling naar onlineimplementaties

Verkeersroutering voor blauw/groen implementatie

Verkeer spiegelen naar online-implementaties

Meer mogelijkheden van online-eindpunten in Azure Machine Learning

Verificatie en versleuteling

Automatisch schalen

Beheerde netwerkisolatie

Online-eindpunten en -implementaties bewaken

Geheime injectie in online implementaties (preview)

Volgende stappen

Aanvullende resources

Modelpad identificeren met betrekking tot `AZUREML_MODEL_DIR`