Efterhånden som demokratisering af fundamentmodeller (FM'er) bliver mere udbredt, og efterspørgslen efter AI-augmented services stiger, søger software-as-a-service-udbydere (SaaS) at bruge maskinlæringsplatforme (ML), der understøtter flere lejere - for dataforskere internt i deres organisation og eksterne kunder. Flere og flere virksomheder indser værdien af at bruge FM'er til at generere meget personligt og effektivt indhold til deres kunder. Finjustering af FM'er på dine egne data kan markant øge modelnøjagtigheden for din specifikke brugssag, uanset om det er salgs-e-mailgenerering ved hjælp af sidebesøgskontekst, generering af søgesvar skræddersyet til en virksomheds tjenester eller automatisering af kundesupport ved at træne i historiske samtaler.
At levere generativ AI-modelhosting som en service gør det muligt for enhver organisation nemt at integrere, pilotteste og implementere FM'er i skala på en omkostningseffektiv måde uden at have behov for intern AI-ekspertise. Dette giver virksomheder mulighed for at eksperimentere med AI-brugstilfælde som hyper-personaliseret salgs- og marketingindhold, intelligent søgning og tilpassede kundeservice-arbejdsgange. Ved at bruge hostede generative modeller, der er finjusteret på pålidelige kundedata, kan virksomheder levere det næste niveau af personaliserede og effektive AI-applikationer for bedre at engagere og betjene deres kunder.
Amazon SageMaker tilbyder forskellige ML-inferensmuligheder, herunder realtids-, asynkron- og batchtransformation. Dette indlæg fokuserer på at give præskriptiv vejledning om at hoste FM'er omkostningseffektivt i stor skala. Specifikt diskuterer vi den hurtige og responsive verden af realtidsinferens og udforsker forskellige muligheder for realtidsinferens for FM'er.
Til slutninger skal multi-tenant AI/ML-arkitekturer tage hensyn til kravene til data og modeller, såvel som de beregningsressourcer, der kræves for at udføre slutninger fra disse modeller. Det er vigtigt at overveje, hvordan multi-tenant AI/ML-modeller implementeres - ideelt set skal du, for at udnytte CPU'er og GPU'er optimalt, være i stand til at opbygge en inferencing-løsning, der kan forbedre serveringsgennemstrømningen og reducere omkostningerne ved at sikre, at modellerne er distribueret på tværs af computerinfrastrukturen på en effektiv måde. Derudover leder kunderne efter løsninger, der hjælper dem med at implementere en best-practice inferencing-arkitektur uden at skulle bygge alt fra bunden.
SageMaker Inference er en fuldt administreret ML-hostingtjeneste. Det understøtter opbygning af generative AI-applikationer, mens det opfylder regulatoriske standarder som FedRAMP. SageMaker muliggør omkostningseffektiv skalering til arbejdsbelastninger med høj gennemstrømning. Det understøtter forskellige arbejdsbelastninger, herunder realtids-, asynkron- og batch-slutninger på hardware som AWS Inferentia, AWS Graviton, NVIDIA GPU'er og Intel CPU'er. SageMaker giver dig fuld kontrol over optimeringer, arbejdsbelastningsisolering og containerisering. Det giver dig mulighed for at bygge generativ AI som en serviceløsning i stor skala med understøttelse af multimodel- og multicontainer-implementeringer.
Udfordringer ved at være vært for fundamentmodeller i stor skala
Følgende er nogle af udfordringerne ved at være vært for FM'er til slutninger i skala:
- Stort hukommelsesfodaftryk – FM'er med titusinder eller hundreder af milliarder af modelparametre overstiger ofte hukommelseskapaciteten for en enkelt acceleratorchip.
- Transformere er langsomme – Autoregressiv afkodning i FM'er, især med lange input- og outputsekvenser, forværrer hukommelsens I/O-operationer. Dette kulminerer i uacceptable latensperioder, hvilket negativt påvirker realtidsslutning.
- Koste – FM'er kræver ML-acceleratorer, der giver både høj hukommelse og høj beregningskraft. At opnå høj gennemløb og lav latenstid uden at ofre nogen af dem er en specialiseret opgave, der kræver en dyb forståelse af samoptimering af hardware-softwareacceleration.
- Længere time-to-market – Optimal ydeevne fra FM'er kræver streng tuning. Denne specialiserede tuning-proces, kombineret med kompleksiteten af infrastrukturstyring, resulterer i forlængede time-to-market-cyklusser.
- Arbejdsbelastningsisolation – At være vært for FM'er i stor skala introducerer udfordringer med at minimere sprængningsradius og håndtere støjende naboer. Evnen til at skalere hver FM som reaktion på modelspecifikke trafikmønstre kræver tunge løft.
- Skalering til hundredvis af FM'er – Betjening af hundredvis af FM'er samtidig introducerer betydelige driftsomkostninger. Effektiv slutpunktsstyring, passende udskæring og acceleratorallokering og modelspecifik skalering er opgaver, der forværres i kompleksitet, efterhånden som flere modeller implementeres.
Fitness funktioner
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 Thought Works i deres arbejde Bygning af evolutionære arkitekturer. Fitness-funktioner giver en præskriptiv vurdering af forskellige hostingmuligheder baseret på dine 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.
Vi foreslår, at du overvejer følgende fitnessfunktioner, når det kommer til at vælge den rigtige FM-inferensmulighed i stor skala og omkostningseffektivt:
- Fundamentmodelstørrelse – FM'er er baseret på transformere. Transformere er langsomme og hukommelseskrævende til at generere lange tekstsekvenser på grund af modellernes store størrelse. Store sprogmodeller (LLM'er) er en type FM, der, når de bruges til at generere tekstsekvenser, har brug for enorme mængder computerkraft og har svært ved at få adgang til den tilgængelige hukommelse med høj båndbredde (HBM) og computerkapacitet. Dette skyldes, at en stor del af den tilgængelige hukommelsesbåndbredde forbruges ved at indlæse modellens parametre og af autoregressiv afkodningsproces. Som et resultat er FM'er begrænset af hukommelse I/O og beregningsgrænser, selv med enorme mængder computerkraft. Derfor bestemmer modelstørrelsen en masse beslutninger, såsom om modellen passer på en enkelt accelerator eller kræver flere ML-acceleratorer, der bruger model-sharding på instansen for at køre inferensen med en højere gennemstrømning. Modeller med mere end 3 milliarder parametre vil generelt begynde at kræve flere ML-acceleratorer, fordi modellen muligvis ikke passer ind i en enkelt acceleratorenhed.
- Ydeevne og FM-slutningsforsinkelse – Mange ML-modeller og -applikationer er latenstidskritiske, hvor inferensforsinkelsen skal være inden for grænserne angivet af et serviceniveaumål. FM-slutningsforsinkelse afhænger af en lang række faktorer, herunder:
- FM model størrelse – Modelstørrelse, inklusive kvantisering ved kørsel.
- Hardware – Beregn (TFLOPS), HBM-størrelse og -båndbredde, netværksbåndbredde, inter-instans sammenkoblingshastighed og lagerbåndbredde.
- Software miljø – Modelserver, model parallelbibliotek, modeloptimeringsmotor, kollektiv kommunikationsydelse, modelnetværksarkitektur, kvantisering og ML-framework.
- Hurtig – Input- og outputlængde og hyperparametre.
- Skaleringsforsinkelse – Tid til at skalere som reaktion på trafikken.
- Koldstartsforsinkelse – Funktioner som forvarmning af modelbelastningen kan reducere koldstartsforsinkelsen ved indlæsning af FM.
- Arbejdsbelastningsisolation – Dette refererer til krav til arbejdsbyrdeisolering ud fra et lovgivnings- og overholdelsesperspektiv, herunder beskyttelse af fortrolighed og integritet af AI-modeller og algoritmer, fortrolighed af data under AI-inferens og beskyttelse af AI-intellektuel ejendom (IP) mod uautoriseret adgang eller fra et risikostyringsperspektiv. For eksempel kan du reducere påvirkningen af en sikkerhedshændelse ved målrettet at reducere sprængningsradius eller ved at forhindre støjende naboer.
- Omkostningseffektivitet – At implementere og vedligeholde en FM-model og 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. De skalerer automatisk til nul pr. model, når der ikke er trafik for at spare omkostninger.
- Skalerbarhed – Dette inkluderer:
- Operationel overhead ved styring af hundredvis af FM'er til slutning i en multi-lejer platform.
- Evnen til at pakke flere FM'er i et enkelt endepunkt og skala pr. model.
- Aktivering af skalering på instansniveau og modelbeholderniveau baseret på arbejdsbelastningsmønstre.
- Understøttelse af skalering til hundredvis af FM'er pr. slutpunkt.
- Støtte til den indledende placering af modellerne i flåden og håndtering af utilstrækkelige acceleratorer.
Repræsenterer dimensionerne i fitnessfunktioner
Vi bruger et edderkopdiagram, også nogle gange kaldet et radardiagram, til at repræsentere dimensionerne i fitnessfunktionerne. Et edderkoppediagram bruges ofte, når du vil vise data på tværs af flere unikke dimensioner. Disse dimensioner er normalt kvantitative og varierer typisk fra nul til en maksimal værdi. Hver dimensions rækkevidde er normaliseret til hinanden, så når vi tegner vores edderkopdiagram, vil længden af en linje fra nul til en dimensions maksimale værdi være den samme for hver dimension.
Følgende diagram illustrerer beslutningsprocessen involveret, når du vælger din arkitektur på SageMaker. Hver radius på edderkoppediagrammet er en af de fitnessfunktioner, som du vil prioritere, når du bygger din inferensløsning.
Ideelt set vil du gerne have en form, der er ligesidet på tværs af alle sider (en femkant). Det viser, at du er i stand til at optimere på tværs af alle fitnessfunktioner. Men virkeligheden er, at det vil være udfordrende at opnå den form – når du prioriterer én fitnessfunktion, vil det påvirke linjerne for den anden radius. Det betyder, at der altid vil være afvejninger afhængigt af, hvad der er vigtigst for din generative AI-applikation, og du vil have en graf, der vil være skæv mod en bestemt radius. Dette er de kriterier, som du måske er villig til at fraprioritere til fordel for de andre afhængigt af, hvordan du ser på hver funktion. I vores diagram er hver fitnessfunktions metriske vægt defineret som sådan – jo lavere værdien er, jo mindre optimal er den for den pågældende fitnessfunktion (med undtagelse af modelstørrelsen, i hvilket tilfælde jo højere værdien er, jo større er størrelsen af model).
Lad os for eksempel tage en use case, hvor du gerne vil bruge en stor opsummeringsmodel (såsom Anthropic Claude) til at lave arbejdsresuméer af servicesager og kundeengagementer baseret på casedata og kundehistorik. Vi har følgende edderkoppediagram.
Fordi dette kan involvere følsomme kundedata, vælger du at isolere denne arbejdsbyrde fra andre modeller og hoste den på et enkelt-model-slutpunkt, hvilket kan gøre det udfordrende at skalere, fordi du er nødt til at spinne op og administrere separate slutpunkter for hver FM. Den generative AI-applikation, du bruger modellen med, bliver brugt af serviceagenter i realtid, så latens og gennemløb er en prioritet, og derfor er det nødvendigt at bruge større instanstyper, såsom en P4De. I denne situation skal omkostningerne muligvis være højere, fordi prioriteringen er isolation, latens og gennemløb.
En anden use case ville være en serviceorganisation, der bygger en Q&A chatbot-applikation, der er tilpasset til et stort antal kunder. Følgende edderkoppediagram afspejler deres prioriteter.
Hver chatbot-oplevelse skal muligvis skræddersyes til hver specifik kunde. De anvendte modeller kan være relativt mindre (FLAN-T5-XXL, Llama 7B og k-NN), og hver chatbot opererer på et bestemt sæt timer for forskellige tidszoner hver dag. Løsningen kan også have Retrieval Augmented Generation (RAG) inkorporeret med en database, der indeholder alle vidensbaseelementer, der skal bruges med slutninger i realtid. Der udveksles ikke kundespecifikke data gennem denne chatbot. Koldstartsforsinkelser er tolerable, fordi chatbots opererer efter en defineret tidsplan. Til denne brugssituation kan du vælge en multi-model slutpunktsarkitektur og kan muligvis minimere omkostningerne ved at bruge mindre instanstyper (som en G5) og potentielt reducere driftsomkostningerne ved at hoste flere modeller på hvert slutpunkt i skala. Med undtagelse af arbejdsbelastningsisolering kan fitnessfunktioner i dette tilfælde have mere lige prioritet, og afvejninger minimeres til en vis grad.
Et sidste eksempel ville være en billedgenereringsapplikation, der bruger en model som Stable Diffusion 2.0, som er en model med 3.5 milliarder parametre. Vores edderkoppediagram er som følger.
Dette er en abonnementsbaseret applikation, der betjener tusindvis af FM'er og kunder. Svartiden skal være hurtig, fordi hver kunde forventer en hurtig vending af billedoutput. Gennemstrømning er også kritisk, fordi der vil være hundredtusindvis af anmodninger på et givet sekund, så instanstypen skal være en større instanstype, som en P4D, der har nok GPU og hukommelse. Til dette kan du overveje at bygge et multi-container-endepunkt, der hoster flere kopier af modellen for at dæmpe billedgenerering fra et anmodningssæt til et andet. For denne brugssituation, for at prioritere latens og gennemløb og imødekomme brugernes efterspørgsel, vil omkostningerne ved beregning og isolering af arbejdsbelastning være afvejningen.
Anvendelse af fitnessfunktioner til at vælge FM-hosting-indstillingen
I dette afsnit viser vi dig, hvordan du anvender de foregående fitnessfunktioner til at vælge den rigtige FM-hostingmulighed på SageMaker FM'er i stor skala.
SageMaker enkelt-model slutpunkter
SageMaker enkelt-model slutpunkter giver dig mulighed for at være vært for én FM 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-model-slutpunktet som et klargjort slutpunkt, hvor du sender endepunktsinfrastrukturkonfigurationen, såsom forekomsttype og -antal, hvor SageMaker automatisk starter computerressourcer og skalerer dem ind og ud afhængigt af den automatiske skaleringspolitik. Du kan skalere til at være vært for hundredvis af modeller ved hjælp af flere enkeltmodelslutpunkter og anvende en cellebaseret arkitektur for øget elasticitet og reduceret sprængningsradius.
Når du evaluerer fitnessfunktioner for et klargjort enkeltmodelslutpunkt, skal du overveje følgende:
- Fundamentmodelstørrelse – Dette er velegnet, hvis du har modeller, der ikke kan passe ind i en enkelt ML-accelerators hukommelse og derfor har brug for flere acceleratorer i en instans.
- Ydeevne og FM-slutningsforsinkelse – Dette er relevant for latency-kritiske generative AI-applikationer.
- Arbejdsbelastningsisolation – Din ansøgning kan have brug for Amazon Elastic Compute Cloud (Amazon EC2) isolation på instansniveau på grund af sikkerhedsoverholdelsesårsager. Hver FM vil få et separat slutningsendepunkt og vil ikke dele EC2-instansen med en anden anden model. For eksempel kan du isolere en HIPAA-relateret modelinferensarbejdsbelastning (såsom en PHI-detektionsmodel) i et separat slutpunkt med en dedikeret sikkerhedsgruppekonfiguration med netværksisolering. Du kan isolere din GPU-baserede modelinferensarbejdsbelastning fra andre baseret på Nitro-baserede EC2-instanser som p4dn for at isolere dem fra mindre betroede arbejdsbelastninger. De Nitro System-baserede EC2-instanser giver en unik tilgang til virtualisering og isolering, så du til enhver tid kan sikre og isolere følsom databehandling fra AWS-operatører og software. Det giver den vigtigste dimension af fortrolig computing som et iboende, on-by-default sæt af beskyttelser fra systemsoftwaren og cloud-operatører. Denne mulighed understøtter også implementering af AWS Marketplace-modeller leveret af tredjepartsmodeludbydere på SageMaker.
SageMaker multi-model slutpunkter
SageMaker multi-model slutpunkter (MME'er) giver dig mulighed for at være vært for 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 pris-ydelse.
MME'er er det bedste valg, hvis du skal være vært for mindre modeller, der alle kan passe ind i en enkelt ML-accelerator på en instans. Denne strategi bør overvejes, hvis du har et stort antal (op til tusindvis) modeller af lignende størrelse (færre end 1 milliard parametre), som du kan betjene gennem en delt container i en instans og ikke behøver at få adgang til alle modellerne på samme tid. Du kan indlæse den model, der skal bruges, og derefter aflæsse den til en anden model.
MME'er er også designet til co-hosting af modeller, der bruger den samme ML-ramme, fordi de bruger den delte container til at indlæse flere modeller. Derfor, hvis du har en blanding af ML-frameworks i din modelflåde (såsom PyTorch og TensorFlow), vil et SageMaker-slutpunkt med InferenceComponents
er et bedre valg. Vi diskuterer InferenceComponents
mere senere i dette indlæg.
Endelig er MME'er velegnede til applikationer, der kan tolerere en lejlighedsvis koldstartsforsinkelse, fordi sjældent brugte modeller kan aflastes til fordel for ofte påberåbte modeller. Hvis du har en lang hale af sjældent tilgåede modeller, kan et multi-model slutpunkt effektivt betjene denne trafik og muliggøre betydelige omkostningsbesparelser.
Overvej følgende, når du vurderer, hvornår du skal bruge MME'er:
- Fundamentmodelstørrelse – Du har muligvis modeller, der passer ind i en enkelt ML-accelerator's HBM på en instans og derfor ikke har brug for flere acceleratorer.
- Ydeevne og FM-slutningsforsinkelse – Du har muligvis generative AI-applikationer, der kan tolerere koldstartsforsinkelse, når modellen er anmodet om og ikke er i hukommelsen.
- Arbejdsbelastningsisolation – Overvej at lade alle modellerne dele den samme beholder.
- Skalerbarhed – Overvej følgende:
- Du kan pakke flere modeller i et enkelt slutpunkt og skalere pr. model og ML-instans.
- Du kan aktivere automatisk skalering på instansniveau baseret på arbejdsbelastningsmønstre.
- MME'er understøtter skalering til tusindvis af modeller pr. slutpunkt. Du behøver ikke at vedligeholde automatisk skalering og implementeringskonfiguration pr. model.
- Du kan bruge hot-implementering, når modellen anmodes om af slutningsanmodningen.
- Du kan indlæse modellerne dynamisk i henhold til slutningsanmodningen og aflæse som svar på hukommelsestryk.
- Du kan tid dele de underliggende ressourcer med modellerne.
- Omkostningseffektivitet – Overvej tidsdeling af ressourcen på tværs af modellerne ved dynamisk lastning og losning af modellerne, hvilket resulterer i omkostningsbesparelser.
SageMaker inference endpoint med InferenceComponents
Det nye SageMaker slutningspunkt med InferenceComponents
giver en skalerbar tilgang til hosting af flere FM'er i et enkelt slutpunkt og skalering pr. model. Det giver dig finkornet kontrol til at allokere ressourcer (acceleratorer, hukommelse, CPU) og indstille automatiske skaleringspolitikker på basis af model for at få sikret gennemløb og forudsigelig ydeevne, og du kan administrere udnyttelsen af computeren på tværs af flere modeller individuelt. Hvis du har mange modeller af varierende størrelse og trafikmønstre, som du skal være vært for, og modelstørrelserne ikke tillader dem at passe ind i en enkelt accelerators hukommelse, er dette den bedste mulighed. Det giver dig også mulighed for at skalere til nul for at spare omkostninger, men dine applikationsforsinkelseskrav skal være fleksible nok til at tage højde for en koldstartstid for modeller. Denne mulighed giver dig den største fleksibilitet i at bruge din computer, så længe isolering på containerniveau pr. kunde eller FM er tilstrækkelig. For flere detaljer om det nye SageMaker-slutpunkt med InferenceComponents
, se det detaljerede indlæg Reducer omkostningerne til modelimplementering med 50 % i gennemsnit ved at bruge de nyeste funktioner i Amazon SageMaker.
Overvej følgende, når du bestemmer, hvornår du skal bruge et endepunkt med InferenceComponents
:
- Fundamentmodelstørrelse – Dette er velegnet til modeller, der ikke kan passe ind i en enkelt ML-accelerators hukommelse og derfor har brug for flere acceleratorer i en instans.
- Ydeevne og FM-slutningsforsinkelse – Dette er velegnet til latency-kritiske generative AI-applikationer.
- Arbejdsbelastningsisolation – Du kan have applikationer, hvor isolering på beholderniveau er tilstrækkelig.
- Skalerbarhed – Overvej følgende:
- Du kan pakke flere FM'er i et enkelt endepunkt og skalere pr. model.
- Du kan aktivere skalering på instansniveau og modelbeholderniveau baseret på arbejdsbelastningsmønstre.
- Denne metode understøtter skalering til hundredvis af FM'er pr. slutpunkt. Du behøver ikke at konfigurere den automatiske skaleringspolitik for hver model eller container.
- Det understøtter den indledende placering af modellerne i flåden og håndtering af utilstrækkelige acceleratorer.
- Omkostningseffektivitet – Du kan skalere til nul pr. model, når der ikke er trafik, for at spare omkostninger.
Pakning af flere FM'er på samme endepunkt: Modelgruppering
Bestemmelsen af, hvilken inferensarkitekturstrategi, du anvender på SageMaker, afhænger af dine applikationsprioriteter og -krav. Nogle SaaS-udbydere sælger til regulerede miljøer, der stiller strenge isolationskrav - de skal have en mulighed, der gør dem i stand til at tilbyde nogle eller alle deres FM'er muligheden for at blive implementeret i en dedikeret model. Men for at optimere omkostningerne og opnå stordriftsfordele, skal SaaS-udbydere også have multi-tenant-miljøer, hvor de hoster flere FM'er på tværs af et fælles sæt SageMaker-ressourcer. De fleste organisationer vil sandsynligvis have et hybridt hostingmiljø, hvor de både har enkelt-model-endepunkter og multi-model- eller multi-container-endepunkter som en del af deres SageMaker-arkitektur.
En kritisk øvelse, du skal udføre, når du opbygger dette distribuerede inferensmiljø, er at gruppere dine modeller for hver type arkitektur, du skal opsætte i dine SageMaker-endepunkter. Den første beslutning, du skal træffe, er omkring krav til isolering af arbejdsbelastning - du bliver nødt til at isolere de FM'er, der skal være i deres egne dedikerede endepunkter, uanset om det er af sikkerhedsmæssige årsager, for at reducere eksplosionsradius og støjende naborisiko eller møde strenge SLA'er for latenstid.
For det andet skal du afgøre, om FM'erne passer ind i en enkelt ML-accelerator eller kræver flere acceleratorer, hvad modelstørrelserne er, og hvad deres trafikmønstre er. Lignende størrelsesmodeller, der tilsammen tjener til at understøtte en central funktion, kunne logisk set grupperes sammen ved at være vært for flere modeller på et slutpunkt, fordi disse ville være en del af en enkelt forretningsapplikation, der administreres af et centralt team. For at være vært for flere modeller på det samme slutpunkt skal der udføres en grupperingsøvelse for at bestemme, hvilke modeller der kan sidde i en enkelt instans, en enkelt container eller flere containere.
Gruppering af modellerne for MME'er
MME'er er bedst egnet til mindre modeller (færre end 1 milliard parametre, der kan passe ind i en enkelt accelerator) og har samme størrelse og kaldforsinkelse. Nogle variationer i modelstørrelse er acceptabel; for eksempel, Zendesks modeller spænder fra 10-50 MB, hvilket fungerer fint, men variationer i størrelse, der er en faktor på 10, 50 eller 100 gange større, er ikke egnede. Større modeller kan forårsage et højere antal ind- og udlæsninger af mindre modeller for at rumme tilstrækkelig hukommelsesplads, hvilket kan resultere i øget latenstid på slutpunktet. Forskelle i ydeevnekarakteristika for større modeller kan også forbruge ressourcer som CPU ujævnt, hvilket kan påvirke andre modeller på instansen.
De modeller, der er grupperet sammen på MME'en, skal have forskudte trafikmønstre for at give dig mulighed for at dele beregning på tværs af modellerne til slutning. Dine adgangsmønstre og inferensforsinkelse skal også give mulighed for noget koldstartstid, når du skifter mellem modeller.
Følgende er nogle af de anbefalede kriterier for gruppering af modellerne for MME'er:
- Mindre modeller – Brug modeller med færre end 1 milliard parametre
- Modelstørrelse – Gruppér modeller af lignende størrelse og co-host i det samme slutpunkt
- Invokationsforsinkelse – Gruppér modeller med lignende krav til aktiveringsforsinkelse, der kan tolerere koldstart
- Hardware – Gruppér modellerne ved hjælp af den samme underliggende EC2-instanstype
Gruppering af modellerne for et slutpunkt med InferenceComponents
Et SageMaker-endepunkt med InferenceComponents
er bedst egnet til at hoste større FM'er (over 1 milliard parametre) i skala, der kræver flere ML-acceleratorer eller enheder i en EC2-instans. Denne mulighed er velegnet til latenstidsfølsomme arbejdsbelastninger og applikationer, hvor isolering på containerniveau er tilstrækkelig. Det følgende er nogle af de anbefalede kriterier for gruppering af modellerne for et endepunkt med flere InferenceComponents
:
- Hardware – Gruppér modellerne ved hjælp af den samme underliggende EC2-instanstype
- Modelstørrelse – Gruppering af modellen baseret på modelstørrelse anbefales, men ikke obligatorisk
Resumé
I dette indlæg så vi på tre ML-inferensmuligheder i realtid (enkelt-endepunkter, multi-model-endepunkter og slutpunkter med InferenceComponents
) i SageMaker for effektivt at være vært for FM'er i skala omkostningseffektivt. Du kan bruge de fem fitnessfunktioner til at hjælpe dig med at vælge den rigtige SageMaker-hostingmulighed til FM'er i stor skala. Gruppér FM'erne og co-host dem på SageMaker-slutningsendepunkter ved hjælp af de anbefalede grupperingskriterier. Ud over de fitnessfunktioner, vi diskuterede, kan du bruge følgende tabel til at beslutte, hvilken delt SageMaker-hostingmulighed, der er bedst til din brug. Du kan finde kodeeksempler for hver af FM-hostingmulighederne på SageMaker i følgende GitHub-repos: enkelt SageMaker-endepunkt, multi-model slutpunktog InferenceComponents
slutpunkt.
. | Enkeltmodel slutpunkt | Multi-model slutpunkt | Slutpunkt med InferenceComponents |
Modellens livscyklus | API til ledelse | Dynamisk gennem Amazon S3-sti | API til ledelse |
Forekomsttyper understøttes | CPU, enkelt- og multi-GPU, AWS Inferentia-baserede instanser | CPU, enkelt GPU-baserede instanser | CPU, enkelt- og multi-GPU, AWS Inferentia-baserede instanser |
Metrisk granularitet | Endpoint | Endpoint | Endpoint og container |
Skalering af granularitet | ML forekomst | ML forekomst | Container |
Skaleringsadfærd | Uafhængig ML-instansskalering | Modeller ind- og udlæses fra hukommelsen | Uafhængig beholderskalering |
Model fastgørelse | . | Modeller kan aflæses baseret på hukommelse | Hver container kan konfigureres til altid at blive læsset eller losset |
Containerkrav | SageMaker præbygget, SageMaker-kompatibel Bring Your Own Container (BYOC) | MMS, Triton, BYOC med MME-kontrakter | SageMaker præbygget, SageMaker-kompatibel BYOC |
Rutemuligheder | Tilfældig eller mindst forbindelse | Tilfældigt, klæbrigt med popularitetsvindue | Tilfældig eller mindst forbindelse |
Hardwaretildeling til model | Dedikeret til enkelt model | delt | Dedikeret til hver container |
Antal understøttede modeller | Single | Tusinder | Hundreder |
Svar streaming | Understøttet | Ikke understøttet | Understøttet |
Datafangst | Understøttet | Ikke understøttet | Ikke understøttet |
Skyggetest | Understøttet | Ikke understøttet | Ikke understøttet |
Multivarianter | Understøttet | Ikke relevant | Ikke understøttet |
AWS Marketplace-modeller | Understøttet | Ikke relevant | Ikke understøttet |
Om forfatterne
Mehran Najafi, PhD, er en Senior Solutions Architect for AWS med fokus på AI/ML og SaaS-løsninger i skala.
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.
Rielah DeJesus er en Principal Solutions Architect hos AWS, som med succes har hjulpet forskellige virksomhedskunder i DC, Maryland og Virginia-området med at flytte til skyen. Hun er kundeadvokat og teknisk rådgiver og hjælper organisationer som Heroku/Salesforce med at opnå succes på AWS-platformen. Hun er en varm tilhænger af Women in IT og brænder meget for at finde måder at kreativt bruge teknologi og data til at løse hverdagens udfordringer.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
- PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
- PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
- PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/scale-foundation-model-inference-to-hundreds-of-models-with-amazon-sagemaker-part-1/
- :har
- :er
- :ikke
- :hvor
- $OP
- 1
- 10
- 100
- 11
- 25
- 50
- 7
- a
- evne
- I stand
- Om
- acceleration
- accelerator
- acceleratorer
- acceptabel
- adgang
- af udleverede
- Adgang
- imødekomme
- Konto
- nøjagtighed
- opnå
- opnå
- tværs
- tilføjet
- Desuden
- negativt
- rådgiver
- fortaler
- påvirke
- påvirker
- midler
- AI
- AI modeller
- ai use cases
- AI / ML
- algoritmer
- Alle
- tildele
- allokering
- tillade
- tillader
- også
- altid
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- beløb
- an
- ,
- årligt
- En anden
- svar
- Antropisk
- enhver
- Anvendelse
- applikationer
- Indløs
- tilgang
- passende
- arkitekter
- arkitektur
- ER
- OMRÅDE
- omkring
- kunstig
- kunstig intelligens
- AS
- vurdere
- Vurdering
- vurdering
- sikker
- At
- augmented
- auto
- automatisk
- Automatisering
- autonomi
- til rådighed
- gennemsnit
- AWS
- AWS-inferens
- AWS Marketplace
- båndbredde
- bund
- baseret
- grundlag
- BE
- fordi
- bliver
- bag
- være
- BEDSTE
- Bedre
- mellem
- Billion
- milliarder
- boost
- låntagning
- både
- bounds
- bringe
- bygge
- Bygning
- virksomhed
- Forretningsproces
- virksomheder
- men
- by
- beregnet
- kaldet
- CAN
- Kapacitet
- tilfælde
- tilfælde
- Årsag
- central
- udfordringer
- udfordrende
- lave om
- karakteristika
- Chart
- chatbot
- chatbots
- kontrollere
- chip
- valg
- valg
- Vælg
- vælge
- Luk
- Cloud
- Co-Host
- kode
- opfundet
- forkølelse
- kolleger
- kollektive
- kollektivt
- kombineret
- kommer
- Kommunikation
- Virksomheder
- Selskabs
- kompatibel
- kompleksiteter
- kompleksitet
- Compliance
- komponenter
- Forbindelse
- beregning
- beregningsmæssige
- computerkraft
- Compute
- computer
- Computer Vision
- computing
- computerkraft
- Konceptet
- fortrolighed
- Konfiguration
- konfigureret
- Overvej
- betragtes
- Overvejer
- forbruge
- forbruges
- Container
- Beholdere
- indhold
- sammenhæng
- kontrol
- samtaler
- Core
- Koste
- omkostningsbesparelser
- omkostningseffektiv
- Omkostninger
- kunne
- koblede
- skabe
- kriterier
- kritisk
- kunde
- kundedata
- Kundeservice
- Kunde support
- Kunder
- tilpassede
- cykler
- data
- databehandling
- Database
- dag
- dc
- beslutte
- beslutning
- Beslutningstagning
- afgørelser
- Dekodning
- dedikeret
- dyb
- dyb læring
- definerede
- levere
- Efterspørgsel
- krav
- demokratisering
- Afhængigt
- afhænger
- indsætte
- indsat
- implementering
- implementering
- implementeringer
- udpeget
- konstrueret
- ønskes
- detaljeret
- detaljer
- Detektion
- Bestem
- bestemmer
- bestemmelse
- enhed
- Enheder
- forskelle
- forskellige
- Vanskelighed
- Broadcasting
- Dimension
- størrelse
- diskutere
- drøftet
- Skærm
- distribueret
- distribueret computing
- forskelligartede
- Domæner
- Dont
- tegne
- grund
- i løbet af
- dynamisk
- dynamisk
- hver
- nemt
- økonomier
- Stordriftsfordele
- Effektiv
- effektiv
- effektivt
- enten
- muliggøre
- muliggør
- muliggør
- Endpoint
- engagere
- engagementer
- Engine (Motor)
- Ingeniører
- forbedre
- nok
- sikre
- sikring
- Enterprise
- virksomheder
- Miljø
- miljøer
- især
- evaluere
- Endog
- begivenhed
- Hver
- hverdagen
- at alt
- evolution
- udvikler
- eksempel
- overstige
- undtagelse
- udveksles
- Dyrke motion
- forventer
- erfaring
- eksperiment
- ekspertise
- Udforskning
- udstrækning
- ekstern
- faktor
- faktorer
- FAST
- favorisere
- Funktionalitet
- færre
- endelige
- Finde
- finde
- ende
- Fornavn
- passer
- fitness
- fem
- FLÅDE
- Fleksibilitet
- fleksibel
- fokuserede
- fokuserer
- efter
- følger
- Til
- Ford
- Foundation
- Framework
- rammer
- hyppigt
- fra
- fuld
- fuldt ud
- funktion
- funktioner
- Gevinst
- generelt
- generere
- generere
- generation
- generative
- Generativ AI
- få
- GitHub
- given
- giver
- Mål
- GPU
- GPU'er
- graf
- større
- stærkt
- gruppe
- vejledning
- vejlede
- Håndtering
- Hardware
- Have
- have
- he
- tunge
- tunge løft
- hjælpe
- hjulpet
- hjælper
- dermed
- Høj
- højere
- stærkt
- hans
- historisk
- historie
- host
- hostede
- Hosting
- HOT
- HOURS
- Hvordan
- How To
- http
- HTTPS
- Hundreder
- Hybrid
- if
- illustrerer
- billede
- enorme
- KIMOs Succeshistorier
- Påvirkninger
- vigtigt
- pålægge
- in
- omfatter
- Herunder
- Indgående
- Incorporated
- øget
- Stigninger
- Individuelt
- Infrastruktur
- initial
- indgang
- instans
- integrere
- integritet
- Intel
- intellektuel
- intellektuel ejendomsret
- Intelligens
- Intelligent
- interne
- ind
- iboende
- Introducerer
- påberåbes
- involvere
- involverede
- IP
- isolation
- IT
- Varer
- jpg
- viden
- Sprog
- stor
- Store virksomheder
- større
- Latency
- senere
- seneste
- lanceringer
- læring
- mindst
- Længde
- mindre
- Niveau
- Bibliotek
- løft
- ligesom
- Limited
- grænser
- Line (linje)
- linjer
- Llama
- belastning
- lastning
- belastninger
- logisk
- Lang
- kiggede
- leder
- Lot
- Lav
- lavere
- maskine
- machine learning
- lavet
- vedligeholde
- Vedligeholdelse
- lave
- administrere
- lykkedes
- ledelse
- styring
- måde
- mange
- Marketing
- markedsplads
- Maryland
- massive
- maksimal
- Kan..
- midler
- møde
- Hukommelse
- metode
- metrisk
- måske
- minimering
- blande
- ML
- model
- modeller
- overvågning
- mere
- mest
- bevæge sig
- multi
- Multi-model slutpunkt
- flere
- mangfoldighed
- skal
- nødvendig
- Behov
- behøve
- behov
- naboer
- netværk
- Ny
- næste
- Nitro
- NLP
- ingen
- nummer
- Nvidia
- objektiv
- målsætninger
- opnå
- lejlighedsvis
- of
- tilbyde
- Tilbud
- tit
- on
- ONE
- betjene
- opererer
- drift
- operationelle
- Produktion
- Operatører
- optimal
- optimering
- Optimer
- Option
- Indstillinger
- or
- ordrer
- organisation
- organisationer
- Andet
- Andre
- vores
- ud
- output
- udgange
- i løbet af
- samlet
- egen
- ejerskab
- Pack
- side
- Parallel
- parametre
- del
- partner
- passerer
- lidenskabelige
- mønstre
- femkant
- per
- Udfør
- ydeevne
- udføres
- periode
- perioder
- Personlig
- perspektiv
- phd
- pilot
- placering
- planlagt
- perron
- Platforme
- plato
- Platon Data Intelligence
- PlatoData
- politikker
- politik
- popularitet
- del
- Indlæg
- potentielt
- magt
- Forudsigelig
- tryk
- fremherskende
- forebyggelse
- Main
- Prioriter
- prioritet
- sandsynligvis
- problemer
- behandle
- forarbejdning
- ejendom
- foreslå
- beskyttelse
- give
- forudsat
- udbydere
- giver
- leverer
- formål
- pytorch
- Spørgsmål og svar
- kvantitativ
- Hurtig
- radar
- rækkevidde
- spænder
- ægte
- realtid
- Reality
- realisere
- årsager
- anbefales
- reducere
- Reduceret
- reducere
- henvise
- refererer
- afspejler
- reguleret
- lovgivningsmæssige
- relaterede
- relativt
- relevant
- resterne
- afsmeltet
- repræsentere
- anmode
- anmodninger
- kræver
- påkrævet
- Krav
- Kræver
- ressource
- Ressourcer
- svar
- lydhør
- resultere
- resulterer
- Resultater
- højre
- stringent
- Risiko
- risikostyring
- Kør
- runtime
- SaaS
- at ofre
- sagemaker
- SageMaker Inference
- løn
- salg
- samme
- Gem
- Besparelser
- skalerbar
- Scale
- skalaer
- skalering
- scenarie
- planlægge
- forskere
- ridse
- Søg
- Anden
- Sektion
- sikker
- sikkerhed
- udvælgelse
- Salg
- senior
- følsom
- adskille
- tjener
- server
- tjeneste
- Tjenester
- servering
- sæt
- flere
- Shape
- sharding
- Del
- delt
- deling
- hun
- bør
- Vis
- Shows
- sider
- signifikant
- betydeligt
- lignende
- samtidigt
- enkelt
- sidde
- Situationen
- Størrelse
- størrelse
- størrelser
- langsom
- mindre
- So
- Software
- software som en tjeneste
- løsninger
- Løsninger
- SOLVE
- nogle
- sommetider
- Space
- specialiserede
- specifikke
- specifikt
- specificeret
- hastighed
- Spin
- stabil
- standarder
- starte
- Nystartede
- klæbrig
- opbevaring
- Strategi
- Streng
- væsentlig
- succes
- Succesfuld
- sådan
- tilstrækkeligt
- egnede
- support
- supporter
- Understøtter
- Kontakt
- systemet
- bord
- skræddersyet
- Tag
- Opgaver
- opgaver
- hold
- hold
- Teknisk
- Teknologier
- tiere
- tensorflow
- prøve
- tekst
- end
- at
- deres
- Them
- derefter
- Der.
- derfor
- Disse
- de
- tredjepart
- denne
- tænkte
- tusinder
- tre
- Gennem
- kapacitet
- tid
- gange
- til
- sammen
- værktøj
- I alt
- mod
- Trafik
- Kurser
- Transform
- transformers
- Triton
- betroet
- tuning
- typen
- typer
- typisk
- uberettiget
- underliggende
- forstå
- forståelse
- enestående
- brug
- brug tilfælde
- anvendte
- Bruger
- ved brug af
- sædvanligvis
- udnytte
- Ved hjælp af
- værdi
- Værdier
- forskellige
- Varierende
- meget
- Specifikation
- Virginia
- vision
- Besøg
- ønsker
- var
- måder
- we
- web
- webservices
- vægt
- GODT
- Hvad
- Hvad er
- hvornår
- når
- hvorvidt
- som
- mens
- WHO
- vilje
- villig
- med
- inden for
- uden
- Dame
- Arbejde
- arbejdede
- arbejdsgange
- virker
- world
- ville
- Du
- Din
- zephyrnet
- nul
- zoner