Applikationer för maskininlärning (ML) är komplexa att implementera och kräver ofta förmågan att hyperskala och har extremt låga latenskrav och stringenta kostnadsbudgetar. Användningsfall som bedrägeriupptäckt, produktrekommendationer och trafikförutsägelser är exempel där millisekunder är viktiga och avgörande för affärsframgång. Strikta servicenivåavtal (SLA) måste uppfyllas, och en typisk begäran kan kräva flera steg som förbearbetning, datatransformation, funktionsteknik, modellvalslogik, modellaggregation och efterbearbetning.
Att distribuera ML-modeller i stor skala med optimerad kostnad och beräkningseffektivitet kan vara en skrämmande och besvärlig uppgift. Varje modell har sina egna fördelar och beroenden baserat på de externa datakällorna samt runtime-miljön som CPU/GPU-kraft för de underliggande beräkningsresurserna. En applikation kan kräva flera ML-modeller för att betjäna en enda slutledningsbegäran. I vissa scenarier kan en begäran flöda över flera modeller. Det finns inget enskilt tillvägagångssätt, och det är viktigt för ML-utövare att leta efter beprövade metoder för att hantera återkommande ML-värdutmaningar. Detta har lett till utvecklingen av designmönster för ML-modellvärd.
I det här inlägget utforskar vi vanliga designmönster för att bygga ML-applikationer på Amazon SageMaker.
Designmönster för att bygga ML-applikationer
Låt oss titta på följande designmönster att använda för att vara värd för ML-applikationer.
Enkelmodellbaserade ML-applikationer
Det här är ett bra alternativ när ditt ML-användningsfall kräver en enda modell för att betjäna en begäran. Modellen är utplacerad på en dedikerad beräkningsinfrastruktur med möjlighet att skala baserat på ingångstrafiken. Det här alternativet är också idealiskt när klientapplikationen har ett slutledningskrav med låg latens (i storleksordningen millisekunder eller sekunder).
Flermodellbaserade ML-applikationer
För att göra hosting mer kostnadseffektivt tillåter detta designmönster dig att vara värd för flera modeller på samma hyresgästinfrastruktur. Flera ML-modeller kan dela värd- eller behållarresurserna, inklusive cachelagring av de mest använda ML-modellerna i minnet, vilket resulterar i bättre utnyttjande av minne och beräkningsresurser. Beroende på vilken typ av modeller du valde att distribuera, kan modellsamhotell använda följande metoder:
- Flermodellshotell – Det här alternativet låter dig vara värd för flera modeller med en delad serveringsbehållare på en enda slutpunkt. Den här funktionen är idealisk när du har ett stort antal liknande modeller som du kan servera genom en delad serveringsbehållare och inte behöver komma åt alla modeller samtidigt.
- Hosting för flera behållare – Det här alternativet är idealiskt när du har flera modeller som körs på olika visningsstackar med liknande resursbehov, och när enskilda modeller inte har tillräckligt med trafik för att utnyttja den fulla kapaciteten hos slutpunktsinstanserna. Hosting för flera behållare låter dig distribuera flera behållare som använder olika modeller eller ramverk på en enda slutpunkt. Modellerna kan vara helt heterogena, med en egen oberoende serveringsstack.
- Modellensembler – I många fall av produktionsanvändning kan det ofta finnas många uppströmsmodeller som matar insatser till en given nedströmsmodell. Det är här ensembler är användbara. Ensemblemönster involverar att blanda utdata från en eller flera basmodeller för att minska generaliseringsfel av förutsägelsen. Basmodellerna kan vara olika och tränas med olika algoritmer. Modellensembler kan prestera bättre än enstaka modeller eftersom modellens prediktionsfel minskar när ensemblemetoden används.
Följande är vanliga användningsfall av ensemblemönster och deras motsvarande designmönsterdiagram:
- Scatter-samla – I ett scatter-insamlingsmönster dirigeras en begäran om slutledning till ett antal modeller. En aggregator används sedan för att samla in svaren och destillera dem till ett enda slutledningssvar. Till exempel kan ett användningsfall för bildklassificering använda tre olika modeller för att utföra uppgiften. Spridningsmönstret låter dig kombinera resultat från slutsatser som körs på tre olika modeller och välja den mest sannolika klassificeringsmodellen.
- Modellaggregat – I ett aggregeringsmönster beräknas ett genomsnitt av utdata från flera modeller. För klassificeringsmodeller utvärderas flera modellers förutsägelser för att bestämma den klass som fick flest röster och behandlas som den slutliga produktionen av ensemblen. Till exempel, i ett klassificeringsproblem med två klasser för att klassificera en uppsättning frukter som apelsiner eller äpplen, om två modeller röstar på en apelsin och en modell röstar på ett äpple, blir den aggregerade produktionen en apelsin. Aggregation hjälper till att bekämpa felaktigheter i enskilda modeller och gör utdata mer exakt.
- Dynamiskt urval – Ett annat mönster för ensemblemodeller är att dynamiskt utföra modellval för de givna ingångsattributen. Till exempel, i en given ingång av bilder av frukter, om inmatningen innehåller en apelsin, kommer modell A att användas eftersom den är specialiserad på apelsiner. Om ingången innehåller ett äpple kommer modell B att användas eftersom den är specialiserad på äpplen.
- Seriell inferens ML-applikationer – Med ett seriellt inferensmönster, även känt som en inferenspipeline, har användningsfall krav på att förbehandla inkommande data innan en förtränad ML-modell för generering av slutledningar anropas. I vissa fall kan dessutom de genererade slutledningarna behöva bearbetas ytterligare så att de enkelt kan konsumeras av nedströmsapplikationer. En slutledningspipeline låter dig återanvända samma förbearbetningskod som användes under modellträning för att bearbeta inferensförfrågningsdata som används för förutsägelser.
- Företagslogik – Att producera ML innebär alltid affärslogik. Affärslogikmönster involverar allt som behövs för att utföra en ML-uppgift som inte är ML-modellinferens. Detta inkluderar att ladda modellen från Amazon enkel lagringstjänst (Amazon S3), till exempel, databasuppslagningar för att validera indata, erhålla förberäknade funktioner från funktionslagret och så vidare. När dessa affärslogiska steg är slutförda skickas indata till ML-modeller.
ML slutledningsalternativ
För modelldistribution är det viktigt att arbeta bakåt från ditt användningsfall. Vad är frekvensen av förutsägelsen? Förväntar du dig livetrafik till din applikation och realtidssvar till dina kunder? Har du många modeller utbildade för olika delmängder av data för samma användningsfall? Varierar förutsägelsetrafiken? Är latens för slutledning ett problem? Baserat på dessa detaljer kan alla föregående designmönster implementeras med hjälp av följande distributionsalternativ:
- Inferens i realtid – Realtidsinferens är idealisk för slutledningsarbetsbelastningar där du har interaktiva realtidskrav med låg latens. Arbetsbelastningar för ML-inferens i realtid kan inkludera en enmodellbaserad ML-applikation, där en applikation endast kräver en ML-modell för att betjäna en enda begäran, eller en multimodellbaserad ML-applikation, där en applikation kräver flera ML-modeller för att betjäna en enda begäran.
- Nästan realtid (asynkron) slutledning – Med nästan realtids slutledning kan du köa inkommande förfrågningar. Detta kan användas för att köra slutledning på ingångar som är hundratals MB. Den fungerar i nästan realtid och tillåter användare att använda indata för slutledning och läsa utdata från slutpunkten från en S3-skopa. Det kan särskilt vara praktiskt i fall med NLP och datorseende, där det finns stora nyttolaster som kräver längre förbehandlingstider.
- Batchavledning – Batch-inferens kan användas för att köra slutledning offline på en stor datamängd. Eftersom det körs offline, erbjuder inte batch-inferens den lägsta latensen. Här bearbetas slutledningsbegäran med antingen en schemalagd eller händelsebaserad trigger av ett batch slutledningsjobb.
- Serverlös slutledning – Serverlös slutledning är idealisk för arbetsbelastningar som har inaktiva perioder mellan trafiksprutor och som kan tolerera några extra sekunders latens (kallstart) för det första anropet efter en viloperiod. Till exempel en chatbottjänst eller en applikation för att bearbeta formulär eller analysera data från dokument. I det här fallet kanske du vill ha ett onlineslutledningsalternativ som automatiskt kan tillhandahålla och skala beräkningskapacitet baserat på volymen av slutledningsbegäranden. Och under inaktiv tid bör den kunna stänga av beräkningskapaciteten helt så att du inte laddas. Serverlös slutledning tar bort det odifferentierade tunga lyftet med att välja och hantera servrar genom att automatiskt starta beräkningsresurser och skala in och ut dem beroende på trafik.
Använd fitnessfunktioner för att välja rätt ML-inferensalternativ
Att välja rätt värdalternativ är viktigt eftersom det påverkar slutanvändarna som renderas av dina applikationer. För detta ändamål lånar vi begreppet fitnessfunktioner, som myntades av Neal Ford och hans kollegor från AWS Partner ThoughtWorks i deras arbete Bygga evolutionära arkitekturer. Fitnessfunktioner ger en preskriptiv bedömning av olika värdalternativ baserat på kundens mål. Fitnessfunktioner hjälper dig att skaffa nödvändiga data för att möjliggöra den planerade utvecklingen av din arkitektur. De sätter upp mätbara värden för att bedöma hur nära din lösning är att uppnå dina uppsatta mål. Fitnessfunktioner kan och bör anpassas i takt med att arkitekturen utvecklas för att styra en önskad förändringsprocess. Detta ger arkitekter ett verktyg för att vägleda sina team samtidigt som teamets självständighet bibehålls.
Det finns fem huvudsakliga fitnessfunktioner som kunder bryr sig om när det gäller att välja rätt ML-inferensalternativ för att vara värd för sina ML-modeller och applikationer.
Fitness funktion | Beskrivning |
Pris |
Att distribuera och underhålla en ML-modell och ML-applikation på ett skalbart ramverk är en kritisk affärsprocess, och kostnaderna kan variera mycket beroende på val som görs om modellvärdinfrastruktur, värdalternativ, ML-ramverk, ML-modellegenskaper, optimeringar, skalningspolicy, och mer. Arbetsbelastningen måste utnyttja hårdvaruinfrastrukturen optimalt för att säkerställa att kostnaden förblir i schack. Denna fitnessfunktion hänvisar specifikt till infrastrukturkostnaden, som är en del av den totala totala ägandekostnaden (TCO). Infrastrukturkostnaderna är de kombinerade kostnaderna för lagring, nätverk och beräkning. Det är också viktigt att förstå andra komponenter i TCO, inklusive driftskostnader och kostnader för säkerhet och efterlevnad. Driftskostnader är de kombinerade kostnaderna för drift, övervakning och underhåll av ML-infrastrukturen. Driftskostnaderna beräknas som antalet ingenjörer som krävs baserat på varje scenario och ingenjörernas årslön, aggregerad över en specifik period. Kunder som använder självhanterade ML-lösningar på Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), och Amazon Elastic Kubernetes-tjänst (Amazon EKS) behöver bygga operativa verktyg själva. Kunder som använder SageMaker får betydligt mindre TCO. SageMaker inferens är en helt hanterad tjänst och tillhandahåller möjligheter direkt för att distribuera ML-modeller för slutledning. Du behöver inte tillhandahålla instanser, övervaka instansernas tillstånd, hantera säkerhetsuppdateringar eller korrigeringar, sända operativa mätvärden eller bygga övervakning för dina ML-inferensarbetsbelastningar. Den har inbyggda möjligheter för att säkerställa hög tillgänglighet och motståndskraft. SageMaker stöder säkerhet med end-to-end-kryptering vid vila och under överföring, inklusive kryptering av rotvolymen och Amazon Elastic Block Store (Amazon EBS) volym, Amazon Virtual Private Cloud (Amazon VPC) stöd, AWS PrivateLink, kundhanterade nycklar, AWS identitets- och åtkomsthantering (IAM) finkornig åtkomstkontroll, AWS CloudTrail revisioner, internodkryptering för utbildning, taggbaserad åtkomstkontroll, nätverksisolering och Interactive Application Proxy. Alla dessa säkerhetsfunktioner tillhandahålls direkt i SageMaker och kan rädda företag tiotals utvecklingsmånader av ingenjörsarbete under en 3-årsperiod. SageMaker är en HIPAA-berättigad tjänst och är certifierad enligt PCI, SOC, GDPR och ISO. SageMaker stöder även FIPS-slutpunkter. För mer information om TCO, se Den totala ägandekostnaden för Amazon SageMaker. |
Slutledningslatens | Många ML-modeller och applikationer är fördröjningskritiska, där slutledningslatensen måste ligga inom de gränser som specificeras av ett servicenivåmål. Slutledningslatens beror på en mängd faktorer, inklusive modellstorlek och komplexitet, hårdvaruplattform, mjukvarumiljö och nätverksarkitektur. Till exempel kan större och mer komplexa modeller ta längre tid att köra slutledning. |
Genomströmning (transaktioner per sekund) | För modellinferens är optimering av genomströmningen avgörande för prestandajustering och för att uppnå affärsmålet för ML-applikationen. När vi fortsätter att utvecklas snabbt i alla aspekter av ML, inklusive implementeringar på låg nivå av matematiska operationer i chipdesign, spelar hårdvaruspecifika bibliotek en större roll i prestandaoptimering. Olika faktorer som nyttolaststorlek, nätverkshopp, typ av hopp, modelldiagramfunktioner, operatörer i modellen och CPU, GPU och minnesprofil för modellvärdinstanserna påverkar genomströmningen av ML-modellen. |
Skalningskonfigurationskomplexitet | Det är avgörande för ML-modellerna eller applikationerna att köras på ett skalbart ramverk som kan hantera efterfrågan från varierande trafik. Det möjliggör också maximalt utnyttjande av CPU- och GPU-resurser och förhindrar överprovisionering av beräkningsresurser. |
Förväntat trafikmönster | ML-modeller eller applikationer kan ha olika trafikmönster, allt från kontinuerlig realtidstrafik till periodiska toppar av tusentals förfrågningar per sekund, och från sällsynta, oförutsägbara förfrågningsmönster till offline-batchförfrågningar på större datamängder. Att arbeta bakåt från det förväntade trafikmönstret rekommenderas för att välja rätt värdalternativ för din ML-modell. |
Distribuera modeller med SageMaker
SageMaker är en fullt hanterad AWS-tjänst som ger varje utvecklare och datavetare möjlighet att snabbt bygga, träna och distribuera ML-modeller i stor skala. Med SageMaker inference kan du distribuera dina ML-modeller på värdbaserade slutpunkter och få slutledningsresultat. SageMaker tillhandahåller ett brett urval av hårdvara och funktioner för att möta dina arbetsbelastningskrav, vilket gör att du kan välja över 70 instanstyper med hårdvaruacceleration. SageMaker kan också ge rekommendationer om inferensinstanser med hjälp av en ny funktion som kallas SageMaker Inference Recommender, om du inte är säker på vilken som skulle vara mest optimal för din arbetsbelastning.
Du kan välja distributionsalternativ för att på bästa sätt möta dina användningsfall, såsom slutpunkter i realtid, asynkrona, batch- och till och med serverlösa slutpunkter. Dessutom erbjuder SageMaker olika distributionsstrategier som kanariefågel, blå grön, skugga, och A/B-testning för modellimplementering, tillsammans med kostnadseffektiv implementering med multi-modell, multi-container endpoints och elastisk skalning. Med SageMaker-inferens kan du se prestandamåtten för dina slutpunkter i amazoncloudwatch, automatiskt skala slutpunkter baserat på trafik, och uppdatera dina modeller i produktion utan att förlora någon tillgänglighet.
SageMaker erbjuder fyra alternativ för att distribuera din modell så att du kan börja göra förutsägelser:
- Inferens i realtid – Detta är lämpligt för arbetsbelastningar med millisekunders latenskrav, nyttolaststorlekar upp till 6 MB och bearbetningstider på upp till 60 sekunder.
- Batchtransformation – Detta är idealiskt för offlineförutsägelser om stora mängder data som är tillgängliga i förväg.
- Asynkron slutledning – Det här är designat för arbetsbelastningar som inte har krav på fördröjning under en sekund, nyttolaststorlekar upp till 1 GB och bearbetningstider på upp till 15 minuter.
- Serverlös slutledning – Med serverlös slutledning kan du snabbt distribuera ML-modeller för slutledning utan att behöva konfigurera eller hantera den underliggande infrastrukturen. Dessutom betalar du bara för den beräkningskapacitet som används för att behandla slutledningsförfrågningar, vilket är idealiskt för intermittent arbetsbelastning.
Följande diagram kan hjälpa dig att förstå utbyggnadsalternativen för SageMaker-värdmodellen tillsammans med tillhörande utvärderingar av fitnessfunktioner.
Låt oss utforska vart och ett av distributionsalternativen mer i detalj.
Realtids slutledning i SageMaker
SageMaker realtidsinferens rekommenderas om du har ihållande trafik och behöver lägre och konsekvent latens för dina förfrågningar med nyttolaststorlekar på upp till 6 MB och bearbetningstider på upp till 60 sekunder. Du distribuerar din modell till SageMakers värdtjänster och får en slutpunkt som kan användas för slutledning. Dessa slutpunkter är helt hanterade och stöder automatisk skalning. Realtidsinferens är populärt för användningsfall där du förväntar dig ett synkront svar med låg latens med förutsägbara trafikmönster, såsom personliga rekommendationer för produkter och tjänster eller användningsfall för upptäckt av transaktionsbedrägerier.
Vanligtvis skickar en klientapplikation förfrågningar till SageMaker HTTPS-slutpunkten för att få slutsatser från en utplacerad modell. Du kan distribuera flera varianter av en modell till samma SageMaker HTTPS-slutpunkt. Detta är användbart för att testa varianter av en modell i produktion. Med automatisk skalning kan du dynamiskt justera antalet instanser som tillhandahålls för en modell som svar på ändringar i din arbetsbelastning.
Följande tabell ger vägledning för att utvärdera SageMaker realtidsinferens baserat på fitnessfunktionerna.
Fitness funktion | Beskrivning |
Pris |
Realtidsslutpunkter erbjuder synkront svar på slutledningsförfrågningar. Eftersom slutpunkten alltid är igång och tillgänglig för att ge synkront slutledningssvar i realtid, betalar du för att använda instansen. Kostnaderna kan snabbt öka när du distribuerar flera slutpunkter, särskilt om slutpunkterna inte fullt ut utnyttjar de underliggande instanserna. Att välja rätt instans för din modell hjälper till att säkerställa att du har den mest presterande instansen till lägsta kostnad för dina modeller. Automatisk skalning rekommenderas för att dynamiskt justera kapaciteten beroende på trafik för att bibehålla en stabil och förutsägbar prestanda till lägsta möjliga kostnad. SageMaker utökar åtkomsten till Graviton2- och Graviton3-baserade ML-instansfamiljer. AWS Graviton processorer är specialbyggda av Amazon Web Services med hjälp av 64-bitars Arm Neoverse-kärnor för att leverera bästa prisprestanda för dina molnarbeten som körs på Amazon EC2. Med Graviton-baserade instanser har du fler alternativ för att optimera kostnaden och prestanda när du distribuerar dina ML-modeller på SageMaker. SageMaker stöder också Inf1-instanser, ger hög prestanda och kostnadseffektiv ML slutledning. Med 1–16 AWS Inferentia-chips per instans kan Inf1-instanser skala i prestanda och leverera upp till tre gånger högre genomströmning och upp till 50 % lägre kostnad per slutledning jämfört med AWS GPU-baserade instanser. För att använda Inf1-instanser i SageMaker kan du kompilera dina tränade modeller med hjälp av Amazon SageMaker Neo och välj Inf1-instanserna för att distribuera den kompilerade modellen på SageMaker. Du kan också utforska Sparplaner för SageMaker att dra nytta av kostnadsbesparingar på upp till 64 % jämfört med on-demand-priset. När du skapar en slutpunkt, kopplar SageMaker en EBS-lagringsvolym till varje ML-beräkningsinstans som är värd för slutpunkten. Storleken på lagringsvolymen beror på instanstypen. Ytterligare kostnad för realtidsändpunkter inkluderar kostnaden för GB-månads provisionerad lagring, plus GB-data som bearbetas in och GB-data som bearbetas från slutpunktsinstansen. |
Slutledningslatens | Realtidsinferens är idealiskt när du behöver en beständig slutpunkt med millisekunders latenskrav. Den stöder nyttolaststorlekar på upp till 6 MB och bearbetningstider på upp till 60 sekunder. |
genomströmning |
Ett idealiskt värde för slutledningsgenomströmning är subjektivt för faktorer som modell, modellinmatningsstorlek, batchstorlek och typ av slutpunktsinstans. Som en bästa praxis, granska CloudWatch-statistik för indataförfrågningar och resursanvändning, och välj lämplig instanstyp för att uppnå optimal genomströmning. En affärsapplikation kan antingen vara genomströmningsoptimerad eller latensoptimerad. Till exempel kan dynamisk batchning hjälpa till att öka genomströmningen för latenskänsliga appar med hjälp av realtidsinferens. Det finns dock gränser för batchstorlek, utan vilka slutledningsfördröjningen kan påverkas. Slutledningslatens kommer att växa när du ökar batchstorleken för att förbättra genomströmningen. Därför är realtidsinferens ett idealiskt alternativ för latenskänsliga applikationer. SageMaker tillhandahåller alternativ för asynkron slutledning och batchtransformering, som är optimerade för att ge högre genomströmning jämfört med realtidsinferens om affärsapplikationerna kan tolerera en något högre latens. |
Skalningskonfigurationskomplexitet |
SageMaker-slutpunkter i realtid automatisk skalning utanför lådan. När arbetsbelastningen ökar gör automatisk skalning fler instanser online. När arbetsbelastningen minskar tar automatisk skalning bort onödiga instanser, vilket hjälper dig att minska din beräkningskostnad. Utan automatisk skalning måste du ta hänsyn till högtrafik eller otillgänglighet av riskmodeller. Om inte trafiken till din modell är jämn under hela dagen, kommer det att finnas överskott av outnyttjad kapacitet. Detta leder till lågt utnyttjande och slöseri med resurser. Med SageMaker kan du konfigurera olika skalningsalternativ baserat på det förväntade trafikmönstret. Enkel skalning eller målspårningsskalning är idealiskt när du vill skala baserat på ett specifikt CloudWatch-mått. Du kan göra detta genom att välja ett specifikt mått och ställa in tröskelvärden. De rekommenderade mätvärdena för det här alternativet är genomsnittliga Om du behöver avancerad konfiguration kan du ställa in en policy för stegskalning för att dynamiskt justera antalet instanser som ska skalas baserat på storleken på larmöverträdelsen. Detta hjälper dig att konfigurera ett mer aggressivt svar när efterfrågan når en viss nivå. Du kan använda ett schemalagt skalningsalternativ när du vet att efterfrågan följer ett visst schema under dagen, veckan, månaden eller året. Detta hjälper dig att specificera ett engångsschema eller ett återkommande schema eller cron-uttryck tillsammans med start- och sluttider, som utgör gränserna för när den automatiska skalningsåtgärden startar och slutar. Mer information finns i Konfigurera slutpunkter för automatisk skalning av slutpunkter i Amazon SageMaker och Ladda testa och optimera en Amazon SageMaker-slutpunkt med hjälp av automatisk skalning. |
Trafikmönster | Realtidsinferens är idealisk för arbetsbelastningar med ett kontinuerligt eller regelbundet trafikmönster. |
Asynkron slutledning i SageMaker
SageMaker asynkron inferens är en ny funktion i SageMaker som köar inkommande förfrågningar och behandlar dem asynkront. Det här alternativet är idealiskt för förfrågningar med stora nyttolaststorlekar (upp till 1 GB), långa bearbetningstider (upp till 15 minuter) och fördröjningskrav i nästan realtid. Exempel på arbetsbelastningar för asynkron slutledning inkluderar hälsovårdsföretag som bearbetar högupplösta biomedicinska bilder eller videor som ekokardiogram för att upptäcka anomalier. Dessa applikationer tar emot skurar av inkommande trafik vid olika tidpunkter på dygnet och kräver bearbetning nästan i realtid till låg kostnad. Bearbetningstiderna för dessa förfrågningar kan variera i storleksordningen minuter, vilket eliminerar behovet av att köra slutledning i realtid. Istället kan indata bearbetas asynkront från en objektbutik som Amazon S3 med automatisk köning och en fördefinierad samtidighetströskel. Vid bearbetning placerar SageMaker slutledningssvaret på den tidigare returnerade Amazon S3-platsen. Du kan valfritt välja att få framgångs- eller felmeddelanden via Amazon enkel meddelandetjänst (Amazon SNS).
Följande tabell ger vägledning för att utvärdera SageMaker asynkron slutledning baserat på fitnessfunktionerna.
Fitness funktion | Beskrivning |
Pris | Asynkron slutledning är ett utmärkt val för kostnadskänsliga arbetsbelastningar med stora nyttolaster och bursttrafik. Asynkron slutledning gör att du kan spara på kostnader genom att automatiskt skala instansräkningen till noll när det inte finns några förfrågningar att behandla, så du betalar bara när din slutpunkt behandlar förfrågningar. Förfrågningar som tas emot när det finns noll instanser köas för behandling efter att ändpunkten skalas upp. |
Slutledningslatens | Asynkron slutledning är idealisk för fördröjningskrav i nästan realtid. Förfrågningarna placeras i en kö och behandlas så snart beräkningen är tillgänglig. Detta resulterar vanligtvis i tiotals millisekunder i latens. |
genomströmning | Asynkron slutledning är idealisk för användningsfall som inte är känsliga för latens, eftersom applikationer inte behöver kompromissa med genomströmningen. Begäranden släpps inte under trafikspikar eftersom den asynkrona slutpunkten för slutpunkten köar förfrågningar istället för att ta bort dem. |
Skalningskonfigurationskomplexitet |
SageMaker stöder automatisk skalning för asynkron slutpunkt. Till skillnad från värdbaserade slutpunkter i realtid, stödjer asynkrona slutpunkter för slutpunkter att skala ner instanser till noll genom att sätta minimikapaciteten till noll. För asynkrona slutpunkter rekommenderar SageMaker starkt att du skapar en policykonfiguration för målspårningsskalning för en distribuerad modell (variant). För användningsfall som kan tolerera en kallstartsavgift på några minuter, kan du valfritt skala ner slutpunktsinstansräkningen till noll när det inte finns några utestående förfrågningar och skala upp igen när nya förfrågningar kommer så att du bara betalar för den tid som endpoints bearbetar aktivt förfrågningar. |
Trafikmönster | Asynkrona slutpunkter köar inkommande förfrågningar och behandlar dem asynkront. De är ett bra alternativ för intermittenta eller sällsynta trafikmönster. |
Batch slutledning i SageMaker
SageMaker batchtransform är idealisk för offline-förutsägelser om stora mängder data som är tillgängliga i förväg. Batchtransformeringsfunktionen är en högpresterande och högkapacitetsmetod för att transformera data och generera slutsatser. Den är idealisk för scenarier där du har att göra med stora mängder data, inte behöver fördröjning under en sekund eller behöver både förbearbeta och transformera träningsdata. Kunder inom vissa domäner som reklam och marknadsföring eller hälsovård behöver ofta göra offlineförutsägelser på datauppsättningar i hyperskala där hög genomströmning ofta är syftet med användningsfallet och latens inte är ett problem.
När ett batchtransformeringsjobb startar, initierar SageMaker beräkningsinstanser och fördelar inferensarbetsbelastningen mellan dem. Det frigör resurserna när jobben är klara, så du betalar bara för det som användes under körningen av ditt jobb. När jobbet är klart sparar SageMaker förutsägelseresultaten i en S3-bucket som du anger. Batch slutledningsuppgifter är vanligtvis bra kandidater för horisontell skalning. Varje arbetare inom ett kluster kan arbeta på olika delmängder av data utan att behöva utbyta information med andra arbetare. AWS erbjuder flera lagrings- och beräkningsalternativ som möjliggör horisontell skalning. Exempel på arbetsbelastningar för SageMaker batchtransformering inkluderar offlineapplikationer som bankapplikationer för att förutsäga kundavgång där ett offlinejobb kan schemaläggas att köras regelbundet.
Följande tabell ger vägledning för att utvärdera SageMaker batchtransformering baserat på fitnessfunktionerna.
Fitness funktion | Beskrivning |
Pris | SageMaker batchtransformering låter dig köra förutsägelser på stora eller små batchdatauppsättningar. Du debiteras för den instanstyp du väljer, baserat på användningstiden. SageMaker hanterar tillhandahållandet av resurser i början av jobbet och släpper dem när jobbet är klart. Det tillkommer ingen extra kostnad för databehandling. |
Slutledningslatens | Du kan använda händelsebaserad eller schemalagd anrop. Latensen kan variera beroende på storleken på slutledningsdata, samtidigt jobb, modellens komplexitet och beräkningsinstanskapacitet. |
genomströmning |
Batchtransformeringsjobb kan göras på en rad datauppsättningar, från petabyte data till mycket små datauppsättningar. Det finns inget behov av att ändra storlek på större datamängder till små databitar. Du kan påskynda batchtransformeringsjobb genom att använda optimala värden för parametrar som t.ex MaxPayloadInMB, MaxConcurrentTransforms, eller Batchstrategi. Det idealiska värdet för Batchbearbetning kan öka genomströmningen och optimera dina resurser eftersom det hjälper till att slutföra ett större antal slutsatser under en viss tid på bekostnad av latens. För att optimera modelldistributionen för högre genomströmning är den allmänna riktlinjen att öka satsstorleken tills genomströmningen minskar. |
Skalningskonfigurationskomplexitet | SageMaker batchtransformering används för offline slutledning som inte är latenskänslig. |
Trafikmönster | För offline slutledning schemaläggs eller startas ett batchtransformeringsjobb med en händelsebaserad utlösare. |
Serverlös slutledning i SageMaker
SageMaker serverlös inferens låter dig distribuera ML-modeller för slutledning utan att behöva konfigurera eller hantera den underliggande infrastrukturen. Baserat på mängden slutledningsförfrågningar som din modell tar emot, tillhandahåller SageMaker serverlös slutledning automatiskt, skalar och stänger av beräkningskapacitet. Som ett resultat betalar du endast för beräkningstiden för att köra din slutledningskod och mängden data som behandlas, inte för vilotid. Du kan använda SageMakers inbyggda algoritmer och ML-ramverksservande behållare för att distribuera din modell till en serverlös slutpunkt eller välja att ta med din egen behållare. Om trafiken blir förutsägbar och stabil kan du enkelt uppdatera från en serverlös slutpunkt till en SageMaker realtidsslutpunkt utan att behöva göra ändringar i din containerbild. Med serverlös slutledning drar du också nytta av andra SageMaker-funktioner, inklusive inbyggda mätvärden som anropsantal, fel, latens, värdstatistik och fel i CloudWatch.
Följande tabell ger vägledning för att utvärdera SageMaker serverlös slutledning baserat på fitnessfunktionerna.
Fitness funktion | Beskrivning |
Pris | Med en pay-as-you-run-modell är serverlös slutledning ett kostnadseffektivt alternativ om du har sällsynta eller intermittenta trafikmönster. Du betalar endast för den tid som slutpunkten bearbetar begäran och kan därför spara kostnader om trafikmönstret är intermittent. |
Slutledningslatens |
Serverlösa slutpunkter erbjuder låg slutledningslatens (i storleksordningen millisekunder till sekunder), med möjligheten att skala omedelbart från tiotals till tusentals slutsatser inom några sekunder baserat på användningsmönstren, vilket gör den idealisk för ML-applikationer med intermittent eller oförutsägbar trafik. Eftersom serverlösa slutpunkter tillhandahåller beräkningsresurser på begäran, kan din slutpunkt uppleva några extra sekunders latens (kallstart) för den första anropet efter en inaktiv period. Kallstarttiden beror på din modellstorlek, hur lång tid det tar att ladda ner din modell och starttiden för din behållare. |
genomströmning | När du konfigurerar din serverlösa slutpunkt kan du ange minnesstorlek och maximalt antal samtidiga anrop. SageMaker serverlös slutledning tilldelar automatiskt beräkningsresurser proportionellt mot det minne du väljer. Om du väljer en större minnesstorlek har din behållare tillgång till fler vCPU:er. Som en allmän regel bör minnesstorleken vara minst lika stor som din modellstorlek. Minnesstorlekarna du kan välja är 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB och 6144 MB. Oavsett vilken minnesstorlek du väljer har serverlösa slutpunkter 5 GB tillfällig disklagring tillgänglig. |
Skalningskonfigurationskomplexitet | Serverlösa slutpunkter startar automatiskt beräkningsresurser och skalar in och ut dem beroende på trafik, vilket eliminerar behovet av att välja instanstyper eller hantera skalningspolicyer. Detta tar bort det odifferentierade tunga lyftet av att välja och hantera servrar. |
Trafikmönster | Serverlös slutledning är idealisk för arbetsbelastningar med sällsynta eller intermittenta trafikmönster. |
Modellvärddesignmönster i SageMaker
SageMaker slutpunkter för slutpunkter använder Docker-behållare för att vara värd för ML-modeller. Behållare låter dig paketera programvara i standardiserade enheter som körs konsekvent på alla plattformar som stöder Docker. Detta säkerställer portabilitet över plattformar, oföränderlig infrastrukturinstallationer och enklare förändringshantering och CI/CD-implementeringar. SageMaker tillhandahåller förbyggda hanterade behållare för populära ramverk som Apache MXNet, TensorFlow, PyTorch, Sklearn och Hugging Face. För en fullständig lista över tillgängliga SageMaker-behållarbilder, se Tillgängliga bilder för Deep Learning Containers. Om SageMaker inte har en behållare som stöds, kan du också bygga din egen behållare (BYOC) och pusha din egen anpassade bild, installera de beroenden som är nödvändiga för din modell.
För att distribuera en modell på SageMaker behöver du en behållare (SageMaker-hanterade ramverksbehållare eller BYOC) och en beräkningsinstans som värd för behållaren. SageMaker stöder flera avancerade alternativ för vanliga designmönster för ML-modellvärdar där modeller kan vara värd på en enda container eller co-host på en delad container.
En ML-applikation i realtid kan använda en enda modell eller flera modeller för att betjäna en enda förutsägelseförfrågan. Följande diagram visar olika slutledningsscenarier för en ML-applikation.
Låt oss utforska ett lämpligt SageMaker-värdalternativ för vart och ett av de föregående slutledningsscenarierna. Du kan hänvisa till fitnessfunktionerna för att bedöma om det är rätt alternativ för det givna användningsfallet.
Värd för en enmodellbaserad ML-applikation
Det finns flera alternativ för att vara värd för enmodellbaserade ML-applikationer med SageMaker-värdtjänster beroende på installationsscenariot.
Endpoint för en modell
SageMaker enkelmodellslutpunkter låter dig vara värd för en modell på en behållare som är värd för dedikerade instanser för låg latens och hög genomströmning. Dessa slutpunkter är helt hanterade och stöder automatisk skalning. Du kan konfigurera slutpunkten med en modell som en tillhandahållen slutpunkt där du skickar in slutpunktsinfrastrukturkonfiguration som instanstyp och antal, eller en serverlös slutpunkt där SageMaker automatiskt startar beräkningsresurser och skalar in och ut dem beroende på trafik, vilket eliminerar behovet för att välja instanstyper eller hantera skalningspolicyer. Serverlösa slutpunkter är för applikationer med intermittent eller oförutsägbar trafik.
Följande diagram visar slutpunktsscenarier för en enda modell.
Följande tabell ger vägledning för att utvärdera konditionsfunktioner för en tillhandahållen slutpunkt för en modell. För serverless endpoint fitness-funktionsutvärderingar, se avsnittet serverless endpoint i det här inlägget.
Fitness funktion | Beskrivning |
Pris | Du debiteras för användning av den instanstyp du väljer. Eftersom slutpunkten alltid är igång och tillgänglig kan kostnaderna snabbt öka. Att välja rätt instans för din modell hjälper till att säkerställa att du har den mest presterande instansen till lägsta kostnad för dina modeller. Automatisk skalning rekommenderas för att dynamiskt justera kapaciteten beroende på trafik för att bibehålla en stabil och förutsägbar prestanda till lägsta möjliga kostnad. |
Slutledningslatens | En slutpunkt i en enda modell ger interaktiv, synkron slutledning i realtid med krav på millisekunders latens. |
genomströmning | Genomströmningen kan påverkas av olika faktorer, som modellinmatningsstorlek, batchstorlek, typ av slutpunktsinstans och så vidare. Det rekommenderas att granska CloudWatch-statistik för inmatningsförfrågningar och resursutnyttjande, och välja lämplig instanstyp för att uppnå optimal genomströmning. SageMaker tillhandahåller funktioner för att hantera resurser och optimera slutledningsprestanda vid distribution av ML-modeller. Du kan optimera modellens prestanda med Neo, eller använd Inf1-instanser för bättre genomströmning av dina SageMaker-värdmodeller med en GPU-instans för din slutpunkt. |
Skalningskonfigurationskomplexitet | Automatisk skalning stöds direkt från förpackningen. SageMaker rekommenderar att du väljer en lämplig skalningskonfiguration genom att utföra belastningstester. |
Trafikmönster | En slutpunkt i en modell är idealisk för arbetsbelastningar med förutsägbara trafikmönster. |
Samvärd för flera modeller
När du har att göra med ett stort antal modeller kan implementering av var och en på en individuell slutpunkt med en dedikerad behållare och instans resultera i en betydande kostnadsökning. Dessutom blir det också svårt att hantera så många modeller i produktionen, speciellt när du inte behöver anropa alla modeller samtidigt men ändå behöver vara tillgängliga hela tiden. Att vara värd för flera modeller på samma underliggande beräkningsresurser gör det enkelt att hantera ML-distributioner i stor skala och sänker dina värdkostnader genom ökad användning av slutpunkten och dess underliggande beräkningsresurser. SageMaker stöder avancerade samvärdsalternativ för modeller som multi-model endpoint (MME) för homogena modeller och multi-container endpoint (MCE) för heterogena modeller. Homogena modeller använder samma ML-ramverk på en delad tjänstebehållare, medan heterogena modeller låter dig distribuera flera serveringsbehållare som använder olika modeller eller ramverk på en enda slutpunkt.
Följande diagram visar alternativ för modellsamhotell med SageMaker.
SageMaker flermodellslutpunkter
SageMaker MME låter dig vara värd för flera modeller med en delad serveringsbehållare på en enda slutpunkt. Detta är en skalbar och kostnadseffektiv lösning för att distribuera ett stort antal modeller som tillgodoser samma användningsfall, ramverk eller slutledningslogik. MME:er kan dynamiskt betjäna förfrågningar baserat på den modell som anropas av den som ringer. Det minskar också distributionskostnader eftersom SageMaker hanterar att ladda modeller i minnet och skala dem baserat på trafikmönstren till dem. Den här funktionen är idealisk när du har ett stort antal liknande modeller som du kan servera genom en delad serveringsbehållare och inte behöver komma åt alla modeller samtidigt. Flermodellslutpunkter möjliggör också tidsdelning av minnesresurser mellan dina modeller. Detta fungerar bäst när modellerna är ganska lika i storlek och anropslatens, vilket gör att MME:er effektivt kan använda instanserna över alla modeller. SageMaker MME:er stöder värd för både CPU- och GPU-stödda modeller. Genom att använda GPU-stödda modeller kan du sänka dina modellimplementeringskostnader genom ökad användning av slutpunkten och dess underliggande accelererade beräkningsinstanser. För en verklig användning av MME:er, se Hur man skalar inferens för maskininlärning för SaaS-användningsfall med flera hyresgäster.
Följande tabell ger vägledning för att utvärdera fitnessfunktionerna för MME:er.
Fitness funktion | Beskrivning |
Pris |
MME:er gör det möjligt att använda en delad serveringsbehållare för att vara värd för tusentals modeller på en enda slutpunkt. Detta minskar värdkostnaderna avsevärt genom att förbättra användningen av slutpunkter jämfört med att använda slutpunkter med en enda modell. Till exempel, om du har 10 modeller att distribuera med en ml.c5.large-instans, baserat på SageMaker prissättning, kostnaden för att ha 10 beständiga slutpunkter för en enda modell är: 10 * $0.102 = $1.02 per timme. Medan en MME som är värd för de 10 modellerna, uppnår vi 10 gånger kostnadsbesparingar: 1 * $0.102 = $0.102 per timme. |
Slutledningslatens |
Som standard cachelagrar MME ofta använda modeller i minnet och på disken för att ge slutledning med låg latens. De cachade modellerna laddas ur eller raderas från disk endast när en behållare tar slut på minne eller diskutrymme för att rymma en nyligen riktad modell. MME:er tillåter lat inläsning av modeller, vilket innebär att modeller läses in i minnet när de anropas för första gången. Detta optimerar minnesutnyttjandet; det orsakar dock svarstidstoppar vid första laddning, vilket resulterar i ett kallstartsproblem. Därför är MME också väl lämpade för scenarier som kan tolerera enstaka kallstartsrelaterade latenspåföljder som uppstår när man anropar sällan använda modeller. För att möta latens- och genomströmningsmålen för ML-applikationer är GPU-instanser att föredra framför CPU-instanser (med tanke på beräkningskraftens GPU:er erbjuder). Med MME-stöd för GPU kan du distribuera tusentals djupinlärningsmodeller bakom en enda SageMaker-slutpunkt. MME:er kan köra flera modeller på en GPU-kärna, dela GPU-instanser bakom en slutpunkt över flera modeller och dynamiskt ladda och ladda ner modeller baserat på den inkommande trafiken. Med detta kan du avsevärt spara kostnader och uppnå bästa prisprestanda. Om ditt användningsfall kräver betydligt högre transaktioner per sekund (TPS) eller latenskrav rekommenderar vi att du är värd för modellerna på dedikerade slutpunkter. |
genomströmning |
Ett idealiskt värde för MME-inferensgenomströmning beror på faktorer som modell, nyttolaststorlek och slutpunktsinstanstyp. En högre mängd instansminne gör att du kan ha fler modeller laddade och redo att betjäna slutledningsförfrågningar. Du behöver inte slösa tid på att ladda modellen. En högre mängd vCPU:er gör att du kan anropa fler unika modeller samtidigt. MME:er laddar och laddar ur modellen dynamiskt till och från instansminnet, vilket kan påverka I/O-prestandan. SageMaker MME med GPU fungerar med NVIDIA Triton Inference Server, som är en öppen källkod för inferensservering som förenklar inferensserveringsprocessen och ger hög slutledningsprestanda. SageMaker laddar modellen till NVIDIA Triton-behållarens minne på en GPU-accelererad instans och betjänar slutledningsbegäran. GPU-kärnan delas av alla modeller i en instans. Om modellen redan är laddad i containerminnet, serveras de efterföljande förfrågningarna snabbare eftersom SageMaker inte behöver ladda ner och ladda den igen. En korrekt prestandatestning och analys rekommenderas vid framgångsrika produktionsinstallationer. SageMaker tillhandahåller CloudWatch-statistik för flermodellslutpunkter så att du kan bestämma slutpunktsanvändningen och cacheminnets träfffrekvens för att hjälpa till att optimera din slutpunkt. |
Skalningskonfigurationskomplexitet | SageMaker multi-model endpoints har fullt stöd för automatisk skalning, som hanterar kopior av modeller för att säkerställa att modeller skalas baserat på trafikmönster. En korrekt belastningstestning rekommenderas dock för att fastställa den optimala storleken på instanserna för automatisk skalning av slutpunkten. Rätt dimensionering av MME-flottan är viktigt för att undvika att alltför många modeller lossas. Att ladda hundratals modeller på ett fåtal större instanser kan leda till strypning i vissa fall, och användning av fler och mindre instanser kan vara att föredra. För att dra fördel av automatiserad modellskalning i SageMaker, se till att du har ställ in automatisk skalning för instans för att tillhandahålla ytterligare instanskapacitet. Ställ in din skalningspolicy på slutpunktsnivå med antingen anpassade parametrar eller anrop per minut (rekommenderas) för att lägga till fler instanser till slutpunktsflottan. Anropshastigheterna som används för att utlösa en automatisk skalningshändelse baseras på den sammanlagda uppsättningen av förutsägelser över hela uppsättningen modeller som betjänas av slutpunkten. |
Trafikmönster | MME:er är idealiska när du har ett stort antal modeller av liknande storlek som du kan servera genom en delad serveringsbehållare och inte behöver komma åt alla modeller samtidigt. |
SageMaker slutpunkter för flera behållare
SageMaker MCE:er stöd för att distribuera upp till 15 behållare som använder olika modeller eller ramverk på en enda slutpunkt, och anropa dem oberoende eller i sekvens för slutledning med låg latens och kostnadsbesparingar. Modellerna kan vara helt heterogena, med en egen oberoende serveringsstack. Säker värd för flera modeller från olika ramverk på en enda instans kan spara upp till 90 % i kostnad.
MCE-anropsmönstren är följande:
- Slutledningsledningar – Behållare i en MME kan anropas i en linjär sekvens, även känd som en seriell slutledningspipeline. De används vanligtvis för att separera förbearbetning, modellinferens och efterbearbetning i oberoende behållare. Utdata från den aktuella behållaren skickas som indata till nästa. De är representerade som en enda pipeline-modell i SageMaker. En slutledningspipeline kan distribueras som en MME, där en av behållarna i pipelinen dynamiskt kan betjäna förfrågningar baserat på modellen som anropas.
- Direkt anrop - Med direkt anrop, kan en begäran skickas till en specifik slutledningsbehållare som finns på en MCE.
Följande tabell ger vägledning för att utvärdera konditionsfunktionerna för MCE.
Fitness funktion | Beskrivning |
Pris | MCE:er gör att du kan köra upp till 15 olika ML-behållare på en enda slutpunkt och anropa dem oberoende, vilket sparar kostnader. Det här alternativet är idealiskt när du har flera modeller som körs på olika visningsstackar med liknande resursbehov, och när enskilda modeller inte har tillräckligt med trafik för att utnyttja den fulla kapaciteten hos slutpunktsinstanserna. MCE:er är därför mer kostnadseffektiva än en endpoint med en modell. MCE:er erbjuder synkront slutledningssvar, vilket innebär att slutpunkten alltid är tillgänglig och du betalar för instansens upptid. Kostnaden kan läggas ihop beroende på antalet och typen av instanser. |
Slutledningslatens | MCE:er är idealiska för att köra ML-appar med olika ML-ramverk och algoritmer för varje modell som nås sällan men som fortfarande kräver slutledning med låg latens. Modellerna är alltid tillgängliga för slutledning med låg latens och det finns inga kallstartsproblem. |
genomströmning | MCE:er är begränsade till upp till 15 behållare på en slutpunkt för flera behållare, och GPU-inferens stöds inte på grund av resurskonflikt. För slutpunkter med flera behållare som använder direktanropsläge tillhandahåller SageMaker inte bara mätvärden på instansnivå som det gör med andra vanliga slutpunkter, utan stöder också mätvärden per behållare. Som en bästa praxis, granska CloudWatch-statistik för indataförfrågningar och resursanvändning, och välj lämplig instanstyp för att uppnå optimal genomströmning. |
Skalningskonfigurationskomplexitet | MCE:er stöder automatisk skalning. Men för att konfigurera automatisk skalning rekommenderas det att modellen i varje behållare uppvisar liknande CPU-användning och latens vid varje slutledningsbegäran. Detta rekommenderas eftersom om trafiken till slutpunkten med flera behållare skiftar från en modell med låg CPU-användning till en modell med hög CPU-användning, men den totala samtalsvolymen förblir densamma, skalas inte slutpunkten ut och det kanske inte finns tillräckligt med instanser för att hantera alla förfrågningar till modellen med hög CPU-användning. |
Trafikmönster | MCE:er är idealiska för arbetsbelastningar med kontinuerliga eller regelbundna trafikmönster, för värdmodeller över olika ramverk (som TensorFlow, PyTorch eller Sklearn) som kanske inte har tillräckligt med trafik för att mätta den fulla kapaciteten hos en slutpunktsinstans. |
Värd för en multimodellbaserad ML-applikation
Många affärsapplikationer behöver använda flera ML-modeller för att skicka en enda förutsägelseförfrågan till sina konsumenter. Till exempel ett detaljhandelsföretag som vill ge rekommendationer till sina användare. ML-applikationen i detta användningsfall kanske vill använda olika anpassade modeller för att rekommendera olika kategorier av produkter. Om företaget vill lägga till personalisering till rekommendationerna genom att använda individuell användarinformation, ökar antalet anpassade modeller ytterligare. Att vara värd för varje anpassad modell på en distinkt beräkningsinstans är inte bara kostnadskrävande, utan leder också till underutnyttjande av värdresurserna om inte alla modeller används ofta. SageMaker erbjuder effektiva värdalternativ för multimodellbaserade ML-applikationer.
Följande diagram visar värdalternativ för flera modeller för en enda slutpunkt med SageMaker.
Seriell slutledningspipeline
En inferenspipeline är en SageMaker-modell som är sammansatt av en linjär sekvens av 2–15 behållare som behandlar förfrågningar om slutsatser om data. Du använder en slutledningspipeline för att definiera och distribuera valfri kombination av förtränade SageMaker inbyggda algoritmer och dina egna anpassade algoritmer paketerade i Docker-behållare. Du kan använda en slutledningspipeline för att kombinera uppgifter för förbearbetning, förutsägelser och efterbearbetning av datavetenskap. Utdata från en behållare skickas som indata till nästa. När du definierar behållarna för en pipelinemodell anger du också i vilken ordning behållarna körs. De är representerade som en enda pipeline-modell i SageMaker. Inferenspipelinen kan distribueras som en MME, där en av behållarna i pipelinen dynamiskt kan betjäna förfrågningar baserat på modellen som anropas. Du kan också köra en batch-omvandling jobb med en slutledningspipeline. Slutledningsledningar hanteras fullt ut.
Följande tabell ger vägledning för att utvärdera fitnessfunktionerna för värd för ML-modeller med hjälp av en seriell slutledningspipeline.
Fitness funktion | Beskrivning |
Pris | Seriell inferenspipeline gör att du kan köra upp till 15 olika ML-behållare på en enda slutpunkt, vilket leder till kostnadseffektivitet för att vara värd för slutledningsbehållarna. Det tillkommer inga extra kostnader för att använda den här funktionen. Du betalar endast för de instanser som körs på en slutpunkt. Kostnaden kan läggas ihop beroende på antalet och typen av instanser. |
Slutledningslatens | När en ML-applikation distribueras som en slutledningspipeline lämnar inte data mellan olika modeller behållarutrymmet. Funktionsbearbetning och slutledningar körs med låg latens eftersom behållarna är samlokaliserade på samma EC2-instanser. |
genomströmning | Inom en inferenspipelinemodell hanterar SageMaker anrop som en sekvens av HTTP-förfrågningar. Den första behållaren i pipelinen hanterar den initiala begäran, sedan skickas mellansvaret som en begäran till den andra behållaren, och så vidare, för varje behållare i pipelinen. SageMaker returnerar det slutliga svaret till kunden. Genomströmningen är subjektiv för faktorer som modell, modellinmatningsstorlek, batchstorlek och slutpunktsinstanstyp. Som en bästa praxis, granska CloudWatch-statistik för indataförfrågningar och resursanvändning, och välj lämplig instanstyp för att uppnå optimal genomströmning. |
Skalningskonfigurationskomplexitet | Seriella inferenspipelines stöder automatisk skalning. Men för att konfigurera automatisk skalning rekommenderas det att modellen i varje behållare uppvisar liknande CPU-användning och latens vid varje slutledningsbegäran. Detta rekommenderas eftersom om trafiken till slutpunkten med flera behållare skiftar från en modell med låg CPU-användning till en modell med hög CPU-användning, men den totala samtalsvolymen förblir densamma, skalas inte slutpunkten ut och det kanske inte finns tillräckligt med instanser för att hantera alla förfrågningar till modellen med hög CPU-användning. |
Trafikmönster |
Seriella inferenspipelines är idealiska för förutsägbara trafikmönster med modeller som körs sekventiellt på samma slutpunkt. |
Utplacera modellensembler (Triton DAG):
SageMaker erbjuder integration med NVIDIA Triton Inference Server dig genom Triton Inference Server Containers. Dessa behållare inkluderar NVIDIA Triton Inference Server, stöd för vanliga ML-ramverk och användbara miljövariabler som låter dig optimera prestanda på SageMaker. Med NVIDIA Triton-containerbilder kan du enkelt servera ML-modeller och dra nytta av prestandaoptimeringarna, dynamisk batchning och stöd för flera ramar som NVIDIA Triton erbjuder. Triton hjälper till att maximera utnyttjandet av GPU och CPU, vilket ytterligare sänker kostnaden för slutledning.
I affärsanvändningsfall där ML-applikationer använder flera modeller för att betjäna en förutsägelseförfrågan, om varje modell använder ett annat ramverk eller är värd på en separat instans, kan det leda till ökad arbetsbelastning och kostnad samt en ökning av den totala latensen. SageMaker NVIDIA Triton Inference Server stöder distribution av modeller från alla större ramverk, som TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT och Python/C++ modellformat med mera. Triton modellensemble representerar en pipeline av en eller flera modeller eller förbearbetnings- och efterbearbetningslogik, och anslutningen av ingångs- och utgångstensorer mellan dem. En enda slutledningsbegäran till en ensemble utlöser körningen av hela pipelinen. Triton har också flera inbyggda schemaläggnings- och batchalgoritmer som kombinerar individuella slutledningsbegäranden för att förbättra slutledningsgenomströmningen. Dessa schemaläggnings- och batchbeslut är transparenta för klienten som begär slutledning. Modellerna kan köras på CPU:er eller GPU:er för maximal flexibilitet och för att stödja heterogena datorkrav.
Att vara värd för flera GPU-stödda modeller på flermodellslutpunkter stöds genom SageMaker Triton Inference Server. NVIDIA Triton Inference Server har utökats för att implementera en MME API-kontrakt, för att integrera med MME. Du kan använda NVIDIA Triton Inference Server, som skapar en modelllagringskonfiguration för olika ramverksbackends, för att distribuera en MME med automatisk skalning. Den här funktionen låter dig skala hundratals hyperpersonifierade modeller som är finjusterade för att tillgodose unika slutanvändarupplevelser i AI-applikationer. Du kan också använda den här funktionen för att uppnå nödvändig prisprestanda för din slutledningsapplikation med hjälp av fraktionerade GPU:er. För att lära dig mer, se Kör flera djupinlärningsmodeller på GPU med Amazon SageMaker multi-model endpoints.
Följande tabell ger vägledning för att utvärdera fitnessfunktionerna för ML-modellvärd som använder MME med GPU-stöd på Triton-inferensbehållare. För utvärderingar av endpoints med en modell och serverlösa endpoint fitnessfunktioner, se de tidigare avsnitten i det här inlägget.
Fitness funktion | Beskrivning |
Pris | SageMaker MME med GPU-stöd som använder Triton Inference Server ger ett skalbart och kostnadseffektivt sätt att distribuera ett stort antal djupinlärningsmodeller bakom en enda SageMaker-slutpunkt. Med MME:er delar flera modeller GPU-instansen bakom en slutpunkt. Detta gör det möjligt för dig att bryta den linjärt ökande kostnaden för att vara värd för flera modeller och återanvända infrastruktur för alla modeller. Du betalar för instansens upptid. |
Slutledningslatens |
SageMaker med Triton Inference Server är specialbyggd för att maximera genomströmning och hårdvaruanvändning med ultralåg (ensiffriga millisekunder) slutledningslatens. Den har ett brett utbud av ML-ramverk som stöds (inklusive TensorFlow, PyTorch, ONNX, XGBoost och NVIDIA TensorRT) och infrastrukturbackends, inklusive NVIDIA GPU:er, CPU:er och AWS slutledning. Med MME-stöd för GPU som använder SageMaker Triton Inference Server kan du distribuera tusentals djupinlärningsmodeller bakom en SageMaker-slutpunkt. SageMaker laddar modellen till NVIDIA Triton-behållarens minne på en GPU-accelererad instans och betjänar slutledningsbegäran. GPU-kärnan delas av alla modeller i en instans. Om modellen redan är laddad i containerminnet, serveras de efterföljande förfrågningarna snabbare eftersom SageMaker inte behöver ladda ner och ladda den igen. |
genomströmning |
MME erbjuder möjligheter att köra flera djupinlärnings- eller ML-modeller på GPU:n samtidigt med Triton Inference Server. Detta gör att du enkelt kan använda NVIDIA Triton multi-framework, högpresterande slutledningsservering med SageMaker helt hanterade modellimplementering. Triton stöder all NVIDIA GPU-, x86-, Arm® CPU- och AWS Inferentia-baserad slutledning. Den erbjuder dynamisk batchning, samtidiga körningar, optimal modellkonfiguration, modellensemble och strömmande ljud- och videoingångar för att maximera genomströmning och utnyttjande. Andra faktorer som nätverk och nyttolaststorlek kan spela en minimal roll i den omkostnad som är associerad med slutsatsen. |
Skalningskonfigurationskomplexitet |
MME:er kan skala horisontellt med hjälp av en policy för automatisk skalning och tillhandahålla ytterligare GPU-beräkningsinstanser baserat på mätvärden som t.ex. Med Triton inferensserver kan du enkelt bygga en anpassad behållare som inkluderar din modell med Triton och ta den till SageMaker. SageMaker Inference kommer att hantera förfrågningarna och automatiskt skala behållaren när användningen ökar, vilket gör modelldistributionen med Triton på AWS enklare. |
Trafikmönster |
MME:er är idealiska för förutsägbara trafikmönster med modeller som körs som DAG:er på samma slutpunkt. SageMaker tar hand om trafikformningen till MME-slutpunkten och upprätthåller optimala modellkopior på GPU-instanser för bästa prisprestanda. Den fortsätter att dirigera trafik till den instans där modellen laddas. Om instansresurserna når kapacitet på grund av högt utnyttjande, lossar SageMaker de minst använda modellerna från behållaren för att frigöra resurser för att ladda mer frekvent använda modeller. |
Bästa praxis
Tänk på följande bästa praxis:
- Hög sammanhållning och låg koppling mellan modeller – Värd modellerna i samma behållare som har hög sammanhållning (driver funktionalitet för enskilda företag) och kapsla in dem för enkel uppgradering och hanterbarhet. Koppla samtidigt bort dessa modeller från varandra (värd för dem i olika behållare) så att du enkelt kan uppgradera en modell utan att påverka andra modeller. Värd för flera modeller som använder olika behållare bakom en slutpunkt och anropar sedan oberoende eller lägg till modellförbearbetnings- och efterbearbetningslogik som en seriell slutledningspipeline.
- Slutledningslatens – Gruppera modellerna som drivs av en enda företagsfunktion och värd dem i en enda behållare för att minimera antalet hopp och därför minimera den totala latensen. Det finns andra varningar, som om de grupperade modellerna använder flera ramverk; du kan också välja att vara värd i flera behållare men köra på samma värd för att minska latens och minimera kostnaden.
- Gruppera logiskt ML-modeller med hög sammanhållning – Den logiska gruppen kan bestå av modeller som är homogena (till exempel alla XGBoost-modeller) eller heterogena (till exempel några XGBoost och några BERT). Den kan bestå av modeller som delas mellan flera affärsfunktioner eller kan vara specifik för att uppfylla endast en affärsfunktionalitet.
- Delade modeller – Om den logiska gruppen består av delade modeller, kommer enkelheten att uppgradera modellerna och latensen att spela en stor roll i utformningen av SageMaker-slutpunkterna. Till exempel, om latens är en prioritet, är det bättre att placera alla modeller i en enda behållare bakom en enda SageMaker-slutpunkt för att undvika flera hopp. Nackdelen är att om någon av modellerna behöver uppgraderas kommer det att resultera i att alla relevanta SageMaker-slutpunkter som är värd för denna modell uppgraderas.
- Ej delade modeller – Om den logiska gruppen endast består av affärsfunktionsspecifika modeller och inte delas med andra grupper, kommer paketeringskomplexiteten och latensdimensionerna att bli nyckeln att uppnå. Det är tillrådligt att vara värd för dessa modeller i en enda behållare bakom en enda SageMaker-slutpunkt.
- Effektiv användning av hårdvara (CPU, GPU) – Gruppera CPU-baserade modeller tillsammans och värd dem på samma värd så att du effektivt kan använda CPU:n. Gruppera på samma sätt GPU-baserade modeller så att du effektivt kan använda och skala dem. Det finns hybridarbetsbelastningar som kräver både CPU och GPU på samma värd. Att vara värd för endast CPU- och GPU-modeller på samma värd bör drivas av höga krav på sammanhållning och applikationslatens. Dessutom är kostnad, förmåga att skala och sprängradie vid kollision i händelse av fel de viktigaste dimensionerna att titta närmare på.
- Fitnessfunktioner – Använd fitnessfunktioner som en riktlinje för att välja ett ML-värdalternativ.
Slutsats
När det gäller ML-hosting finns det inget som passar alla. ML-utövare måste välja rätt designmönster för att hantera sina ML-värdutmaningar. Att utvärdera fitnessfunktionerna ger föreskrivande vägledning för att välja rätt ML-värdalternativ.
För mer information om vart och ett av värdalternativen, se följande inlägg i den här serien:
Om författarna
Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning inklusive NLP- och Computer Vision-domäner. Han hjälper kunder att uppnå högpresterande modellslutningar på SageMaker.
Deepali Rajale är AI/ML Specialist Technical Account Manager på Amazon Web Services. Hon arbetar med företagskunder och tillhandahåller teknisk vägledning om implementering av maskininlärningslösningar med bästa praxis. På fritiden tycker hon om att vandra, filma och umgås med familj och vänner.
Saurabh Trikande är senior produktchef för Amazon SageMaker Inference. Han brinner för att arbeta med kunder och motiveras av målet att demokratisera maskininlärning. Han fokuserar på kärnutmaningar relaterade till att distribuera komplexa ML-applikationer, multi-tenant ML-modeller, kostnadsoptimeringar och att göra implementeringen av djupinlärningsmodeller mer tillgänglig. På sin fritid gillar Saurabh att vandra, lära sig om innovativ teknik, följa TechCrunch och umgås med sin familj.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- förmåga
- Able
- Om oss
- accelererad
- tillgång
- Accessed
- tillgänglig
- rymma
- Konto
- exakt
- Uppnå
- uppnå
- tvärs
- Handling
- aktivt
- Dessutom
- Annat
- Dessutom
- adress
- avancera
- avancerat
- Fördel
- reklam
- påverka
- Efter
- aggregation
- Aggregator
- aggressiv
- avtal
- AI
- AI / ML
- larm
- algoritmer
- Alla
- tillåta
- tillåter
- redan
- alltid
- amason
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- mängd
- analys
- analysera
- och
- och infrastruktur
- årsringar
- Annan
- Apache
- api
- Apple
- Ansökan
- tillämpningar
- tillvägagångssätt
- lämpligt
- appar
- arkitektur
- ARM
- konstgjord
- artificiell intelligens
- aspekter
- bedömning
- associerad
- attribut
- audio
- revisioner
- bil
- Automatiserad
- Automat
- automatiskt
- tillgänglighet
- tillgänglig
- genomsnitt
- AWS
- tillbaka
- dragen tillbaka
- Banking
- bas
- baserat
- därför att
- blir
- blir
- innan
- bakom
- Där vi får lov att vara utan att konstant prestera,
- fördel
- BÄST
- bästa praxis
- Bättre
- mellan
- biomedicinsk
- Blockera
- upplåning
- gränser
- Box
- brott
- Ha sönder
- föra
- Bringar
- budgetar
- SLUTRESULTAT
- Byggnad
- byggt
- inbyggd
- företag
- Business Applications
- Affärsprocess
- företag
- Cache
- beräknat
- Ring
- kallas
- Uppringare
- kandidater
- kapacitet
- Kapacitet
- vilken
- Vid
- fall
- kategorier
- Orsakerna
- vissa
- Certifierad
- utmaningar
- byta
- Förändringar
- egenskaper
- laddad
- chatbot
- ta
- chip
- val
- val
- Välja
- välja
- klass
- klassificering
- klassificera
- klient
- klienter
- Stänga
- cloud
- kluster
- koda
- myntade
- kollegor
- samla
- bekämpa
- kombination
- kombinera
- kombinerad
- Gemensam
- Företag
- företag
- jämfört
- fullborda
- fullständigt
- komplex
- Komplexiteten
- Efterlevnad
- komponenter
- sammansatt
- kompromiss
- beräkningskraft
- Compute
- dator
- Datorsyn
- databehandling
- begrepp
- Oro
- konkurrent
- konfiguration
- anslutning
- konsekvent
- konsumeras
- konsumenter
- Behållare
- Behållare
- innehåller
- fortsätta
- fortsätter
- kontinuerlig
- kontroll
- Kärna
- Motsvarande
- Pris
- kostnadsbesparingar
- kostnadseffektiv
- Kostar
- kunde
- skapa
- skapar
- kritisk
- avgörande
- Aktuella
- beställnings
- kund
- Kunder
- DAG
- datum
- databehandling
- datavetenskap
- datavetare
- Databas
- datauppsättningar
- dag
- som handlar om
- beslut
- dedicerad
- djup
- djupt lärande
- Standard
- definierande
- leverera
- Efterfrågan
- krav
- demokrati
- beroende
- beror
- distribuera
- utplacerade
- utplacera
- utplacering
- distributioner
- Designa
- Design mönster
- utformade
- detalj
- detaljer
- Detektering
- Bestämma
- Utvecklare
- Utveckling
- diagrammen
- olika
- svårt
- dimensioner
- rikta
- distinkt
- distribueras
- distribuerad databehandling
- flera
- Hamnarbetare
- dokument
- inte
- domäner
- inte
- ner
- ladda ner
- nackdelen
- driven
- tappade
- Drop
- under
- dynamisk
- varje
- Tidigare
- lättare
- lätt
- Effektiv
- effektivt
- effektivitet
- effektiviteter
- effektiv
- effektivt
- ansträngning
- antingen
- eliminera
- möjliggöra
- möjliggör
- kryptering
- början till slut
- Slutpunkt
- Teknik
- Ingenjörer
- tillräckligt
- säkerställa
- säkerställer
- Företag
- företag
- Hela
- Miljö
- fel
- fel
- speciellt
- utvärderade
- utvärderingar
- Även
- händelse
- allt
- Utvecklingen
- exempel
- exempel
- utbyta
- utställningar
- förvänta
- förväntat
- erfarenhet
- Erfarenheter
- utforska
- uttryck
- extern
- extra
- Ansikte
- faktorer
- Misslyckande
- ganska
- familjer
- familj
- snabbare
- Leverans
- Funktioner
- matning
- få
- slutlig
- Förnamn
- första gången
- fitness
- FLOTTA
- Flexibilitet
- flöda
- fluktuera
- fokuserar
- efter
- följer
- ford
- formen
- former
- fraktionerad
- Ramverk
- ramar
- bedrägeri
- spårning av bedrägerier
- Fri
- Frekvens
- ofta
- vänner
- från
- Frukt
- full
- fullständigt
- fungera
- funktionaliteter
- funktionalitet
- funktioner
- ytterligare
- GDPR
- Allmänt
- genereras
- generera
- skaffa sig
- Ge
- ges
- Målet
- Mål
- god
- GPU
- GPUs
- diagram
- stor
- större
- kraftigt
- Grupp
- Gruppens
- Väx
- styra
- hantera
- Handtag
- praktisk
- hårdvara
- har
- Hälsa
- hälso-och sjukvård
- hjälpa
- hjälpa
- hjälper
- här.
- Hög
- högpresterande
- hög upplösning
- högre
- Träffa
- Horisontell
- värd
- värd
- värd
- värdkostnader
- värdtjänster
- Hur ser din drömresa ut
- Men
- html
- HTTPS
- Hundratals
- Hybrid
- idealisk
- Identitet
- Idle
- bild
- Bildklassificering
- bilder
- oföränderlig
- Inverkan
- påverkade
- Konsekvenser
- genomföra
- genomföras
- genomföra
- med Esport
- förbättra
- förbättra
- in
- innefattar
- innefattar
- Inklusive
- Inkommande
- Öka
- ökat
- Ökar
- ökande
- oberoende
- oberoende av
- individuellt
- informationen
- Infrastruktur
- inledande
- innovativa
- innovativa tekniker
- ingång
- installera
- exempel
- istället
- integrera
- integrering
- Intelligens
- interaktiva
- engagera
- ISO
- isolering
- IT
- Jobb
- Lediga jobb
- Nyckel
- nycklar
- Vet
- känd
- Large
- större
- Latens
- lansera
- lanserar
- lansera
- leda
- ledande
- Leads
- LÄRA SIG
- inlärning
- Lämna
- Led
- Nivå
- bibliotek
- lyft
- Begränsad
- gränser
- Lista
- lever
- läsa in
- läser in
- laster
- läge
- Lång
- längre
- se
- förlora
- Lot
- Låg
- Maskinen
- maskininlärning
- gjord
- Huvudsida
- bibehålla
- upprätthåller
- större
- göra
- GÖR
- Framställning
- hantera
- förvaltade
- ledning
- chef
- förvaltar
- hantera
- många
- Marknadsföring
- matematisk
- Materia
- Maximera
- maximal
- betyder
- Möt
- Minne
- metod
- metoder
- metriska
- Metrics
- kanske
- minimum
- minsta
- minuter
- Blandning
- ML
- Mode
- modell
- modeller
- Övervaka
- övervakning
- Månad
- månader
- mer
- mest
- motiverad
- Filmer
- Multi-Model Endpoint
- multipel
- mängd
- Natur
- nödvändigt för
- Behöver
- behov
- nät
- Nya
- Nästa
- nlp
- anmälan
- anmälningar
- antal
- Nvidia
- objektet
- mål
- mål
- erhållande
- tillfällig
- erbjudanden
- Erbjudanden
- offline
- ONE
- nätet
- öppen källkod
- driva
- fungerar
- drift
- operativa
- Verksamhet
- operatörer
- optimala
- optimering
- Optimera
- optimerad
- optimerar
- optimera
- Alternativet
- Tillbehör
- Orange
- beställa
- organisationer
- Övriga
- utestående
- övergripande
- egen
- ägande
- paket
- förpackning
- parametrar
- del
- särskilt
- partnern
- Godkänd
- brinner
- Plåster
- Mönster
- mönster
- Betala
- Topp
- Utföra
- prestanda
- utför
- perioden
- periodisk
- perioder
- personalisering
- personlig
- plocka
- rörledning
- Plats
- platser
- planeras
- planer
- plattform
- Plattformar
- plato
- Platon Data Intelligence
- PlatonData
- Spela
- plus
- Strategier
- policy
- Populära
- möjlig
- Inlägg
- inlägg
- kraft
- praktiken
- praxis
- Förutsägbar
- förutsäga
- förutsägelse
- Förutsägelser
- föredragen
- tidigare
- pris
- Principal
- prioritet
- privat
- Problem
- problem
- process
- Bearbetad
- processer
- bearbetning
- processorer
- Produkt
- produktchef
- Produktion
- Produkter
- Profil
- rätt
- ge
- förutsatt
- ger
- tillhandahålla
- tillhandahållande
- ombud
- Syftet
- Tryck
- pytorch
- snabbt
- område
- som sträcker sig
- snabbt
- Betygsätta
- rates
- nå
- når
- Läsa
- redo
- verklig
- verkliga världen
- realtid
- motta
- mottagna
- erhåller
- rekommenderar
- Rekommendation
- rekommendationer
- rekommenderas
- rekommendera
- rekommenderar
- återkommande
- minska
- minskar
- hänvisar
- Oavsett
- regelbunden
- relaterad
- meddelanden
- relevanta
- resterna
- Repository
- representerade
- representerar
- begära
- förfrågningar
- kräver
- Obligatorisk
- krav
- Krav
- Kräver
- resurs
- Resurser
- respons
- REST
- resultera
- resulterande
- Resultat
- detaljhandeln
- återgår
- översyn
- Risk
- Roll
- rot
- Rutt
- Regel
- Körning
- rinnande
- SaaS
- sagemaker
- SageMaker Inference
- lönen
- Samma
- Save
- sparande
- Besparingar
- skalbar
- Skala
- skalor
- skalning
- scenarier
- tidtabellen
- planerad
- Vetenskap
- Forskare
- Andra
- sekunder
- §
- sektioner
- säkert
- säkerhet
- väljer
- Val
- senior
- känslig
- Sekvens
- seriell
- Serier
- tjänar
- Server
- Servrar
- serverar
- service
- Tjänster
- portion
- in
- inställning
- flera
- formning
- Dela
- delas
- Skift
- skall
- Visar
- signifikant
- signifikant
- liknande
- Liknande
- Enkelt
- enda
- Storlek
- storlekar
- Small
- mindre
- So
- Mjukvara
- lösning
- Lösningar
- några
- Källor
- Utrymme
- specialist
- specialiserad
- specifik
- specifikt
- specificerade
- fart
- Spendera
- spikar
- stabil
- stapel
- Stacks
- starta
- igång
- startar
- start
- Startups
- stadig
- Steg
- Steg
- Fortfarande
- Stoppar
- förvaring
- lagra
- strategier
- streaming
- Strikt
- starkt
- senare
- framgång
- framgångsrik
- sådana
- tillräcklig
- lämplig
- stödja
- Som stöds
- Stöder
- uppstår
- bord
- Ta
- tar
- Målet
- riktade
- uppgift
- uppgifter
- grupp
- lag
- TechCrunch
- Teknisk
- Tekniken
- hyresgäst
- tensorflow
- testa
- Testning
- Smakämnen
- deras
- sig själva
- vari
- därför
- tusentals
- tre
- tröskelvärde
- Genom
- hela
- genomströmning
- tid
- gånger
- till
- tillsammans
- alltför
- verktyg
- Totalt
- tps
- Spårning
- trafik
- Tåg
- tränad
- Utbildning
- transaktion
- Transaktioner
- Förvandla
- Transformation
- omvandla
- transitering
- transparent
- utlösa
- Triton
- SVÄNG
- typer
- typisk
- typiskt
- under
- underliggande
- förstå
- unika
- enheter
- oförutsägbar
- oanvänd
- Uppdatering
- Uppdateringar
- uppgradera
- uppgraderad
- upptid
- Användning
- användning
- användningsfall
- Användare
- användare
- vanligen
- utnyttja
- utnyttjas
- BEKRÄFTA
- värde
- Värden
- Variant
- olika
- via
- Video
- Video
- utsikt
- Virtuell
- syn
- volym
- Rösta
- avgivna
- Avfall
- webb
- webbservice
- vecka
- Vad
- Vad är
- som
- medan
- bred
- Brett utbud
- kommer
- inom
- utan
- Arbete
- arbetade
- arbetstagaren
- arbetare
- arbetssätt
- fungerar
- världen
- skulle
- XGBoost
- år
- Om er
- Din
- zephyrnet
- noll-