Kulusäästlik ML-i järeldus Amazon SageMakeri mitme raamistiku mudelite abil 

Masinõpe (ML) on osutunud üheks edukamaks ja laialdasemalt levinud tehnoloogiarakenduseks, mis mõjutab paljusid tööstusharusid ja mõjutab iga päev miljardeid kasutajaid. Tänu ML-i kiirele kasutuselevõtule igas tööstusharus seisavad ettevõtted silmitsi väljakutsetega madala latentsusajaga prognooside toetamisel ja kõrgel saadavusel, maksimeerides samal ajal ressursside kasutamist ja vähendades sellega seotud kulusid. Kuna igal ML-raamistikul on oma sõltuvused ja iga raamistiku juurutamisetapid on erinevad, muutub erinevatesse raamistikesse ehitatud mudelite juurutamine tootmises ja iga lõpp-punkti haldamine üha keerulisemaks.

Amazon SageMaker multi-container endpoints (MCE) võimaldab meil rühmitada mudeleid erinevatel raamistikel ja juurutada need samasse hosti, luues ühe lõpp-punkti. Saate pakkuda konteinereid erinevate raamistike jaoks, mida mudelite koostamiseks kasutate, ja SageMaker võtab kõik need konteinerid ja asetab need ühe lõpp-punkti taha. Näiteks võite lasta PyTorchi ja TensorFlow mudeli laadida kahele pühendatud lõpp-punktile, mis teenindavad samu või täiesti erinevaid kasutusjuhtumeid, ja mõlemal mudelil on katkendlik sissetulev liiklus, mis ei kasuta ressursse maksimaalselt. Sellise stsenaariumi korral võiksite need koondada konteinerite abil ühte lõpp-punkti, kasutades MCE-d, parandades ressursside kasutamist, vähendades samal ajal kulusid, mis tekivad, kui mõlemad mudelid teenindavad erinevatest lõpp-punktidest.

Mitme konteineri lõpp-punktid pakuvad skaleeritavat ja kulutõhusat lahendust kuni 15 mudeli juurutamiseks, mis on üles ehitatud erinevatele ML-raamistikele, mudeliserveritele ja algoritmidele, mis teenindavad sama või erinevat kasutusjuhtumit, mis tähendab, et teil võivad olla mudelid, mis on üles ehitatud erinevatele ML-raamistikele või vahendajatele. kõigi nende konteinerite ja mudelite vahel. Kõigile nendele mudelitele pääseb juurde eraldi otsekutsumise kaudu või ühendatakse need konveierisse, kasutades jadakutset, kus ühe mudeli väljund on järgmise mudeli sisend.

Selles postituses arutame, kuidas teha kulutõhusaid ML-i järeldusi mitme raamistiku mudelitega SageMakeris.

MCE kutsumismustrid

SageMaker MCE otsekutsumine on kasulik juhtudel, kui olete ühendanud sõltumatud mudelid MCE lõpp-punkti või teete MCE lõpp-punkti taga olevate mudelite vahel A/B-testi, et hinnata nende toimivust. Saate helistada konkreetsele konteinerile otse API-kõnes ja saada selle mudeli prognoosi.

Jadakutsega saate kokku õmmelda 2–15 konteinerit ja ühe väljundist saab järjestikku järgmise konteineri sisend. See on ideaalne kasutusjuhtum, kui teil on näiteks mitmeastmeline ennustuskonveier, kus vahepealse prognoosi jaoks kasutatakse Scikit-learni mudelit ja tulemus edastatakse lõplikuks järelduseks TensorFlow mudelisse. Selle asemel, et neid juurutada erinevate lõpp-punktidena ja neid korraldada muul rakendusel või tööl ning teha mitu API-kutset, saate need juurutada SageMakeri MCE-na, võttes loogikast välja ja seadistades need jadakutseks, kus SageMaker haldab andmeedastust ühe konteineri vahel. automaatselt teisele ja saadab lõpliku konteineri väljundi API päringu esitavale kliendile.

SageMaker MCE seeriakutse erineb põhimõtteliselt SageMakeri jadajärelduskonveierist (üksikasju leiate allolevatest jaotistest). Jadajärelduskonveier on rohkem suunatud keerukate ML-i töövoogude korraldamiseks, nagu andmete eeltöötlus, mudelite komplekti loomine, tingimuslike kontrollide rakendamine, et määrata, millist mudelit kutsuda, või ennustuse järeltöötlus, mis hõlmab äriloogikat enne ennustuse saatmist allavoolu rakendustele. . Seevastu MCE seeriakutse on mõeldud 2–14 mudeli ühendamiseks konveieriks järelduste tegemiseks, kusjuures iga mudel kasutab sisendina eelmise mudeli ennustust.

Kõik MCE konteinerid on alati teeninduses ja mälus, nii et lõpp-punkti kutsumisel ei toimu külmkäivitust. MCE-d parandavad ka lõpp-punkti kasutamist ja suurendavad kulusid, kuna mudelid juurutatakse ühe lõpp-punkti taha ja jagavad aluseks olevat arvutuseksemplari, selle asemel, et iga mudel hõivaks individuaalseid arvutusressursse.

Vaatame mõningaid kasutusjuhtumeid ja vaatame, kuidas saate SageMakeri MCE-sid kasutada ML-i järelduste optimeerimiseks.

Kasutusjuhtumid SageMaker MCE-de jaoks

Oletame, et teil on arvamuste klassifitseerimiseks kaks mudelit, üks inglise ja teine ​​saksa keele jaoks, ning need mudelid teenindavad eri geograafilisi piirkondi ja liiklust saabub päeva eri aegadel. Selle asemel, et kaks lõpp-punkti töötaksid ööpäevaringselt, saate need mõlemad MCE abil ühte lõpp-punkti juurutada ja neile otsekutsega juurde pääseda, optimeerides seeläbi oma ressursikasutust ja kulusid. Vaadake järgmist koodi:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

Selles näites on meil kaks mudelit (englishModel ja germanModel) ja määratleme konteinerid rakenduses SageMaker create_model konstrueerida ja määratleda InferenceExecutionConfig kui "Otsene". Nüüd saame kutsuda lõpp-punkti järelduste tegemiseks ja määratleda TargetContainerHostname nagu kumbki englishModel or germanModel sõltuvalt API-kõnet tegevast kliendist:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Saate kasutada ka otsekutset MCE-s, et käitada A/B-teste, et võrrelda mudelite toimivust.

Järgmine diagramm illustreerib meie arhitektuuri.

Sarnaselt muudel ML-i kasutusjuhtudel, kui päringu töötlemiseks kasutatakse koolitatud mudelit, saab mudel andmeid vormingus, mida tuleb enne eeltöötlemist (näiteks esiletoomist), enne kui need saab edasi anda algoritmile järelduste tegemiseks. ML-algoritmide aheldamisel on ühe mudeli väljund enne lõpptulemuseni jõudmist sisendiks järgmisele. Sel juhul saate luua SageMaker MCE jadakonveieri, kus konteinerid räägivad üksteisega jaotises määratletud järjekorras. create_model konstrueerida selle asemel, et juurutada kõik mudelid erinevatesse lõpp-punktidesse ja kirjutada sõltumatu loogika, et hõlbustada andmevoogu kõigi nende mudelite ja API-kõnede vahel. Järgmine diagramm illustreerib seda arhitektuuri.

Sel kasutusjuhul kasutame järgmist koodi:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

Selles näites on meil kaks töötlemismahutit (Processing-1 ja Processing-2) funktsioonide töötlemiseks ja andmete teisendamiseks ning kaks järelduskonteinerit (Inference-1 ja Inference-2), et käitada eeltöödeldud andmetel ML-mudeli ennustusi. The PipelineModel eksemplar võimaldab teil määratleda järelduste konveieri, mis koosneb neljast konteinerist koosnevast lineaarsest jadast, mis töötleb andmete järeldamistaotlusi. Konteinerid asuvad samas eksemplaris, mis võimaldab teil teha järeldusi madala latentsusajaga.

Mitme mudeli lõpp-punktide skaleerimine suure hulga mudelite jaoks

SageMakeri mitme mudeli lõpp-punktide eelised suurenevad mudeli konsolideerimise ulatuse alusel. Kahe ühe lõpp-punktiga mudeli hostimisel näete kulude kokkuhoidu ning sadade või tuhandete mudelitega kasutusjuhtudel on kokkuhoid palju suurem.

MCE lõpp-punktide skaleerimine on samuti lihtne, kasutades SageMakerVariantInvocationsPerInstance eelmääratletud mõõdik, mis annab keskmise arvu kordi minutis, mil mudeli lõpp-punkti iga eksemplari käivitatakse, et määratleda TargetScaling poliitika. SageMaker kohandab dünaamiliselt mudeli jaoks ette nähtud eksemplaride arvu vastavalt teie töökoormuse muutustele. Kui töökoormus suureneb, toob automaatne skaleerimine võrku rohkem eksemplare ning laadib taotluste teenindamise jätkamiseks sihtmudelite ja konteineritega. Kui töökoormus väheneb, eemaldab automaatne skaleerimine mittevajalikud eksemplarid ja laadib mudelikonteinerid maha, nii et konteinerid ei sööks ressursse ja te ei maksa eksemplaride eest, mida te ei kasuta. Antud mudeliga seotud esimese taotluse täitmiseks kulub mudeli allalaadimiseks täiendav latentsusaeg (nn külmkäivitus). Amazoni lihtne salvestusteenus (Amazon S3) ja laadige see mällu. Järgmised kõned lõppevad ilma lisakuludeta, kuna mudel on juba laaditud. Vaadake järgmist koodi:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Järgides eelnevat poliitikakonfiguratsiooni näidet, kasutame SageMakerVariantInvocationsPerInstance eelmääratletud mõõdik, et kohandada variantide arvu nii, et igal eksemplaril oleks InvocationsPerInstance meeter 70.

Samuti saame SageMakeri MCE-sid skaleerida oma kohandatud mõõdiku alusel, näiteks CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationvõi DiskUtilization, et suurendada või vähendada eksemplaride arvu vastavalt konkreetse ressursi kasutamisele. Lisateabe saamiseks vaadake Skaleerige Amazon SageMakeri mudeleid automaatselt.

Soovitatav on, et igas konteineris olev mudel esitaks iga järelduspäringu puhul sarnaseid arvutus- ja latentsusnõudeid, sest kui liiklus MCE-sse nihkub kõrge protsessori kasutusega mudelilt madala CPU kasutusega mudelile, kuid kõne üldine maht jääb samaks, siis lõpp-punkt ei skaleerita ja juhtumeid ei pruugi olla piisavalt, et käsitleda kõiki kõrge protsessori kasutusega mudeli taotlusi.

Turvalised MCE-d

Otsese kutsumisega MCE-de puhul hostitakse ühes eksemplaris mitut konteinerit, jagades mälu ja salvestusmahtu. Oluline on kindlustada konteinerid, säilitada sihtkonteinerite päringute õige vastendamine ja pakkuda kasutajatele õiget juurdepääsu sihtkonteineritele. Saate piirata invoke_endpoint juurdepääs piiratud hulgale konteineritele MCE-s, kasutades sagemaker:TargetContainerHostname AWS-i identiteedi- ja juurdepääsuhaldus (IAM) tingimuse võti. SageMaker kasutab IAM-i rollid et pakkuda IAM-i identiteedipõhiseid eeskirju, mida kasutate lubatud või keelatud toimingute ja ressursside ning toimingute lubatud või keelamise tingimuste määramiseks. Järgmised eeskirjad näitavad, kuidas piirata kõnesid lõpp-punktis konkreetsetele konteineritele.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Jälgige mitme mudeli lõpp-punkte Amazon CloudWatchi mõõdikute abil

Hinna ja toimivuse kompromisside tegemiseks soovite testida mitme mudeli lõpp-punkte mudelite ja tüüpilise liiklusega oma rakendusest. SageMaker pakub täiendavaid mõõdikuid Amazon CloudWatch mitme mudeli lõpp-punktide jaoks, et saaksite määrata lõpp-punkti kasutuse ja vahemälu tabamussageduse ning optimeerida oma lõpp-punkti. Mõõdikud on järgmised:

• ModelLoadingWaitTime – Ajavahemik, mille jooksul kutsumistaotlus ootab sihtmudeli allalaadimist või laadimist, et teha järeldus.
• ModelUnloadingTime – Ajavahemik, mis kulub mudeli mahalaadimiseks läbi konteineri UnloadModel API kõne.
• Mudeli allalaadimise aeg – Ajavahemik, mis kulub mudeli Amazon S3-st allalaadimiseks.
• Mudeli laadimise aeg – Ajavahemik, mis kulub mudeli laadimiseks läbi konteineri LoadModel API kõne.
• ModelCacheHit – arv InvokeEndpoint päringud, mis saadeti lõpp-punkti, kus mudel oli juba laaditud. Võttes Average statistika näitab nende päringute suhet, milles mudel oli juba laaditud.
• LoadedModelCount – lõpp-punkti konteineritesse laaditud mudelite arv. See mõõdik väljastatakse eksemplari kohta. The Average 1-minutilise perioodiga statistika näitab teile eksemplari kohta laaditud mudelite keskmist arvu ja Sum statistika näitab kõigi lõpp-punkti eksemplaride jaoks laaditud mudelite koguarvu. Mudelid, mida see mõõdik jälgib, ei pruugi olla ainulaadsed, kuna saate laadida mudeli lõpp-punktis mitmesse konteinerisse.

Iga eksemplaril töötav konteiner kasutab ka mitmeid muid mõõdikuid, näiteks Invocations märkides numbri InvokeEndpoint lõpp-punktis olevasse konteinerisse saadetud päringud, ContainerLatency anda aeg, mis lõpp-punktil kulus, kuni sihtkonteiner või kõik seeriakutses olevad konteinerid reageerisid, nagu SageMakerist vaadatuna on näha, ja CPUUtilization ja MemoryUtilizaton näitab protsessori ühikuid ja mälu protsenti.

Järeldus

Postituses arutasime, kuidas SageMakeri mitme konteineri lõpp-punktid võivad olla abiks kulude ja ressursside kasutamise optimeerimisel. MCE-de kasutamise näited hõlmavad, kuid ei ole nendega piiratud, järgmist:

• Majutusmudelid erinevates raamistikes (nt TensorFlow, PyTorch ja Scikit-learn), millel pole eksemplari täisvõimsuse küllastamiseks piisavalt liiklust
• Samast raamistikust pärit mudelite hostimine erinevate ML-algoritmide (nt soovitused, prognoosimine või klassifitseerimine) ja töötleja funktsioonidega
• Erinevates raamistiku versioonides (nt TensorFlow 1.x vs. TensorFlow 2.x) töötavate sarnaste arhitektuuride võrdlused selliste stsenaariumide jaoks nagu A/B testimine

SageMaker MCE-d toetavad kuni 15 konteineri juurutamist reaalajas lõpp-punktides ja nende iseseisvat kutsumist madala latentsusajaga järelduste tegemiseks ja kulude kokkuhoiuks. Mudelid võivad olla täiesti heterogeensed ja neil on oma sõltumatu serveerimispakk. Saate neid konteinereid iga päringu jaoks käivitada järjestikku või eraldi. Mitme mudeli turvaline hostimine erinevatest raamistikest ühel eksemplaril võib säästa kuni 90% kulusid võrreldes mudelite hostimisega spetsiaalsetes ühe eksemplari lõpp-punktides.

Autoritest

Dhawal Patel on AWS-i peamine masinõppe arhitekt. Ta on hajutatud andmetöötluse ja tehisintellektiga seotud probleemide lahendamisel töötanud organisatsioonidega alates suurettevõtetest kuni keskmise suurusega idufirmadeni. Ta keskendub sügavale õppimisele, sealhulgas NLP ja arvutinägemise valdkondadele. Ta aitab klientidel teha Amazon SageMakeris suure jõudlusega mudeli järeldusi.

Vikram Elango on Ameerika Ühendriikides Virginias asuva Amazon Web Servicesi AI/ML-lahenduste vanemarhitekt. Vikram aitab globaalsetel finants- ja kindlustussektori klientidel projekteerimise ja ideede juhtimisel luua ja juurutada laiaulatuslikult masinõpperakendusi. Praegu on ta keskendunud loomuliku keele töötlemisele, vastutustundlikule AI-le, järelduste optimeerimisele ja ML-i skaleerimisele kogu ettevõttes. Vabal ajal meeldib talle perega reisida, matkata, süüa teha ja telkida.

Saurabh Trikande on Amazon SageMaker Inference'i vanemtootejuht. Ta on kirglik töö klientidega ja teda motiveerib eesmärk demokratiseerida masinõpe. Ta keskendub põhiprobleemidele, mis on seotud keeruliste ML-rakenduste, mitme rentniku ML-mudelite, kulude optimeerimise ja süvaõppemudelite juurutamise kättesaadavamaks muutmisega. Vabal ajal naudib Saurabh matkamist, uuenduslike tehnoloogiate õppimist, TechCrunchi jälgimist ja perega aega veetmist.