Költséghatékony ML következtetés az Amazon SageMaker több keretrendszerű modelljeivel 

A gépi tanulás (ML) a technológia egyik legsikeresebb és legelterjedtebb alkalmazásának bizonyult, amely számos iparágat érint, és naponta több milliárd felhasználót érint. Az ML gyors bevezetésével minden iparágban a vállalatok kihívásokkal néznek szembe az alacsony késleltetésű előrejelzések és a magas rendelkezésre állás támogatása terén, miközben maximalizálják az erőforrás-kihasználást és csökkentik a kapcsolódó költségeket. Mivel minden ML-keretrendszernek megvannak a saját függőségei, és az egyes keretrendszerek telepítési lépései eltérőek, a különböző keretrendszerekbe épített modellek üzembe helyezése a termelésben és az egyes végpontok kezelése egyre bonyolultabbá válik.

Amazon SageMaker A multi-container endpoints (MCE) lehetővé teszi, hogy modelleket csoportosítsunk különböző keretrendszereken, és telepítsük őket ugyanarra a gazdagépre, egyetlen végpontot létrehozva. Konténereket biztosíthat a modellek felépítéséhez használt különböző keretrendszerekhez, és a SageMaker ezeket a tárolókat veszi, és egy végpont mögé helyezi. Például betölthet egy PyTorch és egy TensorFlow modellt két dedikált végpontra, amelyek ugyanazt vagy teljesen eltérő használati eseteket szolgálnak ki, és mindkét modellben időszakos bejövő forgalom van, amely nem használja ki az erőforrásokat a korlátlanul. Egy ilyen forgatókönyvben konténerek használatával egyetlen végpontba egyesítheti őket egy MCE segítségével, javítva az erőforrás-kihasználást, miközben csökkenti a mindkét modell különböző végpontokról történő kiszolgálása során felmerülő költségeket.

A több tárolóból álló végpontok méretezhető és költséghatékony megoldást kínálnak akár 15 különböző ML-keretrendszerekre, modellkiszolgálókra és algoritmusokra épülő modell üzembe helyezéséhez, amelyek ugyanazt vagy eltérő használati esetet szolgálják ki, ami azt jelenti, hogy különböző ML-keretrendszerekre vagy közvetítőkre épülő modelleket készíthet. lépések ezeken a konténereken és modelleken. Mindezek a modellek külön-külön elérhetők közvetlen meghívással, vagy soros meghívással összefűzhetők egy folyamatba, ahol az egyik modell kimenete a következő bemenete.

Ebben a bejegyzésben megvitatjuk, hogyan lehet költséghatékony ML következtetést levonni több keretrendszerű modellekkel a SageMakeren.

MCE meghívási minták

A SageMaker MCE közvetlen meghívása olyan esetekben hasznos, amikor a nem kapcsolódó modelleket egy MCE-végpontba helyezte, vagy A/B-tesztet futtat az MCE-végpont mögötti modellek között, hogy felmérje a teljesítményüket. Meghívhatja az adott tárolót közvetlenül az API-hívásban, és lekérheti az előrejelzést az adott modellből.

Soros meghívással 2–15 tárolót fűzhet össze, és az egyik kimenete a sorrendben következő tároló bemenete lesz. Ez egy ideális felhasználási eset, ha például többlépcsős előrejelzési folyamattal rendelkezik, ahol egy Scikit-learn modellt használnak egy közbenső előrejelzéshez, és az eredményt egy TensorFlow modellbe táplálják a végső következtetéshez. Ahelyett, hogy különböző végpontokként telepítené őket, és egy másik alkalmazás vagy feladat hangszerelné őket, és több API-hívást kezdeményezne, telepítheti őket SageMaker MCE-ként, amely elvonatkoztatja a logikát, és beállítja őket soros hívásra, ahol a SageMaker kezeli az adatátvitelt egy tároló között. automatikusan egy másikra, és kiadja a végső tároló kimenetét az API-kérést benyújtó ügyfélnek.

A SageMaker MCE soros hívás alapvetően különbözik a SageMaker soros következtetési folyamattól (további részletek az alábbi szakaszokban). A soros következtetési folyamat inkább az összetett ML munkafolyamatok irányítására szolgál, mint például az adatok előfeldolgozása, a modellegyüttes felépítése, a feltételes ellenőrzések végrehajtása annak meghatározására, hogy melyik modellt hívja meg, vagy az előrejelzés utófeldolgozása, amely magában foglalja az üzleti logikát, mielőtt az előrejelzést elküldenék a downstream alkalmazásoknak. . Ezzel szemben az MCE soros hívást úgy tervezték, hogy 2–14 modellt egy folyamatba fűzzen össze következtetések levonásához, és mindegyik modell az előző modell előrejelzését veszi bemenetként.

Az MCE-ben lévő összes tároló mindig szolgáltatásban van és a memóriában van, így nincs hidegindítás a végpont meghívásakor. Az MCE-k javítják a végpontok kihasználtságát és növelik a költségeket is, mivel a modelleket egy végpont mögött helyezik üzembe, és megosztják a mögöttes számítási példányt, ahelyett, hogy minden modell egyedi számítási erőforrásokat foglalna el.

Nézzünk meg néhány használati esetet, és nézzük meg, hogyan használhatjuk a SageMaker MCE-ket az ML következtetések optimalizálására.

A SageMaker MCE-k használati esetei

Tegyük fel, hogy két modellje van a hangulatosztályozáshoz, az egyik az angol és a másik a német nyelvhez, és ezek a modellek különböző földrajzi területeket szolgálnak ki, és a forgalom egy nap különböző időpontjaiban érkezik. Ahelyett, hogy két végpont a hét minden napján, 24 órában futna, mindkettőt telepítheti egy végpontba egy MCE segítségével, és közvetlen hívás útján érheti el őket, így optimalizálhatja az erőforrás-kihasználást és a költségeket. Lásd a következő kódot:

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’)

Ebben a példában két modellünk van (englishModel és a germanModel), és meghatározzuk a tárolókat a SageMakerben create_model megkonstruálni és meghatározni a InferenceExecutionConfig „Közvetlen” néven. Most meghívhatjuk a végpontot következtetés céljából, és meghatározhatjuk a TargetContainerHostname mint akármelyik englishModel or germanModel az API-hívást végző ügyféltől függően:

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

Az MCE-n belüli közvetlen hívást is használhatja A/B tesztek futtatásához a modellek teljesítményének összehasonlításához.

Az alábbi ábra szemlélteti felépítésünket.

Hasonlóképpen, más ML felhasználási esetekben, amikor a betanított modellt egy kérés feldolgozására használják, a modell olyan formátumban kap adatokat, amelyet elő kell feldolgozni (például jellemzővé kell tenni), mielőtt átadnák az algoritmusnak következtetés céljából. Az ML algoritmusok összeláncolásakor az egyik modell kimenete bemenetként szolgál a következőhöz, mielőtt elérné a végeredményt. Ebben az esetben építhet SageMaker MCE soros csővezetéket, ahol a konténerek a create_model ahelyett, hogy az egyes modelleket különböző végpontokra telepítené, és független logikát írna, hogy megkönnyítse az adatok áramlását ezen modellek és API-hívások között. A következő diagram ezt az architektúrát szemlélteti.

Ebben az esetben a következő kódot használjuk:

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,...)

Ebben a példában két feldolgozó tárolónk van (Processing-1 és a Processing-2) jellemzők feldolgozásához és adatátalakításokhoz, valamint két következtetési konténer (Inference-1 és a Inference-2) ML modell előrejelzések futtatásához az előfeldolgozott adatokon. A PipelineModel példány lehetővé teszi egy négy konténer lineáris sorozatából álló következtetési folyamat meghatározását, amelyek feldolgozzák az adatokra vonatkozó következtetési kéréseket. A tárolók ugyanazon a példányon helyezkednek el, így alacsony késleltetéssel lehet következtetéseket lefuttatni.

Több modelles végpontok méretezése nagy számú modellhez

A SageMaker többmodelles végpontjainak előnyei a modellkonszolidáció mértéke alapján nőnek. Költségmegtakarítás érhető el, ha két modellt tárol egy végponttal, és több száz vagy több ezer modell esetén a megtakarítás sokkal nagyobb.

Az MCE-végpontok méretezése szintén egyszerű a SageMakerVariantInvocationsPerInstance előre definiált metrika, amely megadja, hogy percenként átlagosan hányszor hívják meg a modell végpontjának egyes példányait egy TargetScaling irányelv. A SageMaker dinamikusan módosítja a modellhez kiépített példányok számát a munkaterhelés változásai alapján. Amikor a munkaterhelés növekszik, az automatikus skálázás több példányt tesz online, és betöltődik a célmodellekkel és -tárolókkal, hogy folyamatosan kiszolgálja a kéréseket. Amikor a munkaterhelés csökken, az automatikus skálázás eltávolítja a szükségtelen példányokat, és tehermentesíti a modelltárolókat, így a tárolók nem fogyasztják az erőforrásokat, és nem kell fizetnie a nem használt példányokért. Az első kérés teljesítésének ideje egy adott modellhez további késleltetést (úgynevezett hidegindítást) tapasztal a modell letöltéséhez Amazon egyszerű tárolási szolgáltatás (Amazon S3), és töltse be a memóriába. A további hívások további többletköltség nélkül fejeződnek be, mert a modell már be van töltve. Lásd a következő kódot:

# 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
    }
)

Az előző példa házirend-konfigurációt követve a SageMakerVariantInvocationsPerInstance előre meghatározott metrika a változatpéldányok számának beállításához, hogy minden példány rendelkezzen egy InvocationsPerInstance 70-es mérőszám.

A SageMaker MCE-ket saját egyéni mérőszámunk alapján is méretezhetjük, mint pl CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationvagy DiskUtilization, a példányok számának növeléséhez vagy csökkentéséhez egy adott erőforrás felhasználása alapján. További információkért lásd: Automatikusan méretezheti az Amazon SageMaker modelleket.

Javasoljuk, hogy az egyes tárolókban lévő modellek hasonló számítási és késleltetési követelményeket mutassanak be minden következtetési kérésnél, mert ha az MCE-re irányuló forgalom a magas CPU kihasználtságú modellről egy alacsony CPU kihasználtságú modellre tolódik el, de a teljes hívásmennyiség változatlan marad, a végpont nem skálázódik ki, és előfordulhat, hogy nincs elég példány a magas CPU kihasználtságú modellhez intézett összes kérés kezelésére.

Biztonságos MCE-k

A közvetlen meghívással rendelkező MCE-k esetében több tárolót tárolnak egyetlen példányban a memória és a tárolókötet megosztásával. Fontos a tárolók biztonságossá tétele, a kérések megfelelő leképezése a céltárolókhoz, és a felhasználók számára a megfelelő hozzáférés biztosítása a céltárolókhoz. Korlátozhatod invoke_endpoint hozzáférést egy korlátozott számú konténerhez az MCE-ben a segítségével sagemaker:TargetContainerHostname AWS Identity and Access Management (IAM) feltétel kulcs. SageMaker használ IAM szerepek IAM identitás alapú házirendek biztosításához, amelyek segítségével megadhatja az engedélyezett vagy tiltott műveleteket és erőforrásokat, valamint azokat a feltételeket, amelyek mellett a műveletek engedélyezettek vagy megtagadtak. A következő házirendek bemutatják, hogyan korlátozhatja a hívásokat egy végponton belüli meghatározott tárolókra:

{
    "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*"]
                }
            }
        }
    ]
}

A többmodelles végpontok figyelése az Amazon CloudWatch mérőszámai segítségével

Az ár és a teljesítmény kompromisszumos megoldása érdekében érdemes több modellből álló végpontokat tesztelni a saját alkalmazásából származó modellekkel és reprezentatív forgalommal. A SageMaker további mutatókat biztosít amazonfelhőóra többmodell végpontokhoz, így meghatározhatja a végponthasználatot és a gyorsítótár találati arányát, és optimalizálhatja a végpontot. A mutatók a következők:

• ModelLoadingWaitTime – Az az időintervallum, ameddig egy hívási kérelem a célmodell letöltésére vagy betöltésére vár a következtetés végrehajtásához.
• ModelUnloadingTime – Az az időintervallum, amely alatt a modellt a konténeren keresztül kirakják UnloadModel API hívás.
• Modelletöltési idő – A modell Amazon S3-ról való letöltéséhez szükséges időintervallum.
• ModelLoadingTime – Az az időintervallum, amely alatt a modell betöltődik a konténeren keresztül LoadModel API hívás.
• ModelCacheHit - Száma InvokeEndpoint kéréseket küldenek arra a végpontra, ahol a modell már betöltött. Fogadva a Average A statisztika azon kérések arányát mutatja, amelyekben a modell már betöltődött.
• LoadedModelCount – A végpontban lévő tárolókba betöltött modellek száma. Ez a mérőszám példányonként kerül kiadásra. A Average Az 1 perces időtartamú statisztika megmutatja a példányonként betöltött modellek átlagos számát, és a Sum A statisztika megmutatja a végpont összes példányára betöltött modellek teljes számát. A metrika által nyomon követett modellek nem feltétlenül egyediek, mert egy modellt több tárolóba is betölthet a végpontban.

Számos egyéb mérőszám is létezik, amelyeket minden egyes példányon futó tároló használ, mint pl Invocations számának feltüntetésével InvokeEndpoint végponton belüli tárolóba küldött kérések, ContainerLatency megadja azt az időt, amely alatt egy végpont a céltárolónak vagy a soros hívásban szereplő összes tárolónak válaszolni tudott, ahogy azt a SageMaker látja, és CPUUtilization és a MemoryUtilizaton jelzi a CPU egységeket és a memória százalékos arányát.

Következtetés

A bejegyzésben megvitattuk, hogy a SageMaker többkonténeres végpontjai hogyan lehetnek hasznosak a költségek és az erőforrás-kihasználás optimalizálása terén. Példák az MCE használatára, de nem kizárólag, a következők:

• Tárolási modellek különböző keretrendszereken (például TensorFlow, PyTorch és Scikit-learn), amelyek nem rendelkeznek elegendő forgalommal egy példány teljes kapacitásának telítéséhez
• Ugyanabból a keretrendszerből származó modellek tárolása különböző ML-algoritmusokkal (például ajánlásokkal, előrejelzésekkel vagy osztályozással) és kezelőfunkciókkal
• Különböző keretrendszer-verziókon futó hasonló architektúrák összehasonlítása (mint például a TensorFlow 1.x vs. TensorFlow 2.x) olyan forgatókönyvekhez, mint az A/B tesztelés

A SageMaker MCE-k akár 15 tároló telepítését is támogatják valós idejű végpontokon, és ezek egymástól függetlenül történő meghívását az alacsony késleltetésű következtetések és a költségmegtakarítás érdekében. A modellek lehetnek teljesen heterogének, saját, független tálalókészlettel. Ezeket a tárolókat szekvenciálisan vagy külön-külön is meghívhatja minden egyes kérelemhez. Ha több modellt, különböző keretrendszerekből, egyetlen példányon biztonságosan tárol, akár 90%-ot is megtakaríthat a költségeken a dedikált egypéldányos végpontokban lévő modellekhez képest.

A szerzőkről

Dhawal Patel az AWS vezető gépi tanulási építésze. Az elosztott számítástechnikával és a mesterséges intelligenciával kapcsolatos problémákon a nagyvállalatoktól a közepes méretű startupokig számos szervezettel dolgozott együtt. A mély tanulásra összpontosít, beleértve az NLP-t és a számítógépes látást. Segít az ügyfeleknek abban, hogy nagy teljesítményű modellkövetkeztetést érjenek el az Amazon SageMakeren.

Vikram Elango az Amazon Web Services vezető mesterséges intelligencia/ML-megoldások szakértője, székhelye Virginia államban (USA). A Vikram a globális pénzügyi és biztosítási ágazat ügyfeleit tervezői és gondolati vezetői képességekkel segíti a gépi tanulási alkalmazások nagyszabású létrehozásában és üzembe helyezésében. Jelenleg a természetes nyelvi feldolgozásra, a felelős AI-re, a következtetések optimalizálására és az ML méretezésére összpontosít a vállalaton belül. Szabadidejében szeret utazni, kirándulni, főzni és kempingezni a családjával.

Saurabh Trikande az Amazon SageMaker Inference vezető termékmenedzsere. Szenvedélyesen dolgozik az ügyfelekkel, és a gépi tanulás demokratizálásának célja motiválja. A komplex ML-alkalmazások telepítésével, a több bérlős ML-modellekkel, a költségoptimalizálással és a mély tanulási modellek bevezetésének elérhetőbbé tételével kapcsolatos alapvető kihívásokra összpontosít. Szabadidejében Saurabh szeret túrázni, innovatív technológiákat tanulni, követi a TechCrunch-ot, és a családjával tölt időt.