Batchgewijs scoren voor deep learning-modellen met Behulp van Azure Machine Learning-pijplijnen

Logic Apps
Machine Learning
Op rollen gebaseerd toegangsbeheer van Azure
Storage

Deze referentiearchitectuur laat zien hoe u neurale overdracht toepast op een video met behulp van Azure Machine Learning. Stijloverdracht is een deep learning-techniek waarmee een bestaande afbeelding wordt samengesteld in de stijl van een andere afbeelding. U kunt deze architectuur generaliseren voor elk scenario waarin batchscores met deep learning worden gebruikt.

Architectuur

Architectuurdiagram voor deep learning-modellen met behulp van Azure Machine Learning.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom

Deze architectuur bestaat uit de volgende onderdelen.

Compute

Azure Machine Learning maakt gebruik van pijplijnen om reproduceerbare en eenvoudig te beheren reeksen berekeningen te maken. Het biedt ook een beheerd rekendoel (waarop een pijplijnberekening kan worden uitgevoerd) met de naam Azure Machine Learning Compute voor het trainen, implementeren en scoren van machine learning-modellen.

Storage

Azure Blob Storage slaat alle afbeeldingen (invoerafbeeldingen, stijlafbeeldingen en uitvoerafbeeldingen) op. Azure Machine Learning kan worden geïntegreerd met Blob Storage, zodat gebruikers geen gegevens handmatig hoeven te verplaatsen tussen rekenplatforms en blobopslag. Blob Storage is ook rendabel voor de prestaties die deze workload vereist.

Trigger

Azure Logic Apps activeert de werkstroom. Wanneer de logische app detecteert dat een blob is toegevoegd aan de container, wordt de Azure Machine Learning-pijplijn geactiveerd. Logic Apps is geschikt voor deze referentiearchitectuur omdat het een eenvoudige manier is om wijzigingen in blob-opslag te detecteren, met een eenvoudig proces voor het wijzigen van de trigger.

De gegevens voorverwerken en achteraf verwerken

Deze referentiearchitectuur maakt gebruik van videobeelden van een orang-oetan in een boom.

  1. Gebruik FFmpeg om het audiobestand uit de videobeelden uit te pakken, zodat het audiobestand later weer in de uitvoervideo kan worden geplakt.
  2. Gebruik FFmpeg om de video op te splitsen in afzonderlijke frames. De frames worden onafhankelijk, parallel verwerkt.
  3. Op dit moment kunt u gelijktijdig neurale stijloverdracht toepassen op elk afzonderlijk frame.
  4. Nadat elk frame is verwerkt, gebruikt u FFmpeg om de frames weer aan elkaar te koppelen.
  5. Bevestig ten slotte het audiobestand opnieuw aan de restitched beelden.

Onderdelen

Oplossingsdetails

Deze referentiearchitectuur is ontworpen voor workloads die worden geactiveerd door de aanwezigheid van nieuwe media in Azure Storage.

De verwerking omvat de volgende stappen:

  1. Upload een videobestand naar Azure Blob Storage.
  2. Het videobestand activeert Azure Logic Apps om een aanvraag te verzenden naar het gepubliceerde eindpunt van de Azure Machine Learning-pijplijn.
  3. De pijplijn verwerkt de video, past stijloverdracht toe met MPI en verwerkt de video naverwerking.
  4. De uitvoer wordt weer opgeslagen in Blob Storage zodra de pijplijn is voltooid.

Potentiële gebruikscases

Een mediaorganisatie heeft een video waarvan de stijl ze willen wijzigen, zodat deze eruitzien als een specifiek schilderij. De organisatie wil deze stijl tijdig en geautomatiseerd toepassen op alle frames van de video. Zie Afbeeldingsstijloverdracht met behulp van convolutionele neurale netwerken (PDF) voor meer achtergrondinformatie over algoritmen voor overdracht van neurale stijlen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie Overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

GPU versus CPU

Voor deep learning-workloads presteren GPU's over het algemeen aanzienlijk beter dan CPU's, in de mate dat een aanzienlijk cluster van CPU's doorgaans nodig is om vergelijkbare prestaties te verkrijgen. Hoewel u in deze architectuur alleen CPU's kunt gebruiken, bieden GPU's een veel beter kosten-/prestatieprofiel. We raden u aan om de nieuwste NCv3-serie met voor GPU geoptimaliseerde VM's te gebruiken.

GPU's zijn niet standaard ingeschakeld in alle regio's. Zorg ervoor dat u een regio selecteert waarvoor GPU's zijn ingeschakeld. Bovendien hebben abonnementen een standaardquotum van nul kernen voor VM's die zijn geoptimaliseerd voor GPU. U kunt dit quotum verhogen door een ondersteuningsaanvraag te openen. Zorg ervoor dat uw abonnement voldoende quotum heeft om uw workload uit te voeren.

Parallelliseren tussen VM's versus kernen

Wanneer u een stijloverdrachtproces uitvoert als een batchtaak, moeten de taken die voornamelijk op GPU's worden uitgevoerd, parallel worden verdeeld over vm's. Er zijn twee benaderingen mogelijk: u kunt een groter cluster maken met behulp van VM's met één GPU of een kleiner cluster maken met behulp van VM's met veel GPU's.

Voor deze workload hebben deze twee opties vergelijkbare prestaties. Het gebruik van minder VM's met meer GPU's per VM kan helpen om de gegevensverplaatsing te verminderen. Het gegevensvolume per taak voor deze workload is echter niet groot, dus u ziet niet veel beperkingen door Blob Storage.

MPI-stap

Bij het maken van de Azure Machine Learning-pijplijn is een van de stappen die worden gebruikt om parallelle berekeningen uit te voeren de MPI-stap (interface voor berichtverwerking). Met de MPI-stap kunt u de gegevens gelijkmatig verdelen over de beschikbare knooppunten. De MPI-stap wordt pas uitgevoerd als alle aangevraagde knooppunten gereed zijn. Als één knooppunt uitvalt of wordt afgekeerd (als het een virtuele machine met lage prioriteit is), moet de MPI-stap opnieuw worden uitgevoerd.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie. Deze sectie bevat overwegingen voor het bouwen van veilige oplossingen.

Toegang tot Azure Blob Storage beperken

In deze referentiearchitectuur is Azure Blob Storage het belangrijkste opslagonderdeel dat moet worden beveiligd. De basislijnimplementatie die wordt weergegeven in de GitHub-opslagplaats, maakt gebruik van opslagaccountsleutels voor toegang tot de blobopslag. Voor meer controle en beveiliging kunt u overwegen om in plaats daarvan een Shared Access Signature (SAS) te gebruiken. Hiermee verleent u beperkte toegang tot objecten in de opslag, zonder dat u de accountsleutels hoeft te coderen of ze in tekst zonder opmaak hoeft op te slaan. Deze benadering is vooral handig omdat accountsleutels zichtbaar zijn in tekst zonder opmaak in de ontwerpinterface van de logische app. Het gebruik van een SAS helpt ook om ervoor te zorgen dat het opslagaccount de juiste governance heeft en dat toegang alleen wordt verleend aan de personen die het moeten hebben.

Voor scenario's met meer gevoelige gegevens moet u ervoor zorgen dat al uw opslagsleutels zijn beveiligd, omdat deze sleutels volledige toegang verlenen tot alle invoer- en uitvoergegevens van de workload.

Gegevensversleuteling en gegevensverplaatsing

Deze referentiearchitectuur maakt gebruik van stijloverdracht als voorbeeld van een batchgewijs scoreproces. Voor meer gegevensgevoelige scenario's moeten de gegevens in de opslag at rest worden versleuteld. Telkens wanneer gegevens van de ene naar de andere locatie worden verplaatst, gebruikt u Transport Layer Security (TSL) om de gegevensoverdracht te beveiligen. Zie Azure Storage Security Guide (Beveiligingshandleiding voor Azure Storage) voor meer informatie.

Uw berekening beveiligen in een virtueel netwerk

Wanneer u uw Machine Learning-rekencluster implementeert, kunt u het cluster configureren om te worden ingericht binnen een subnet van een virtueel netwerk. Met dit subnet kunnen de rekenknooppunten in het cluster veilig communiceren met andere virtuele machines.

Bescherming tegen schadelijke activiteiten

In scenario's waarin er meerdere gebruikers zijn, moet u ervoor zorgen dat gevoelige gegevens zijn beveiligd tegen schadelijke activiteiten. Als andere gebruikers toegang krijgen tot deze implementatie om de invoergegevens aan te passen, moet u rekening houden met de volgende voorzorgsmaatregelen en overwegingen:

  • Gebruik op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) om de toegang van gebruikers te beperken tot alleen de resources die ze nodig hebben.
  • Richt twee afzonderlijke opslagaccounts in. Sla invoer- en uitvoergegevens op in het eerste account. Externe gebruikers kunnen toegang krijgen tot dit account. Sla uitvoerbare scripts en uitvoerlogboekbestanden op in het andere account. Externe gebruikers mogen geen toegang hebben tot dit account. Deze scheiding zorgt ervoor dat externe gebruikers geen uitvoerbare bestanden kunnen wijzigen (om schadelijke code in te voeren) en geen toegang hebben tot logboekbestanden die gevoelige informatie kunnen bevatten.
  • Kwaadwillende gebruikers kunnen een DDoS-aanval uitvoeren op de taakwachtrij of ongeldige gifberichten in de taakwachtrij injecteren, waardoor het systeem wordt vergrendeld of fouten in de wachtrij worden verwijderd.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het zoeken naar manieren om onnodige kosten te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Vergeleken met de opslag- en planningsonderdelen, domineren de rekenresources die in deze referentiearchitectuur worden gebruikt, veruit in termen van kosten. Een van de belangrijkste uitdagingen is het effectief parallelliseren van het werk op een cluster met GPU-computers.

De grootte van het Azure Machine Learning Compute-cluster kan automatisch omhoog en omlaag worden geschaald, afhankelijk van de taken in de wachtrij. U kunt automatisch schalen programmatisch inschakelen door het minimum en maximum aantal knooppunten in te stellen.

Voor werk waarvoor geen onmiddellijke verwerking nodig is, configureert u automatische schaalaanpassing zodat de standaardstatus (minimum) een cluster van knooppunten is. Met deze configuratie begint het cluster met nul knooppunten en wordt het alleen omhoog geschaald wanneer er taken in de wachtrij worden gedetecteerd. Als het batchscoreproces slechts een paar keer per dag of minder plaatsvindt, resulteert deze instelling in aanzienlijke kostenbesparingen.

Automatisch schalen is mogelijk niet geschikt voor batchtaken die te dicht bij elkaar plaatsvinden. Er zijn ook kosten verbonden aan de tijd die nodig is om een cluster op te starten en uit te schakelen. Als een batchworkload dus slechts enkele minuten na het beëindigen van de vorige taak begint, is het mogelijk rendabeler om het cluster tussen taken te laten werken.

Azure Machine Learning Compute biedt ook ondersteuning voor virtuele machines met een lage prioriteit, waarmee u uw berekeningen kunt uitvoeren op virtuele machines met korting, met het voorbehoud dat deze op elk gewenst moment worden afgekeerd. Virtuele machines met lage prioriteit zijn ideaal voor niet-kritieke werkbelastingen voor batchscores.

Batchtaken bewaken

Tijdens het uitvoeren van uw taak is het belangrijk om de voortgang te controleren en ervoor te zorgen dat de taak werkt zoals verwacht. Het kan echter een uitdaging zijn om een cluster met actieve knooppunten te bewaken.

Als u de algehele status van het cluster wilt controleren, gaat u naar de Machine Learning-service in de Azure Portal om de status van de knooppunten in het cluster te controleren. Als een knooppunt inactief is of als een taak is mislukt, worden de foutenlogboeken opgeslagen in Blob Storage en zijn ze ook toegankelijk in de Azure Portal.

Bewaking kan verder worden uitgebreid door logboeken te verbinden met Application Insights of door afzonderlijke processen uit te voeren om de status van het cluster en de bijbehorende taken te peilen.

Logboekregistratie met Azure Machine Learning

In Azure Machine Learning worden alle stdout/stderr automatisch in het gekoppelde Blob Storage-account opgenomen. Tenzij anders aangegeven, wordt in uw Azure Machine Learning-werkruimte automatisch een opslagaccount ingericht en worden uw logboeken erin gedumpt. U kunt ook een hulpprogramma voor opslagnavigatie gebruiken, zoals Azure Storage Explorer. Dit is een eenvoudigere manier om door logboekbestanden te navigeren.

Dit scenario implementeren

Als u deze referentiearchitectuur wilt implementeren, volgt u de stappen die worden beschreven in de GitHub-opslagplaats.

U kunt ook een architectuur voor batchgewijs scoren implementeren voor deep learning-modellen met behulp van de Azure Kubernetes Service. Volg de stappen die worden beschreven in deze GitHub-opslagplaats.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen