Machine learning (ML) er blevet allestedsnærværende. Vores kunder anvender ML i alle aspekter af deres forretning, inklusive de produkter og tjenester, de bygger, og for at få indsigt om deres kunder.
For at bygge en ML-baseret applikation skal du først bygge den ML-model, der opfylder dine forretningskrav. Opbygning af ML-modeller involverer forberedelse af data til træning, udtrækning af funktioner og derefter træning og finjustering af modellen ved hjælp af funktionerne. Dernæst skal modellen sættes i gang, så den kan generere inferens (eller forudsigelser) fra nye data, som derefter kan bruges i applikationen. Selvom du kan integrere modellen direkte i en applikation, er den fremgangsmåde, der fungerer godt for applikationer i produktionsgrad, at implementere modellen bag et endepunkt og derefter påkalde endepunktet via et RESTful API-kald for at opnå slutningen. I denne tilgang er modellen typisk implementeret på en infrastruktur (computer, storage og netværk), der passer til applikationens pris-ydelseskrav. Disse krav omfatter antallet af inferenser, som endepunktet forventes at returnere på et sekund (kaldet kapacitet), hvor hurtigt inferensen skal genereres (den latens), og de samlede omkostninger ved at være vært for modellen.
Amazon SageMaker gør det nemt at implementere ML-modeller til slutninger til den bedste pris-ydelse til enhver brug. Det giver et bredt udvalg af ML-infrastruktur og modelimplementeringsmuligheder for at hjælpe med at opfylde alle dine ML-slutningsbehov. Det er en fuldt administreret service, så du kan skalere din modelimplementering, reducere omkostningerne ved slutninger, administrere modeller mere effektivt i produktionen og reducere driftsbyrden. En af måderne at minimere dine omkostninger på er kun at levere så meget computerinfrastruktur, som det er nødvendigt for at betjene slutningsanmodningerne til slutpunktet (også kendt som konkludere arbejdsbyrde) på ethvert givet tidspunkt. Fordi trafikmønsteret af slutningsanmodninger kan variere over tid, skal det mest omkostningseffektive implementeringssystem være i stand til at skalere ud, når arbejdsbyrden stiger, og skalere ind, når arbejdsbyrden falder i realtid. SageMaker understøtter automatisk skalering (automatisk skalering) for dine hostede modeller. Automatisk skalering justerer dynamisk antallet af forekomster, der er klargjort for en model som svar på ændringer i din slutningsarbejdsbyrde. Når arbejdsbyrden øges, bringer automatisk skalering flere forekomster online. Når arbejdsbyrden falder, fjerner automatisk skalering unødvendige forekomster, så du ikke betaler for klargjorte forekomster, som du ikke bruger.
Med SageMaker kan du vælge, hvornår du vil automatisk skalere, og hvor mange forekomster, der skal klargøres eller fjernes for at opnå den rigtige tilgængelighed og omkostningsudligning for din applikation. SageMaker understøtter tre muligheder for automatisk skalering. Den første og almindeligt anvendte mulighed er målsporing. I denne mulighed vælger du en ideel værdi af en amazoncloudwatch metric efter dit valg, såsom den gennemsnitlige CPU-udnyttelse eller -gennemstrømning, som du ønsker at opnå som et mål, og SageMaker vil automatisk skalere ind eller udskalere antallet af forekomster for at opnå målmetrikken. Den anden mulighed er at vælge trinskalering, som er en avanceret metode til skalering baseret på størrelsen af CloudWatch-alarmbruddet. Den tredje mulighed er planlagt skalering, som lader dig angive en tilbagevendende tidsplan for ind- og udskalering af dit slutpunkt baseret på forventet efterspørgsel. Vi anbefaler, at du kombinerer disse skaleringsmuligheder for bedre modstandsdygtighed.
I dette indlæg giver vi et designmønster til at udlede den rigtige automatiske skaleringskonfiguration til din applikation. Derudover giver vi en liste over trin, der skal følges, så selvom din applikation har en unik adfærd, såsom forskellige systemkarakteristika eller trafikmønstre, kan denne systemiske tilgang anvendes til at bestemme de rigtige skaleringspolitikker. Proceduren forenkles yderligere med brug af Inferensanbefaling, et værktøj til den rigtige størrelse og benchmarking bygget inde i SageMaker. Du kan dog bruge et hvilket som helst andet benchmarkingværktøj.
Du kan gennemgå notesbog vi plejede at køre denne procedure for at udlede den rigtige implementeringskonfiguration til vores use case.
SageMaker hoster endepunkter og målinger i realtid
SageMaker-endepunkter i realtid er ideelle til ML-applikationer, der skal håndtere en bred vifte af trafik og svare på anmodninger i realtid. Applikationsopsætningen begynder med at definere runtime-miljøet, inklusive containerne, ML-modellen, miljøvariabler og så videre i create-model API'en og derefter definere hostingdetaljerne såsom instanstype og instansantal for hver variant i oprette- endpoint-config API. Endpoint-konfigurations-API'en giver dig også mulighed for at opdele eller duplikere trafik mellem varianter ved hjælp af produktions- og skyggevarianter. Men for dette eksempel definerer vi skaleringspolitikker ved hjælp af en enkelt produktionsvariant. Efter opsætning af applikationen opsætter du skalering, som involverer registrering af skaleringsmålet og anvendelse af skaleringspolitikker. Henvise til Konfiguration af autoskalering af inferensslutpunkter i Amazon SageMaker for flere detaljer om de forskellige skaleringsmuligheder.
Følgende diagram illustrerer applikations- og skaleringsopsætningen i SageMaker.
Endpoint-metrics
For at forstå skaleringsøvelsen er det vigtigt at forstå de målinger, som slutpunktet udsender. På et højt niveau er disse metrics kategoriseret i tre klasser: invokationsmetrikker, latensmetrikker og udnyttelsesmetrikker.
Følgende diagram illustrerer disse metrics og slutpunktsarkitekturen.
Følgende tabeller uddyber detaljerne for hver metrik.
Invokationsmålinger
Metrics | Oversigt | Periode | Enheder | Statistik |
Invokationer | Antallet af InvokeEndpoint-anmodninger sendt til et modelslutpunkt. | 1 minutter | Ingen | Sum |
InvocationsPerInstance | Antallet af opkald sendt til en model, normaliseret af InstanceCount i hver variant. 1/numberOfInstances sendes som værdien på hver anmodning, hvor numberOfInstances er antallet af aktive forekomster for varianten bag endepunktet på tidspunktet for anmodningen. | 1 minutter | Ingen | Sum |
Invocation4XXErrors | Antallet af InvokeEndpoint-anmodninger, hvor modellen returnerede en 4xx HTTP-svarkode. | 1 minutter | Ingen | Gennemsnit, Sum |
Invocation5XXErrors | Antallet af InvokeEndpoint-anmodninger, hvor modellen returnerede en 5xx HTTP-svarkode. | 1 minutter | Ingen | Gennemsnit, Sum |
Latency-metrics
Metrics | Oversigt | Periode | Enheder | Statistik |
ModelLatency | Det tidsinterval, det tager en model at reagere, set fra SageMaker. Dette interval inkluderer de lokale kommunikationstider, det tager at sende anmodningen og hente svaret fra containeren til en model og den tid, det tager at fuldføre slutningen i containeren. | 1 minutter | Mikrosekunder | Gennemsnit, Sum, Min, Maks, Prøveantal |
OverheadLatency | Tidsintervallet tilføjet til den tid, det tager at svare på en klientanmodning fra SageMaker-omkostninger. Dette interval måles fra det tidspunkt, SageMaker modtager anmodningen, indtil den returnerer et svar til klienten, minus ModelLatency. Overhead-latenstiden kan variere afhængigt af flere faktorer, herunder anmodnings- og svarnyttelaststørrelser, anmodningsfrekvens og godkendelse eller godkendelse af anmodningen. | 1 minutter | Mikrosekunder | Gennemsnit, Sum, Min, Maks, Prøveantal |
Udnyttelsesmålinger
Metrics | Oversigt | Periode | Enheder |
CPUUtilisation | Summen af hver enkelt CPU-kernes udnyttelse. CPU-udnyttelsen af hvert kerneområde er 0-100. For eksempel, hvis der er fire CPU'er, er CPUUtilization-området 0–400 %. | 1 minutter | procent |
Hukommelsesudnyttelse | Procentdelen af hukommelse, der bruges af containerne på en instans. Dette værdiområde er 0–100 %. | 1 minutter | procent |
GPUUtilisation | Procentdelen af GPU-enheder, der bruges af containerne på en forekomst. Værdien kan variere mellem 0-100 og ganges med antallet af GPU'er. | 1 minutter | procent |
GPUMemoryUtilization | Procentdelen af GPU-hukommelse, der bruges af containerne på en instans. Værdiområdet er 0-100 og ganges med antallet af GPU'er. For eksempel, hvis der er fire GPU'er, er GPUMemoryUtilization-området 0–400 %. | 1 minutter | procent |
DiskUtilization | Den procentdel af diskplads, der bruges af containerne på en instans. Dette værdiområde er 0–100 %. | 1 minutter | procent |
Brug case oversigt
Vi bruger en simpel XGBoost-klassificeringsmodel til vores applikation og har besluttet at være vært for instanstypen ml.c5.large. Den følgende procedure er dog uafhængig af modellen eller implementeringskonfigurationen, så du kan anvende den samme tilgang til dit eget valg af applikation og implementering. Vi antager, at du allerede har en ønsket instanstype ved starten af denne proces. Hvis du har brug for hjælp til at bestemme den ideelle instanstype til din applikation, bør du bruge Inference Recommender standardjob for at få instanstypeanbefalinger.
Skaleringsplan
Skaleringsplanen er en procedure i tre trin, som illustreret i følgende diagram:
- Identificer applikationens karakteristika – At kende flaskehalsene i applikationen på den valgte hardware er en væsentlig del af dette.
- Indstil skaleringsforventninger – Dette involverer at bestemme det maksimale antal anmodninger pr. sekund, og hvordan anmodningsmønsteret vil se ud (om det vil være glat eller spidst).
- Ansøg og vurder – Skaleringspolitikker bør udvikles baseret på applikationskarakteristika og skaleringsforventninger. Som en del af dette sidste trin skal du evaluere politikkerne ved at køre den belastning, den forventes at håndtere. Derudover anbefaler vi at gentage det sidste trin, indtil skaleringspolitikken kan håndtere anmodningsbelastningen.
Identificer applikationskarakteristika
I dette afsnit diskuterer vi metoderne til at identificere applikationskarakteristika.
Benchmarking
For at udlede den rigtige skaleringspolitik er det første trin i planen at bestemme applikationsadfærd på den valgte hardware. Dette kan opnås ved at køre applikationen på en enkelt vært og gradvist øge anmodningsbelastningen til slutpunktet, indtil den er mættet. I mange tilfælde, efter mætning, kan slutpunktet ikke længere håndtere flere anmodninger, og ydeevnen begynder at blive dårligere. Dette kan ses i endpoint invocation metrics. Vi anbefaler også, at du gennemgår hardwareudnyttelsesmålinger og forstår eventuelle flaskehalse. For CPU-forekomster kan flaskehalsen være i CPU-, hukommelses- eller diskudnyttelsesmetrikken, mens flaskehalsen for GPU-forekomster kan være i GPU-udnyttelsen og dens hukommelse. Vi diskuterer invokationer og udnyttelsesmetrikker på ml.c5.large hardware i det følgende afsnit. Det er også vigtigt at huske, at CPU-udnyttelsen er aggregeret på tværs af alle kerner, derfor er den på 200 % skala for en ml.c5.large to-core maskine.
Til benchmarking bruger vi standardjobbet Inference Recommender. Inference Recommender standardjob vil som standard benchmarke med flere instanstyper. Du kan dog indsnævre søgningen til din valgte instanstype ved at videregive dem i understøttede instanser. Tjenesten, der så klargør endepunktet, øger gradvist anmodningen og stopper, når benchmarken når mætning, eller hvis endepunktkaldet API-kald mislykkes for 1 % af resultaterne. Hosting-metrikken kan bruges til at bestemme hardwaregrænserne og indstille den rigtige skaleringsgrænse. I tilfælde af, at der er en hardwareflaskehals, anbefaler vi, at du skalerer instansstørrelsen op i samme familie eller ændrer instansfamilien helt.
Følgende diagram illustrerer arkitekturen for benchmarking ved hjælp af Inference Recommender.
Brug følgende kode:
def trigger_inference_recommender(model_url, payload_url, container_url, instance_type, execution_role, framework, framework_version, domain="MACHINE_LEARNING", task="OTHER", model_name="classifier", mime_type="text/csv"): model_package_arn = create_model_package(model_url, payload_url, container_url, instance_type, framework, framework_version, domain, task, model_name, mime_type) job_name = create_inference_recommender_job(model_package_arn, execution_role) wait_for_job_completion(job_name) return job_name
Analyser resultatet
Vi analyserer derefter resultaterne af anbefalingsjobbet ved hjælp af endpoint-metrics. Fra den følgende hardwareudnyttelsesgraf bekræfter vi, at hardwaregrænserne er inden for grænserne. Desuden øges CPUUtilization-linjen proportionalt med anmodningsbelastning, så det er nødvendigt også at have skaleringsgrænser for CPU-udnyttelse.
Fra den følgende figur bekræfter vi, at invokationen flader ud, efter at den når sit højdepunkt.
Dernæst går vi videre til påkaldelser og latency-metrikker til indstilling af skaleringsgrænsen.
Find skaleringsgrænser
I dette trin kører vi forskellige skaleringsprocenter for at finde den rigtige skaleringsgrænse. Som en generel skaleringsregel bør hardwareudnyttelsesprocenten være omkring 40 %, hvis du optimerer for tilgængelighed, omkring 70 %, hvis du optimerer for omkostninger, og omkring 50 %, hvis du vil balancere tilgængelighed og omkostninger. Vejledningen giver et overblik over de to dimensioner: tilgængelighed og pris. Jo lavere tærskel, jo bedre tilgængelighed. Jo højere tærsklen er, jo bedre omkostninger. I den følgende figur plottede vi grafen med 55 % som den øvre grænse og 45 % som den nedre grænse for invokationsmetrikker. Den øverste graf viser påkaldelser og latency-metrics; den nederste graf viser udnyttelsesmålinger.
Du kan bruge følgende eksempelkode til at ændre procentsatserne og se, hvad grænserne er for påkaldelser, latenstid og udnyttelsesmetrikker. Vi anbefaler stærkt, at du leger med procenter og finder den bedste pasform baseret på dine metrics.
def analysis_inference_recommender_result(job_name, index=0, upper_threshold=80.0, lower_threshold=65.0):
Fordi vi ønsker at optimere for tilgængelighed og omkostninger i dette eksempel, besluttede vi at bruge 50 % samlet CPU-udnyttelse. Da vi valgte en maskine med to kerner, er vores samlede CPU-udnyttelse 200 %. Vi sætter derfor en tærskel på 100 % for CPU-udnyttelse, fordi vi laver 50 % for to kerner. Ud over udnyttelsestærsklen sætter vi også InvocationPerInstance-tærsklen til 5000. Værdien for InvocationPerInstance udledes ved at overlejre CPUUtilization = 100 % over invokationsgrafen.
Som en del af trin 1 i skaleringsplanen (vist i den følgende figur), benchmarkerede vi applikationen ved hjælp af standardjobbet Inference Recommender, analyserede resultaterne og bestemte skaleringsgrænsen baseret på omkostninger og tilgængelighed.
Indstil skaleringsforventninger
Næste skridt er at opstille forventninger og udvikle skaleringspolitikker baseret på disse forventninger. Dette trin involverer at definere maksimum- og minimumsanmodninger, der skal leveres, samt yderligere detaljer, som f.eks. hvad er den maksimale anmodningsvækst, som applikationen skal håndtere? Er det jævnt eller spidst trafikmønster? Data som denne vil hjælpe med at definere forventningen og hjælpe dig med at udvikle en skaleringspolitik, der imødekommer din efterspørgsel.
Følgende diagram illustrerer et eksempel på et trafikmønster.
For vores applikation er forventningerne maksimale anmodninger pr. sekund (max) = 500, og minimumsanmodninger pr. sekund (min) = 70.
Baseret på disse forventninger definerer vi MinCapacity og MaxCapacity ved hjælp af følgende formel. For de følgende beregninger normaliserer vi InvocationsPerInstance til sekunder, fordi det er pr. minut. Derudover definerer vi vækstfaktor, som er mængden af yderligere kapacitet, som du er villig til at tilføje, når din skala overstiger de maksimale anmodninger pr. sekund. Vækstfaktoren skal altid være større end 1, og den er essentiel i planlægningen af yderligere vækst.
MinCapacity = ceil(min / (InvocationsPerInstance/60) )
MaxCapacity = ceil(max / (InvocationsPerInstance/60)) * Growth_factor
I sidste ende kommer vi frem til MinCapacity = 1 og MaxCapacity = 8 (med 20% som vækstfaktor), og vi planlægger at håndtere et spidst trafikmønster.
Definer skaleringspolitikker og bekræft
Det sidste trin er at definere en skaleringspolitik og evaluere dens virkning. Evalueringen tjener til at validere resultaterne af de hidtidige beregninger. Derudover hjælper det os med at justere skaleringsindstillingen, hvis den ikke opfylder vores behov. Evalueringen udføres ved hjælp af Inference Recommender avanceret job, hvor vi specificerer trafikmønsteret, MaxInvocations og endepunkt, der skal benchmarkes imod. I dette tilfælde klargør vi slutpunktet og indstiller skaleringspolitikkerne og kører derefter det avancerede job Inference Recommender for at validere politikken.
Målsporing
Det anbefales at opsætte målsporing baseret på InvocationsPerInstance. Tærsklen er allerede blevet defineret i trin 1, så vi sætter CPUUtilization-tærsklen til 100 og InvocationsPerInstance-tærsklen til 5000. Først definerer vi en skaleringspolitik baseret på antallet af InvocationsPerInstance, og derefter opretter vi en skaleringspolitik, der er afhængig af CPU udnyttelse.
Som i eksempelnotesbogen bruger vi følgende funktioner til at registrere og indstille skaleringspolitikker:
def set_target_scaling_on_invocation(endpoint_name, variant_name, target_value, scale_out_cool_down=10, scale_in_cool_down=100): policy_name = 'target-tracking-invocations-{}'.format(str(round(time.time()))) resource_id = "endpoint/{}/variant/{}".format(endpoint_name, variant_name) response = aas_client.put_scaling_policy( PolicyName=policy_name, ServiceNamespace='sagemaker', ResourceId=resource_id, ScalableDimension='sagemaker:variant:DesiredInstanceCount', PolicyType='TargetTrackingScaling', TargetTrackingScalingPolicyConfiguration={ 'TargetValue': target_value, 'PredefinedMetricSpecification': { 'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance', }, 'ScaleOutCooldown': scale_out_cool_down, 'ScaleInCooldown': scale_in_cool_down, 'DisableScaleIn': False } ) return policy_name, response def set_target_scaling_on_cpu_utilization(endpoint_name, variant_name, target_value, scale_out_cool_down=10, scale_in_cool_down=100): policy_name = 'target-tracking-cpu-util-{}'.format(str(round(time.time()))) resource_id = "endpoint/{}/variant/{}".format(endpoint_name, variant_name) response = aas_client.put_scaling_policy( PolicyName=policy_name, ServiceNamespace='sagemaker', ResourceId=resource_id, ScalableDimension='sagemaker:variant:DesiredInstanceCount', PolicyType='TargetTrackingScaling', TargetTrackingScalingPolicyConfiguration={ 'TargetValue': target_value, 'CustomizedMetricSpecification': { 'MetricName': 'CPUUtilization', 'Namespace': '/aws/sagemaker/Endpoints', 'Dimensions': [ {'Name': 'EndpointName', 'Value': endpoint_name}, {'Name': 'VariantName', 'Value': variant_name} ], 'Statistic': 'Average', 'Unit': 'Percent' }, 'ScaleOutCooldown': scale_out_cool_down, 'ScaleInCooldown': scale_in_cool_down, 'DisableScaleIn': False } ) return policy_name, response
Fordi vi skal håndtere spidse trafikmønstre, bruger prøvenotebooken ScaleOutCooldown = 10 og ScaleInCooldown = 100 som nedkølingsværdier. Mens vi evaluerer politikken i næste trin, planlægger vi at justere nedkølingsperioden (hvis det er nødvendigt).
Evalueringsmålsporing
Evalueringen udføres ved hjælp af Inference Recommender avanceret job, hvor vi specificerer trafikmønsteret, MaxInvocations og endepunkt, der skal benchmarkes imod. I dette tilfælde klargør vi slutpunktet og indstiller skaleringspolitikkerne og kører derefter det avancerede job Inference Recommender for at validere politikken.
from inference_recommender import trigger_inference_recommender_evaluation_job
from result_analysis import analysis_evaluation_result eval_job = trigger_inference_recommender_evaluation_job(model_package_arn=model_package_arn, execution_role=role, endpoint_name=endpoint_name, instance_type=instance_type, max_invocations=max_tps*60, max_model_latency=10000, spawn_rate=1) print ("Evaluation job = {}, EndpointName = {}".format(eval_job, endpoint_name)) # In the next step, we will visualize the cloudwatch metrics and verify if we reach 30000 invocations.
max_value = analysis_evaluation_result(endpoint_name, variant_name, job_name=eval_job) print("Max invocation realized = {}, and the expecation is {}".format(max_value, 30000))
Efter benchmarking visualiserede vi invokationsgrafen for at forstå, hvordan systemet reagerer på skaleringspolitikker. Den skaleringspolitik, vi har etableret, kan håndtere anmodningerne og kan nå op til 30,000 påkaldelser uden fejl.
Lad os nu overveje, hvad der sker, hvis vi tredobler antallet af nye brugere. Gælder den samme politik? Vi kan køre det samme evalueringssæt igen med en højere anmodningshastighed og indstille spawn-hastigheden (en ekstra bruger pr. minut) til 3.
Med ovenstående resultat bekræfter vi, at den nuværende auto-skaleringspolitik kan dække selv det aggressive trafikmønster.
Trinskalering
Ud over målsporing anbefaler vi også at bruge trinskalering for at få bedre kontrol over aggressiv trafik. Derfor definerede vi en ekstra trinskala med skaleringsjusteringer for at håndtere spids trafik.
def set_step_scaling(endpoint_name, variant_name): policy_name = 'step-scaling-{}'.format(str(round(time.time()))) resource_id = "endpoint/{}/variant/{}".format(endpoint_name, variant_name) response = aas_client.put_scaling_policy( PolicyName=policy_name, ServiceNamespace='sagemaker', ResourceId=resource_id, ScalableDimension='sagemaker:variant:DesiredInstanceCount', PolicyType='StepScaling', StepScalingPolicyConfiguration={ 'AdjustmentType': 'ChangeInCapacity', 'StepAdjustments': [ { 'MetricIntervalLowerBound': 0.0, 'MetricIntervalUpperBound': 5.0, 'ScalingAdjustment': 1 }, { 'MetricIntervalLowerBound': 5.0, 'MetricIntervalUpperBound': 80.0, 'ScalingAdjustment': 3 }, { 'MetricIntervalLowerBound': 80.0, 'ScalingAdjustment': 4 }, ], 'MetricAggregationType': 'Average' }, ) return policy_name, response
Skalering af evalueringstrin
Vi følger derefter det samme trin for at evaluere, og efter benchmark bekræfter vi, at skaleringspolitikken kan håndtere et spidst trafikmønster og nå op på 30,000 opkald uden fejl.
Derfor er det en nødvendig del af valideringen at definere skaleringspolitikkerne og evaluere resultaterne ved hjælp af Inference Recommender.
Yderligere tuning
I dette afsnit diskuterer vi yderligere indstillingsmuligheder.
Flere skaleringsmuligheder
Som vist i vores use case, kan du vælge flere skaleringspolitikker, der opfylder dine behov. Ud over de tidligere nævnte muligheder, bør du også overveje planlagt skalering, hvis du forudser trafik i en periode. Kombinationen af skaleringspolitikker er kraftfuld og bør evalueres ved hjælp af benchmarkingværktøjer som Inference Recommender.
Skaler op eller ned
SageMaker Hosting tilbyder over 100 instanstyper til at være vært for din model. Din trafikbelastning kan være begrænset af den hardware, du har valgt, så overvej anden hosting-hardware. For eksempel, hvis du vil have et system til at håndtere 1,000 anmodninger i sekundet, skal du opskalere i stedet for ud. Accelerator-instanser som G5 og Inf1 kan behandle et højere antal anmodninger på en enkelt vært. Op- og nedskalering kan give bedre modstandskraft til nogle trafikbehov end at skalere ind og ud.
Tilpassede metrics
Ud over InvocationsPerInstance og andre SageMaker-hosting-metrics kan du også definere metrics til skalering af din applikation. Alle brugerdefinerede målinger, der bruges til skalering, bør dog vise systemets belastning. Målingerne bør stige i værdi, når udnyttelsen er høj, og falde ellers. De tilpassede metrics kunne give mere detaljerede oplysninger om belastningen og hjælpe med at definere tilpassede skaleringspolitikker.
Justering af skaleringsalarm
Ved at definere skaleringspolitikken opretter du en alarm til skalering, og disse alarmer bruges til at skalere ind og ud. Disse alarmer har dog et standardantal af datapunkter, hvorpå de bliver advaret. Hvis du ønsker at ændre antallet af datapunkter for alarmen, kan du gøre det. Ikke desto mindre, efter enhver opdatering af skaleringspolitikker, anbefales det at evaluere politikken ved at bruge et benchmarkingværktøj med den belastning, det skal håndtere.
Konklusion
Processen med at definere skaleringspolitikken for din applikation kan være udfordrende. Du skal forstå applikationens karakteristika, bestemme dine skaleringsbehov og gentage skaleringspolitikker for at imødekomme disse behov. Dette indlæg har gennemgået hvert af disse trin og forklaret den tilgang, du bør tage ved hvert trin. Du kan finde dine applikationsegenskaber og evaluere skaleringspolitikker ved at bruge Inference Recommender-benchmarking-systemet. Det foreslåede designmønster kan hjælpe dig med at oprette en skalerbar applikation inden for timer, snarere end dage, der tager højde for tilgængeligheden og omkostningerne ved din applikation.
Om forfatterne
Mohan Gandhi er senior softwareingeniør hos AWS. Han har været hos AWS i de sidste 10 år og har arbejdet på forskellige AWS-tjenester som EMR, EFA og RDS. I øjeblikket er han fokuseret på at forbedre SageMaker Inference Experience. I sin fritid nyder han at vandre og maratonløb.
Vikram Elango er en AI/ML Specialist Solutions Architect hos Amazon Web Services, baseret i Virginia USA. Vikram hjælper finans- og forsikringsbranchens kunder med design, tankelederskab til at bygge og implementere maskinlæringsapplikationer i stor skala. Han er i øjeblikket fokuseret på naturlig sprogbehandling, ansvarlig AI, inferensoptimering og skalering af ML på tværs af virksomheden. I sin fritid nyder han at rejse, vandre, lave mad og campere med sin familie.
Venkatesh Krishnan leder Product Management for Amazon SageMaker i AWS. Han er produktejer for en portefølje af SageMaker-tjenester, der gør det muligt for kunder at implementere maskinlæringsmodeller til Inference. Tidligere var han Head of Product, Integrations og den ledende produktchef for Amazon AppFlow, en ny AWS-tjeneste, som han hjalp med at bygge fra bunden. Før han kom til Amazon i 2018, tjente Venkatesh i forskellige forsknings-, ingeniør- og produktroller hos Qualcomm, Inc. Han har en ph.d. i elektro- og computerteknik fra Georgia Tech og en MBA fra ULCA's Anderson School of Management.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/optimize-your-machine-learning-deployments-with-auto-scaling-on-amazon-sagemaker/
- 000
- 1
- 10
- 100
- 2018
- 7
- 70
- 9
- a
- I stand
- Om
- over
- accelerator
- Konto
- opnå
- opnået
- tværs
- aktiv
- tilføjet
- Desuden
- Yderligere
- Derudover
- vedtage
- fremskreden
- Efter
- mod
- aggressive
- AI
- AI / ML
- alarm
- Alle
- tillader
- allerede
- Skønt
- altid
- Amazon
- Amazon SageMaker
- Amazon Web Services
- beløb
- analysere
- ,
- Forventet
- api
- Anvendelse
- applikationer
- anvendt
- Indløs
- Anvendelse
- tilgang
- arkitektur
- omkring
- udseende
- Assistance
- Godkendelse
- tilladelse
- auto
- Automatisk Ur
- automatisk
- tilgængelighed
- gennemsnit
- AWS
- Balance
- baseret
- fordi
- bliver
- før
- bag
- benchmark
- benchmarkes
- benchmarking
- BEDSTE
- Bedre
- mellem
- Bund
- brud
- bringe
- Bringer
- bred
- bygge
- Bygning
- bygget
- byrde
- virksomhed
- beregninger
- ringe
- kaldet
- Kapacitet
- tilfælde
- tilfælde
- udfordrende
- lave om
- Ændringer
- karakteristika
- valg
- Vælg
- valgt
- klasser
- kunde
- kode
- kombination
- kombinerer
- almindeligt
- Kommunikation
- fuldføre
- Compute
- computer
- Computer Engineering
- Konfiguration
- Bekræfte
- Overvej
- Container
- Beholdere
- kontrol
- Core
- Koste
- omkostningseffektiv
- Omkostninger
- kunne
- dæksel
- skabe
- Oprettelse af
- Nuværende
- For øjeblikket
- skik
- Kunder
- data
- datapunkter
- Dage
- besluttede
- falde
- Standard
- definerede
- definere
- Efterspørgsel
- Afhængigt
- indsætte
- indsat
- implementering
- implementeringer
- Afledt
- Design
- ønskes
- detaljer
- Bestem
- bestemmes
- bestemmelse
- udvikle
- udviklet
- forskellige
- størrelse
- direkte
- diskutere
- Er ikke
- gør
- domæne
- Dont
- ned
- tegning
- dynamisk
- hver
- tidligere
- effektivt
- Uddybe
- muliggøre
- Endpoint
- ingeniør
- Engineering
- Enterprise
- helt
- Miljø
- fejl
- fejl
- væsentlig
- etableret
- evaluere
- evalueret
- evaluere
- evaluering
- Endog
- begivenhed
- Hver
- eksempel
- overstiger
- Dyrke motion
- forventning
- forventninger
- forventet
- erfaring
- forklarede
- faktorer
- mislykkes
- familie
- Funktionalitet
- Figur
- endelige
- finansielle
- Finde
- Fornavn
- passer
- fokuserede
- følger
- efter
- Forecast
- Formula
- Framework
- Frekvens
- fra
- fuldt ud
- funktioner
- yderligere
- Endvidere
- Generelt
- generere
- genereret
- Georgien
- få
- given
- giver
- GPU
- GPU'er
- gradvist
- graf
- større
- Ground
- Vækst
- håndtere
- sker
- Hardware
- hoved
- hjælpe
- hjulpet
- hjælper
- Høj
- højere
- stærkt
- besidder
- host
- hostede
- Hosting
- HOURS
- Hvordan
- Men
- HTML
- HTTPS
- ideal
- identificere
- KIMOs Succeshistorier
- importere
- vigtigt
- forbedring
- in
- Inc.
- omfatter
- omfatter
- Herunder
- Forøg
- Stigninger
- stigende
- uafhængig
- individuel
- industrien
- Infrastruktur
- indsigt
- instans
- i stedet
- forsikring
- integrere
- integrationer
- IT
- Job
- Karriere
- sammenføjning
- Kendskab til
- kendt
- Sprog
- stor
- Efternavn
- Latency
- føre
- Leadership" (virkelig menneskelig ledelse)
- Leads
- læring
- Lets
- Niveau
- GRÆNSE
- Limited
- grænser
- Line (linje)
- Liste
- belastning
- lokale
- længere
- Se
- maskine
- machine learning
- lavet
- maerker
- administrere
- lykkedes
- ledelse
- leder
- mange
- max
- maksimal
- Mød
- opfylder
- Hukommelse
- nævnte
- metode
- metoder
- metrisk
- Metrics
- minimum
- minut
- ML
- model
- modeller
- mere
- mest
- bevæge sig
- flere
- ganget
- navn
- Natural
- Natural Language Processing
- nødvendig
- Behov
- behov
- netværk
- Ikke desto mindre
- Ny
- næste
- notesbog
- nummer
- numre
- opnå
- Tilbud
- ONE
- online
- operationelle
- optimering
- Optimer
- optimering
- Option
- Indstillinger
- ordrer
- Andet
- Ellers
- samlet
- oversigt
- egen
- ejer
- del
- Passing
- Mønster
- mønstre
- Betal
- Peak
- procent
- procentdel
- ydeevne
- periode
- pick
- fly
- planlægning
- plato
- Platon Data Intelligence
- PlatoData
- Leg
- punkter
- politikker
- politik
- portefølje
- Indlæg
- vigtigste
- Forudsigelser
- forberede
- tidligere
- behandle
- forarbejdning
- Produkt
- produktstyring
- produktchef
- produktion
- Produkter
- foreslog
- give
- giver
- bestemmelse
- sætte
- Qualcomm
- hurtigt
- rækkevidde
- Sats
- nå
- når
- ægte
- realtid
- gik op for
- modtager
- anbefaler
- Anbefaling
- anbefalinger
- anbefales
- tilbagevendende
- reducere
- register
- registrering
- huske
- Fjern
- anmode
- anmodninger
- krav
- Krav
- forskning
- modstandskraft
- Svar
- svar
- ansvarlige
- resultere
- Resultater
- afkast
- afkast
- gennemgå
- revideret
- roller
- Herske
- Kør
- kører
- sagemaker
- SageMaker Inference
- samme
- skalerbar
- Scale
- skalering
- planlægge
- planlagt
- Skole
- Søg
- Anden
- sekunder
- Sektion
- valgt
- valg
- senior
- tjener
- tjener
- tjeneste
- Tjenester
- sæt
- indstilling
- setup
- Shadow
- bør
- vist
- Shows
- Simpelt
- forenklet
- enkelt
- Størrelse
- størrelser
- So
- indtil nu
- Software
- Software Engineer
- Løsninger
- nogle
- Space
- specialist
- delt
- starte
- Trin
- Steps
- stopper
- opbevaring
- sådan
- Understøttet
- Understøtter
- systemet
- systemisk
- Tag
- tager
- mål
- Opgaver
- tech
- Grafen
- deres
- derfor
- Tredje
- tænkte
- tænkt lederskab
- tre
- tre-trins
- tærskel
- kapacitet
- tid
- gange
- til
- værktøj
- værktøjer
- top
- Sporing
- Trafik
- Kurser
- Traveling
- Triple
- typer
- typisk
- allestedsnærværende
- forstå
- enestående
- enhed
- enheder
- Opdatering
- us
- USA
- brug
- brug tilfælde
- Bruger
- VALIDATE
- validering
- værdi
- Værdier
- Variant
- række
- forskellige
- verificere
- via
- Virginia
- måder
- web
- webservices
- Hvad
- Hvad er
- hvorvidt
- som
- mens
- vilje
- villig
- inden for
- uden
- Arbejde
- arbejdede
- virker
- XGBoost
- år
- Du
- Din
- zephyrnet