Batchscores voor Deep Learning-modellen met behulp Azure Machine Learning pijplijnen

Deze referentiearchitectuur laat zien hoe u neurale stijloverdracht kunt toepassen op een video, met behulp van Azure Machine Learning. Stijloverdracht is een deep learning-techniek waarmee een bestaande afbeelding in de stijl van een andere afbeelding wordt gemaakt. Deze architectuur kan worden ge generaliseerd voor elk scenario dat gebruikmaakt van batch scoren met deep learning. Deze oplossing implementeren.

Scenario: een mediaorganisatie heeft een video waarvan de stijl die ze willen wijzigen, eruit wilt zien als een specifieke schilderij. De organisatie wil deze stijl tijdig en op een geautomatiseerde manier toepassen op alle frames van de video. Zie Image Style Transfer Using Convolutional Neural Networks (PDF) (Afbeeldingsstijloverdracht met convolutionele neurale netwerken (PDF) voor meer achtergrondinformatie over algoritmen voor neurale overdracht.

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 videobestand toevoegen aan Azure Blob Storage.
2. Het videobestand activeert Azure Logic Apps aanvraag te verzenden naar het gepubliceerde Azure Machine Learning van de pijplijn.
3. De pijplijn verwerkt de video, past stijloverdracht toe met MPI en verwerkt de video.
4. De uitvoer wordt weer opgeslagen in blobopslag zodra de pijplijn is voltooid.

Architectuur voor een pijplijn voor ML deep learning

Deze architectuur bestaat uit de volgende onderdelen.

Compute

Azure Machine Learning pijplijnen gebruikt om reproduceerbare en eenvoudig te beheren rekenreeksen 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 machine learning modellen.

Storage

Azure Blob Storage wordt gebruikt voor het opslaan van alle afbeeldingen (invoerafbeeldingen, stijlafbeeldingen en uitvoerafbeeldingen). Azure Machine Learning kan worden geïntegreerd met Blob Storage, zodat gebruikers gegevens niet handmatig tussen rekenplatforms en blobopslag moeten verplaatsen. Blob-opslag is ook rendabel voor de prestaties die deze workload vereist.

Activeren/plannen

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

Onze gegevens voorverwerken en nabewerken

Deze referentiearchitectuur maakt gebruik van videobeelden van een orang-oetang in een boomstructuur.

1. Gebruik FFmpeg om het audiobestand uit de videobeelden te extraheren, zodat het audiobestand later weer kan worden toegevoegd aan de uitvoervideo.
2. Gebruik FFmpeg om de video op te delen in afzonderlijke frames. De frames worden onafhankelijk, parallel verwerkt.
3. Op dit moment kunnen we neurale stijloverdracht parallel toepassen op elk afzonderlijk frame.
4. Als elk frame is verwerkt, moeten we FFmpeg gebruiken om de frames opnieuw te maken.
5. Ten slotte wordt het audiobestand opnieuw in deattaching op de opnieuw opgeslagen beeldmateriaal.

Prestatieoverwegingen

GPU versus CPU

Voor deep learning-workloads presteren GPU's over het algemeen aanzienlijk beter dan CPU's, in zoverre een groot cluster met CPU's doorgaans nodig is om vergelijkbare prestaties te krijgen. Hoewel het een optie is om alleen CPU's in deze architectuur te gebruiken, bieden GPU's een veel beter kosten-/prestatieprofiel. We raden u aan 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 met GPU's ingeschakeld. Daarnaast hebben abonnementen een standaardquotum van nul kernen voor voor GPU geoptimaliseerde VM's. U kunt dit quotum verhogen door een ondersteuningsaanvraag te openen. Zorg ervoor dat uw abonnement voldoende quota heeft om uw workload uit te voeren.

Parallelliseren tussen VM's versus kernen

Bij het uitvoeren van een stijloverdrachtsproces als een batch-job, moeten de taken die voornamelijk op GPU's worden uitgevoerd, parallel worden uitgevoerd op 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 verplaatsing van gegevens te verminderen. Het gegevensvolume per taak voor deze workload is echter niet groot, dus u zult niet veel bandbreedtebeperking door blobopslag zien.

MPI-stap

Bij het maken van Azure Machine Learning pijplijnis de MPI-stap (message processing interface) een van de stappen die wordt gebruikt om een parallelle berekening uit te voeren. Met de MPI-stap kunt u de gegevens gelijkmatig splitsen over de beschikbare knooppunten. De MPI-stap wordt pas uitgevoerd als alle aangevraagde knooppunten gereed zijn. Als één knooppunt uitvallen of worden verdroomd (als het een virtuele machine met lage prioriteit is), moet de MPI-stap opnieuw wordenrun.

Beveiligingsoverwegingen

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 gebruikt opslagaccountsleutels voor toegang tot de blobopslag. Voor meer controle en beveiliging kunt u in plaats daarvan een Shared Access Signature (SAS) gebruiken. Dit verleent beperkte toegang tot objecten in de opslag, zonder dat de accountsleutels in code hoeven te worden gecodeerd of in niet-gecodeerde tekst hoeven te worden opgeslagen. Deze aanpak is vooral nuttig omdat accountsleutels in platte tekst zichtbaar zijn in de ontwerpinterface van de logische app. Het gebruik van een SAS helpt er ook voor te zorgen dat het opslagaccount een goede governance heeft en dat alleen toegang wordt verleend aan de personen die het willen hebben.

Voor scenario's met 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 gegevensversleuteling

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

Uw berekening in een virtueel netwerk beveiligen

Wanneer u uw Machine Learning-rekencluster implementeert, kunt u uw cluster zo configureren dat het wordt ingericht in 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 met meerdere gebruikers 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.
• Twee afzonderlijke opslagaccounts inrichten. 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 te injecteren) en geen toegang hebben tot logboekbestanden die gevoelige informatie kunnen bevatten.
• Kwaadwillende gebruikers kunnen een DDoS-aanval uitvoeren op de wachtrij van de taak of onjuist vorm geven aan de wachtrij, waardoor het systeem wordt vergrendeld of fouten in de wachtrij worden verwijderd.

Bewaking en registratie

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 te controleren op een cluster met actieve knooppunten.

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 foutlogboeken opgeslagen in blobopslag en zijn ze ook toegankelijk in de Azure Portal.

Bewaking kan verder worden verrijkt door logboeken te verbinden met Application Insights of door afzonderlijke processen uit te laten uitvoeren om de status van het cluster en de taken ervan te peilen.

Logboekregistratie met Azure Machine Learning

Azure Machine Learning worden alle stdout/stderr automatisch aan het gekoppelde blob-opslagaccount gekoppeld. Tenzij anders aangegeven, wordt in Azure Machine Learning werkruimte automatisch een opslagaccount ingericht en worden uw logboeken in de werkruimte dumpen. U kunt ook een opslagnavigatieprogramma zoals Azure Storage Explorergebruiken. Dit is een eenvoudigere manier om door logboekbestanden te navigeren.

Kostenoverwegingen

Vergeleken met de opslag- en planningsonderdelen zijn de rekenbronnen die in deze referentiearchitectuur worden gebruikt, verreweg de belangrijkste kosten. Een van de belangrijkste uitdagingen is het parallelliseren van het werk in een cluster met GPU-computers.

De Azure Machine Learning grootte van het rekencluster 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 is vereist, configureert u automatisch schalen, zodat de standaardtoestand (minimum) een cluster van nul knooppunten is. Met deze configuratie begint het cluster met nul knooppunten en wordt het alleen omhoog geschaald wanneer taken in de wachtrij worden gedetecteerd. Als het batchscoreproces slechts een paar keer per dag of minder wordt gedaan, leidt deze instelling tot aanzienlijke kostenbesparingen.

Automatisch schalen is mogelijk niet geschikt voor batchtaken die te dicht bij elkaar plaatsvinden. De tijd die het kost om een cluster op te zetten en te laten draaien, brengt ook kosten met zich mee. Als een batchworkload dus slechts enkele minuten na het einde van de vorige taak begint, kan het rendabeler zijn om het cluster tussen taken actief te houden.

Azure Machine Learning Compute ondersteunt ook virtuele machines met lage prioriteit, waarmee u uw berekening kunt uitvoeren op virtuele machines met korting, met het nadeel dat ze op elk moment kunnen worden verrekenen. Virtuele machines met lage prioriteit zijn ideaal voor niet-kritieke workloads voor batchscore.

De oplossing implementeren

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