Maskinlæringsapplikasjoner (ML) er komplekse å distribuere og krever ofte evnen til å hyperskalere, og har ultralave latenskrav og strenge kostnadsbudsjetter. Brukstilfeller som svindeloppdagelse, produktanbefalinger og trafikkanslag er eksempler der millisekunder er viktige og avgjørende for suksess. Strenge servicenivåavtaler (SLAer) må oppfylles, og en typisk forespørsel kan kreve flere trinn som forbehandling, datatransformasjon, funksjonsutvikling, modellvalglogikk, modellaggregering og etterbehandling.
Det kan være en skremmende og tungvint oppgave å distribuere ML-modeller i stor skala med optimert kostnads- og dataeffektivitet. Hver modell har sine egne fordeler og avhengigheter basert på de eksterne datakildene samt kjøretidsmiljø som CPU/GPU-kraften til de underliggende dataressursene. En applikasjon kan kreve flere ML-modeller for å betjene en enkelt slutningsforespørsel. I visse scenarier kan en forespørsel flyte på tvers av flere modeller. Det er ingen enkel tilnærming som passer alle, og det er viktig for ML-utøvere å se etter velprøvde metoder for å møte tilbakevendende ML-vertsutfordringer. Dette har ført til utviklingen av designmønstre for ML-modellhosting.
I dette innlegget utforsker vi vanlige designmønstre for å bygge ML-applikasjoner på Amazon SageMaker.
Designmønstre for å bygge ML-applikasjoner
La oss se på følgende designmønstre som skal brukes for hosting av ML-applikasjoner.
Enkeltmodellbaserte ML-applikasjoner
Dette er et flott alternativ når ML-brukssaken krever en enkelt modell for å betjene en forespørsel. Modellen er distribuert på en dedikert datainfrastruktur med mulighet til å skalere basert på inndatatrafikken. Dette alternativet er også ideelt når klientapplikasjonen har et slutningskrav med lav latens (i størrelsesorden millisekunder eller sekunder).
Multimodellbaserte ML-applikasjoner
For å gjøre hosting mer kostnadseffektivt lar dette designmønsteret deg være vert for flere modeller på samme leietakerinfrastruktur. Flere ML-modeller kan dele verts- eller containerressursene, inkludert bufring av de mest brukte ML-modellene i minnet, noe som resulterer i bedre utnyttelse av minne og dataressurser. Avhengig av typene modeller du velger å distribuere, kan modellsamvert bruke følgende metoder:
- Multi-modell hosting – Dette alternativet lar deg være vert for flere modeller ved å bruke en delt serveringsbeholder på ett enkelt endepunkt. Denne funksjonen er ideell når du har et stort antall lignende modeller som du kan servere gjennom en delt serveringsbeholder og ikke trenger tilgang til alle modellene samtidig.
- Hosting for flere containere – Dette alternativet er ideelt når du har flere modeller som kjører på forskjellige serverstabler med lignende ressursbehov, og når individuelle modeller ikke har tilstrekkelig trafikk til å utnytte hele kapasiteten til endepunktforekomstene. Hosting med flere containere lar deg distribuere flere containere som bruker forskjellige modeller eller rammeverk på ett enkelt endepunkt. Modellene kan være helt heterogene, med sin egen uavhengige serveringsstabel.
- Modellensembler – I mange produksjonstilfeller kan det ofte være mange oppstrømsmodeller som mater input til en gitt nedstrømsmodell. Det er her ensembler er nyttige. Ensemblemønstre innebærer å blande utdata fra en eller flere basismodeller for å redusere generaliseringsfeil av spådommen. Basismodellene kan være mangfoldige og trent av forskjellige algoritmer. Modellensembler kan utkonkurrere enkeltmodeller fordi prediksjonsfeilen til modellen reduseres når ensembletilnærmingen brukes.
Følgende er vanlige brukstilfeller av ensemblemønstre og deres tilsvarende designmønsterdiagrammer:
- Spre-samle – I et scatter-samler-mønster blir en forespørsel om slutning rutet til en rekke modeller. En aggregator brukes deretter til å samle svarene og destillere dem til en enkelt slutningsrespons. For eksempel kan en brukstilfelle for bildeklassifisering bruke tre forskjellige modeller for å utføre oppgaven. Scatter-samler-mønsteret lar deg kombinere resultater fra slutninger som kjøres på tre forskjellige modeller og velge den mest sannsynlige klassifiseringsmodellen.
- Modellaggregat – I et aggregeringsmønster beregnes utdata fra flere modeller gjennomsnitt. For klassifiseringsmodeller blir flere modellers spådommer evaluert for å bestemme klassen som fikk flest stemmer og behandles som den endelige produksjonen av ensemblet. For eksempel, i et klassifiseringsproblem med to klasser for å klassifisere et sett med frukt som appelsiner eller epler, hvis to modeller stemmer for en appelsin og en modell stemmer for et eple, vil den aggregerte produksjonen være en appelsin. Aggregering hjelper til med å bekjempe unøyaktighet i individuelle modeller og gjør utdataene mer nøyaktige.
- Dynamisk utvalg – Et annet mønster for ensemblemodeller er å dynamisk utføre modellvalg for de gitte inngangsattributtene. For eksempel, i en gitt inngang av bilder av frukt, hvis inngangen inneholder en appelsin, vil modell A bli brukt fordi den er spesialisert for appelsiner. Hvis inngangen inneholder et eple, vil modell B bli brukt fordi den er spesialisert for epler.
- Seriell inferens ML-applikasjoner – Med et serielt slutningsmønster, også kjent som en slutningspipeline, har brukstilfeller krav til å forhåndsbehandle innkommende data før man påkaller en forhåndstrent ML-modell for å generere slutninger. I tillegg, i noen tilfeller, kan det hende at de genererte slutningene må behandles videre, slik at de lett kan konsumeres av nedstrømsapplikasjoner. En slutningspipeline lar deg bruke den samme forbehandlingskoden som ble brukt under modelltrening for å behandle slutningsforespørselsdataene som brukes til prediksjoner.
- Forretningslogikk – Å produsere ML innebærer alltid forretningslogikk. Forretningslogikkmønstre involverer alt som er nødvendig for å utføre en ML-oppgave som ikke er ML-modellslutning. Dette inkluderer lasting av modellen fra Amazon enkel lagringstjeneste (Amazon S3), for eksempel databaseoppslag for å validere inndata, hente forhåndsberegnet funksjoner fra funksjonslageret, og så videre. Etter at disse forretningslogikktrinnene er fullført, sendes inngangene til ML-modeller.
ML slutningsalternativer
For modelldistribusjon er det viktig å jobbe bakover fra brukssaken. Hva er frekvensen av prediksjonen? Forventer du live trafikk til applikasjonen din og sanntidsrespons til kundene dine? Har du mange modeller som er trent for forskjellige delmengder av data for samme brukstilfelle? Varierer prediksjonstrafikken? Er latens av slutninger en bekymring? Basert på disse detaljene kan alle de foregående designmønstrene implementeres ved å bruke følgende distribusjonsalternativer:
- Slutning i sanntid – Sanntidsslutning er ideell for inferensarbeidsbelastninger der du har sanntids, interaktive krav med lav latens. Sanntidsarbeidsbelastninger for ML-slutninger kan inkludere en enkeltmodellbasert ML-applikasjon, der en applikasjon krever bare én ML-modell for å betjene en enkelt forespørsel, eller en multimodellbasert ML-applikasjon, der en applikasjon krever flere ML-modeller for å betjene en enkelt be om.
- Nesten sanntids (asynkron) inferens – Med nesten sanntidsslutning kan du sette innkommende forespørsler i kø. Dette kan brukes til å kjøre slutninger på innganger som er hundrevis av MB. Den opererer i nesten sanntid og lar brukere bruke inngangen til slutninger, og lese utdataene fra endepunktet fra en S3-bøtte. Det kan spesielt være nyttig i tilfeller med NLP og datasyn, hvor det er store nyttelaster som krever lengre forbehandlingstider.
- Batch inferens – Batch-inferens kan brukes for å kjøre inferens offline på et stort datasett. Fordi den kjører offline, tilbyr ikke batch-inferens den laveste latensen. Her behandles slutningsforespørselen med enten en planlagt eller hendelsesbasert trigger av en batch slutningsjobb.
- Serverløs slutning – Serverløs inferens er ideell for arbeidsbelastninger som har inaktive perioder mellom trafikkspurtene og kan tolerere noen ekstra sekunders latency (kaldstart) for den første påkallingen etter en inaktiv periode. For eksempel en chatbot-tjeneste eller en applikasjon for å behandle skjemaer eller analysere data fra dokumenter. I dette tilfellet vil du kanskje ha et nettbasert slutningsalternativ som er i stand til automatisk å klargjøre og skalere beregningskapasitet basert på volumet av slutningsforespørsler. Og under inaktiv tid skal den kunne slå av datakapasiteten helt slik at du ikke blir ladet. Serverløs slutning fjerner det udifferensierte tunge løftet ved å velge og administrere servere ved automatisk å starte dataressurser og skalere dem inn og ut avhengig av trafikk.
Bruk treningsfunksjoner for å velge riktig ML-slutningsalternativ
Å bestemme seg for riktig vertsalternativ er viktig fordi det påvirker sluttbrukerne som gjengis av applikasjonene dine. For dette formålet låner vi konseptet treningsfunksjoner, som ble laget av Neal Ford og hans kolleger fra AWS Partner ThoughtWorks i deres arbeid Bygging av evolusjonære arkitekturer. Treningsfunksjoner gir en preskriptiv vurdering av ulike hostingalternativer basert på kundens mål. Treningsfunksjoner hjelper deg å skaffe de nødvendige dataene for å tillate den planlagte utviklingen av arkitekturen din. De setter målbare verdier for å vurdere hvor nær løsningen din er å nå dine fastsatte mål. Treningsfunksjoner kan og bør tilpasses etter hvert som arkitekturen utvikler seg for å veilede en ønsket endringsprosess. Dette gir arkitekter et verktøy for å veilede teamene sine samtidig som teamets autonomi opprettholdes.
Det er fem hovedtreningsfunksjoner som kundene bryr seg om når det gjelder å velge riktig ML-slutningsalternativ for å være vert for deres ML-modeller og -applikasjoner.
Fitness funksjon | Beskrivelse |
Kostnad |
Å distribuere og vedlikeholde en ML-modell og ML-applikasjon på et skalerbart rammeverk er en kritisk forretningsprosess, og kostnadene kan variere sterkt avhengig av valg som er gjort om modellvertsinfrastruktur, vertsalternativ, ML-rammeverk, ML-modellegenskaper, optimaliseringer, skaleringspolicy, og mer. Arbeidsbelastningene må utnytte maskinvareinfrastrukturen optimalt for å sikre at kostnadene holdes i sjakk. Denne treningsfunksjonen refererer spesifikt til infrastrukturkostnaden, som er en del av den totale eierkostnaden (TCO). Infrastrukturkostnadene er de kombinerte kostnadene for lagring, nettverk og databehandling. Det er også viktig å forstå andre komponenter i TCO, inkludert driftskostnader og kostnader for sikkerhet og overholdelse. Driftskostnader er de kombinerte kostnadene ved drift, overvåking og vedlikehold av ML-infrastrukturen. Driftskostnadene beregnes som antall ingeniører som kreves basert på hvert scenario og årslønnen til ingeniører, aggregert over en bestemt periode. Kunder som bruker selvstyrte ML-løsninger på Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), og Amazon Elastic Kubernetes-tjeneste (Amazon EKS) trenger å bygge operativt verktøy selv. Kunder som bruker SageMaker pådrar seg betydelig mindre TCO. SageMaker inference er en fullstendig administrert tjeneste og gir muligheter rett ut av boksen for å distribuere ML-modeller for inferens. Du trenger ikke å klargjøre forekomster, overvåke forekomsthelse, administrere sikkerhetsoppdateringer eller patcher, sende ut operasjonelle beregninger eller bygge overvåking for arbeidsbelastningene dine for ML-slutninger. Den har innebygde muligheter for å sikre høy tilgjengelighet og robusthet. SageMaker støtter sikkerhet med ende-til-ende-kryptering i hvile og under transport, inkludert kryptering av rotvolumet og Amazon Elastic Block Store (Amazon EBS) volum, Amazon Virtual Private Cloud (Amazon VPC) støtte, AWS PrivateLink, kundeadministrerte nøkler, AWS identitets- og tilgangsadministrasjon (IAM) finmasket tilgangskontroll, AWS CloudTrail revisjoner, internodekryptering for opplæring, tag-basert tilgangskontroll, nettverksisolasjon og Interactive Application Proxy. Alle disse sikkerhetsfunksjonene leveres ut av esken i SageMaker, og kan spare bedrifter for titalls utviklingsmåneder med ingeniørarbeid over en 3-års periode. SageMaker er en HIPAA-kvalifisert tjeneste, og er sertifisert under PCI, SOC, GDPR og ISO. SageMaker støtter også FIPS-endepunkter. For mer informasjon om TCO, se De totale eierkostnadene til Amazon SageMaker. |
Inferenslatens | Mange ML-modeller og -applikasjoner er latenstidskritiske, der slutningsforsinkelsen må være innenfor grensene spesifisert av et tjenestenivåmål. Inferensforsinkelse avhenger av en rekke faktorer, inkludert modellstørrelse og kompleksitet, maskinvareplattform, programvaremiljø og nettverksarkitektur. For eksempel kan større og mer komplekse modeller ta lengre tid å kjøre inferens. |
Gjennomstrømning (transaksjoner per sekund) | For modellslutninger er optimalisering av gjennomstrømningen avgjørende for ytelsesinnstilling og oppnåelse av forretningsmålet til ML-applikasjonen. Ettersom vi fortsetter å gå raskt i alle aspekter av ML, inkludert implementeringer på lavt nivå av matematiske operasjoner i brikkedesign, spiller maskinvarespesifikke biblioteker en større rolle i ytelsesoptimalisering. Ulike faktorer som nyttelaststørrelse, nettverkshopp, humlens natur, modellgraffunksjoner, operatører i modellen og CPU-, GPU- og minneprofilen til modellvertsinstansene påvirker gjennomstrømningen til ML-modellen. |
Skaleringskonfigurasjonskompleksitet | Det er avgjørende for ML-modellene eller applikasjonene å kjøre på et skalerbart rammeverk som kan håndtere etterspørselen fra varierende trafikk. Den tillater også maksimal utnyttelse av CPU- og GPU-ressurser og forhindrer overforsyning av dataressurser. |
Forventet trafikkmønster | ML-modeller eller -applikasjoner kan ha forskjellige trafikkmønstre, alt fra kontinuerlig sanntids live trafikk til periodiske topper på tusenvis av forespørsler per sekund, og fra sjeldne, uforutsigbare forespørselsmønstre til offline batchforespørsler på større datasett. Det anbefales å jobbe bakover fra det forventede trafikkmønsteret for å velge riktig vertsalternativ for ML-modellen din. |
Utrulling av modeller med SageMaker
SageMaker er en fullt administrert AWS-tjeneste som gir alle utviklere og dataforskere muligheten til raskt å bygge, trene og distribuere ML-modeller i stor skala. Med SageMaker inference kan du distribuere ML-modellene dine på vertsbaserte endepunkter og få slutningsresultater. SageMaker tilbyr et bredt utvalg av maskinvare og funksjoner for å møte arbeidsbelastningskravene dine, slik at du kan velge over 70 forekomsttyper med maskinvareakselerasjon. SageMaker kan også gi anbefaling av inferensforekomsttype ved å bruke en ny funksjon kalt SageMaker Inference Recommender, i tilfelle du ikke er sikker på hvilken som vil være mest optimal for arbeidsmengden din.
Du kan velge distribusjonsalternativer for best mulig å møte dine brukstilfeller, for eksempel sanntidsslutninger, asynkrone, batch- og til og med serverløse endepunkter. I tillegg tilbyr SageMaker ulike distribusjonsstrategier som kanarifugl, blå grønn, skygge, og A/B-testing for modelldistribusjon, sammen med kostnadseffektiv distribusjon med multi-modell, multi-container endepunkter og elastisk skalering. Med SageMaker-inferens kan du se ytelsesberegningene for endepunktene dine i Amazon CloudWatch, automatisk skaler endepunkter basert på trafikk, og oppdater modellene dine i produksjon uten å miste noen tilgjengelighet.
SageMaker tilbyr fire alternativer for å distribuere modellen din slik at du kan begynne å lage spådommer:
- Slutning i sanntid – Dette er egnet for arbeidsbelastninger med millisekunders latenskrav, nyttelaststørrelser på opptil 6 MB og behandlingstider på opptil 60 sekunder.
- Batchtransformasjon – Dette er ideelt for offline spådommer på store mengder data som er tilgjengelig på forhånd.
- Asynkron slutning – Dette er designet for arbeidsbelastninger som ikke har krav til forsinkelser på under sekunder, nyttelaststørrelser på opptil 1 GB og behandlingstider på opptil 15 minutter.
- Serverløs slutning – Med serverløs inferens kan du raskt distribuere ML-modeller for inferens uten å måtte konfigurere eller administrere den underliggende infrastrukturen. I tillegg betaler du kun for beregningskapasiteten som brukes til å behandle slutningsforespørsler, som er ideell for periodiske arbeidsbelastninger.
Det følgende diagrammet kan hjelpe deg med å forstå utplasseringsalternativene for SageMaker-vertsmodellen sammen med de tilhørende evalueringene av treningsfunksjoner.
La oss utforske hvert av distribusjonsalternativene mer detaljert.
Sanntidsslutning i SageMaker
SageMaker sanntidsslutning anbefales hvis du har vedvarende trafikk og trenger lavere og konsekvent ventetid for forespørslene dine med nyttelaststørrelser på opptil 6 MB og behandlingstider på opptil 60 sekunder. Du distribuerer modellen din til SageMaker-vertstjenester og får et endepunkt som kan brukes til slutninger. Disse endepunktene er fullstendig administrert og støtter automatisk skalering. Sanntidsslutning er populært for brukstilfeller der du forventer en lav latens, synkron respons med forutsigbare trafikkmønstre, for eksempel personlig tilpassede anbefalinger for produkter og tjenester eller brukstilfeller for oppdagelse av transaksjonssvindel.
Vanligvis sender en klientapplikasjon forespørsler til SageMaker HTTPS-endepunktet for å få slutninger fra en distribuert modell. Du kan distribuere flere varianter av en modell til samme SageMaker HTTPS-endepunkt. Dette er nyttig for å teste varianter av en modell i produksjon. Automatisk skalering lar deg dynamisk justere antallet forekomster som er klargjort for en modell som svar på endringer i arbeidsmengden din.
Følgende tabell gir veiledning for å evaluere SageMaker sanntidsslutning basert på treningsfunksjonene.
Fitness funksjon | Beskrivelse |
Kostnad |
Sanntidsendepunkter tilbyr synkron respons på slutningsforespørsler. Fordi endepunktet alltid kjører og er tilgjengelig for å gi sanntids synkron inferensrespons, betaler du for å bruke forekomsten. Kostnadene kan raskt øke når du distribuerer flere endepunkter, spesielt hvis endepunktene ikke fullt ut utnytter de underliggende forekomstene. Å velge riktig forekomst for modellen din bidrar til å sikre at du har den mest effektive forekomsten til den laveste kostnaden for modellene dine. Automatisk skalering anbefales for å dynamisk justere kapasiteten avhengig av trafikk for å opprettholde jevn og forutsigbar ytelse til lavest mulig kostnad. SageMaker utvider tilgangen til Graviton2- og Graviton3-baserte ML-forekomstfamilier. AWS Graviton prosessorer er spesialbygd av Amazon Web Services ved å bruke 64-bits Arm Neoverse-kjerner for å levere den beste prisytelsen for dine skyarbeidsbelastninger som kjører på Amazon EC2. Med Graviton-baserte forekomster har du flere muligheter for å optimalisere kostnadene og ytelsen når du distribuerer ML-modellene dine på SageMaker. SageMaker støtter også Inf1-forekomster, som gir høy ytelse og kostnadseffektiv ML-slutning. Med 1–16 AWS Inferentia-brikker per instans kan Inf1-instanser skalere i ytelse og levere opptil tre ganger høyere gjennomstrømning og opptil 50 % lavere kostnad per slutning sammenlignet med AWS GPU-baserte instanser. For å bruke Inf1-forekomster i SageMaker, kan du kompilere dine trente modeller ved hjelp av Amazon SageMaker Neo og velg Inf1-forekomstene for å distribuere den kompilerte modellen på SageMaker. Du kan også utforske Spareplaner for SageMaker å dra nytte av kostnadsbesparelser på opptil 64 % sammenlignet med bestillingsprisen. Når du oppretter et endepunkt, knytter SageMaker et EBS-lagringsvolum til hver ML-beregningsforekomst som er vert for endepunktet. Størrelsen på lagringsvolumet avhenger av instanstypen. Ekstra kostnader for sanntidsendepunkter inkluderer kostnaden for GB-måned med klargjort lagring, pluss GB-data behandlet i og GB-data behandlet ut av endepunktforekomsten. |
Inferenslatens | Sanntidsslutning er ideell når du trenger et vedvarende endepunkt med millisekunders latenskrav. Den støtter nyttelaststørrelser på opptil 6 MB, og behandlingstider på opptil 60 sekunder. |
gjennomstrømming |
En ideell verdi for inferensgjennomstrømning er subjektiv til faktorer som modell, modellinndatastørrelse, batchstørrelse og endepunktforekomsttype. Som en beste praksis, se gjennom CloudWatch-beregninger for inputforespørsler og ressursutnyttelse, og velg riktig forekomsttype for å oppnå optimal gjennomstrømning. En forretningsapplikasjon kan enten være optimalisert for gjennomstrømning eller ventetid. For eksempel kan dynamisk batching bidra til å øke gjennomstrømningen for latenssensitive apper ved å bruke sanntidsslutning. Det er imidlertid grenser for batchstørrelse, uten hvilke inferensforsinkelsen kan bli påvirket. Inferenslatens vil vokse etter hvert som du øker batchstørrelsen for å forbedre gjennomstrømningen. Derfor er sanntidsslutning et ideelt alternativ for ventetid-sensitive applikasjoner. SageMaker tilbyr alternativer for asynkron inferens og batch-transformasjon, som er optimalisert for å gi høyere gjennomstrømning sammenlignet med sanntidsslutning hvis forretningsapplikasjonene tåler en litt høyere latens. |
Skaleringskonfigurasjonskompleksitet |
SageMaker sanntids endepunkter støtte automatisk skalering ut av boksen. Når arbeidsmengden øker, bringer automatisk skalering flere forekomster online. Når arbeidsmengden reduseres, fjerner automatisk skalering unødvendige forekomster, og hjelper deg med å redusere beregningskostnadene. Uten automatisk skalering må du sørge for høytrafikk eller utilgjengelighet av risikomodeller. Med mindre trafikken til modellen din er jevn gjennom dagen, vil det være overflødig ubrukt kapasitet. Dette fører til lav utnyttelse og bortkastede ressurser. Med SageMaker kan du konfigurere forskjellige skaleringsalternativer basert på forventet trafikkmønster. Enkel skalering eller målsporingsskalering er ideell når du ønsker å skalere basert på en spesifikk CloudWatch-beregning. Du kan gjøre dette ved å velge en spesifikk beregning og angi terskelverdier. De anbefalte beregningene for dette alternativet er gjennomsnittlige Hvis du trenger avansert konfigurasjon, kan du angi en trinnskaleringspolicy for dynamisk å justere antall forekomster som skal skaleres basert på størrelsen på alarmbruddet. Dette hjelper deg med å konfigurere en mer aggressiv respons når etterspørselen når et visst nivå. Du kan bruke et planlagt skaleringsalternativ når du vet at etterspørselen følger en bestemt tidsplan på dagen, uken, måneden eller året. Dette hjelper deg med å spesifisere en engangsplan eller en tilbakevendende tidsplan eller cron-uttrykk sammen med start- og sluttider, som danner grensene for når den automatiske skaleringshandlingen starter og stopper. For mer informasjon, se Konfigurering av autoskalering av slutningsendepunkter i Amazon SageMaker og Last test og optimaliser et Amazon SageMaker-endepunkt ved hjelp av automatisk skalering. |
Trafikkmønster | Sanntidsslutning er ideell for arbeidsbelastninger med et kontinuerlig eller vanlig trafikkmønster. |
Asynkron slutning i SageMaker
SageMaker asynkron inferens er en ny funksjon i SageMaker som setter innkommende forespørsler i kø og behandler dem asynkront. Dette alternativet er ideelt for forespørsler med store nyttelaststørrelser (opptil 1 GB), lange behandlingstider (opptil 15 minutter) og krav til ventetid nesten i sanntid. Eksempler på arbeidsbelastninger for asynkron slutning inkluderer helseselskaper som behandler høyoppløselige biomedisinske bilder eller videoer som ekkokardiogrammer for å oppdage anomalier. Disse applikasjonene mottar støt med innkommende trafikk til forskjellige tider på dagen og krever behandling i nesten sanntid til lave kostnader. Behandlingstiden for disse forespørslene kan variere i størrelsesorden minutter, noe som eliminerer behovet for å kjøre sanntidsslutning. I stedet kan input-nyttelast behandles asynkront fra et objektlager som Amazon S3 med automatisk kø og en forhåndsdefinert samtidighetsterskel. Ved behandling plasserer SageMaker slutningsresponsen på den tidligere returnerte Amazon S3-posisjonen. Du kan valgfritt velge å motta suksess- eller feilmeldinger via Amazon enkel varslingstjeneste (Amazon SNS).
Følgende tabell gir veiledning om evaluering av SageMaker asynkron inferens basert på treningsfunksjonene.
Fitness funksjon | Beskrivelse |
Kostnad | Asynkron inferens er et godt valg for kostnadssensitive arbeidsbelastninger med stor nyttelast og burst-trafikk. Asynkron inferens lar deg spare kostnader ved å automatisk skalere forekomsttellingen til null når det ikke er noen forespørsler å behandle, slik at du bare betaler når endepunktet ditt behandler forespørsler. Forespørsler som mottas når det er null forekomster, står i kø for behandling etter at endepunktet skaleres opp. |
Inferenslatens | Asynkron inferens er ideell for ventetid i nesten sanntid. Forespørslene plasseres i en kø og behandles så snart beregningen er tilgjengelig. Dette resulterer vanligvis i titalls millisekunder i ventetid. |
gjennomstrømming | Asynkron slutning er ideell for ikke-latenssensitive brukstilfeller, fordi applikasjoner ikke trenger å gå på akkord med gjennomstrømming. Forespørsler blir ikke droppet under trafikkøkninger fordi det asynkrone slutningspunktet setter forespørsler i kø i stedet for å droppe dem. |
Skaleringskonfigurasjonskompleksitet |
SageMaker støtter automatisk skalering for asynkront endepunkt. I motsetning til vertsbaserte endepunkter i sanntid, støtter asynkrone inferensendepunkter nedskalering av forekomster til null ved å sette minimumskapasiteten til null. For asynkrone endepunkter anbefaler SageMaker på det sterkeste at du oppretter en policykonfigurasjon for målsporingsskalering for en distribuert modell (variant). For brukstilfeller som tåler en kaldstartstraff på noen få minutter, kan du valgfritt nedskalere endepunktforekomsttellingen til null når det ikke er utestående forespørsler og skalere opp etter hvert som nye forespørsler kommer, slik at du kun betaler for varigheten som endepunkter behandler forespørsler aktivt. |
Trafikkmønster | Asynkrone endepunkter setter innkommende forespørsler i kø og behandler dem asynkront. De er et godt alternativ for periodiske eller sjeldne trafikkmønstre. |
Batch-inferens i SageMaker
SageMaker batch-transformasjon er ideell for offline spådommer på store mengder data som er tilgjengelig på forhånd. Batch-transformeringsfunksjonen er en metode med høy ytelse og høy gjennomstrømning for å transformere data og generere slutninger. Den er ideell for scenarier der du har å gjøre med store mengder data, ikke trenger sekundvis ventetid, eller trenger å både forhåndsbehandle og transformere treningsdataene. Kunder i visse domener som reklame og markedsføring eller helsetjenester trenger ofte å lage offline spådommer på hyperskala datasett der høy gjennomstrømning ofte er målet for brukstilfellet og latenstid ikke er en bekymring.
Når en batch-transformeringsjobb starter, initialiserer SageMaker beregningsforekomster og fordeler slutningsarbeidsbelastningen mellom dem. Den frigjør ressursene når jobbene er fullførte, slik at du kun betaler for det som ble brukt under arbeidet. Når jobben er fullført, lagrer SageMaker prediksjonsresultatene i en S3-bøtte som du spesifiserer. Batch-inferensoppgaver er vanligvis gode kandidater for horisontal skalering. Hver arbeidstaker i en klynge kan operere på et annet delsett av data uten å måtte utveksle informasjon med andre arbeidere. AWS tilbyr flere lagrings- og beregningsalternativer som muliggjør horisontal skalering. Eksempler på arbeidsbelastninger for SageMaker batch-transformasjon inkluderer offline-applikasjoner som bankapplikasjoner for å forutsi kundefragang der en frakoblet jobb kan planlegges til å kjøre med jevne mellomrom.
Følgende tabell gir veiledning for evaluering av SageMaker batch-transformasjon basert på treningsfunksjonene.
Fitness funksjon | Beskrivelse |
Kostnad | SageMaker batch-transformasjon lar deg kjøre spådommer på store eller små batch-datasett. Du belastes for forekomsttypen du velger, basert på bruksvarigheten. SageMaker administrerer tilførselen av ressurser ved starten av jobben og frigir dem når jobben er fullført. Det er ingen ekstra databehandlingskostnader. |
Inferenslatens | Du kan bruke hendelsesbasert eller planlagt påkalling. Latens kan variere avhengig av størrelsen på slutningsdata, samtidighet på jobben, kompleksiteten til modellen og dataforekomstkapasitet. |
gjennomstrømming |
Batch-transformeringsjobber kan gjøres på en rekke datasett, fra petabyte med data til svært små datasett. Det er ikke nødvendig å endre størrelse på større datasett til små databiter. Du kan øke hastigheten på batch-transformeringsjobber ved å bruke optimale verdier for parametere som f.eks MaxPayloadInMB, MaxConcurrentTransformseller Batchstrategi. Den ideelle verdien for Batchbehandling kan øke gjennomstrømmingen og optimere ressursene dine fordi den hjelper til med å fullføre et større antall slutninger på en viss tid på bekostning av latens. For å optimalisere modelldistribusjon for høyere gjennomstrømning, er den generelle retningslinjen å øke batchstørrelsen til gjennomstrømningen avtar. |
Skaleringskonfigurasjonskompleksitet | SageMaker batch-transformasjon brukes for offline slutninger som ikke er latenssensitive. |
Trafikkmønster | For frakoblet slutning planlegges eller startes en batchtransformasjonsjobb ved å bruke en hendelsesbasert utløser. |
Serverløs slutning i SageMaker
SageMaker serverløs inferens lar deg distribuere ML-modeller for inferens uten å måtte konfigurere eller administrere den underliggende infrastrukturen. Basert på volumet av slutningsforespørsler modellen din mottar, vil SageMaker serverløs slutning automatisk klargjøre, skalere og slå av datakapasitet. Som et resultat betaler du kun for beregningstiden for å kjøre slutningskoden og mengden data som behandles, ikke for inaktiv tid. Du kan bruke SageMakers innebygde algoritmer og ML-rammeverksserverende containere for å distribuere modellen til et serverløst sluttpunkt eller velge å ta med din egen container. Hvis trafikken blir forutsigbar og stabil, kan du enkelt oppdatere fra et serverløst sluttpunkt til et SageMaker sanntidsendepunkt uten å måtte gjøre endringer i containerbildet ditt. Med serverløs slutning drar du også nytte av andre SageMaker-funksjoner, inkludert innebygde beregninger som antall påkallinger, feil, latens, vertsmålinger og feil i CloudWatch.
Følgende tabell gir veiledning for evaluering av SageMaker serverløs slutning basert på treningsfunksjonene.
Fitness funksjon | Beskrivelse |
Kostnad | Med en betal-som-du-kjør-modell er serverløs slutning et kostnadseffektivt alternativ hvis du har sjeldne eller intermitterende trafikkmønstre. Du betaler kun for varigheten som endepunktet behandler forespørselen, og kan derfor spare kostnader hvis trafikkmønsteret er periodisk. |
Inferenslatens |
Serverløse endepunkter tilbyr lav slutningsforsinkelse (i størrelsesorden millisekunder til sekunder), med muligheten til å skalere øyeblikkelig fra titalls til tusenvis av slutninger i løpet av sekunder basert på bruksmønstrene, noe som gjør den ideell for ML-applikasjoner med intermitterende eller uforutsigbar trafikk. Fordi serverløse endepunkter leverer dataressurser på forespørsel, kan endepunktet ditt oppleve noen ekstra sekunders forsinkelse (kaldstart) for den første påkallingen etter en inaktiv periode. Kaldstarttiden avhenger av modellstørrelsen din, hvor lang tid det tar å laste ned modellen og oppstartstiden for beholderen. |
gjennomstrømming | Når du konfigurerer det serverløse endepunktet ditt, kan du spesifisere minnestørrelsen og maksimalt antall samtidige påkallinger. SageMaker serverløs inferens tildeler automatisk dataressurser proporsjonalt med minnet du velger. Hvis du velger en større minnestørrelse, har beholderen tilgang til flere vCPUer. Som en generell regel bør minnestørrelsen være minst like stor som modellstørrelsen din. Minnestørrelsene du kan velge er 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB og 6144 MB. Uavhengig av minnestørrelsen du velger, har serverløse endepunkter 5 GB flyktig disklagring tilgjengelig. |
Skaleringskonfigurasjonskompleksitet | Serverløse endepunkter starter automatisk dataressurser og skalerer dem inn og ut avhengig av trafikk, og eliminerer behovet for å velge forekomsttyper eller administrere skaleringspolicyer. Dette tar bort de udifferensierte tunge løftene ved å velge og administrere servere. |
Trafikkmønster | Serverløs slutning er ideell for arbeidsbelastninger med sjeldne eller intermitterende trafikkmønstre. |
Modellvertsdesignmønstre i SageMaker
SageMaker inferensendepunkter bruker Docker-beholdere for å være vert for ML-modeller. Containere lar deg pakke programvare inn i standardiserte enheter som kjører konsekvent på alle plattformer som støtter Docker. Dette sikrer portabilitet på tvers av plattformer, uforanderlig infrastrukturimplementering og enklere endringsadministrasjon og CI/CD-implementeringer. SageMaker tilbyr forhåndsbygde administrerte beholdere for populære rammeverk som Apache MXNet, TensorFlow, PyTorch, Sklearn og Hugging Face. For en fullstendig liste over tilgjengelige SageMaker-beholderbilder, se Tilgjengelige bilder av Deep Learning Containers. I tilfelle SageMaker ikke har en støttet container, kan du også bygge din egen container (BYOC) og pushe ditt eget tilpassede bilde, installere avhengighetene som er nødvendige for modellen din.
For å distribuere en modell på SageMaker trenger du en beholder (SageMaker-administrerte rammeverksbeholdere eller BYOC) og en dataforekomst som vert for beholderen. SageMaker støtter flere avanserte alternativer for vanlige ML-modellvertsdesignmønstre der modellene kan hostes på en enkelt container eller co-hostes på en delt container.
En ML-applikasjon i sanntid kan bruke en enkelt modell eller flere modeller for å betjene en enkelt prediksjonsforespørsel. Følgende diagram viser ulike slutningsscenarier for en ML-applikasjon.
La oss utforske et passende SageMaker-vertsalternativ for hvert av de foregående slutningsscenariene. Du kan referere til treningsfunksjonene for å vurdere om det er det riktige alternativet for den gitte brukssaken.
Hosting av en enkeltmodellbasert ML-applikasjon
Det er flere alternativer for å være vert for enkeltmodellbaserte ML-applikasjoner som bruker SageMaker-vertstjenester, avhengig av distribusjonsscenariet.
Endepunkt for én modell
SageMaker-endepunkter for én modell lar deg være vert for én modell på en container som er vert for dedikerte forekomster for lav ventetid og høy gjennomstrømning. Disse endepunktene er fullstendig administrert og støtter automatisk skalering. Du kan konfigurere enkeltmodellendepunktet som et klargjort endepunkt der du sender inn endepunktinfrastrukturkonfigurasjon som forekomsttype og antall, eller et serverløst endepunkt der SageMaker automatisk starter dataressurser og skalerer dem inn og ut avhengig av trafikk, og eliminerer behovet for å velge forekomsttyper eller administrere skaleringspolicyer. Serverløse endepunkter er for applikasjoner med intermitterende eller uforutsigbar trafikk.
Følgende diagram viser endepunktsscenarier med én modell.
Følgende tabell gir veiledning om evaluering av kondisjonsfunksjoner for et klargjort enkeltmodellendepunkt. For evalueringer av serverløse endepunkttreningsfunksjoner, se delen om serverløse endepunkt i dette innlegget.
Fitness funksjon | Beskrivelse |
Kostnad | Du belastes for bruk av forekomsttypen du velger. Fordi endepunktet alltid kjører og er tilgjengelig, kan kostnadene raskt øke. Å velge riktig forekomst for modellen din bidrar til å sikre at du har den mest effektive forekomsten til den laveste kostnaden for modellene dine. Automatisk skalering anbefales for å dynamisk justere kapasiteten avhengig av trafikk for å opprettholde jevn og forutsigbar ytelse til lavest mulig kostnad. |
Inferenslatens | Et endepunkt med én modell gir interaktiv, synkron slutning i sanntid med millisekunders latenskrav. |
gjennomstrømming | Gjennomstrømning kan påvirkes av ulike faktorer, for eksempel modellinndatastørrelse, batchstørrelse, endepunktforekomsttype og så videre. Det anbefales å gjennomgå CloudWatch-beregninger for inputforespørsler og ressursutnyttelse, og velge riktig forekomsttype for å oppnå optimal gjennomstrømning. SageMaker tilbyr funksjoner for å administrere ressurser og optimalisere slutningsytelse ved distribusjon av ML-modeller. Du kan optimalisere modellytelsen ved å bruke Neo, eller bruk Inf1-forekomster for bedre gjennomstrømning av dine SageMaker-vertsbaserte modeller ved å bruke en GPU-forekomst for endepunktet ditt. |
Skaleringskonfigurasjonskompleksitet | Automatisk skalering støttes ut av esken. SageMaker anbefaler å velge en passende skaleringskonfigurasjon ved å opptre belastningstester. |
Trafikkmønster | Et endepunkt med én modell er ideelt for arbeidsbelastninger med forutsigbare trafikkmønstre. |
Samvært for flere modeller
Når du har å gjøre med et stort antall modeller, kan distribusjon av hver enkelt på et individuelt endepunkt med en dedikert beholder og instans resultere i en betydelig kostnadsøkning. I tillegg blir det også vanskelig å administrere så mange modeller i produksjon, spesielt når du ikke trenger å påkalle alle modellene samtidig, men fortsatt trenger at de er tilgjengelige til enhver tid. Å være vertskap for flere modeller på de samme underliggende dataressursene gjør det enkelt å administrere ML-implementeringer i stor skala og reduserer vertskostnadene dine gjennom økt bruk av endepunktet og dets underliggende databehandlingsressurser. SageMaker støtter avanserte modell co-hosting alternativer som multi-model endpoint (MME) for homogene modeller og multi-container endpoint (MCE) for heterogene modeller. Homogene modeller bruker det samme ML-rammeverket på en delt tjenestebeholder, mens heterogene modeller lar deg distribuere flere serveringsbeholdere som bruker forskjellige modeller eller rammeverk på et enkelt endepunkt.
Følgende diagram viser alternativer for samvertsmodeller ved bruk av SageMaker.
SageMaker multi-modell endepunkter
SageMaker MMEer lar deg være vert for flere modeller ved å bruke en delt serveringsbeholder på ett enkelt endepunkt. Dette er en skalerbar og kostnadseffektiv løsning for å distribuere et stort antall modeller som imøtekommer samme brukstilfelle, rammeverk eller slutningslogikk. MMEer kan dynamisk betjene forespørsler basert på modellen som kalles opp. Det reduserer også distribusjonskostnader fordi SageMaker administrerer lasting av modeller i minnet og skalerer dem basert på trafikkmønstrene til dem. Denne funksjonen er ideell når du har et stort antall lignende modeller som du kan servere gjennom en delt serveringsbeholder og ikke trenger tilgang til alle modellene samtidig. Multi-modell endepunkter muliggjør også tidsdeling av minneressurser på tvers av modellene dine. Dette fungerer best når modellene er ganske like i størrelse og påkallingsforsinkelse, slik at MME-er effektivt kan bruke forekomstene på tvers av alle modeller. SageMaker MME-er støtter hosting av både CPU- og GPU-støttede modeller. Ved å bruke GPU-støttede modeller kan du redusere kostnadene for modelldistribusjon gjennom økt bruk av endepunktet og dets underliggende akselererte databehandlingsforekomster. For en reell brukstilfelle av MMEer, se Hvordan skalere maskinlæringsslutning for SaaS-brukstilfeller med flere leietakere.
Tabellen nedenfor gir veiledning om evaluering av treningsfunksjonene for MME-er.
Fitness funksjon | Beskrivelse |
Kostnad |
MME-er gjør det mulig å bruke en delt serveringsbeholder for å være vert for tusenvis av modeller på ett enkelt endepunkt. Dette reduserer hostingkostnadene betydelig ved å forbedre endepunktutnyttelsen sammenlignet med bruk av enkeltmodellendepunkter. Hvis du for eksempel har 10 modeller å distribuere ved å bruke en ml.c5.large-forekomst, basert på SageMaker-priser, er kostnaden for å ha 10 enkeltmodell vedvarende endepunkter: 10 * $0.102 = $1.02 per time. Mens med en MME som er vert for de 10 modellene, oppnår vi 10 ganger kostnadsbesparelser: 1 * $0.102 = $0.102 per time. |
Inferenslatens |
Som standard cacher MME-er ofte brukte modeller i minnet og på disken for å gi slutninger med lav latens. De bufrede modellene lastes ut eller slettes fra disken bare når en beholder går tom for minne eller diskplass for å få plass til en nylig målrettet modell. MMEer tillater lat lasting av modeller, noe som betyr at modeller lastes inn i minnet når de startes for første gang. Dette optimerer minneutnyttelsen; det forårsaker imidlertid responstidstopper ved første lasting, noe som resulterer i et kaldstartproblem. Derfor er MME-er også godt egnet for scenarier som kan tolerere sporadiske kaldstartrelaterte latensstraff som oppstår når man påkaller sjelden brukte modeller. For å møte latens- og gjennomstrømningsmålene til ML-applikasjoner, foretrekkes GPU-forekomster fremfor CPU-forekomster (gitt GPU-er med beregningskraft). Med MME-støtte for GPU kan du distribuere tusenvis av dyplæringsmodeller bak ett SageMaker-endepunkt. MME-er kan kjøre flere modeller på en GPU-kjerne, dele GPU-forekomster bak et endepunkt på tvers av flere modeller, og dynamisk laste og losse modeller basert på den innkommende trafikken. Med dette kan du spare betydelige kostnader og oppnå den beste prisytelsen. Hvis din brukstilfelle krever betydelig høyere transaksjoner per sekund (TPS) eller latenskrav, anbefaler vi å være vert for modellene på dedikerte endepunkter. |
gjennomstrømming |
En ideell verdi for MME-inferensgjennomstrømning avhenger av faktorer som modell, nyttelaststørrelse og endepunktforekomsttype. En større mengde forekomstminne gjør at du kan ha flere modeller lastet og klare til å betjene slutningsforespørsler. Du trenger ikke å kaste bort tid på å laste modellen. En høyere mengde vCPU-er gjør at du kan påkalle flere unike modeller samtidig. MME-er laster og laster ut modellen dynamisk til og fra instansminne, noe som kan påvirke I/O-ytelsen. SageMaker MMEer med GPU fungerer ved hjelp av NVIDIA Triton Inference Server, som er en åpen kildekode-programvare for slutningsvisning som forenkler slutningsserveringsprosessen og gir høy slutningsytelse. SageMaker laster modellen til NVIDIA Triton-beholderens minne på en GPU-akselerert forekomst og betjener slutningsforespørselen. GPU-kjernen deles av alle modellene i en instans. Hvis modellen allerede er lastet inn i containerminnet, blir de påfølgende forespørslene servert raskere fordi SageMaker ikke trenger å laste den ned og laste den på nytt. En skikkelig ytelsestesting og analyse anbefales ved vellykkede produksjonsinstallasjoner. SageMaker gir CloudWatch-beregninger for endepunkter med flere modeller, slik at du kan bestemme endepunktbruken og hurtigbufferens trefffrekvens for å optimalisere endepunktet ditt. |
Skaleringskonfigurasjonskompleksitet | SageMaker multi-modell endepunkter støtter fullt ut automatisk skalering, som administrerer kopier av modeller for å sikre at modellene skaleres basert på trafikkmønstre. En skikkelig belastningstesting anbefales imidlertid for å bestemme den optimale størrelsen på forekomstene for automatisk skalering av endepunktet. Riktig dimensjonering av MME-flåten er viktig for å unngå at for mange modeller losses. Lasting av hundrevis av modeller på noen få større instanser kan føre til struping i noen tilfeller, og bruk av flere og mindre instanser kan være å foretrekke. For å dra nytte av automatisert modellskalering i SageMaker, sørg for at du har forekomst automatisk skalering satt opp å skaffe ekstra instanskapasitet. Konfigurer skaleringspolicyen på endepunktnivå med enten egendefinerte parametere eller påkallinger per minutt (anbefalt) for å legge til flere forekomster til endepunktflåten. Anropshastighetene som brukes til å utløse en automatisk skaleringshendelse er basert på det samlede settet med spådommer på tvers av hele settet med modeller som betjenes av endepunktet. |
Trafikkmønster | MME-er er ideelle når du har et stort antall modeller av lignende størrelse som du kan servere gjennom en delt serveringsbeholder og ikke trenger tilgang til alle modellene samtidig. |
SageMaker multi-beholder endepunkter
SageMaker MCE-er støtter distribusjon av opptil 15 containere som bruker forskjellige modeller eller rammeverk på ett enkelt endepunkt, og påkaller dem uavhengig eller i rekkefølge for slutninger med lav latens og kostnadsbesparelser. Modellene kan være helt heterogene, med sin egen uavhengige serveringsstabel. Sikker vert for flere modeller fra forskjellige rammeverk på en enkelt forekomst kan spare deg for opptil 90 % i kostnader.
MCE-anropsmønstrene er som følger:
- Inferensrørledninger – Beholdere i en MME kan påkalles i en lineær sekvens, også kjent som en seriell inferensrørledning. De brukes vanligvis til å skille forbehandling, modellslutning og etterbehandling i uavhengige beholdere. Utdata fra gjeldende beholder sendes som input til neste. De er representert som en enkelt pipeline-modell i SageMaker. En inferensrørledning kan distribueres som en MME, der en av beholderne i rørledningen dynamisk kan betjene forespørsler basert på modellen som påkalles.
- Direkte påkalling - Med direkte påkalling, kan en forespørsel sendes til en spesifikk slutningsbeholder som er vert for en MCE.
Følgende tabell gir veiledning om evaluering av treningsfunksjonene for MCE-er.
Fitness funksjon | Beskrivelse |
Kostnad | MCEer lar deg kjøre opptil 15 forskjellige ML-beholdere på ett enkelt endepunkt og påkalle dem uavhengig, og dermed spare kostnader. Dette alternativet er ideelt når du har flere modeller som kjører på forskjellige serverstabler med lignende ressursbehov, og når individuelle modeller ikke har tilstrekkelig trafikk til å utnytte hele kapasiteten til endepunktforekomstene. MCE-er er derfor mer kostnadseffektive enn et endepunkt med én modell. MCE-er tilbyr synkron inferensrespons, noe som betyr at endepunktet alltid er tilgjengelig og du betaler for oppetiden til forekomsten. Kostnadene kan øke avhengig av antall og type forekomster. |
Inferenslatens | MCE-er er ideelle for å kjøre ML-apper med forskjellige ML-rammeverk og algoritmer for hver modell som brukes sjelden, men som fortsatt krever inferens med lav latens. Modellene er alltid tilgjengelige for slutninger med lav latens, og det er ingen kaldstartproblem. |
gjennomstrømming | MCE-er er begrenset til opptil 15 beholdere på et endepunkt med flere beholdere, og GPU-inferens støttes ikke på grunn av ressursstrid. For endepunkter med flere beholdere som bruker direkte anropsmodus, gir SageMaker ikke bare beregninger på instansnivå som med andre vanlige endepunkter, men støtter også beregninger per beholder. Som en beste praksis, se gjennom CloudWatch-beregninger for inputforespørsler og ressursutnyttelse, og velg passende forekomsttype for å oppnå optimal gjennomstrømning. |
Skaleringskonfigurasjonskompleksitet | MCE-er støtter automatisk skalering. For å konfigurere automatisk skalering anbefales det imidlertid at modellen i hver beholder viser lik CPU-utnyttelse og latens på hver slutningsforespørsel. Dette anbefales fordi hvis trafikken til multibeholderendepunktet skifter fra en modell med lav CPU-bruk til en modell med høy CPU-bruk, men det totale anropsvolumet forblir det samme, skaleres ikke endepunktet ut, og det kan hende at det ikke er nok forekomster å håndtere alle forespørsler til modellen med høy CPU-utnyttelse. |
Trafikkmønster | MCE-er er ideelle for arbeidsbelastninger med kontinuerlige eller vanlige trafikkmønstre, for hosting av modeller på tvers av forskjellige rammeverk (som TensorFlow, PyTorch eller Sklearn) som kanskje ikke har tilstrekkelig trafikk til å mette hele kapasiteten til en endepunktforekomst. |
Hosting av en multimodellbasert ML-applikasjon
Mange forretningsapplikasjoner må bruke flere ML-modeller for å levere en enkelt prediksjonsforespørsel til sine forbrukere. For eksempel et detaljhandelsselskap som ønsker å gi anbefalinger til sine brukere. ML-applikasjonen i dette tilfellet vil kanskje bruke forskjellige tilpassede modeller for å anbefale forskjellige produktkategorier. Hvis selskapet ønsker å legge til personalisering i anbefalingene ved å bruke individuell brukerinformasjon, øker antallet tilpassede modeller ytterligere. Å være vert for hver tilpassede modell på en distinkt beregningsforekomst er ikke bare uoverkommelig, men fører også til underutnyttelse av vertsressursene hvis ikke alle modellene brukes ofte. SageMaker tilbyr effektive hostingalternativer for multimodellbaserte ML-applikasjoner.
Følgende diagram viser vertsalternativer for flere modeller for et enkelt endepunkt ved bruk av SageMaker.
Seriell inferensrørledning
En slutningspipeline er en SageMaker-modell som er sammensatt av en lineær sekvens på 2–15 beholdere som behandler forespørsler om slutninger om data. Du bruker en slutningspipeline til å definere og distribuere en hvilken som helst kombinasjon av forhåndstrente SageMaker innebygde algoritmer og dine egne tilpassede algoritmer pakket i Docker-beholdere. Du kan bruke en slutningspipeline til å kombinere forbehandling, spådommer og etterbehandling av datavitenskapelige oppgaver. Utdata fra en beholder sendes som input til den neste. Når du definerer beholderne for en rørledningsmodell, spesifiserer du også rekkefølgen beholderne kjøres i. De er representert som en enkelt pipeline-modell i SageMaker. Inferensrørledningen kan distribueres som en MME, der en av beholderne i rørledningen dynamisk kan betjene forespørsler basert på modellen som påkalles. Du kan også kjøre en batch-transformasjon jobb med en inferensrørledning. Inferensrørledninger er fullt administrert.
Følgende tabell gir veiledning om evaluering av treningsfunksjonene for ML-modellvert ved bruk av en seriell inferens-pipeline.
Fitness funksjon | Beskrivelse |
Kostnad | Seriell inferenspipeline lar deg kjøre opptil 15 forskjellige ML-beholdere på ett enkelt endepunkt, noe som fører til kostnadseffektivitet ved å være vert for inferensbeholderne. Det er ingen ekstra kostnader for å bruke denne funksjonen. Du betaler kun for forekomstene som kjører på et endepunkt. Kostnadene kan øke avhengig av antall og type forekomster. |
Inferenslatens | Når en ML-applikasjon er distribuert som en inferenspipeline, forlater ikke dataene mellom ulike modeller beholderplassen. Funksjonsbehandling og slutninger kjører med lav ventetid fordi beholderne er samlokalisert på de samme EC2-forekomstene. |
gjennomstrømming | Innenfor en slutningspipeline-modell håndterer SageMaker påkallinger som en sekvens av HTTP-forespørsler. Den første beholderen i rørledningen håndterer den første forespørselen, deretter sendes mellomsvaret som en forespørsel til den andre beholderen, og så videre, for hver beholder i rørledningen. SageMaker returnerer det endelige svaret til klienten. Gjennomstrømning er subjektiv for faktorer som modell, modellinndatastørrelse, batchstørrelse og endepunktforekomsttype. Som en beste praksis, se gjennom CloudWatch-beregninger for inputforespørsler og ressursutnyttelse, og velg riktig forekomsttype for å oppnå optimal gjennomstrømning. |
Skaleringskonfigurasjonskompleksitet | Serielle inferensrørledninger støtter automatisk skalering. For å konfigurere automatisk skalering anbefales det imidlertid at modellen i hver beholder viser lik CPU-utnyttelse og latens på hver slutningsforespørsel. Dette anbefales fordi hvis trafikken til multibeholderendepunktet skifter fra en modell med lav CPU-bruk til en modell med høy CPU-bruk, men det totale anropsvolumet forblir det samme, skaleres ikke endepunktet ut og det kan hende at det ikke er nok forekomster til å håndtere alle forespørsler til modellen med høy CPU-utnyttelse. |
Trafikkmønster |
Serielle inferensrørledninger er ideelle for forutsigbare trafikkmønstre med modeller som kjører sekvensielt på samme endepunkt. |
Utplassering av modellensembler (Triton DAG):
SageMaker tilbyr integrasjon med NVIDIA Triton Inference Server gjennom Triton Inference Server Containers. Disse beholderne inkluderer NVIDIA Triton Inference Server, støtte for vanlige ML-rammeverk og nyttige miljøvariabler som lar deg optimere ytelsen på SageMaker. Med NVIDIA Triton-beholderbilder kan du enkelt betjene ML-modeller og dra nytte av ytelsesoptimaliseringer, dynamisk batching og multi-framework-støtte som tilbys av NVIDIA Triton. Triton hjelper til med å maksimere utnyttelsen av GPU og CPU, og redusere kostnadene ved slutninger ytterligere.
I forretningsbrukstilfeller der ML-applikasjoner bruker flere modeller for å betjene en prediksjonsforespørsel, hvis hver modell bruker et annet rammeverk eller er vert for en separat forekomst, kan det føre til økt arbeidsbelastning og kostnader samt en økning i total latens. SageMaker NVIDIA Triton Inference Server støtter distribusjon av modeller fra alle større rammeverk, som TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT og Python/C++ modellformater og mer. Triton modellensemble representerer en pipeline av én eller flere modeller eller forbehandlings- og etterbehandlingslogikk, og koblingen av inngangs- og utgangstensorer mellom dem. En enkelt slutningsforespørsel til et ensemble utløser kjøringen av hele rørledningen. Triton har også flere innebygde planleggings- og batchalgoritmer som kombinerer individuelle slutningsforespørsler for å forbedre slutningsgjennomstrømningen. Disse planleggings- og batchbeslutningene er transparente for klienten som ber om konklusjon. Modellene kan kjøres på CPUer eller GPUer for maksimal fleksibilitet og for å støtte heterogene datakrav.
Hosting av flere GPU-støttede modeller på multi-modell endepunkter støttes gjennom SageMaker Triton Inference Server. NVIDIA Triton Inference Server har blitt utvidet til å implementere en MME API-kontrakt, for å integrere med MMEer. Du kan bruke NVIDIA Triton Inference Server, som oppretter en modelldepotkonfigurasjon for forskjellige rammeverk, for å distribuere en MME med automatisk skalering. Denne funksjonen lar deg skalere hundrevis av hyperpersonaliserte modeller som er finjustert for å imøtekomme unike sluttbrukeropplevelser i AI-applikasjoner. Du kan også bruke denne funksjonen for å oppnå nødvendig prisytelse for slutningsapplikasjonen din ved å bruke fraksjonerte GPUer. For å lære mer, se Kjør flere dyplæringsmodeller på GPU med Amazon SageMaker multi-modell endepunkter.
Følgende tabell gir veiledning om evaluering av treningsfunksjonene for ML-modellvert ved bruk av MME-er med GPU-støtte på Triton-inferensbeholdere. Se de tidligere delene i dette innlegget for endepunkter med enkeltmodeller og evalueringer av serverløse endepunkttreningsfunksjoner.
Fitness funksjon | Beskrivelse |
Kostnad | SageMaker MMEer med GPU-støtte ved bruk av Triton Inference Server gir en skalerbar og kostnadseffektiv måte å distribuere et stort antall dyplæringsmodeller bak ett SageMaker-endepunkt. Med MME-er deler flere modeller GPU-forekomsten bak et endepunkt. Dette lar deg bryte de lineært økende kostnadene ved å være vert for flere modeller og gjenbruke infrastruktur på tvers av alle modellene. Du betaler for oppetiden til instansen. |
Inferenslatens |
SageMaker med Triton Inference Server er spesialbygd for å maksimere gjennomstrømming og maskinvareutnyttelse med ultralav (ensifret millisekunder) inferensforsinkelse. Den har et bredt spekter av støttede ML-rammeverk (inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, inkludert NVIDIA GPUer, CPUer og AWS slutning. Med MME-støtte for GPU som bruker SageMaker Triton Inference Server, kan du distribuere tusenvis av dyplæringsmodeller bak ett SageMaker-endepunkt. SageMaker laster modellen til NVIDIA Triton-beholderens minne på en GPU-akselerert forekomst og betjener slutningsforespørselen. GPU-kjernen deles av alle modellene i en instans. Hvis modellen allerede er lastet inn i containerminnet, blir de påfølgende forespørslene servert raskere fordi SageMaker ikke trenger å laste den ned og laste den på nytt. |
gjennomstrømming |
MME-er tilbyr muligheter for å kjøre flere dyplærings- eller ML-modeller på GPU-en samtidig med Triton Inference Server. Dette lar deg enkelt bruke NVIDIA Triton multi-framework, høyytelses inferensservering med SageMaker fullt administrerte modellimplementering. Triton støtter all NVIDIA GPU-, x86-, Arm® CPU- og AWS Inferentia-basert inferencing. Den tilbyr dynamisk batching, samtidige kjøringer, optimal modellkonfigurasjon, modellensemble og streaming av lyd- og videoinnganger for å maksimere gjennomstrømming og utnyttelse. Andre faktorer som nettverk og nyttelaststørrelse kan spille en minimal rolle i overhead knyttet til slutningen. |
Skaleringskonfigurasjonskompleksitet |
MME-er kan skalere horisontalt ved hjelp av en automatisk skaleringspolicy, og sørge for ytterligere GPU-beregningsforekomster basert på beregninger som f.eks. Med Triton inferensserver kan du enkelt bygge en tilpasset beholder som inkluderer modellen din med Triton og bringe den til SageMaker. SageMaker Inference vil håndtere forespørslene og automatisk skalere beholderen etter hvert som bruken øker, noe som gjør modellimplementering med Triton på AWS enklere. |
Trafikkmønster |
MME-er er ideelle for forutsigbare trafikkmønstre med modeller som kjøres som DAG-er på samme endepunkt. SageMaker tar seg av trafikkformingen til MME-endepunktet og opprettholder optimale modellkopier på GPU-instanser for best prisytelse. Den fortsetter å rute trafikk til forekomsten der modellen er lastet. Hvis instansressursene når kapasitet på grunn av høy utnyttelse, laster SageMaker ut de minst brukte modellene fra containeren for å frigjøre ressurser for å laste mer hyppig brukte modeller. |
Beste praksis
Vurder følgende beste fremgangsmåter:
- Høy kohesjon og lav kobling mellom modellene – Vert modellene i samme container som har høy kohesjon (driver funksjonalitet for enkeltbedrifter) og kapsle dem sammen for enkel oppgradering og administrasjon. Koble samtidig disse modellene fra hverandre (vert dem i en annen container) slik at du enkelt kan oppgradere én modell uten å påvirke andre modeller. Vær vert for flere modeller som bruker forskjellige beholdere bak ett endepunkt og påkaller deretter uavhengig eller legger til modellforbehandlings- og etterbehandlingslogikk som en seriell slutningspipeline.
- Inferenslatens – Grupper modellene som er drevet av enkeltbedriftsfunksjonalitet og vert dem i én enkelt beholder for å minimere antall hopp og derfor minimere den totale ventetiden. Det er andre forbehold, som hvis de grupperte modellene bruker flere rammeverk; du kan også velge å være vert i flere containere, men kjøre på samme vert for å redusere ventetiden og minimere kostnadene.
- Grupper logisk ML-modeller med høy kohesjon – Den logiske gruppen kan bestå av modeller som er homogene (for eksempel alle XGBoost-modeller) eller heterogene (for eksempel noen få XGBoost og noen få BERT). Den kan bestå av modeller som deles på tvers av flere forretningsfunksjoner eller kan være spesifikke for å oppfylle bare én forretningsfunksjonalitet.
- Delte modeller – Hvis den logiske gruppen består av delte modeller, vil enkel oppgradering av modellene og latens spille en stor rolle i utformingen av SageMaker-endepunktene. For eksempel, hvis ventetid er en prioritet, er det bedre å plassere alle modellene i en enkelt beholder bak et enkelt SageMaker-endepunkt for å unngå flere hopp. Ulempen er at hvis noen av modellene må oppgraderes, vil det resultere i å oppgradere alle de relevante SageMaker-endepunktene som er vert for denne modellen.
- Ikke-delte modeller – Hvis den logiske gruppen kun består av forretningsfunksjonsspesifikke modeller og ikke deles med andre grupper, vil pakkekompleksiteten og latensdimensjonene bli nøkkelen til å oppnå. Det anbefales å være vert for disse modellene i en enkelt beholder bak et enkelt SageMaker-endepunkt.
- Effektiv bruk av maskinvare (CPU, GPU) – Grupper CPU-baserte modeller sammen og vert dem på samme vert slik at du kan bruke CPUen effektivt. På samme måte kan du gruppere GPU-baserte modeller slik at du effektivt kan bruke og skalere dem. Det er hybride arbeidsbelastninger som krever både CPU og GPU på samme vert. Å være vert for bare CPU- og GPU-modeller på samme vert bør drives av høye krav til samhørighet og programforsinkelse. I tillegg er kostnad, evne til å skalere og sprengningsradius ved støt i tilfelle feil nøkkeldimensjonene å se nærmere på.
- Treningsfunksjoner – Bruk treningsfunksjoner som en retningslinje for å velge et ML-vertsalternativ.
konklusjonen
Når det kommer til ML-hosting, er det ingen enkel tilnærming som passer alle. ML-utøvere må velge riktig designmønster for å møte sine ML-vertsutfordringer. Evaluering av treningsfunksjonene gir foreskrivende veiledning om valg av riktig ML-vertsalternativ.
For mer informasjon om hvert av vertsalternativene, se følgende innlegg i denne serien:
Om forfatterne
Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring inkludert NLP- og Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.
Deepali Rajale er AI/ML Specialist Technical Account Manager hos Amazon Web Services. Hun jobber med bedriftskunder og gir teknisk veiledning om implementering av maskinlæringsløsninger med beste praksis. På fritiden liker hun å gå tur, filme og henge med familie og venner.
Saurabh Trikande er senior produktsjef for Amazon SageMaker Inference. Han brenner for å jobbe med kunder og er motivert av målet om å demokratisere maskinlæring. Han fokuserer på kjerneutfordringer knyttet til distribusjon av komplekse ML-applikasjoner, multi-tenant ML-modeller, kostnadsoptimaliseringer og å gjøre distribusjon av dyplæringsmodeller mer tilgjengelig. På fritiden liker Saurabh å gå tur, lære om innovative teknologier, følge TechCrunch og tilbringe tid med familien.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang 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 oss
- akselerert
- adgang
- aksesseres
- tilgjengelig
- imøtekomme
- Logg inn
- nøyaktig
- Oppnå
- oppnå
- tvers
- Handling
- aktivt
- tillegg
- Ytterligere
- I tillegg
- adresse
- avansere
- avansert
- Fordel
- Annonsering
- påvirke
- Etter
- aggregering
- aggregator
- aggressiv
- avtaler
- AI
- AI / ML
- alarm
- algoritmer
- Alle
- tillate
- tillater
- allerede
- alltid
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- beløp
- analyse
- analysere
- og
- og infrastruktur
- årlig
- En annen
- Apache
- api
- eple
- Søknad
- søknader
- tilnærming
- hensiktsmessig
- apps
- arkitektur
- ARM
- kunstig
- kunstig intelligens
- aspekter
- evaluering
- assosiert
- attributter
- lyd
- revisjoner
- auto
- Automatisert
- Automatisk
- automatisk
- tilgjengelighet
- tilgjengelig
- gjennomsnittlig
- AWS
- tilbake
- Backed
- Banking
- basen
- basert
- fordi
- bli
- blir
- før du
- bak
- være
- nytte
- BEST
- beste praksis
- Bedre
- mellom
- biomedisinsk
- Blokker
- Låne
- grenser
- Eske
- brudd
- Break
- bringe
- Bringer
- Budsjetter
- bygge
- Bygning
- bygget
- innebygd
- virksomhet
- Business Applications
- Forretningsprosess
- bedrifter
- Cache
- beregnet
- ring
- som heter
- Caller
- kandidater
- evner
- Kapasitet
- hvilken
- saken
- saker
- kategorier
- årsaker
- viss
- Sertifisert
- utfordringer
- endring
- Endringer
- egenskaper
- ladet
- chatbot
- sjekk
- chip
- valg
- valg
- Velg
- velge
- klasse
- klassifisering
- Klassifisere
- kunde
- klienter
- Lukke
- Cloud
- Cluster
- kode
- laget
- kollegaer
- samle
- bekjempe
- kombinasjon
- kombinere
- kombinert
- Felles
- Selskaper
- Selskapet
- sammenlignet
- fullføre
- helt
- komplekse
- kompleksitet
- samsvar
- komponenter
- komponert
- kompromiss
- regnekraft
- Beregn
- datamaskin
- Datamaskin syn
- databehandling
- konsept
- Bekymring
- samtidig
- Konfigurasjon
- tilkobling
- konsistent
- forbrukes
- Forbrukere
- Container
- Containere
- inneholder
- fortsette
- fortsetter
- kontinuerlig
- kontroll
- Kjerne
- Tilsvarende
- Kostnad
- kostnadsbesparelser
- kostnadseffektiv
- Kostnader
- kunne
- skape
- skaper
- kritisk
- avgjørende
- Gjeldende
- skikk
- kunde
- Kunder
- DAG
- dato
- databehandling
- datavitenskap
- dataforsker
- Database
- datasett
- dag
- håndtering
- avgjørelser
- dedikert
- dyp
- dyp læring
- Misligholde
- definere
- leverer
- Etterspørsel
- krav
- Demokratisering
- avhengig
- avhenger
- utplassere
- utplassert
- utplasserings
- distribusjon
- distribusjoner
- utforming
- designmønstre
- designet
- detalj
- detaljer
- Gjenkjenning
- Bestem
- Utvikler
- Utvikling
- diagrammer
- forskjellig
- vanskelig
- dimensjoner
- direkte
- distinkt
- distribueres
- distribuert databehandling
- diverse
- Docker
- dokumenter
- ikke
- domener
- ikke
- ned
- nedlasting
- ulempen
- drevet
- droppet
- slippe
- under
- dynamisk
- hver enkelt
- Tidligere
- enklere
- lett
- Effektiv
- effektivt
- effektivitet
- effektivitet
- effektiv
- effektivt
- innsats
- enten
- eliminere
- muliggjøre
- muliggjør
- kryptering
- ende til ende
- Endpoint
- Ingeniørarbeid
- Ingeniører
- nok
- sikre
- sikrer
- Enterprise
- bedrifter
- Hele
- Miljø
- feil
- feil
- spesielt
- evaluert
- evalueringer
- Selv
- Event
- alt
- evolusjon
- eksempel
- eksempler
- utveksling
- utstillinger
- forvente
- forventet
- erfaring
- Erfaringer
- utforske
- uttrykkene
- utvendig
- ekstra
- Face
- faktorer
- Failure
- ganske
- familier
- familie
- raskere
- Trekk
- Egenskaper
- fôring
- Noen få
- slutt~~POS=TRUNC
- Først
- første gang
- fitness
- FLÅTE
- fleksibilitet
- flyten
- svinge
- fokuserer
- etter
- følger
- Ford
- skjema
- skjemaer
- brøk
- Rammeverk
- rammer
- svindel
- svindeloppdagelse
- Gratis
- Frekvens
- ofte
- venner
- fra
- Frukt
- fullt
- fullt
- funksjon
- funksjonalitet
- funksjonalitet
- funksjoner
- videre
- GDPR
- general
- generert
- genererer
- få
- Gi
- gitt
- mål
- Mål
- god
- GPU
- GPU
- graf
- flott
- større
- sterkt
- Gruppe
- Gruppens
- Grow
- veilede
- håndtere
- Håndterer
- praktisk
- maskinvare
- å ha
- Helse
- helsetjenester
- hjelpe
- hjelpe
- hjelper
- her.
- Høy
- høy ytelse
- høy oppløsning
- høyere
- hit
- Horisontal
- vert
- vert
- Hosting
- hosting kostnader
- hostingtjenester
- Hvordan
- Men
- HTML
- HTTPS
- Hundrevis
- Hybrid
- ideell
- Identitet
- Idle
- bilde
- Bildeklassifisering
- bilder
- uforanderlige
- Påvirkning
- påvirket
- Konsekvenser
- iverksette
- implementert
- implementere
- viktig
- forbedre
- bedre
- in
- inkludere
- inkluderer
- Inkludert
- Innkommende
- Øke
- økt
- øker
- økende
- uavhengig
- uavhengig av hverandre
- individuelt
- informasjon
- Infrastruktur
- innledende
- innovative
- innovative teknologier
- inngang
- installere
- f.eks
- i stedet
- integrere
- integrering
- Intelligens
- interaktiv
- involvere
- ISO
- isolasjon
- IT
- Jobb
- Jobb
- nøkkel
- nøkler
- Vet
- kjent
- stor
- større
- Ventetid
- lansere
- lanseringer
- lansere
- føre
- ledende
- Fører
- LÆRE
- læring
- Permisjon
- Led
- Nivå
- bibliotekene
- løfte
- Begrenset
- grenser
- Liste
- leve
- laste
- lasting
- laster
- plassering
- Lang
- lenger
- Se
- å miste
- Lot
- Lav
- maskin
- maskinlæring
- laget
- Hoved
- vedlikeholde
- opprettholder
- større
- gjøre
- GJØR AT
- Making
- administrer
- fikk til
- ledelse
- leder
- forvalter
- administrerende
- mange
- Marketing
- matematiske
- Saken
- Maksimer
- maksimal
- midler
- Møt
- Minne
- metode
- metoder
- metrisk
- Metrics
- kunne
- minimal
- minimum
- minutter
- Blanding
- ML
- Mote
- modell
- modeller
- Overvåke
- overvåking
- Måned
- måneder
- mer
- mest
- motivert
- Filmer
- Multi-Model endepunkt
- flere
- mangfold
- Natur
- nødvendig
- Trenger
- behov
- nettverk
- Ny
- neste
- nlp
- varsling
- varslinger
- Antall
- Nvidia
- objekt
- Målet
- mål
- å skaffe seg
- sporadisk
- tilby
- Tilbud
- offline
- ONE
- på nett
- åpen kildekode
- betjene
- opererer
- drift
- operasjonell
- Drift
- operatører
- optimal
- optimalisering
- Optimalisere
- optimalisert
- Optimaliserer
- optimalisere
- Alternativ
- alternativer
- oransje
- rekkefølge
- organisasjoner
- Annen
- enestående
- samlet
- egen
- eierskap
- pakke
- emballasje
- parametere
- del
- Spesielt
- partner
- bestått
- lidenskapelig
- Patches
- Mønster
- mønstre
- Betale
- Topp
- Utfør
- ytelse
- utfører
- perioden
- periodisk
- perioder
- Tilpassing
- Personlig
- plukke
- rørledning
- Sted
- steder
- planlagt
- planer
- plattform
- Plattformer
- plato
- Platon Data Intelligence
- PlatonData
- Spille
- i tillegg til
- Politikk
- politikk
- Populær
- mulig
- Post
- innlegg
- makt
- praksis
- praksis
- Forutsigbar
- forutsi
- prediksjon
- Spådommer
- trekkes
- tidligere
- pris
- Principal
- prioritet
- privat
- Problem
- problemer
- prosess
- Bearbeidet
- Prosesser
- prosessering
- prosessorer
- Produkt
- Produktsjef
- Produksjon
- Produkter
- Profil
- ordentlig
- gi
- forutsatt
- gir
- gi
- forsyning
- proxy
- formål
- Skyv
- pytorch
- raskt
- område
- spenner
- raskt
- Sats
- priser
- å nå
- Når
- Lese
- klar
- ekte
- virkelige verden
- sanntids
- motta
- mottatt
- mottar
- anbefaler
- Anbefaling
- anbefalinger
- anbefales
- anbefale
- anbefaler
- gjentakende
- redusere
- reduserer
- refererer
- Uansett
- regelmessig
- i slekt
- Utgivelser
- relevant
- forblir
- Repository
- representert
- representerer
- anmode
- forespørsler
- krever
- påkrevd
- behov
- Krav
- Krever
- ressurs
- Ressurser
- svar
- REST
- resultere
- resulterende
- Resultater
- detaljhandel
- avkastning
- anmeldelse
- Risiko
- Rolle
- root
- Rute
- Regel
- Kjør
- rennende
- SaaS
- sagemaker
- SageMaker Inference
- lønn
- samme
- Spar
- besparende
- Besparelser
- skalerbar
- Skala
- vekter
- skalering
- scenarier
- planlegge
- planlagt
- Vitenskap
- Forsker
- Sekund
- sekunder
- Seksjon
- seksjoner
- sikkert
- sikkerhet
- velge
- utvalg
- senior
- sensitive
- Sequence
- serie~~POS=TRUNC
- Serien
- betjene
- server~~POS=TRUNC
- Servere
- serverer
- tjeneste
- Tjenester
- servering
- sett
- innstilling
- flere
- forme
- Del
- delt
- Skift
- bør
- Viser
- signifikant
- betydelig
- lignende
- på samme måte
- Enkelt
- enkelt
- Størrelse
- størrelser
- liten
- mindre
- So
- Software
- løsning
- Solutions
- noen
- Kilder
- Rom
- spesialist
- spesialisert
- spesifikk
- spesielt
- spesifisert
- fart
- utgifter
- pigger
- stabil
- stable
- Stabler
- Begynn
- startet
- starter
- oppstart
- startups
- jevn
- Trinn
- Steps
- Still
- Stopper
- lagring
- oppbevare
- strategier
- streaming
- Streng
- sterk
- senere
- suksess
- vellykket
- slik
- tilstrekkelig
- egnet
- støtte
- Støttes
- Støtter
- bølge
- bord
- Ta
- tar
- Target
- målrettet
- Oppgave
- oppgaver
- lag
- lag
- TechCrunch
- Teknisk
- Technologies
- leietaker
- tensorflow
- test
- Testing
- De
- deres
- seg
- derved
- derfor
- tusener
- tre
- terskel
- Gjennom
- hele
- gjennomstrømning
- tid
- ganger
- til
- sammen
- også
- verktøy
- Totalt
- tps
- Sporing
- trafikk
- Tog
- trent
- Kurs
- transaksjonell
- Transaksjoner
- Transform
- Transformation
- transformere
- transitt
- gjennomsiktig
- utløse
- Triton
- SVING
- typer
- typisk
- typisk
- etter
- underliggende
- forstå
- unik
- lomper
- uforutsigbare
- ubrukt
- Oppdater
- oppdateringer
- oppgradering
- oppgradert
- oppetid
- bruk
- bruke
- bruk sak
- Bruker
- Brukere
- vanligvis
- bruke
- benyttes
- VALIDERE
- verdi
- Verdier
- variant
- ulike
- av
- video
- videoer
- Se
- virtuelle
- syn
- volum
- Stem
- stemmer
- Avfall
- web
- webtjenester
- uke
- Hva
- Hva er
- hvilken
- mens
- bred
- Bred rekkevidde
- vil
- innenfor
- uten
- Arbeid
- arbeidet
- arbeidstaker
- arbeidere
- arbeid
- virker
- verden
- ville
- Xgboost
- år
- Du
- Din
- zephyrnet
- null