Batchbedömning för djupinlärningsmodeller med hjälp Azure Machine Learning pipelines

Den här referensarkitekturen visar hur du tillämpar överföring av neurala format till en video med Azure Machine Learning. Stilöverföring är en djupinlärningsteknik som utgör en befintlig bild i en annan bilds format. Den här arkitekturen kan generaliseras för alla scenarier som använder batchbedömning med djupinlärning. Distribuera den här lösningen.

Scenario:En medieorganisation har en video vars stil de vill ändra så att den ser ut som en specifik tavla. Organisationen vill tillämpa det här formatet på alla bildrutor i videon inom rimlig tid och på ett automatiserat sätt. Mer bakgrundsinformation om algoritmer för överföring av neurala format finns i Image Style Transfer Using Convolutional Neural Networks (PDF) (Överföring av bildformat med hjälp av faltning av neurala nätverk (PDF).

Den här referensarkitekturen är utformad för arbetsbelastningar som utlöses av förekomsten av nya media i Azure Storage.

Bearbetningen omfattar följande steg:

1. Upload en videofil till Azure Blob Storage.
2. Videofilen utlöser ett Azure Logic Apps skicka en begäran till den publicerade slutpunkten Azure Machine Learning pipeline.
3. Pipelinen bearbetar videon, tillämpar formatöverföring med MPI och efterbearbetar videon.
4. Utdata sparas tillbaka till bloblagringen när pipelinen har slutförts.

Arkitektur för en pipeline för ML djupinlärning

Den här arkitekturen består av följande komponenter.

Compute

Azure Machine Learning använder pipelines för att skapa reproducerbara och lättanvända beräkningssekvenser. Det erbjuder också ett hanterat beräkningsmål (där en pipelineberäkning kan köras) som kallas Azure Machine Learning Compute för träning, distribution och bedömning av maskininlärningsmodeller.

Storage

Azure Blob Storage används för att lagra alla bilder (indatabilder, formatbilder och utdatabilder). Azure Machine Learning integreras med Blob Storage så att användarna inte behöver flytta data manuellt mellan beräkningsplattformar och bloblagringar. Blob Storage är också kostnadseffektivt för den prestanda som den här arbetsbelastningen kräver.

Utlösare/schemaläggning

Azure Logic Apps används för att utlösa arbetsflödet. När logikappen upptäcker att en blob har lagts till i containern utlöses Azure Machine Learning pipeline. Logic Apps passar bra för den här referensarkitekturen eftersom det är ett enkelt sätt att identifiera ändringar i bloblagring, med en enkel process för att ändra utlösaren.

Förbearbetning och efterbearbetning av våra data

Den här referensarkitekturen använder videosekvenser av en orangutang i ett träd.

1. Använd FFmpeg för att extrahera ljudfilen från videosekvenserna så att ljudfilen kan sammanfogas i utdatavideon senare.
2. Använd FFmpeg för att dela upp videon i enskilda bildrutor. Bildrutorna bearbetas separat, parallellt.
3. I det här läget kan vi tillämpa överföring av neuralt format på varje enskild bildruta parallellt.
4. En bildruta har bearbetats och vi måste använda FFmpeg för att lägga ihop bildrutorna igen.
5. Slutligen återansluter vi ljudfilen till den restitched filmsekvensen.

Saker att tänka på gällande prestanda

GPU jämfört med CPU

För arbetsbelastningar för djupinlärning kommer GPU:er normalt att utföra processorer med en stor mängd, i den utsträckning som ett stort kluster med processorer vanligtvis behövs för att få jämförbara prestanda. Även om det är ett alternativ att endast använda processorer i den här arkitekturen ger GPU:er en mycket bättre kostnads-/prestandaprofil. Vi rekommenderar att du använder den senaste NCv3-serien med GPU-optimerade virtuella datorer.

GPU:er är inte aktiverade som standard i alla regioner. Se till att välja en region med GPU:er aktiverade. Dessutom har prenumerationer en standardkvot på noll kärnor för GPU-optimerade virtuella datorer. Du kan öka kvoten genom att öppna en supportbegäran. Kontrollera att din prenumeration har tillräcklig kvot för att köra din arbetsbelastning.

Parallellisering mellan virtuella datorer jämfört med kärnor

När du kör en formatöverföringsprocess som ett batchjobb måste jobben som körs främst på GPU:er parallelliseras mellan virtuella datorer. Två metoder är möjliga: Du kan skapa ett större kluster med hjälp av virtuella datorer som har en enda GPU eller skapa ett mindre kluster med hjälp av virtuella datorer med många GPU:er.

För den här arbetsbelastningen har dessa två alternativ jämförbara prestanda. Om du använder färre virtuella datorer med fler GPU:er per virtuell dator kan du minska dataflyttningen. Datavolymen per jobb för den här arbetsbelastningen är dock inte stor, så du kommer inte att se någon större begränsning av bloblagring.

MPI-steg

När du skapar Azure Machine Learning pipelineär MPI-steget (meddelandebearbetningsgränssnitt) ett av stegen som används för att utföra parallell beräkning. MPI-steget hjälper till att dela upp data jämnt mellan de tillgängliga noderna. MPI-steget körs inte förrän alla begärda noder är klara. Om en nod misslyckas eller blir inkopplad (om det är en virtuell dator med låg prioritet) måste MPI-steget köras igen.

Säkerhetsöverväganden

Begränsa åtkomsten till Azure Blob Storage

I den här referensarkitekturen är Azure Blob Storage den viktigaste lagringskomponenten som måste skyddas. Baslinjedistributionen som visas i GitHub lagringsplats använder lagringskontonycklar för att komma åt bloblagringen. Överväg att använda en signatur för delad åtkomst (SAS) i stället för ytterligare kontroll och skydd. Detta ger begränsad åtkomst till objekt i lagring, utan att kontonycklarna behöver hårdkoda eller spara dem i klartext. Den här metoden är särskilt användbar eftersom kontonycklar visas i klartext i Logikappens designgränssnitt. Att använda en SAS hjälper också till att säkerställa att lagringskontot har rätt styrning och att åtkomst endast beviljas till de personer som är avsedda att ha det.

För scenarier med känsligare data bör du se till att alla dina lagringsnycklar är skyddade, eftersom dessa nycklar ger fullständig åtkomst till alla in- och utdata från arbetsbelastningen.

Datakryptering och dataförflyttning

I den här referensarkitekturen används formatöverföring som ett exempel på en batchbedömningsprocess. För mer datakänsliga scenarier bör data i lagringen krypteras i vila. Varje gång data flyttas från en plats till nästa använder du Transport Layer Security (TSL) för att skydda dataöverföringen. Mer information finns i Azure Storage säkerhetsguide.

Skydda beräkningen i ett virtuellt nätverk

När du distribuerar Machine Learning beräkningskluster kan du konfigurera klustret så att det etableras i ett undernät i ett virtuellt nätverk. Med det här undernätet kan beräkningsnoderna i klustret kommunicera säkert med andra virtuella datorer.

Skydda mot skadlig aktivitet

I scenarier där det finns flera användare bör du se till att känsliga data skyddas mot skadlig aktivitet. Om andra användare får åtkomst till den här distributionen för att anpassa indata bör du tänka på följande:

• Använd rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att begränsa användarnas åtkomst till endast de resurser de behöver.
• Etablera två separata lagringskonton. Lagra indata och utdata i det första kontot. Externa användare kan ges åtkomst till det här kontot. Lagra körbara skript och utdataloggfiler i det andra kontot. Externa användare bör inte ha åtkomst till det här kontot. Den här separationen säkerställer att externa användare inte kan ändra körbara filer (för att mata in skadlig kod) och inte har åtkomst till loggfiler som kan innehålla känslig information.
• Illvilliga användare kan utföra en DDoS-attack på jobbkön eller mata in skadliga meddelanden i jobbkön, vilket gör att systemet låser sig eller orsakar borttagningsfel.

Övervakning och loggning

Övervaka batchjobb

När du kör jobbet är det viktigt att övervaka förloppet och se till att jobbet fungerar som förväntat. Det kan dock vara en utmaning att övervaka i ett kluster med aktiva noder.

Om du vill kontrollera klustrets övergripande tillstånd går du till Machine Learning i Azure Portal för att kontrollera tillståndet för noderna i klustret. Om en nod är inaktiv eller om ett jobb har misslyckats sparas felloggarna i bloblagringen och är också tillgängliga i Azure Portal.

Övervakningen kan berikas ytterligare genom att ansluta loggar till Application Insights eller genom att köra separata processer för att avskilda klustrets tillstånd och dess jobb.

Loggning med Azure Machine Learning

Azure Machine Learning loggar automatiskt alla stdout/stderr till det associerade bloblagringskontot. Om inget annat anges etablerar arbetsytan Azure Machine Learning automatiskt ett lagringskonto och dumpar loggarna till det. Du kan också använda ett lagringsnavigeringsverktyg som Azure Storage Explorer, vilket är ett enklare sätt att navigera i loggfiler.

Kostnadsöverväganden

Jämfört med lagrings- och schemaläggningskomponenterna så har de beräkningsresurser som används i den här referensarkitekturen överlägset dominerande vad gäller kostnader. En av de största utmaningarna är att effektivt parallellisera arbetet i ett kluster med GPU-aktiverade datorer.

Storleken Azure Machine Learning Compute-kluster kan automatiskt skalas upp och ned beroende på jobben i kön. Du kan aktivera autoskalning programmässigt genom att ange lägsta och högsta antalet noder.

För arbete som inte kräver omedelbar bearbetning konfigurerar du autoskalning så att standardtillståndet (minimum) är ett kluster med noll noder. Med den här konfigurationen börjar klustret med noll noder och skalar bara upp när det identifierar jobb i kön. Om batchbedömningsprocessen bara sker några gånger per dag eller mindre resulterar den här inställningen i betydande kostnadsbesparingar.

Autoskalning kanske inte är lämpligt för batchjobb som sker för nära varandra. Den tid det tar för ett kluster att startar och startar medför också en kostnad, så om en batcharbetsbelastning börjar bara några minuter efter att det tidigare jobbet har avslutats kan det vara mer kostnadseffektivt att hålla klustret igång mellan jobb.

Azure Machine Learning Compute har också stöd för virtuella datorer med låg prioritet, vilket gör att du kan köra beräkningen på rabatterade virtuella datorer, med det förbehåll som de kan bli överskådda när som helst. Virtuella datorer med låg prioritet är idealiska för icke-kritiska batchbedömningsarbetsbelastningar.

Distribuera lösningen

Om du vill distribuera den här referensarkitekturen följer du stegen som beskrivs i GitHub lagringsplatsen.