Maskinlæringsapplikationer (ML) er komplekse at implementere og kræver ofte evnen til at hyperskalere og har ultralave latenskrav og stringente omkostningsbudgetter. Brugssager som f.eks. registrering af svindel, produktanbefalinger og trafikforudsigelse er eksempler, hvor millisekunder er vigtige og er afgørende for virksomhedens succes. Strenge serviceniveauaftaler (SLA'er) skal overholdes, og en typisk anmodning kan kræve flere trin, såsom forbehandling, datatransformation, funktionsudvikling, modelvalgslogik, modelaggregering og efterbehandling.
Det kan være en skræmmende og besværlig opgave at implementere ML-modeller i stor skala med optimeret omkostnings- og computereffektivitet. Hver model har sine egne fordele og afhængigheder baseret på de eksterne datakilder samt runtime-miljø såsom CPU/GPU-kraften i de underliggende computerressourcer. En applikation kan kræve flere ML-modeller for at betjene en enkelt slutningsanmodning. I visse scenarier kan en anmodning flyde på tværs af flere modeller. Der er ingen ensartet tilgang, og det er vigtigt for ML-udøvere at lede efter afprøvede metoder til at løse tilbagevendende ML-hosting-udfordringer. Dette har ført til udviklingen af designmønstre til ML-modelhosting.
I dette indlæg udforsker vi almindelige designmønstre til at bygge ML-applikationer på Amazon SageMaker.
Designmønstre til opbygning af ML-applikationer
Lad os se på følgende designmønstre, der skal bruges til hosting af ML-applikationer.
Enkeltmodelbaserede ML-applikationer
Dette er en fantastisk mulighed, når din ML use case kræver en enkelt model for at betjene en anmodning. Modellen er implementeret på en dedikeret computerinfrastruktur med mulighed for at skalere baseret på inputtrafikken. Denne mulighed er også ideel, når klientapplikationen har et inferenskrav med lav latens (i størrelsesordenen millisekunder eller sekunder).
Multi-model baserede ML applikationer
For at gøre hosting mere omkostningseffektiv giver dette designmønster dig mulighed for at hoste flere modeller på den samme lejerinfrastruktur. Flere ML-modeller kan dele værts- eller containerressourcerne, herunder cachelagring af de mest brugte ML-modeller i hukommelsen, hvilket resulterer i bedre udnyttelse af hukommelse og computerressourcer. Afhængigt af typerne af de modeller, du har valgt at implementere, kan modelco-hosting bruge følgende metoder:
- Multi-model hosting – Denne mulighed giver dig mulighed for at være vært for flere modeller ved hjælp af en delt serveringsbeholder på et enkelt slutpunkt. Denne funktion er ideel, når du har et stort antal lignende modeller, som du kan betjene gennem en delt serveringsbeholder og ikke behøver at få adgang til alle modellerne på samme tid.
- Multi-container hosting – Denne mulighed er ideel, når du har flere modeller, der kører på forskellige serveringsstakke med lignende ressourcebehov, og når individuelle modeller ikke har tilstrækkelig trafik til at udnytte den fulde kapacitet af slutpunktforekomsterne. Multi-container-hosting giver dig mulighed for at implementere flere containere, der bruger forskellige modeller eller rammer på et enkelt slutpunkt. Modellerne kan være fuldstændig heterogene med deres egen uafhængige serveringsstak.
- Model ensembler – I mange produktionstilfælde kan der ofte være mange upstream-modeller, der leverer input til en given downstream-model. Det er her ensembler er nyttige. Ensemblemønstre involverer blanding af output fra en eller flere basismodeller for at reducere generaliseringsfejl af forudsigelsen. Basismodellerne kan være forskellige og trænes af forskellige algoritmer. Modelensembler kan udkonkurrere enkelte modeller, fordi modellens forudsigelsesfejl falder, når ensembletilgangen bruges.
Følgende er almindelige eksempler på ensemblemønstre og deres tilsvarende designmønsterdiagrammer:
- Scatter-samle – I et scatter-samler-mønster sendes en anmodning om slutning til en række modeller. En aggregator bruges derefter til at indsamle svarene og destillere dem til et enkelt slutningssvar. For eksempel kan en brugscase til billedklassificering bruge tre forskellige modeller til at udføre opgaven. Scatter-samler mønsteret giver dig mulighed for at kombinere resultater fra slutninger, der køres på tre forskellige modeller og vælge den mest sandsynlige klassifikationsmodel.
- Modelaggregat – I et aggregeringsmønster beregnes et gennemsnit af output fra flere modeller. For klassifikationsmodeller evalueres flere modellers forudsigelser for at bestemme den klasse, der fik flest stemmer og behandles som det endelige output af ensemblet. For eksempel, hvis to modeller stemmer for en appelsin, og en model stemmer for et æble, vil det aggregerede output være en appelsin i et to-klasses klassificeringsproblem for at klassificere et sæt frugter som appelsiner eller æbler. Aggregation hjælper med at bekæmpe unøjagtighed i individuelle modeller og gør output mere nøjagtigt.
- Dynamisk valg – Et andet mønster for ensemblemodeller er dynamisk at udføre modelvalg for de givne input-attributter. For eksempel, i en given input af billeder af frugter, hvis inputtet indeholder en appelsin, vil model A blive brugt, fordi den er specialiseret til appelsiner. Hvis inputtet indeholder et æble, vil model B blive brugt, fordi det er specialiseret til æbler.
- Seriel inferens ML-applikationer – Med et serielt inferensmønster, også kendt som en inferenspipeline, har use cases krav til at forbehandle indgående data, før en forudtrænet ML-model til generering af inferenser påberåbes. Derudover kan det i nogle tilfælde være nødvendigt at behandle de genererede slutninger yderligere, så de let kan forbruges af downstream-applikationer. En inferenspipeline giver dig mulighed for at genbruge den samme forbehandlingskode, der blev brugt under modeltræning, til at behandle de inferensanmodningsdata, der bruges til forudsigelser.
- Forretningslogik – At producere ML involverer altid forretningslogik. Forretningslogiske mønstre involverer alt, hvad der er nødvendigt for at udføre en ML-opgave, der ikke er ML-modelslutning. Dette inkluderer indlæsning af modellen fra Amazon Simple Storage Service (Amazon S3), for eksempel databaseopslag for at validere inputtet, opnå forudberegnet funktioner fra feature-lageret og så videre. Når disse forretningslogiske trin er afsluttet, overføres inputs til ML-modeller.
ML slutningsmuligheder
For modelimplementering er det vigtigt at arbejde baglæns fra din use case. Hvad er frekvensen af forudsigelsen? Forventer du live trafik til din applikation og realtidssvar til dine kunder? Har du mange modeller trænet til forskellige delmængder af data til samme use case? Svinger forudsigelsestrafikken? Er latens af inferens en bekymring? Baseret på disse detaljer kan alle de foregående designmønstre implementeres ved hjælp af følgende implementeringsmuligheder:
- Realtidsslutning – Realtidsinferens er ideel til inferensarbejdsbelastninger, hvor du har realtidsinteraktive krav med lav latens. Real-time ML-inferens-arbejdsbelastninger kan omfatte en enkeltmodelbaseret ML-applikation, hvor en applikation kun kræver én ML-model for at betjene en enkelt anmodning, eller en multimodelbaseret ML-applikation, hvor en applikation kræver flere ML-modeller for at betjene en enkelt anmodning.
- Nær-realtids (asynkron) inferens – Med næsten-realtidsslutning kan du sætte indgående anmodninger i kø. Dette kan bruges til at køre inferens på input, der er hundredvis af MB. Den fungerer i næsten realtid og giver brugerne mulighed for at bruge input til slutninger og læse output fra endepunktet fra en S3 bucket. Det kan især være praktisk i sager med NLP og computervision, hvor der er store nyttelaster, der kræver længere forbehandlingstider.
- Batch-inferens - Batch-inferens kan bruges til at køre inferens offline på et stort datasæt. Fordi det kører offline, tilbyder batch-inferens ikke den laveste latenstid. Her behandles slutningsanmodningen med enten en planlagt eller hændelsesbaseret trigger af et batchinferensjob.
- Serverløs slutning – Serverløs inferens er ideel til arbejdsbelastninger, der har inaktive perioder mellem trafik-spurt og kan tolerere et par ekstra sekunders latency (koldstart) for den første påkaldelse efter en inaktiv periode. For eksempel en chatbot-tjeneste eller en applikation til at behandle formularer eller analysere data fra dokumenter. I dette tilfælde vil du måske have en online-slutningsmulighed, der er i stand til automatisk at klargøre og skalere beregningskapacitet baseret på mængden af slutningsanmodninger. Og i inaktiv tid bør den kunne slå computerkapaciteten helt fra, så du ikke bliver opladet. Serverløs inferens fjerner det udifferentierede tunge løft ved at vælge og administrere servere ved automatisk at starte computerressourcer og skalere dem ind og ud afhængigt af trafikken.
Brug fitnessfunktioner til at vælge den rigtige ML-inferensindstilling
Det er vigtigt at beslutte sig for den rigtige hostingmulighed, fordi det påvirker slutbrugerne, der gengives af dine applikationer. Til dette formål låner vi begrebet fitness funktioner, som blev opfundet af Neal Ford og hans kolleger fra AWS Partner ThoughtWorks i deres arbejde Bygning af evolutionære arkitekturer. Fitness-funktioner giver en præskriptiv vurdering af forskellige hostingmuligheder baseret på kundens mål. Fitness-funktioner hjælper dig med at få de nødvendige data til at tillade den planlagte udvikling af din arkitektur. De sætter målbare værdier for at vurdere, hvor tæt din løsning er på at nå dine fastsatte mål. Fitnessfunktioner kan og bør tilpasses efterhånden som arkitekturen udvikler sig for at guide en ønsket forandringsproces. Dette giver arkitekter et værktøj til at guide deres teams og samtidig bevare teamets autonomi.
Der er fem primære fitnessfunktioner, som kunder interesserer sig for, når det kommer til at vælge den rigtige ML-inferens-mulighed til hosting af deres ML-modeller og -applikationer.
Fitness funktion | Beskrivelse |
Koste |
At implementere og vedligeholde en ML-model og en ML-applikation på en skalerbar ramme er en kritisk forretningsproces, og omkostningerne kan variere meget afhængigt af de valg, der er truffet om modelhostinginfrastruktur, hostingmulighed, ML-frameworks, ML-modelkarakteristika, optimeringer, skaleringspolitik, og mere. Arbejdsbelastningerne skal udnytte hardwareinfrastrukturen optimalt for at sikre, at omkostningerne forbliver i skak. Denne fitnessfunktion refererer specifikt til infrastrukturomkostningerne, som er en del af de samlede samlede ejeromkostninger (TCO). Infrastrukturomkostningerne er de kombinerede omkostninger til lagring, netværk og beregning. Det er også vigtigt at forstå andre komponenter i TCO, herunder driftsomkostninger og omkostninger til sikkerhed og overholdelse. Driftsomkostninger er de kombinerede omkostninger til drift, overvågning og vedligeholdelse af ML-infrastrukturen. Driftsomkostningerne beregnes som antallet af nødvendige ingeniører baseret på hvert scenarie og den årlige løn for ingeniører, aggregeret over en bestemt periode. Kunder, der bruger selvadministrerede ML-løsninger på Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), og Amazon Elastic Kubernetes Service (Amazon EKS) skal selv bygge operationelt værktøj. Kunder, der bruger SageMaker, pådrager sig betydeligt mindre TCO. SageMaker inference er en fuldt administreret tjeneste og giver muligheder ud af boksen til at implementere ML-modeller til inferens. Du behøver ikke at klargøre forekomster, overvåge forekomstens tilstand, administrere sikkerhedsopdateringer eller patches, udsende operationelle metrics eller bygge overvågning for dine ML-inferensarbejdsbelastninger. Den har indbyggede muligheder for at sikre høj tilgængelighed og robusthed. SageMaker understøtter sikkerhed med ende-til-ende-kryptering i hvile og under transport, herunder kryptering af rodvolumen og Amazon Elastic Block Store (Amazon EBS) volumen, Amazon Virtual Private Cloud (Amazon VPC) support, AWS PrivateLink, kundeadministrerede nøgler, AWS identitets- og adgangsstyring (IAM) finkornet adgangskontrol, AWS CloudTrail audits, internodekryptering til træning, tag-baseret adgangskontrol, netværksisolering og interaktiv applikationsproxy. Alle disse sikkerhedsfunktioner leveres ud af kassen i SageMaker og kan spare virksomheder for snesevis af udviklingsmåneders ingeniørindsats over en 3-årig periode. SageMaker er en HIPAA-kvalificeret service og er certificeret under PCI, SOC, GDPR og ISO. SageMaker understøtter også FIPS-endepunkter. For mere information om TCO, se De samlede omkostninger ved ejerskab af Amazon SageMaker. |
Slutningsforsinkelse | Mange ML-modeller og -applikationer er latenstidskritiske, hvor slutningsforsinkelsen skal være inden for grænserne angivet af et serviceniveaumål. Inferensforsinkelse afhænger af en lang række faktorer, herunder modelstørrelse og kompleksitet, hardwareplatform, softwaremiljø og netværksarkitektur. For eksempel kan større og mere komplekse modeller tage længere tid at køre inferens. |
Gennemløb (transaktioner pr. sekund) | Til modelslutning er optimering af gennemløbet afgørende for justering af ydeevne og opnåelse af forretningsmålet for ML-applikationen. Efterhånden som vi fortsætter med at udvikle os hurtigt i alle aspekter af ML, inklusive implementeringer på lavt niveau af matematiske operationer i chipdesign, spiller hardwarespecifikke biblioteker en større rolle i ydeevneoptimering. Forskellige faktorer såsom nyttelaststørrelse, netværkshop, arten af hop, modelgraffunktioner, operatører i modellen og CPU-, GPU- og hukommelsesprofilen for modelhostingforekomsterne påvirker gennemløbet af ML-modellen. |
Skalering af konfigurationskompleksitet | Det er afgørende for ML-modellerne eller applikationerne at køre på en skalerbar ramme, der kan håndtere efterspørgslen fra varierende trafik. Det giver også mulighed for maksimal udnyttelse af CPU- og GPU-ressourcer og forhindrer overforsyning af computerressourcer. |
Forventet trafikmønster | ML-modeller eller applikationer kan have forskellige trafikmønstre, lige fra kontinuerlig realtidstrafik til periodiske peaks på tusindvis af anmodninger i sekundet og fra sjældne, uforudsigelige anmodningsmønstre til offline batch-anmodninger på større datasæt. Det anbefales at arbejde baglæns fra det forventede trafikmønster for at vælge den rigtige hostingmulighed til din ML-model. |
Implementering af modeller med SageMaker
SageMaker er en fuldt administreret AWS-tjeneste, der giver enhver udvikler og dataforsker mulighed for hurtigt at bygge, træne og implementere ML-modeller i stor skala. Med SageMaker inference kan du implementere dine ML-modeller på hostede endepunkter og få slutningsresultater. SageMaker tilbyder et bredt udvalg af hardware og funktioner til at opfylde dine krav til arbejdsbelastning, så du kan vælge over 70 instanstyper med hardwareacceleration. SageMaker kan også give en anbefaling af inferensforekomster ved hjælp af en ny funktion kaldet SageMaker Inference Recommender, hvis du ikke er sikker på, hvilken der ville være mest optimal for din arbejdsbyrde.
Du kan vælge implementeringsmuligheder for bedst muligt at imødekomme dine use cases, såsom realtidsinferens, asynkrone, batch- og endda serverløse slutpunkter. Derudover tilbyder SageMaker forskellige implementeringsstrategier såsom kanariefugle, blågrøn, skygge, og A/B-test til modelimplementering sammen med omkostningseffektiv implementering med multi-model, multi-container-endepunkter og elastisk skalering. Med SageMaker inference kan du se præstationsmålingerne for dine endepunkter i amazoncloudwatch, skalerer endepunkter automatisk baseret på trafik, og opdatere dine modeller i produktion uden at miste nogen tilgængelighed.
SageMaker tilbyder fire muligheder for at implementere din model, så du kan begynde at lave forudsigelser:
- Realtidsslutning – Dette er velegnet til arbejdsbelastninger med millisekunders latencykrav, nyttelaststørrelser på op til 6 MB og behandlingstider på op til 60 sekunder.
- Batch transformation – Dette er ideelt til offline forudsigelser på store partier af data, der er tilgængelige på forhånd.
- Asynkron inferens – Dette er designet til arbejdsbelastninger, der ikke har forsinkelseskrav på under sekunder, nyttelaststørrelser på op til 1 GB og behandlingstider på op til 15 minutter.
- Serverløs slutning – Med serverløs inferens kan du hurtigt implementere ML-modeller til inferens uden at skulle konfigurere eller administrere den underliggende infrastruktur. Derudover betaler du kun for den beregningskapacitet, der bruges til at behandle slutningsanmodninger, hvilket er ideelt til intermitterende arbejdsbelastninger.
Følgende diagram kan hjælpe dig med at forstå SageMaker-hostingmodellens implementeringsmuligheder sammen med de tilknyttede fitnessfunktionsevalueringer.
Lad os undersøge hver af implementeringsmulighederne mere detaljeret.
Realtidsslutning i SageMaker
SageMaker-realtidsslutning anbefales, hvis du har vedvarende trafik og har brug for lavere og ensartet latenstid for dine anmodninger med nyttelaststørrelser på op til 6 MB og behandlingstider på op til 60 sekunder. Du implementerer din model til SageMaker-hostingtjenester og får et slutpunkt, der kan bruges til slutninger. Disse endepunkter er fuldt administrerede og understøtter automatisk skalering. Realtidsslutning er populær til brugssager, hvor du forventer et synkront svar med lav latens med forudsigelige trafikmønstre, såsom personlige anbefalinger til produkter og tjenester eller tilfælde af registrering af transaktionssvig.
Typisk sender en klientapplikation anmodninger til SageMaker HTTPS-slutpunktet for at opnå slutninger fra en implementeret model. Du kan implementere flere varianter af en model til det samme SageMaker HTTPS-slutpunkt. Dette er nyttigt til at teste variationer af en model i produktionen. Automatisk skalering giver dig mulighed for dynamisk at justere antallet af forekomster, der er klargjort for en model som svar på ændringer i din arbejdsbyrde.
Følgende tabel giver vejledning i evaluering af SageMaker-realtidsslutning baseret på fitnessfunktionerne.
Fitness funktion | Beskrivelse |
Koste |
Realtidsendepunkter tilbyder synkron respons på inferensanmodninger. Fordi endepunktet altid kører og er tilgængeligt til at give synkront inferenssvar i realtid, betaler du for at bruge instansen. Omkostningerne kan hurtigt stige, når du implementerer flere slutpunkter, især hvis slutpunkterne ikke fuldt ud udnytter de underliggende forekomster. At vælge den rigtige instans til din model er med til at sikre, at du har den mest effektive instans til den laveste pris for dine modeller. Automatisk skalering anbefales for dynamisk at justere kapaciteten afhængigt af trafikken for at opretholde en stabil og forudsigelig ydeevne til den laveste pris. SageMaker udvider adgangen til Graviton2- og Graviton3-baserede ML-instansfamilier. AWS Graviton processorer er specialbygget af Amazon Web Services ved hjælp af 64-bit Arm Neoverse-kerner for at levere den bedste prisydeevne for dine cloud-arbejdsbelastninger, der kører på Amazon EC2. Med Graviton-baserede instanser har du flere muligheder for at optimere omkostningerne og ydeevnen, når du implementerer dine ML-modeller på SageMaker. SageMaker understøtter også Inf1 forekomster, der giver høj ydeevne og omkostningseffektiv ML-slutning. Med 1-16 AWS Inferentia-chips pr. instans kan Inf1-instanser skalere i ydeevne og levere op til tre gange højere gennemløb og op til 50 % lavere pris pr. slutning sammenlignet med de AWS GPU-baserede instanser. For at bruge Inf1-instanser i SageMaker kan du kompilere dine trænede modeller ved hjælp af Amazon SageMaker Neo og vælg Inf1-instanserne for at implementere den kompilerede model på SageMaker. Du kan også udforske Spareplaner for SageMaker at drage fordel af omkostningsbesparelser på op til 64 % i forhold til on-demand-prisen. Når du opretter et slutpunkt, knytter SageMaker en EBS-lagervolumen til hver ML-beregningsinstans, der er vært for slutpunktet. Størrelsen på lagervolumen afhænger af instanstypen. Yderligere omkostninger for realtidsslutpunkter inkluderer omkostningerne for GB-måneds klargjort lagerplads plus GB-data behandlet i og GB-data behandlet ud af slutpunktforekomsten. |
Slutningsforsinkelse | Realtidsslutning er ideel, når du har brug for et vedvarende slutpunkt med millisekunders latencykrav. Den understøtter nyttelaststørrelser på op til 6 MB og behandlingstider på op til 60 sekunder. |
gennemløb |
En ideel værdi af inferensgennemløb er subjektiv for faktorer som model, modelinputstørrelse, batchstørrelse og slutpunktforekomsttype. Som en bedste praksis skal du gennemgå CloudWatch-metrics for inputanmodninger og ressourceudnyttelse og vælge den passende instanstype for at opnå optimal gennemstrømning. En virksomhedsapplikation kan enten være gennemløbsoptimeret eller latensoptimeret. For eksempel kan dynamisk batching hjælpe med at øge gennemløbet for latensfølsomme apps ved hjælp af realtidsslutning. Der er dog grænser for batchstørrelsen, uden hvilke inferensforsinkelsen kan blive påvirket. Inferensforsinkelse vil vokse, efterhånden som du øger batchstørrelsen for at forbedre gennemløbet. Derfor er realtidsinferens en ideel mulighed for latensfølsomme applikationer. SageMaker giver muligheder for asynkron inferens og batch-transformation, som er optimeret til at give højere gennemløb sammenlignet med real-time inferens, hvis forretningsapplikationerne kan tolerere en lidt højere latenstid. |
Skalering af konfigurationskompleksitet |
SageMaker-slutpunkter i realtid automatisk skalering ud af boksen. Når arbejdsbyrden øges, bringer automatisk skalering flere forekomster online. Når arbejdsbyrden falder, fjerner automatisk skalering unødvendige forekomster, hvilket hjælper dig med at reducere dine beregningsomkostninger. Uden automatisk skalering skal du sørge for spidsbelastning eller utilgængelighed af risikomodeller. Medmindre trafikken til din model er konstant i løbet af dagen, vil der være overskydende uudnyttet kapacitet. Dette fører til lav udnyttelse og ressourcespild. Med SageMaker kan du konfigurere forskellige skaleringsmuligheder baseret på det forventede trafikmønster. Enkel skalering eller målsporingsskalering er ideel, når du vil skalere baseret på en specifik CloudWatch-metrik. Du kan gøre dette ved at vælge en specifik metrik og indstille tærskelværdier. De anbefalede metrics for denne mulighed er gennemsnitlige Hvis du har brug for avanceret konfiguration, kan du indstille en trinskaleringspolitik for dynamisk at justere antallet af forekomster, der skal skaleres baseret på størrelsen af alarmbruddet. Dette hjælper dig med at konfigurere en mere aggressiv reaktion, når efterspørgslen når et vist niveau. Du kan bruge en planlagt skaleringsindstilling, når du ved, at efterspørgslen følger en bestemt tidsplan på dagen, ugen, måneden eller året. Dette hjælper dig med at angive et engangsskema eller et tilbagevendende skema eller cron-udtryk sammen med start- og sluttidspunkter, som danner grænserne for, hvornår den automatiske skaleringshandling starter og stopper. For flere detaljer henvises til Konfiguration af autoskalering af inferensslutpunkter i Amazon SageMaker , Indlæs test og optimer et Amazon SageMaker-slutpunkt ved hjælp af automatisk skalering. |
Trafikmønster | Realtidsslutning er ideel til arbejdsbelastninger med et kontinuerligt eller regelmæssigt trafikmønster. |
Asynkron inferens i SageMaker
SageMaker asynkron inferens er en ny funktion i SageMaker, der sætter indgående anmodninger i kø og behandler dem asynkront. Denne mulighed er ideel til anmodninger med store nyttelaststørrelser (op til 1 GB), lange behandlingstider (op til 15 minutter) og krav til ventetid næsten i realtid. Eksempler på arbejdsbelastninger for asynkron inferens omfatter sundhedsvirksomheder, der behandler biomedicinske billeder i høj opløsning eller videoer som ekkokardiogrammer for at opdage uregelmæssigheder. Disse applikationer modtager bursts af indgående trafik på forskellige tidspunkter af dagen og kræver næsten-realtidsbehandling til lave omkostninger. Behandlingstider for disse anmodninger kan variere i størrelsesordenen minutter, hvilket eliminerer behovet for at køre realtidsslutning. I stedet kan input-nyttelast behandles asynkront fra et objektlager som Amazon S3 med automatisk kø og en foruddefineret samtidighedstærskel. Efter behandling placerer SageMaker slutningssvaret på den tidligere returnerede Amazon S3-placering. Du kan valgfrit vælge at modtage succes- eller fejlmeddelelser via Amazon Simple Notification Service (Amazon SNS).
Følgende tabel giver vejledning i evaluering af SageMaker asynkron inferens baseret på fitnessfunktionerne.
Fitness funktion | Beskrivelse |
Koste | Asynkron inferens er et godt valg til omkostningsfølsomme arbejdsbelastninger med store nyttelaster og burst-trafik. Asynkron inferens giver dig mulighed for at spare på omkostningerne ved automatisk at skalere instansantallet til nul, når der ikke er nogen anmodninger at behandle, så du betaler kun, når dit slutpunkt behandler anmodninger. Forespørgsler, der modtages, når der er nul forekomster, sættes i kø til behandling, efter endtpunktet skaleres op. |
Slutningsforsinkelse | Asynkron inferens er ideel til forsinkelseskrav i næsten realtid. Anmodningerne placeres i en kø og behandles, så snart beregningen er tilgængelig. Dette resulterer typisk i titusvis af millisekunder i latenstid. |
gennemløb | Asynkron inferens er ideel til ikke-latensfølsomme brugssager, fordi applikationer ikke behøver at gå på kompromis med gennemstrømningen. Anmodninger slettes ikke under trafikstigninger, fordi det asynkrone slutpunkt sætter anmodninger i kø i stedet for at droppe dem. |
Skalering af konfigurationskompleksitet |
SageMaker understøtter automatisk skalering for asynkront endepunkt. I modsætning til hostede endepunkter i realtid understøtter asynkrone inferensslutpunkter nedskalering af forekomster til nul ved at indstille minimumskapaciteten til nul. For asynkrone endepunkter anbefaler SageMaker kraftigt, at du opretter en politikkonfiguration til målsporingsskalering for en implementeret model (variant). For brugssager, der kan tolerere en koldstartsstraf på et par minutter, kan du valgfrit nedskalere endepunktsforekomstoptællingen til nul, når der ikke er nogen udestående anmodninger, og skalere op igen, når der kommer nye anmodninger, så du kun betaler for den varighed, som endepunkter behandler aktivt anmodninger. |
Trafikmønster | Asynkrone slutpunkter sætter indgående anmodninger i kø og behandler dem asynkront. De er en god mulighed for intermitterende eller sjældne trafikmønstre. |
Batch-inferens i SageMaker
SageMaker batch transformation er ideel til offline forudsigelser på store batches af data, der er tilgængelige på forhånd. Batch-transformationsfunktionen er en højtydende og højkapacitetsmetode til at transformere data og generere slutninger. Den er ideel til scenarier, hvor du har at gøre med store batches af data, ikke har brug for sekundær latency eller både skal forbehandle og transformere træningsdataene. Kunder inden for visse domæner som f.eks. annoncering og marketing eller sundhedspleje har ofte behov for at lave offline forudsigelser på datasæt i hyperskala, hvor høj gennemstrømning ofte er formålet med brugssagen, og latenstiden ikke er et problem.
Når et batch-transformationsjob starter, initialiserer SageMaker computerforekomster og fordeler inferensarbejdsbyrden mellem dem. Det frigiver ressourcerne, når opgaverne er færdige, så du betaler kun for det, der blev brugt under løbet af dit job. Når jobbet er færdigt, gemmer SageMaker forudsigelsesresultaterne i en S3-bøtte, som du angiver. Batch-inferensopgaver er normalt gode kandidater til horisontal skalering. Hver medarbejder i en klynge kan arbejde på en anden delmængde af data uden behov for at udveksle information med andre arbejdere. AWS tilbyder flere lagrings- og beregningsmuligheder, der muliggør horisontal skalering. Eksempler på arbejdsbelastninger for SageMaker batch transformation omfatter offline applikationer såsom bankapplikationer til forudsigelse af kundeafgang, hvor et offline job kan planlægges til at køre periodisk.
Følgende tabel giver vejledning i evaluering af SageMaker batchtransformation baseret på fitnessfunktionerne.
Fitness funktion | Beskrivelse |
Koste | SageMaker batchtransformation giver dig mulighed for at køre forudsigelser på store eller små batchdatasæt. Du debiteres for den instanstype, du vælger, baseret på brugens varighed. SageMaker styrer leveringen af ressourcer ved starten af jobbet og frigiver dem, når jobbet er færdigt. Der er ingen ekstra databehandlingsomkostninger. |
Slutningsforsinkelse | Du kan bruge begivenhedsbaseret eller planlagt opkald. Latency kan variere afhængigt af størrelsen af inferensdata, jobsamtidighed, modellens kompleksitet og computerforekomstkapacitet. |
gennemløb |
Batch-transformationsjob kan udføres på en række datasæt, fra petabytes af data til meget små datasæt. Der er ingen grund til at ændre størrelsen på større datasæt til små bidder af data. Du kan fremskynde batchtransformationsjob ved at bruge optimale værdier for parametre som f.eks MaxPayloadInMB, MaxConcurrentTransforms eller Batchstrategi. Den ideelle værdi for Batchbehandling kan øge gennemløbet og optimere dine ressourcer, fordi det hjælper med at fuldføre et større antal slutninger på en vis tid på bekostning af latens. For at optimere modelimplementeringen til højere gennemløb er den generelle retningslinje at øge batchstørrelsen, indtil gennemløbet falder. |
Skalering af konfigurationskompleksitet | SageMaker batch transformation bruges til offline inferens, der ikke er latensfølsom. |
Trafikmønster | Til offline slutning planlægges eller startes et batchtransformationsjob ved hjælp af en hændelsesbaseret trigger. |
Serverløs slutning i SageMaker
SageMaker serverløs inferens giver dig mulighed for at implementere ML-modeller til inferens uden at skulle konfigurere eller administrere den underliggende infrastruktur. Baseret på mængden af slutningsanmodninger, din model modtager, sørger SageMaker serverløs slutning automatisk for, skalerer og slukker for beregningskapacitet. Som følge heraf betaler du kun for beregningstiden for at køre din slutningskode og mængden af behandlede data, ikke for inaktiv tid. Du kan bruge SageMakers indbyggede algoritmer og ML framework-serverende containere til at implementere din model til et serverløst slutpunkt eller vælge at medbringe din egen container. Hvis trafikken bliver forudsigelig og stabil, kan du nemt opdatere fra et serverløst slutpunkt til et SageMaker-endepunkt i realtid uden at skulle foretage ændringer i dit containerbillede. Med serverløs inferens, drager du også fordel af andre SageMaker-funktioner, herunder indbyggede metrics såsom invokationsantal, fejl, latency, host-metrics og fejl i CloudWatch.
Følgende tabel giver vejledning i evaluering af SageMaker serverløs inferens baseret på fitnessfunktionerne.
Fitness funktion | Beskrivelse |
Koste | Med en pay-as-you-run model er serverløs inferens en omkostningseffektiv mulighed, hvis du har sjældne eller intermitterende trafikmønstre. Du betaler kun for den varighed, som endepunktet behandler anmodningen for, og kan derfor spare omkostninger, hvis trafikmønsteret er intermitterende. |
Slutningsforsinkelse |
Serverløse slutpunkter tilbyder lav slutningsforsinkelse (i størrelsesordenen millisekunder til sekunder) med evnen til at skalere øjeblikkeligt fra titusinder til tusindvis af slutninger inden for sekunder baseret på brugsmønstrene, hvilket gør det ideelt til ML-applikationer med intermitterende eller uforudsigelig trafik. Fordi serverløse endepunkter leverer beregningsressourcer efter behov, kan dit endepunkt opleve et par ekstra sekunders latency (koldstart) for den første påkaldelse efter en inaktiv periode. Koldstartstiden afhænger af din modelstørrelse, hvor lang tid det tager at downloade din model og opstartstiden for din container. |
gennemløb | Når du konfigurerer dit serverløse slutpunkt, kan du angive hukommelsesstørrelsen og det maksimale antal samtidige opkald. SageMaker serverløs inferens tildeler automatisk computerressourcer proportionalt med den hukommelse, du vælger. Hvis du vælger en større hukommelsesstørrelse, har din container adgang til flere vCPU'er. Som en generel regel skal hukommelsesstørrelsen være mindst lige så stor som din modelstørrelse. De hukommelsesstørrelser, du kan vælge, er 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB og 6144 MB. Uanset hvilken hukommelsesstørrelse du vælger, har serverløse endepunkter 5 GB midlertidigt disklager til rådighed. |
Skalering af konfigurationskompleksitet | Serverløse slutpunkter starter automatisk computerressourcer og skalerer dem ind og ud afhængigt af trafik, hvilket eliminerer behovet for at vælge instanstyper eller administrere skaleringspolitikker. Dette fjerner det udifferentierede tunge løft ved at vælge og administrere servere. |
Trafikmønster | Serverløs inferens er ideel til arbejdsbelastninger med sjældne eller intermitterende trafikmønstre. |
Model hosting design mønstre i SageMaker
SageMaker-slutningsendepunkter bruger Docker-containere til hosting af ML-modeller. Containere giver dig mulighed for at pakke software til standardiserede enheder, der kører konsekvent på enhver platform, der understøtter Docker. Dette sikrer portabilitet på tværs af platforme, uforanderlige infrastrukturimplementeringer og lettere ændringsstyring og CI/CD-implementeringer. SageMaker leverer forudbyggede administrerede containere til populære rammer som Apache MXNet, TensorFlow, PyTorch, Sklearn og Hugging Face. Se en komplet liste over tilgængelige SageMaker-beholderbilleder Tilgængelige Deep Learning Containers-billeder. I tilfælde af, at SageMaker ikke har en understøttet container, kan du også bygge din egen container (BYOC) og skubbe dit eget brugerdefinerede billede og installere de afhængigheder, der er nødvendige for din model.
For at implementere en model på SageMaker skal du have en container (SageMaker-administrerede rammecontainere eller BYOC) og en computerinstans til at være vært for containeren. SageMaker understøtter flere avancerede muligheder for almindelige ML-model-hosting-designmønstre, hvor modeller kan hostes på en enkelt container eller co-hostes på en delt container.
En ML-applikation i realtid kan bruge en enkelt model eller flere modeller til at betjene en enkelt forudsigelsesanmodning. Følgende diagram viser forskellige slutningsscenarier for en ML-applikation.
Lad os undersøge en passende SageMaker-hostingmulighed for hvert af de foregående slutningsscenarier. Du kan henvise til fitnessfunktionerne for at vurdere, om det er den rigtige mulighed for den givne brugssag.
Vært for en enkeltmodel baseret ML-applikation
Der er flere muligheder for at være vært for enkeltmodelbaserede ML-applikationer ved hjælp af SageMaker-hostingtjenester afhængigt af implementeringsscenariet.
Enkeltmodel slutpunkt
SageMaker enkelt-model slutpunkter giver dig mulighed for at være vært for én model på en container hostet på dedikerede forekomster for lav latenstid og høj gennemstrømning. Disse endepunkter er fuldt administrerede og understøtter automatisk skalering. Du kan konfigurere enkelt-modelslutpunktet som et klargjort slutpunkt, hvor du sender endepunktsinfrastrukturkonfigurationen, såsom forekomsttype og antal, eller et serverløst slutpunkt, hvor SageMaker automatisk starter computerressourcer og skalerer dem ind og ud afhængigt af trafik, hvilket eliminerer behovet at vælge instanstyper eller administrere skaleringspolitikker. Serverløse endepunkter er til applikationer med intermitterende eller uforudsigelig trafik.
Følgende diagram viser single-model endpoint inferens scenarier.
Følgende tabel giver vejledning i evaluering af fitnessfunktioner for et klargjort enkeltmodelslutpunkt. For evalueringer af serverløse endpoint fitness-funktioner, se afsnittet om serverless endpoint i dette indlæg.
Fitness funktion | Beskrivelse |
Koste | Du debiteres for brug af den instanstype, du vælger. Fordi slutpunktet altid kører og er tilgængeligt, kan omkostningerne hurtigt stige. At vælge den rigtige instans til din model er med til at sikre, at du har den mest effektive instans til den laveste pris for dine modeller. Automatisk skalering anbefales for dynamisk at justere kapaciteten afhængigt af trafikken for at opretholde en stabil og forudsigelig ydeevne til den laveste pris. |
Slutningsforsinkelse | Et enkelt-model-slutpunkt giver interaktiv, synkron inferens i realtid med millisekunders latenskrav. |
gennemløb | Gennemløbet kan påvirkes af forskellige faktorer, såsom modelinputstørrelse, batchstørrelse, slutpunktforekomsttype og så videre. Det anbefales at gennemgå CloudWatch-metrics for inputanmodninger og ressourceudnyttelse og vælge den passende instanstype for at opnå optimal gennemstrømning. SageMaker giver funktioner til at administrere ressourcer og optimere slutningsydelsen, når du implementerer ML-modeller. Du kan optimer modellens ydeevne ved hjælp af Neo, eller brug Inf1-instanser for at få bedre gennemstrømning af dine SageMaker-hostede modeller ved hjælp af en GPU-instans til dit slutpunkt. |
Skalering af konfigurationskompleksitet | Automatisk skalering understøttes ud af boksen. SageMaker anbefaler at vælge en passende skaleringskonfiguration ved at optræde belastningstest. |
Trafikmønster | Et enkelt-model slutpunkt er ideelt til arbejdsbelastninger med forudsigelige trafikmønstre. |
Co-hosting af flere modeller
Når du har at gøre med et stort antal modeller, kan implementering af hver enkelt på et individuelt slutpunkt med en dedikeret beholder og instans resultere i en betydelig stigning i omkostningerne. Derudover bliver det også svært at administrere så mange modeller i produktionen, specielt når du ikke behøver at kalde alle modellerne på samme tid, men stadig har brug for, at de er tilgængelige hele tiden. Co-hosting af flere modeller på de samme underliggende computerressourcer gør det nemt at administrere ML-implementeringer i stor skala og sænker dine hostingomkostninger gennem øget brug af slutpunktet og dets underliggende computerressourcer. SageMaker understøtter avancerede model co-hosting muligheder såsom multi-model endpoint (MME) for homogene modeller og multi-container endpoint (MCE) for heterogene modeller. Homogene modeller bruger det samme ML-framework på en delt servicecontainer, hvorimod heterogene modeller giver dig mulighed for at implementere flere serveringscontainere, der bruger forskellige modeller eller frameworks på et enkelt slutpunkt.
Følgende diagram viser muligheder for co-hosting for modeller ved hjælp af SageMaker.
SageMaker multi-model slutpunkter
SageMaker MME'er giver dig mulighed for at være vært for flere modeller ved hjælp af en delt serveringsbeholder på et enkelt slutpunkt. Dette er en skalerbar og omkostningseffektiv løsning til at implementere et stort antal modeller, der henvender sig til samme use case, framework eller inferenslogik. MME'er kan dynamisk betjene anmodninger baseret på den model, som kaldes på. Det reducerer også implementeringsomkostningerne, fordi SageMaker administrerer indlæsning af modeller i hukommelsen og skalerer dem baseret på trafikmønstrene til dem. Denne funktion er ideel, når du har et stort antal lignende modeller, som du kan betjene gennem en delt serveringsbeholder og ikke behøver at få adgang til alle modellerne på samme tid. Multi-model slutpunkter muliggør også tidsdeling af hukommelsesressourcer på tværs af dine modeller. Dette fungerer bedst, når modellerne er nogenlunde ens i størrelse og invokationsforsinkelse, hvilket giver MME'er mulighed for effektivt at bruge forekomsterne på tværs af alle modeller. SageMaker MME'er understøtter hosting af både CPU- og GPU-understøttede modeller. Ved at bruge GPU-understøttede modeller kan du sænke dine modelimplementeringsomkostninger gennem øget brug af slutpunktet og dets underliggende accelererede beregningsinstanser. For en reel anvendelse af MME'er, se Sådan skalerer du maskinlæringsslutning til SaaS-brugssager med flere lejere.
Følgende tabel giver vejledning i evaluering af fitnessfunktionerne for MME'er.
Fitness funktion | Beskrivelse |
Koste |
MME'er gør det muligt at bruge en delt serveringscontainer til at hoste tusindvis af modeller på et enkelt slutpunkt. Dette reducerer hostingomkostningerne betydeligt ved at forbedre endpoint-udnyttelsen sammenlignet med at bruge single-model endpoints. Hvis du f.eks. har 10 modeller at implementere ved hjælp af en ml.c5.large-instans, baseret på SageMaker-priser, omkostningerne ved at have 10 enkelt-model persistente endepunkter er: 10 * $0.102 = $1.02 pr. time. Hvorimod med en MME, der hoster de 10 modeller, opnår vi 10 gange omkostningsbesparelser: 1 * $0.102 = $0.102 i timen. |
Slutningsforsinkelse |
Som standard cachelagrer MME'er ofte brugte modeller i hukommelsen og på disken for at give inferens med lav latens. De cachelagrede modeller fjernes eller slettes kun fra disken, når en beholder løber tør for hukommelse eller diskplads for at kunne rumme en model, der netop er målrettet mod. MME'er tillader doven indlæsning af modeller, hvilket betyder, at modeller indlæses i hukommelsen, når de aktiveres for første gang. Dette optimerer hukommelsesudnyttelsen; det forårsager dog spidser i responstiden ved første belastning, hvilket resulterer i et koldstartsproblem. Derfor er MME'er også velegnede til scenarier, der kan tolerere lejlighedsvise koldstart-relaterede latenssanktioner, der opstår, når man påberåber sig sjældent brugte modeller. For at opfylde ML-applikationernes latens- og gennemløbsmål foretrækkes GPU-instanser frem for CPU-instanser (i betragtning af GPU'ernes beregningskraft). Med MME-understøttelse af GPU kan du implementere tusindvis af deep learning-modeller bag ét SageMaker-slutpunkt. MME'er kan køre flere modeller på en GPU-kerne, dele GPU-instanser bag et slutpunkt på tværs af flere modeller og dynamisk indlæse og aflæse modeller baseret på den indkommende trafik. Med dette kan du spare betydeligt på omkostningerne og opnå den bedste prisydelse. Hvis din use case kræver væsentligt højere transaktioner per sekund (TPS) eller latency krav, anbefaler vi at hoste modellerne på dedikerede slutpunkter. |
gennemløb |
En ideel værdi af MME-inferensgennemløb afhænger af faktorer som model, nyttelaststørrelse og slutpunktforekomsttype. En større mængde instanshukommelse gør det muligt for dig at have flere modeller indlæst og klar til at betjene slutningsanmodninger. Du behøver ikke spilde tid med at indlæse modellen. Et større antal vCPU'er giver dig mulighed for at påkalde flere unikke modeller samtidigt. MME'er indlæser og aflæser modellen dynamisk til og fra instanshukommelsen, hvilket kan påvirke I/O-ydeevnen. SageMaker MME'er med GPU arbejder vha NVIDIA Triton Inference Server, som er en open source-inferensserveringssoftware, der forenkler inferensserveringsprocessen og giver høj inferensydelse. SageMaker indlæser modellen til NVIDIA Triton-beholderens hukommelse på en GPU-accelereret instans og betjener inferensanmodningen. GPU-kernen deles af alle modellerne i en instans. Hvis modellen allerede er indlæst i containerhukommelsen, serveres de efterfølgende anmodninger hurtigere, fordi SageMaker ikke behøver at downloade og indlæse den igen. En ordentlig præstationstest og -analyse anbefales ved succesfulde produktionsinstallationer. SageMaker leverer CloudWatch-metrics for multi-model-endepunkter, så du kan bestemme slutpunktforbruget og cache-hitraten for at hjælpe med at optimere dit slutpunkt. |
Skalering af konfigurationskompleksitet | SageMaker multi-model slutpunkter understøtter fuldt ud automatisk skalering, som administrerer kopier af modeller for at sikre, at modeller skaleres baseret på trafikmønstre. En ordentlig belastningstest anbefales dog for at bestemme den optimale størrelse af instanserne til automatisk skalering af slutpunktet. Den rigtige størrelse af MME-flåden er vigtig for at undgå, at for mange modeller losses. Indlæsning af hundredvis af modeller på nogle få større forekomster kan i nogle tilfælde føre til drosling, og brug af flere og mindre forekomster kunne foretrækkes. For at drage fordel af automatiseret modelskalering i SageMaker skal du sørge for at have opsætning af automatisk skalering at tilvejebringe yderligere instanskapacitet. Konfigurer din skaleringspolitik på endepunktsniveau med enten brugerdefinerede parametre eller opkald pr. minut (anbefales) for at tilføje flere forekomster til endepunktsflåden. De påkaldelseshastigheder, der bruges til at udløse en automatisk skaleringshændelse, er baseret på det samlede sæt af forudsigelser på tværs af det fulde sæt af modeller, der betjenes af slutpunktet. |
Trafikmønster | MME'er er ideelle, når du har et stort antal modeller af lignende størrelse, som du kan betjene gennem en delt serveringsbeholder og ikke behøver at få adgang til alle modellerne på samme tid. |
SageMaker multi-container slutpunkter
SageMaker MCE'er understøtter implementering af op til 15 containere, der bruger forskellige modeller eller rammer på et enkelt slutpunkt, og påberåber dem uafhængigt eller i rækkefølge for at opnå slutninger med lav latens og omkostningsbesparelser. Modellerne kan være fuldstændig heterogene med deres egen uafhængige serveringsstak. Sikker hosting af flere modeller fra forskellige rammer på en enkelt instans kan spare dig op til 90 % i omkostninger.
MCE-invokationsmønstrene er som følger:
- Inferensrørledninger – Containere i en MME kan kaldes i en lineær sekvens, også kendt som en seriel inferenspipeline. De bruges typisk til at adskille forbehandling, modelslutning og efterbehandling i uafhængige beholdere. Outputtet fra den aktuelle beholder sendes som input til den næste. De er repræsenteret som en enkelt pipeline-model i SageMaker. En inferenspipeline kan implementeres som en MME, hvor en af containerne i pipelinen dynamisk kan betjene anmodninger baseret på den model, der påberåbes.
- Direkte påkaldelse - Med direkte påkaldelse, kan en anmodning sendes til en specifik inferensbeholder hostet på en MCE.
Følgende tabel giver vejledning i evaluering af fitnessfunktionerne for MCE'er.
Fitness funktion | Beskrivelse |
Koste | MCE'er gør det muligt for dig at køre op til 15 forskellige ML-containere på et enkelt slutpunkt og aktivere dem uafhængigt, hvilket sparer omkostninger. Denne mulighed er ideel, når du har flere modeller, der kører på forskellige serveringsstakke med lignende ressourcebehov, og når individuelle modeller ikke har tilstrækkelig trafik til at udnytte den fulde kapacitet af slutpunktforekomsterne. MCE'er er derfor mere omkostningseffektive end et enkelt-model slutpunkt. MCE'er tilbyder synkront inferenssvar, hvilket betyder, at slutpunktet altid er tilgængeligt, og du betaler for instansens oppetid. Omkostningerne kan stige afhængigt af antallet og typen af forekomster. |
Slutningsforsinkelse | MCE'er er ideelle til at køre ML-apps med forskellige ML-frameworks og algoritmer for hver model, som tilgås sjældent, men som stadig kræver inferens med lav latens. Modellerne er altid tilgængelige til inferens med lav latens, og der er ingen koldstartsproblem. |
gennemløb | MCE'er er begrænset til op til 15 containere på et multi-container-endepunkt, og GPU-inferens er ikke understøttet på grund af ressourcestrid. For multi-container-endepunkter, der bruger direkte invokationstilstand, leverer SageMaker ikke kun metrics på instansniveau, som det gør med andre almindelige slutpunkter, men understøtter også per-container-metrics. Som en bedste praksis skal du gennemgå CloudWatch-metrics for inputanmodninger og ressourceudnyttelse og vælge den passende instanstype for at opnå optimal gennemstrømning. |
Skalering af konfigurationskompleksitet | MCE'er understøtter automatisk skalering. For at konfigurere automatisk skalering anbefales det dog, at modellen i hver beholder udviser lignende CPU-udnyttelse og latenstid på hver inferensanmodning. Dette anbefales, fordi hvis trafikken til multi-container-endepunktet skifter fra en model med lav CPU-udnyttelse til en model med høj CPU-udnyttelse, men den samlede opkaldsvolumen forbliver den samme, skaleres slutpunktet ikke ud, og der er muligvis ikke nok forekomster at håndtere alle anmodninger til den høje CPU-udnyttelsesmodel. |
Trafikmønster | MCE'er er ideelle til arbejdsbelastninger med kontinuerlige eller regelmæssige trafikmønstre, til hosting af modeller på tværs af forskellige rammer (såsom TensorFlow, PyTorch eller Sklearn), der muligvis ikke har tilstrækkelig trafik til at mætte den fulde kapacitet af en slutpunktinstans. |
Hosting af en multimodelbaseret ML-applikation
Mange forretningsapplikationer skal bruge flere ML-modeller for at levere en enkelt forudsigelsesanmodning til deres forbrugere. For eksempel en detailvirksomhed, der ønsker at give anbefalinger til sine brugere. ML-applikationen i dette tilfælde vil måske bruge forskellige brugerdefinerede modeller til at anbefale forskellige kategorier af produkter. Hvis virksomheden ønsker at tilføje personalisering til anbefalingerne ved at bruge individuelle brugeroplysninger, øges antallet af tilpassede modeller yderligere. Hosting af hver brugerdefineret model på en særskilt computerinstans er ikke kun uoverkommelig, men fører også til underudnyttelse af hostingressourcerne, hvis ikke alle modeller bruges ofte. SageMaker tilbyder effektive hostingmuligheder for multimodelbaserede ML-applikationer.
Følgende diagram viser multi-model hosting muligheder for et enkelt slutpunkt ved hjælp af SageMaker.
Seriel inferenspipeline
En slutningspipeline er en SageMaker-model, der er sammensat af en lineær sekvens på 2-15 containere, der behandler anmodninger om slutninger om data. Du bruger en inferenspipeline til at definere og implementere enhver kombination af forudtrænede SageMaker indbyggede algoritmer og dine egne brugerdefinerede algoritmer pakket i Docker-containere. Du kan bruge en slutningspipeline til at kombinere forbehandling, forudsigelser og efterbehandling af datavidenskabelige opgaver. Outputtet fra en beholder sendes som input til den næste. Når du definerer containerne til en pipelinemodel, angiver du også den rækkefølge, som containerne køres i. De er repræsenteret som en enkelt pipeline-model i SageMaker. Inferenspipelinen kan implementeres som en MME, hvor en af containerne i pipelinen dynamisk kan betjene anmodninger baseret på den model, der påkaldes. Du kan også køre en batch transformation job med en slutningspipeline. Inferensrørledninger styres fuldt ud.
Følgende tabel giver vejledning i evaluering af fitnessfunktionerne for ML-modelhosting ved hjælp af en seriel inferenspipeline.
Fitness funktion | Beskrivelse |
Koste | Seriel inferenspipeline giver dig mulighed for at køre op til 15 forskellige ML-beholdere på et enkelt slutpunkt, hvilket fører til omkostningseffektivitet ved at være vært for inferensbeholderne. Der er ingen ekstra omkostninger ved at bruge denne funktion. Du betaler kun for de forekomster, der kører på et slutpunkt. Omkostningerne kan stige afhængigt af antallet og typen af forekomster. |
Slutningsforsinkelse | Når en ML-applikation er implementeret som en inferenspipeline, forlader dataene mellem forskellige modeller ikke containerpladsen. Funktionsbehandling og inferenser kører med lav latenstid, fordi containerne er samplaceret på de samme EC2-instanser. |
gennemløb | Inden for en inferenspipeline-model håndterer SageMaker påkaldelser som en sekvens af HTTP-anmodninger. Den første container i pipelinen håndterer den indledende anmodning, derefter sendes det mellemliggende svar som en anmodning til den anden container, og så videre for hver container i pipelinen. SageMaker returnerer det endelige svar til klienten. Gennemløbet er subjektivt for faktorer som model, modelinputstørrelse, batchstørrelse og slutpunktforekomsttype. Som en bedste praksis skal du gennemgå CloudWatch-metrics for inputanmodninger og ressourceudnyttelse og vælge den passende instanstype for at opnå optimal gennemstrømning. |
Skalering af konfigurationskompleksitet | Serielle inferensrørledninger understøtter automatisk skalering. For at konfigurere automatisk skalering anbefales det dog, at modellen i hver container udviser ens CPU-udnyttelse og latenstid på hver slutningsanmodning. Dette anbefales, fordi hvis trafikken til multi-container-endepunktet skifter fra en model med lav CPU-udnyttelse til en model med høj CPU-udnyttelse, men den samlede opkaldsvolumen forbliver den samme, skaleres slutpunktet ikke ud, og der er muligvis ikke nok forekomster til at håndtere alle anmodninger til modellen med høj CPU-udnyttelse. |
Trafikmønster |
Seriel inferensrørledninger er ideelle til forudsigelige trafikmønstre med modeller, der kører sekventielt på det samme endepunkt. |
Implementering af modelensembler (Triton DAG):
SageMaker tilbyder integration med NVIDIA Triton Inference Server ved Triton Inference Server Containers. Disse containere inkluderer NVIDIA Triton Inference Server, understøttelse af almindelige ML-frameworks og nyttige miljøvariabler, der lader dig optimere ydeevnen på SageMaker. Med NVIDIA Triton-beholderbilleder kan du nemt betjene ML-modeller og drage fordel af ydeevneoptimeringerne, dynamisk batching og multi-framework-understøttelse fra NVIDIA Triton. Triton hjælper med at maksimere udnyttelsen af GPU og CPU, hvilket yderligere sænker omkostningerne ved inferens.
I tilfælde af forretningsbrug, hvor ML-applikationer bruger flere modeller til at betjene en forudsigelsesanmodning, kan det føre til øget arbejdsbyrde og omkostninger samt en stigning i den samlede latenstid, hvis hver model bruger en anden ramme eller hostes på en separat instans. SageMaker NVIDIA Triton Inference Server understøtter implementering af modeller fra alle større frameworks, såsom TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT og Python/C++ modelformater og mere. Triton modelensemble repræsenterer en pipeline af en eller flere modeller eller forbehandlings- og efterbehandlingslogik og forbindelsen af input- og outputtensorer mellem dem. En enkelt slutningsanmodning til et ensemble udløser kørsel af hele pipelinen. Triton har også flere indbyggede planlægnings- og batch-algoritmer, der kombinerer individuelle slutningsanmodninger for at forbedre slutningsgennemstrømningen. Disse planlægnings- og batchbeslutninger er gennemsigtige for den klient, der anmoder om konklusioner. Modellerne kan køres på CPU'er eller GPU'er for maksimal fleksibilitet og for at understøtte heterogene computerkrav.
Hosting af flere GPU-understøttede modeller på multi-model slutpunkter understøttes gennem SageMaker Triton Inference Server. NVIDIA Triton Inference Server er blevet udvidet til at implementere en MME API kontrakt, for at integrere med MME'er. Du kan bruge NVIDIA Triton Inference Server, som opretter en model repository-konfiguration for forskellige framework-backends, til at implementere en MME med automatisk skalering. Denne funktion giver dig mulighed for at skalere hundredvis af hyper-personaliserede modeller, der er finjusteret til at tage højde for unikke slutbrugeroplevelser i AI-applikationer. Du kan også bruge denne funktion til at opnå den nødvendige prisydeevne for din slutningsapplikation ved hjælp af fraktioneret GPU'er. For at lære mere, se Kør flere deep learning-modeller på GPU med Amazon SageMaker multi-model endpoints.
Følgende tabel giver vejledning i evaluering af fitnessfunktionerne for ML-modelhosting ved hjælp af MME'er med GPU-understøttelse på Triton-inferensbeholdere. For single-model endpoints og serverless endpoint fitness funktion evalueringer, se de tidligere afsnit i dette indlæg.
Fitness funktion | Beskrivelse |
Koste | SageMaker MME'er med GPU-understøttelse ved hjælp af Triton Inference Server giver en skalerbar og omkostningseffektiv måde at implementere et stort antal deep learning-modeller bag ét SageMaker-slutpunkt. Med MME'er deler flere modeller GPU-instansen bag et slutpunkt. Dette giver dig mulighed for at bryde de lineært stigende omkostninger ved hosting af flere modeller og genbruge infrastruktur på tværs af alle modeller. Du betaler for instansens oppetid. |
Slutningsforsinkelse |
SageMaker med Triton Inference Server er specialbygget til at maksimere gennemløb og hardwareudnyttelse med ultralav (encifrede millisekunder) inferensforsinkelse. Den har en bred vifte af understøttede ML-frameworks (inklusive TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, herunder NVIDIA GPU'er, CPU'er og AWS-inferens. Med MME-understøttelse af GPU ved hjælp af SageMaker Triton Inference Server kan du implementere tusindvis af deep learning-modeller bag ét SageMaker-slutpunkt. SageMaker indlæser modellen til NVIDIA Triton-beholderens hukommelse på en GPU-accelereret instans og betjener inferensanmodningen. GPU-kernen deles af alle modellerne i en instans. Hvis modellen allerede er indlæst i containerhukommelsen, serveres de efterfølgende anmodninger hurtigere, fordi SageMaker ikke behøver at downloade og indlæse den igen. |
gennemløb |
MME'er tilbyder muligheder for at køre flere deep learning- eller ML-modeller på GPU'en på samme tid med Triton Inference Server. Dette giver dig mulighed for nemt at bruge NVIDIA Triton multi-framework, højtydende inferensservering med SageMaker fuldt administrerede modelimplementering. Triton understøtter al NVIDIA GPU-, x86-, Arm® CPU- og AWS Inferentia-baseret inferencing. Det tilbyder dynamisk batching, samtidige kørsler, optimal modelkonfiguration, modelensemble og streaming af lyd- og videoinput for at maksimere gennemløb og udnyttelse. Andre faktorer såsom netværk og nyttelaststørrelse kan spille en minimal rolle i den overhead, der er forbundet med slutningen. |
Skalering af konfigurationskompleksitet |
MME'er kan skalere horisontalt ved hjælp af en automatisk skaleringspolitik og levere yderligere GPU-beregningsinstanser baseret på metrics som f.eks. Med Triton-inferensserver kan du nemt bygge en brugerdefineret container, der inkluderer din model med Triton og bringe den til SageMaker. SageMaker Inference vil håndtere anmodningerne og automatisk skalere containeren, efterhånden som brugen stiger, hvilket gør modelimplementering med Triton på AWS nemmere. |
Trafikmønster |
MME'er er ideelle til forudsigelige trafikmønstre med modeller, der kører som DAG'er på det samme endepunkt. SageMaker sørger for trafikformning til MME-slutpunktet og vedligeholder optimale modelkopier på GPU-instanser for den bedste prisydelse. Den fortsætter med at dirigere trafik til den instans, hvor modellen er indlæst. Hvis instansressourcerne når kapacitet på grund af høj udnyttelse, losser SageMaker de mindst brugte modeller fra containeren for at frigøre ressourcer til at indlæse hyppigere brugte modeller. |
Bedste praksis
Overvej følgende bedste praksis:
- Høj sammenhæng og lav kobling mellem modeller – Vær vært for modellerne i den samme container, der har høj sammenhæng (driver funktionalitet for enkeltvirksomheder), og indkapsl dem sammen for at lette opgradering og håndtering. På samme tid skal du afkoble disse modeller fra hinanden (vært dem i en anden container), så du nemt kan opgradere én model uden at påvirke andre modeller. Vær vært for flere modeller, der bruger forskellige containere bag ét slutpunkt og påberåber sig derefter uafhængigt eller tilføjer modelforbehandlings- og efterbehandlingslogik som en seriel inferenspipeline.
- Slutningsforsinkelse – Gruppér de modeller, der er funktionalitetsdrevne for en enkelt virksomhed, og host dem i en enkelt container for at minimere antallet af hop og derfor minimere den samlede latenstid. Der er andre forbehold, som hvis de grupperede modeller bruger flere rammer; du kan også vælge at hoste i flere containere, men køre på den samme vært for at reducere latens og minimere omkostningerne.
- Grupper logisk ML-modeller med høj sammenhængskraft – Den logiske gruppe kan bestå af modeller, der er homogene (f.eks. alle XGBoost-modeller) eller heterogene (f.eks. nogle få XGBoost og nogle få BERT). Det kan bestå af modeller, der deles på tværs af flere forretningsfunktioner eller kan være specifikt til at opfylde kun én forretningsfunktionalitet.
- Delte modeller – Hvis den logiske gruppe består af delte modeller, vil letheden ved at opgradere modellerne og latency spille en stor rolle i udformningen af SageMaker-endepunkterne. For eksempel, hvis latency er en prioritet, er det bedre at placere alle modellerne i en enkelt container bag et enkelt SageMaker-slutpunkt for at undgå flere hop. Ulempen er, at hvis nogen af modellerne skal opgraderes, vil det resultere i en opgradering af alle de relevante SageMaker-slutpunkter, der er vært for denne model.
- Ikke-delte modeller – Hvis den logiske gruppe kun består af forretningsfunktionsspecifikke modeller og ikke deles med andre grupper, vil pakkekompleksiteten og latensdimensionerne blive nøglen til at opnå. Det er tilrådeligt at hoste disse modeller i en enkelt container bag et enkelt SageMaker-slutpunkt.
- Effektiv brug af hardware (CPU, GPU) – Gruppér CPU-baserede modeller sammen og host dem på den samme vært, så du effektivt kan bruge CPU'en. Gruppér GPU-baserede modeller på samme måde, så du effektivt kan bruge og skalere dem. Der er hybride arbejdsbelastninger, der kræver både CPU og GPU på den samme vært. Hosting af kun CPU- og GPU-modeller på den samme vært bør være drevet af høj sammenhængskraft og krav til applikationsforsinkelse. Derudover er omkostninger, evne til at skalere og sprængningsradius ved stød i tilfælde af fejl de vigtigste dimensioner at se nærmere på.
- Fitness funktioner – Brug fitnessfunktioner som en rettesnor for at vælge en ML-hostingmulighed.
Konklusion
Når det kommer til ML-hosting, er der ingen ensartet tilgang. ML praktikere skal vælge det rigtige designmønster for at løse deres ML hosting udfordringer. Evaluering af fitnessfunktionerne giver præskriptiv vejledning om valg af den rigtige ML-hostingmulighed.
For flere detaljer om hver af hostingmulighederne, se følgende indlæg i denne serie:
Om forfatterne
Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret computing og kunstig intelligens. Han fokuserer på Deep learning, herunder NLP og Computer Vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.
Deepali Rajale er AI/ML Specialist Technical Account Manager hos Amazon Web Services. Hun arbejder med virksomhedskunder, der giver teknisk vejledning om implementering af maskinlæringsløsninger med bedste praksis. I sin fritid nyder hun at vandre, filme og hænge ud med familie og venner.
Saurabh Trikande er Senior Product Manager for Amazon SageMaker Inference. Han brænder for at arbejde med kunder og er motiveret af målet om at demokratisere machine learning. Han fokuserer på kerneudfordringer relateret til implementering af komplekse ML-applikationer, multi-tenant ML-modeller, omkostningsoptimeringer og at gøre implementering af deep learning-modeller mere tilgængelig. I sin fritid nyder Saurabh at vandre, lære om innovative teknologier, følge TechCrunch og tilbringe tid med sin familie.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
- Kilde: 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
- evne
- I stand
- Om
- accelereret
- adgang
- af udleverede
- tilgængelig
- imødekomme
- Konto
- præcis
- opnå
- opnå
- tværs
- Handling
- aktivt
- Desuden
- Yderligere
- Derudover
- adresse
- fremme
- fremskreden
- Fordel
- Reklame
- påvirke
- Efter
- aggregering
- aggregator
- aggressive
- aftaler
- AI
- AI / ML
- alarm
- algoritmer
- Alle
- tillade
- tillader
- allerede
- altid
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- beløb
- analyse
- analysere
- ,
- og infrastruktur
- årligt
- En anden
- Apache
- api
- Apple
- Anvendelse
- applikationer
- tilgang
- passende
- apps
- arkitektur
- ARM
- kunstig
- kunstig intelligens
- aspekter
- vurdering
- forbundet
- attributter
- lyd
- revisioner
- auto
- Automatiseret
- Automatisk Ur
- automatisk
- tilgængelighed
- til rådighed
- gennemsnit
- AWS
- tilbage
- Backed
- Bank
- bund
- baseret
- fordi
- bliver
- bliver
- før
- bag
- være
- gavner det dig
- BEDSTE
- bedste praksis
- Bedre
- mellem
- biomedicinsk
- Bloker
- låntagning
- grænser
- Boks
- brud
- Pause
- bringe
- Bringer
- Budgetter
- bygge
- Bygning
- bygget
- indbygget
- virksomhed
- Business Applications
- Forretningsproces
- virksomheder
- Cache
- beregnet
- ringe
- kaldet
- Caller
- kandidater
- kapaciteter
- Kapacitet
- hvilken
- tilfælde
- tilfælde
- kategorier
- årsager
- vis
- Certificeret
- udfordringer
- lave om
- Ændringer
- karakteristika
- opladet
- chatbot
- kontrollere
- chip
- valg
- valg
- Vælg
- vælge
- klasse
- klassificering
- Klassificere
- kunde
- kunder
- Luk
- Cloud
- Cluster
- kode
- opfundet
- kolleger
- indsamler
- bekæmpe
- kombination
- kombinerer
- kombineret
- Fælles
- Virksomheder
- selskab
- sammenlignet
- fuldføre
- fuldstændig
- komplekse
- kompleksitet
- Compliance
- komponenter
- sammensat
- kompromis
- computerkraft
- Compute
- computer
- Computer Vision
- computing
- Konceptet
- Bekymring
- konkurrent
- Konfiguration
- tilslutning
- konsekvent
- forbruges
- Forbrugere
- Container
- Beholdere
- indeholder
- fortsæt
- fortsætter
- kontinuerlig
- kontrol
- Core
- Tilsvarende
- Koste
- omkostningsbesparelser
- omkostningseffektiv
- Omkostninger
- kunne
- skabe
- skaber
- kritisk
- afgørende
- Nuværende
- skik
- kunde
- Kunder
- DAG
- data
- databehandling
- datalogi
- dataforsker
- Database
- datasæt
- dag
- beskæftiger
- afgørelser
- dedikeret
- dyb
- dyb læring
- Standard
- definere
- levere
- Efterspørgsel
- krav
- demokratisering
- Afhængigt
- afhænger
- indsætte
- indsat
- implementering
- implementering
- implementeringer
- Design
- design mønstre
- konstrueret
- detail
- detaljer
- Detektion
- Bestem
- Udvikler
- Udvikling
- diagrammer
- forskellige
- svært
- størrelse
- direkte
- distinkt
- distribueret
- distribueret computing
- forskelligartede
- Docker
- dokumenter
- Er ikke
- Domæner
- Dont
- ned
- downloade
- downside
- drevet
- droppet
- Dropper
- i løbet af
- dynamisk
- hver
- tidligere
- lettere
- nemt
- Effektiv
- effektivt
- effektivitet
- effektivitet
- effektiv
- effektivt
- indsats
- enten
- eliminere
- muliggøre
- muliggør
- kryptering
- ende til ende
- Endpoint
- Engineering
- Ingeniører
- nok
- sikre
- sikrer
- Enterprise
- virksomheder
- Hele
- Miljø
- fejl
- fejl
- især
- evalueret
- evalueringer
- Endog
- begivenhed
- at alt
- evolution
- eksempel
- eksempler
- udveksling
- udstillinger
- forvente
- forventet
- erfaring
- Oplevelser
- udforske
- udtryk
- ekstern
- ekstra
- Ansigtet
- faktorer
- Manglende
- retfærdigt
- familier
- familie
- hurtigere
- Feature
- Funktionalitet
- fodring
- få
- endelige
- Fornavn
- første gang
- fitness
- FLÅDE
- Fleksibilitet
- flow
- svinge
- fokuserer
- efter
- følger
- Ford
- formular
- formularer
- fraktioneret
- Framework
- rammer
- bedrageri
- bedrageri afsløring
- Gratis
- Frekvens
- hyppigt
- venner
- fra
- Frugter
- fuld
- fuldt ud
- funktion
- funktionaliteter
- funktionalitet
- funktioner
- yderligere
- GDPR
- Generelt
- genereret
- generere
- få
- Giv
- given
- mål
- Mål
- godt
- GPU
- GPU'er
- graf
- stor
- større
- stærkt
- gruppe
- Gruppens
- Grow
- vejlede
- håndtere
- Håndterer
- praktisk
- Hardware
- have
- Helse
- sundhedspleje
- hjælpe
- hjælpe
- hjælper
- link.
- Høj
- Høj ydeevne
- høj opløsning
- højere
- Hit
- Vandret
- host
- hostede
- Hosting
- hosting omkostninger
- hosting-tjenester
- Hvordan
- Men
- HTML
- HTTPS
- Hundreder
- Hybrid
- ideal
- Identity
- tomgang
- billede
- Billedklassificering
- billeder
- uforanderlige
- KIMOs Succeshistorier
- påvirket
- Påvirkninger
- gennemføre
- implementeret
- gennemføre
- vigtigt
- Forbedre
- forbedring
- in
- omfatter
- omfatter
- Herunder
- Indgående
- Forøg
- øget
- Stigninger
- stigende
- uafhængig
- uafhængigt
- individuel
- oplysninger
- Infrastruktur
- initial
- innovativ
- innovative teknologier
- indgang
- installation
- instans
- i stedet
- integrere
- integration
- Intelligens
- interaktiv
- involvere
- ISO
- isolation
- IT
- Job
- Karriere
- Nøgle
- nøgler
- Kend
- kendt
- stor
- større
- Latency
- lancere
- lanceringer
- lancering
- føre
- førende
- Leads
- LÆR
- læring
- Forlade
- Led
- Niveau
- biblioteker
- løft
- Limited
- grænser
- Liste
- leve
- belastning
- lastning
- belastninger
- placering
- Lang
- længere
- Se
- miste
- Lot
- Lav
- maskine
- machine learning
- lavet
- Main
- vedligeholde
- fastholder
- større
- lave
- maerker
- Making
- administrere
- lykkedes
- ledelse
- leder
- administrerer
- styring
- mange
- Marketing
- matematiske
- Matter
- Maksimer
- maksimal
- midler
- Mød
- Hukommelse
- metode
- metoder
- metrisk
- Metrics
- måske
- mindste
- minimum
- minutter
- Blanding
- ML
- tilstand
- model
- modeller
- Overvåg
- overvågning
- Måned
- måned
- mere
- mest
- motiveret
- Film
- Multi-model slutpunkt
- flere
- mangfoldighed
- Natur
- nødvendig
- Behov
- behov
- netværk
- Ny
- næste
- NLP
- underretning
- meddelelser
- nummer
- Nvidia
- objekt
- objektiv
- målsætninger
- opnå
- lejlighedsvis
- tilbyde
- Tilbud
- offline
- ONE
- online
- open source
- betjene
- opererer
- drift
- operationelle
- Produktion
- Operatører
- optimal
- optimering
- Optimer
- optimeret
- Optimerer
- optimering
- Option
- Indstillinger
- Orange
- ordrer
- organisationer
- Andet
- udestående
- samlet
- egen
- ejerskab
- pakke
- emballage
- parametre
- del
- særlig
- partner
- Bestået
- lidenskabelige
- Patches
- Mønster
- mønstre
- Betal
- Peak
- Udfør
- ydeevne
- udfører
- periode
- periodisk
- perioder
- Personalisering
- Personlig
- pick
- pipeline
- Place
- Steder
- planlagt
- planer
- perron
- Platforme
- plato
- Platon Data Intelligence
- PlatoData
- Leg
- plus
- politikker
- politik
- Populær
- mulig
- Indlæg
- Indlæg
- magt
- praksis
- praksis
- Forudsigelig
- forudsige
- forudsigelse
- Forudsigelser
- foretrækkes
- tidligere
- pris
- Main
- prioritet
- private
- Problem
- problemer
- behandle
- Behandlet
- Processer
- forarbejdning
- processorer
- Produkt
- produktchef
- produktion
- Produkter
- Profil
- passende
- give
- forudsat
- giver
- leverer
- bestemmelse
- proxy
- formål
- Skub ud
- pytorch
- hurtigt
- rækkevidde
- spænder
- hurtigt
- Sats
- priser
- nå
- når
- Læs
- klar
- ægte
- virkelige verden
- realtid
- modtage
- modtaget
- modtager
- anbefaler
- Anbefaling
- anbefalinger
- anbefales
- anbefale
- anbefaler
- tilbagevendende
- reducere
- reducerer
- refererer
- Uanset
- fast
- relaterede
- Udgivelser
- relevant
- resterne
- Repository
- repræsenteret
- repræsenterer
- anmode
- anmodninger
- kræver
- påkrævet
- krav
- Krav
- Kræver
- ressource
- Ressourcer
- svar
- REST
- resultere
- resulterer
- Resultater
- detail
- afkast
- gennemgå
- Risiko
- roller
- rod
- R
- Herske
- Kør
- kører
- SaaS
- sagemaker
- SageMaker Inference
- løn
- samme
- Gem
- besparelse
- Besparelser
- skalerbar
- Scale
- skalaer
- skalering
- scenarier
- planlægge
- planlagt
- Videnskab
- Videnskabsmand
- Anden
- sekunder
- Sektion
- sektioner
- sikkert
- sikkerhed
- udvælgelse
- valg
- senior
- følsom
- Sequence
- seriel
- Series
- tjener
- Serverless
- Servere
- tjener
- tjeneste
- Tjenester
- servering
- sæt
- indstilling
- flere
- forme
- Del
- delt
- Skift
- bør
- Shows
- signifikant
- betydeligt
- lignende
- Tilsvarende
- Simpelt
- enkelt
- Størrelse
- størrelser
- lille
- mindre
- So
- Software
- løsninger
- Løsninger
- nogle
- Kilder
- Space
- specialist
- specialiserede
- specifikke
- specifikt
- specificeret
- hastighed
- udgifterne
- spikes
- stabil
- stable
- Stakke
- starte
- påbegyndt
- starter
- opstart
- Nystartede
- steady
- Trin
- Steps
- Stadig
- stopper
- opbevaring
- butik
- strategier
- streaming
- Streng
- kraftigt
- efterfølgende
- succes
- vellykket
- sådan
- tilstrækkeligt
- egnede
- support
- Understøttet
- Understøtter
- bølge
- bord
- Tag
- tager
- mål
- målrettet
- Opgaver
- opgaver
- hold
- hold
- TechCrunch
- Teknisk
- Teknologier
- lejer
- tensorflow
- prøve
- Test
- deres
- selv
- derved
- derfor
- tusinder
- tre
- tærskel
- Gennem
- hele
- kapacitet
- tid
- gange
- til
- sammen
- også
- værktøj
- I alt
- TPS
- Sporing
- Trafik
- Tog
- uddannet
- Kurser
- transaktionsbeslutning
- Transaktioner
- Transform
- Transformation
- omdanne
- transit
- gennemsigtig
- udløse
- Triton
- TUR
- typer
- typisk
- typisk
- under
- underliggende
- forstå
- enestående
- enheder
- uforudsigelige
- ubrugt
- Opdatering
- opdateringer
- opgradering
- opgraderet
- oppetid
- Brug
- brug
- brug tilfælde
- Bruger
- brugere
- sædvanligvis
- udnytte
- udnyttet
- VALIDATE
- værdi
- Værdier
- Variant
- forskellige
- via
- video
- Videoer
- Specifikation
- Virtual
- vision
- bind
- Stem
- stemmer
- Affald
- web
- webservices
- uge
- Hvad
- Hvad er
- som
- mens
- bred
- Bred rækkevidde
- vilje
- inden for
- uden
- Arbejde
- arbejdede
- arbejdstager
- arbejdere
- arbejder
- virker
- world
- ville
- XGBoost
- år
- Du
- Din
- zephyrnet
- nul