Dela via


Programplattform för AI-arbetsbelastningar i Azure

Du måste noga överväga programvärdplattformen som din AI-arbetsbelastning distribueras på för att säkerställa att du kan maximera effektiviteten, driftsäkerheten och tillförlitligheten.

Det här designområdet omfattar flera typer av program som kan vara relevanta för din AI-arbetsbelastning:

  • Undersökande dataanalys (EDA)
  • Modellträning och finjustering
  • Slutsatsdragning

Den här artikeln innehåller vägledning för att välja den bästa plattformen för var och en av dessa funktioner för att uppfylla dina affärsbehov. Det finns också allmänna rekommendationer som du kan använda för alla dessa funktioner.

Rekommendationer

Här är sammanfattningen av rekommendationerna i den här artikeln.

Rekommendation beskrivning
Återanvända verktyg. Börja med att utvärdera de verktyg som du redan använder för att förstå om de kan återanvändas för din AI-arbetsbelastning. Om de stöder de funktioner som krävs och kan uppfylla dina krav på tillförlitlighet, säkerhet, kostnad och prestanda kanske det inte är värt kostnaden och arbetet att använda ett nytt verktyg.
Överväg efterlevnadskrav för dina data och de regioner som du planerar att distribuera i. Du kan behöva begränsa de regioner som du distribuerar i eller isolera delar av din arbetsbelastning från varandra för att uppfylla efterlevnadskraven. Om du går in i designfasen med den här informationen kan du skydda dig från att behöva designa om senare.
Minimera skapande. Överväg paaS-lösningar (plattform som en tjänst) eller saaS-lösningar (programvara som en tjänst) för att minimera den driftbelastning som du skapar din egen lösning medför, till exempel korrigering och annat underhåll. Att minimera den dag-2-börda som krävs för den nya tekniken förenklar implementeringen. Många AI-funktioner är komplexa, så vi rekommenderar inte att du skapar en egen plattform.
Förstå dina kvoter och gränser. När du utformar för användning av PaaS- eller SaaS-lösningar bör du förstå eventuella kvoter eller begränsningar som gäller. Din möjlighet att skala ut för att uppfylla höga trafikkrav kan påverkas av kvoter eller gränser, så du kan behöva justera din design för att minimera den risken.
Distribuera i samma region. Försök att distribuera alla relaterade resurser i samma region för att minska svarstiden och förenkla designen.
Öva på säker distribution. I allmänhet bör du behandla API:erna för din AI-arbetsbelastning på samma sätt som andra API:er i din miljö. Alla API:er ska placeras bakom en gateway och all kod ska hanteras med samma säkra distributionsmetoder som alla andra kodtillgånger.
Upprätta prestandamått genom experimentering. Varje AI-arbetsbelastning skiljer sig åt, och hur mycket beräkning du behöver beror på ditt användningsfall. Fastställa mängden och typerna av beräkning som är optimala för din arbetsbelastning genom att utföra noggrann benchmark-testning. Den här guiden hjälper dig att välja en plattform, men du vet bara vilka SKU:er som är lämpliga för din arbetsbelastning efter benchmark-testning.

Överväganden för EDA-plattformen

EDA är en vanlig preliminär funktion som dataexperter utför före modellering eller statistisk analys. Det kan därför betraktas som en utvecklingsfas, vilket innebär att målen för tillförlitlighet och prestanda kan vara betydligt lägre än målen för produktionsresurser och att upprätthålla produktiviteten är den viktigaste faktorn.

Det här avsnittet innehåller vägledning om funktioner att tänka på när du väljer en EDA-plattformslösning.

Funktionskrav

När du utvärderar en EDA-plattform bör du tänka på följande frågor:

  • Stöder plattformen tillfällig användning?

    Plattformen bör ha stöd för tillfälliga arbetsytor och beräkning, vilket innebär att du bör kunna stoppa nödvändiga resurser när de inte används. Den här funktionen hjälper till att kontrollera kostnaderna. EDA-jobb är vanligtvis interaktiva, så användarna måste kunna starta virtuella datorer och stoppa dem när de kör jobb.

  • Har plattformen stöd för beräkningsvalighet?

    Plattformen bör aktivera åtkomst på begäran till GPU:er efter behov och tillhandahålla olika beräkningsalternativ för att göra plattformen rätt storlek.

  • Stöder plattformen MLflow?

    Din EDA-plattform bör göra det möjligt att välja en teknik som möjliggör integrering med MLflow för att spåra dina experiment. Vi rekommenderar MLflow som ett modellutvecklings-, distributions- och hanteringsprotokoll eftersom det ger följande fördelar:

    • Experimentspårning. Med MLflow kan du spåra experiment genom att registrera parametrar, mått och artefakter. Den här funktionen är viktig under EDA så att du kan hålla reda på olika dataförbearbetningssteg och tekniker för funktionsutveckling och deras inverkan på modellprestanda.
    • Reproducerbarhet. Eftersom den loggar all information om dina experiment hjälper MLflow till att säkerställa att du kan återskapa dina resultat, vilket är viktigt för att verifiera resultaten.
    • Data- och modellversionshantering. MLflow hjälper till med versionshantering av datamängder och modeller, vilket gör det enklare att hantera olika versioner av datatransformeringar och testade modeller.
    • Samarbete. MLflow tillhandahåller en centraliserad plattform där dataexperter kan dela sina experiment och resultat, vilket underlättar samarbete och kunskapsdelning.

Icke-funktionella krav

Tänk även på dessa frågor:

  • Hur kan plattformen hjälpa till att kontrollera kostnaderna?

    Plattformen bör göra det möjligt för dataexperter att utföra sitt arbete enligt sina schemakrav, men den bör vara rätt storlek för att säkerställa att kostnadsförväntningarna uppfylls.

  • Vilka säkerhetskrav måste följas för plattformen?

    De data som används under EDA-fasen är förmodligen produktionsdata, vilket kräver att du följer produktionspraxis för att skydda dessa data och övervaka plattformen. Därför bör din plattform ha stöd för alla nödvändiga säkerhetskontroller, inklusive:

    • Åtkomst och auktorisering.
    • Kryptering i vila och under överföring.
    • Regionala dataskyddskrav.
    • Robusta övervaknings- och aviseringsfunktioner, inklusive loggning och granskningsbarhet.
    • Privat nätverksåtkomst till centraliserade lagringsplatser för containeravbildningar, data och kodtillgångar.

Verktyg

Använd en Azure Machine Learning-beräkningsinstans med filresurser på teamnivå som EDA-plattform. Ett undantag till detta är om ditt team eller din organisation redan använder en lämplig värdplattform, till exempel GPU-aktiverade beräkningskluster i Databricks. I så fall kan det vara lämpligare att stanna kvar på den plattformen.

Kommentar

Skapa inte en fullständig EDA-plattform om du inte behöver det. GPU-optimerad beräkning är dyr och är inte lämplig om ditt användningsfall inte kräver det.

Överväganden för modelltränings- och finjusteringsplattformen

När du övergår till modellträning och finjustering behöver du förmodligen GPU-optimerad beräkning med höga prestanda för det beräkningsintensiva arbete som krävs av dessa aktiviteter. Tillförlitlighet är vanligtvis inte lika viktigt som prestanda eftersom det mesta av det här arbetet sker bakom kulisserna. Om hög tillförlitlighet är ett krav bör du utvärdera om det är nödvändigt att sprida arbetsbelastningen mellan tillgänglighetszoner eller regioner. Hög tillförlitlighet blir viktigare när modellens fräschhet uppdateras ofta, vilket kräver att träningen slutförs enligt ett striktare schema. Din RTO bör fastställa den tillförlitlighetsdesign som du väljer.

Vägledningen i det här avsnittet gäller både modellträning och finjustering. Om du inte tvingas använda separata plattformar för dessa funktioner bör du använda en enda plattform.

Funktionskrav

När du utvärderar plattformar för modellträning och finjustering bör du tänka på följande frågor:

  • Stöder plattformen tillfällig användning?

    Precis som EDA-aktiviteter körs modellträning och finjustering vanligtvis inte på heltid, så du bör använda en plattform som kan stoppas när den inte används för att kontrollera kostnaderna. Till skillnad från EDA är modellträning vanligtvis en batchprocess, så beräkningen behövs bara när batchen körs och kan stängas av till nästa körning.

  • Tillhandahåller plattformen orkestrering?

    På grund av komplexiteten som krävs för att hantera beräkningen för modellträning och finjustering rekommenderar vi en orkestrerare.

  • Kan befintliga tekniker i din miljö vara en del av lösningen?

    Om din befintliga dataplattform har maskininlärningsfunktioner, som Azure Databricks , kan du använda den för vissa steg, till exempel datatransformering och funktionsutveckling, utbildning, finjustering och andra steg i Machine Learning. Genom att kombinera tekniker kan du minimera kostnaderna och komplexiteten med att använda en dataplattform för funktioner som den kanske inte passar bäst för.

Icke-funktionella krav

Tänk även på den här frågan:

  • Vad är den acceptabla kompromissen mellan kostnad och prestanda?

    Med tanke på de högpresterande, GPU-optimerade beräkningskraven ser du till att du testar och jämför din träning och finjusterar mycket för att fastställa den idealiska SKU:n som balanserar prestanda mot kostnader.

Verktyg

Vi rekommenderar Azure Machine Learning för modelltränings- och finjusteringsplattformen eftersom den tillhandahåller orkestreringsfunktioner med stöd för batchberäkning. Det finns två beräkningsalternativ att utvärdera:

  • Serverlös beräkning är perfekt för korta, ovanliga körningar som kan tolerera bullriga granneffekter. Du kan välja antingen standardpriser eller spotpriser. Spotpriser rekommenderas endast för mycket avbrottsbar utbildning. Använd inte serverlös beräkning för heltidsåtgärder. Kostnaderna kan eskalera snabbt.
  • Beräkningskluster ger dig betydande kontroll över tillgänglig maskinvara och justeras för parallell eller distribuerad träning.

Kommentar

För grundmodeller kan ditt val av modellvärdplattform begränsa dina finjusteringsalternativ. Om du till exempel använder Azure OpenAI Service för modellvärdtjänster begränsas dina finjusteringsalternativ till de inbyggda finjusteringsfunktionerna i Azure OpenAI.

Överväganden för modellvärd- och slutsatsdragningsplattformen

Modellvärd- och slutsatsdragningsfunktioner utgör serverlagret för AI-arbetsbelastningen. Dessa funktioner utförs med slutpunkter som är specifika för den programvara som du använder. Programvarulösningar för modellservering, som NVIDIA Triton, TorchServe och TensorFlow Serving, är i huvudsak Python-SDK:er som frontar en modell med ett API och lägger till funktioner som är specifika för lösningen. Du kan välja din värdplattform baserat på ditt val av programvara eller välja din programvara baserat på ditt val av värdplattform.

När du använder SaaS- eller PaaS-lösningar med förpaketerade modeller, till exempel de stora språkmodeller som är tillgängliga i Azure OpenAI, har du få eller inga möjligheter att välja en serveringsprogramvara. I stället tillhandahåller tjänsten som du använder ett API. Detta minskar flexibiliteten i processen för att skapa en modelldistribution, vilket kan ge fördelar och nackdelar. Det kan till exempel effektivisera utvecklingsprocessen för din arbetsbelastning. Å andra sidan minskar det flexibiliteten i hur ditt program kan anropa och interagera med modellen.

I grund och botten är API:erna för serverlagret mikrotjänster, så du bör följa samma metoder för dessa API:er som du följer för andra mikrotjänster i din miljö. De ska vara containerbaserade, bulkheaded från andra tjänster och ha sina egna livscykeler som är oberoende av andra tjänster och API:er. Tänk dock på att serve layer-API:er i allmänhet kräver betydligt mer GPU-baserad beräkningskraft och större containeravbildningar än traditionella API:er.

Det här avsnittet innehåller vägledning om funktioner att tänka på när du väljer en modellvärd och inferensplattform.

Funktionskrav

När du utvärderar plattformar för modellvärdering och slutsatsdragning bör du tänka på följande frågor:

  • Kräver din arbetsbelastning batch- eller onlineinferens?

    Slutpunkterna för slutsatsdragning används antingen för batch- eller onlineinferensprocesser, och inferensmetoden hjälper till att fastställa rätt värdplattform. Batch-slutsatsdragning finns bäst på en plattform som stöder tillfällig användning och gör att beräkningen kan stängas av när den inte används. Online-slutsatsdragning finns bäst på en plattform som stöder elastisk beräkningsanvändning, som skalar automatiskt baserat på belastningen vid en viss tidpunkt.

  • Stöder plattformen spårbarhet?

    Spårning är avgörande för att upprätthålla integriteten för de modeller som används i din arbetsbelastning. Det är viktigt att känna till information om modellen, till exempel den aktuella versionen, vem som distribuerade den, när den distribuerades och modellens data härkomst.

    Använd meningsfulla taggar på avbildningar i containerregistret för att säkerställa att din modellvärdtjänst hämtar en specifik version som teamet enkelt kan identifiera. Den här metoden hjälper till med datastyrning genom att minska risken för inaktuella eller felaktiga modeller som används i produktion.

  • Kommer din värdplattform att vara en centraliserad resurs?

    Många organisationer använder en centraliserad modellvärdplattform som används av olika team för sina egna arbetsbelastningar. Om din värdplattform är centraliserad bör du överväga om du behöver support för återbetalning. Med den här funktionen kan du spåra plattformsanvändning efter team och arbetsbelastning.

Icke-funktionella krav

Tänk även på dessa frågor:

  • Vilka är tillförlitlighetskraven för plattformen?

    API:er på servernivå är produktionsresurser, så du bör tillämpa samma tillförlitlighetskrav på dem som du tillämpar på andra arbetsbelastningsflöden som matchar deras kritiskhetsklassificering . Om deras allvarlighetsgrad kräver hög tillgänglighet bör din värdplattform ha stöd för tillgänglighetszoner eller en design för flera regioner.

  • Vilka nätverkskontroller krävs för plattformen?

    Ta reda på om du behöver privata nätverk eller en utgående brandvägg för att ge plattformen skydd.

  • Vilka säkerhetskrav gäller för identitet och åtkomst för plattformen?

    Fastställa vilka identitets- och åtkomstkontroller som krävs för dina slutpunkter. Fundera på om du behöver inbyggd rollbaserad åtkomstkontroll (RBAC) eller inbyggt stöd för din identitets- och åtkomstplattform, till exempel Microsoft Entra-ID.

  • Vilka övervakningsfunktioner stöder plattformen?

    Fastställa vilka övervakningsfunktioner som krävs för dina slutpunkter. Beroende på plattform kan du ha begränsad åtkomst till loggar och mått, vilket kan begränsa din möjlighet att granska aktiviteter eller upptäcka fel.

  • Vilka är prestandakraven för plattformen?

    Svarstid för slutsatsdragning är ett vanligt problem och olika plattformar har olika prestandaprofiler. Serverlösa tjänster och PaaS-tjänster som använder en verktygsmodell kan påverkas av det bullriga granneproblemet och har ofta inga garantier för dataflöde. Å andra sidan kan samma plattformar erbjuda ett lokalt värdbaserat alternativ som ger garanterat dataflöde med en förköpsmodell. Du kan också överväga självvärdering på Kubernetes för mer förutsägbart svarstidsbeteende.

    Tänk på tjänstbegränsningar och kvoter som kan påverka dina prestanda, till exempel för Azure OpenAI. Ofta är dessa kvoter och gränser aggressivt inställda för att uppfylla kapacitetskrav, så om ditt val av plattform inte ger den prestanda som du behöver kan du behöva anta strategier för att sprida beräkningsefterfrågan mellan instanser.

    Avancerade arkitekturer kan kombinera flera distributioner för att uppnå fast dataflöde för huvuddelen av arbetsbelastningen och burst-funktioner för en mer flexibel beräkning.

Verktyg

Batch-slutsatsdragning

  • Om du utför slutsatsdragning av data som finns i en plattform som stöder modellvärdtjänster, till exempel Databricks, bör du överväga att använda den plattformen för slutsatsdragning. Se till att isolera inferensberäkningen från andra funktioner som utförs av dataplattformen.

  • Vi rekommenderar Azure OpenAI Batch API för grundmodeller.

  • För modeller som inte är grundläggande bör du överväga följande rekommendationer:

    • Överväg att använda Azure Machine Learning-batchslutpunkter för följande scenarier:

      • Du måste utföra slutsatsdragning på en stor datauppsättning som distribueras i flera filer och du behöver inte ha låg svarstid.

      • Du måste utföra långvariga batchåtgärder över stora datamängder och kan dra nytta av parallellisering.

      • Du måste distribuera pipelinekomponenter för batchbearbetning.

    • Om du behöver köra Spark-jobb för distribuerad databehandling kan du överväga att använda Azure Synapse Analytics, Databricks eller Serverlös Spark-beräkning utan Machine Learning.

    • Om inget av dessa scenarier gäller rekommenderar vi Machine Learning-batchslutpunkter.

Online-slutsatsdragning

  • Utvärdera plattforms-PaaS och serverlösa lösningar som ett första steg. Dessa tjänster är vanligtvis de enklaste att använda och hantera eftersom de förenklar din design och minimerar driftbelastningen. Azure OpenAI är till exempel ett bra val för grundmodeller.

    • Överväg att använda Azure Machine Learning Serverless API för att aggregera slutpunktsåtkomst även om du använder Azure OpenAI eller någon annan värdlösning för grundmodell.
  • Överväg Maskininlärning med hanterade beräkningskluster när PaaS eller serverlösa lösningar inte passar bäst. Beräkning som hanteras av Machine Learning stöder trafikdelning och spegling för A/B-testning, felsökning och robust granskning. Eftersom beräkningen hanteras av tjänsten är day-2-åtgärder enklare när du är egen värd för din modell. Hanterad beräkning erbjuder också ett brett urval av beräkningskonfigurationer och skalningsfunktioner.

  • Om du väljer att själv vara värd för din modell i ett AKS-kluster (Azure Kubernetes Service) som är kopplat till Machine Learning eller en annan containerbaserad plattform, se till att nodpoolen är isolerad från andra API:er eller andra arbetsbelastningar i klustret för att uppnå förutsägbara prestanda och optimera säkerheten. Undvik att använda GPU-baserad eller GPU-optimerad beräkning för något annat än dina AI-arbetsbelastningsfunktioner för att minska kostnaderna. Etablera i stället din prestandabaslinje genom testning och rätt storlek för din beräkning för att uppfylla dina prestandakrav utan överetablering.

  • Du kan också själv vara värd för din modell med hjälp av IaaS-lösningar (infrastruktur som en tjänst), till exempel Azure Datavetenskap Virtual Machine.

Överväganden för orkestreringsplattformen

Orkestrering i samband med programplattformar för AI-arbetsbelastningar refererar till verktyg som promptflöde i Machine Learning och Azure AI Studio. Dessa verktyg är utformade för att effektivisera hela utvecklingscykeln för AI-program genom att automatisera många vanliga arbetsflödesfunktioner.

Icke-funktionella krav

Precis som med alla andra produktionsarbetsbelastningar i din molnegendom måste du tänka på att när du utvärderar orkestreringsverktyg:

  • Tillförlitlighet, säkerhet och övervakning. Orkestreringsverktyg bör följa tillförlitlighets-, säkerhets- och övervakningsstandarder för produktionsarbetsbelastningar.

  • Prestanda. Orkestreringsverktyg kräver inte GPU-optimerad eller GPU-baserad beräkning, överväg SKU:er för generell användning.

  • Kostnadsoptimering. Orkestreringsverktyg är alltid på, överväg elastiska beräkningsalternativ för att minimera användningskostnaderna.

Verktyg

  • Föredrar en lösning utanför hyllan som promptflöde. Avgör om dess funktioner matchar dina orkestreringsbehov innan du tittar på anpassad värd med verktyg som LangChain eller Semantic Kernel.

  • Värdslutpunkter för lösningar som promptflöde i Machine Learning med beräkningsinstanser eller på AKS med självvärd.

Nästa steg