Rulați și optimizați inferența cu mai multe modele cu punctele finale cu mai multe modele Amazon SageMaker

Amazon SageMaker Multi-model endpoint (MME) vă permite să implementați și să găzduiți mai multe modele într-un singur punct final și apoi să scalați pe orizontală punctul final pentru a atinge scalarea. După cum este ilustrat în figura următoare, aceasta este o tehnică eficientă pentru a implementa multi-chirierea modelelor în infrastructura dvs. de învățare automată (ML). Am văzut că companiile software ca serviciu (SaaS) folosesc această caracteristică pentru a aplica hiperpersonalizarea în modelele lor ML, obținând în același timp costuri mai mici.

Pentru o prezentare generală la nivel înalt a modului în care funcționează MME, vedeți videoclipul AWS Summit Scalarea ML la nivelul următor: găzduiți mii de modele pe SageMaker. Pentru a afla mai multe despre cazurile de utilizare hiperpersonalizate, multi-chiriași pe care le permite MME, consultați Cum să scalați inferența învățării automate pentru cazurile de utilizare SaaS multi-tenant.

În restul acestei postări, ne aprofundăm în arhitectura tehnică a SageMaker MME și împărtășim cele mai bune practici pentru optimizarea punctelor finale cu mai multe modele.

Cazuri de utilizare cele mai potrivite pentru MME

Punctele finale cu mai multe modele SageMaker sunt potrivite pentru găzduirea unui număr mare de modele pe care le puteți servi printr-un container de servire partajat și nu trebuie să accesați toate modelele în același timp. În funcție de dimensiunea memoriei instanței punctului final, un model poate fi ocazional descărcat din memorie în favoarea încărcării unui nou model pentru a maximiza utilizarea eficientă a memoriei, prin urmare, aplicația dvs. trebuie să fie tolerantă la vârfurile ocazionale de latență pe modelele descărcate.

MME este, de asemenea, conceput pentru modele de co-găzduire care folosesc același cadru ML, deoarece folosesc containerul partajat pentru a încărca mai multe modele. Prin urmare, dacă aveți o combinație de cadre ML în flota dvs. de modele (cum ar fi PyTorch și TensorFlow), punctele finale dedicate SageMaker sau găzduirea cu mai multe containere sunt o alegere mai bună.

În cele din urmă, MME este potrivit pentru aplicațiile care pot tolera o penalizare ocazională de latență de pornire la rece, deoarece modelele sunt încărcate la prima invocare și modelele utilizate rar pot fi descărcate din memorie în favoarea încărcării modelelor noi. Prin urmare, dacă aveți o combinație de modele accesate frecvent și rar, un punct final cu mai multe modele poate servi eficient acest trafic cu mai puține resurse și economii mai mari de costuri.

Am văzut, de asemenea, câteva scenarii în care clienții implementează un cluster MME cu suficientă capacitate de memorie agregată pentru a se potrivi tuturor modelelor lor, evitând astfel descărcarea de modele, dar totuși realizând economii de costuri datorită infrastructurii de inferență partajate.

Model de recipiente de servire

Când utilizați SageMaker Inference Toolkit sau un container de servire model SageMaker prefabricat compatibil cu MME, containerul dvs. are Server multimodel (proces JVM) rulează. Cel mai simplu mod de a avea Multi Model Server (MMS) încorporat în containerul dvs. de servire model este să utilizați Containere de servire model SageMaker compatibil cu MME (căutați cei cu Job Type=inference și CPU/GPU=CPU). MMS este un instrument open source, ușor de utilizat, pentru a servi modele de deep learning. Oferă o API REST cu un server web pentru a servi și a gestiona mai multe modele pe o singură gazdă. Cu toate acestea, nu este obligatoriu să utilizați MMS; ai putea implementa propriul server de model atâta timp cât implementează API-uri cerute de MME.

Când sunt utilizate ca parte a platformei MME, toate apelurile API de predicție, încărcare și descărcare către MMS sau propriul dvs. server de model sunt canalizate prin controlerul planului de date MME. Apelurile API de la controlerul planului de date sunt efectuate pe gazda locală numai pentru a preveni accesul neautorizat din afara instanței. Unul dintre avantajele cheie ale MMS este că permite o interfață standardizată pentru încărcarea, descărcarea și invocarea modelelor cu compatibilitate într-o gamă largă de cadre de învățare profundă.

Configurare avansată a MMS

Dacă alegeți să utilizați MMS pentru difuzarea modelelor, luați în considerare următoarele configurații avansate pentru a optimiza scalabilitatea și debitul instanțelor dvs. MME.

Creșteți paralelismul de inferență pe model

MMS creează unul sau mai multe procese de lucru Python per model pe baza valorii default_workers_per_model parametrul de configurare. Acești lucrători Python gestionează fiecare cerere de inferență individuală prin rularea oricăror funcții de preprocesare, predicție și postprocesare pe care le furnizați. Pentru mai multe informații, consultați handler de servicii personalizate Repo GitHub.

Având mai mult de un lucrător de model crește paralelismul predicțiilor care pot fi servite de un model dat. Cu toate acestea, atunci când un număr mare de modele sunt găzduite pe o instanță cu un număr mare de procesoare, ar trebui să efectuați un test de încărcare a MME pentru a găsi valoarea optimă pentru default_workers_per_model pentru a preveni orice epuizare a memoriei sau a resurselor CPU.

Design pentru vârfuri de trafic

Fiecare proces MMS dintr-o instanță de punct final are o coadă de solicitări care poate fi configurată cu job_queue_size parametrul (implicit este 100). Aceasta determină numărul de solicitări pe care MMS-ul va pune în coadă atunci când toate procesele de lucru sunt ocupate. Utilizați acest parametru pentru a regla gradul de răspuns al instanțelor dvs. final după ce v-ați decis asupra numărului optim de lucrători per model.

Într-un raport optim de lucrător pe model, valoarea implicită de 100 ar trebui să fie suficientă pentru majoritatea cazurilor. Cu toate acestea, pentru acele cazuri în care traficul solicitărilor către punctul final crește în mod neobișnuit, puteți reduce dimensiunea cozii dacă doriți ca punctul final să eșueze rapid pentru a transmite controlul către aplicație sau crește dimensiunea cozii dacă doriți ca punctul final să absoarbă vârful. .

Maximizați resursele de memorie per instanță

Când utilizați mai multe procese de lucru pe model, în mod implicit fiecare proces de lucru își încarcă propria copie a modelului. Acest lucru poate reduce memoria de instanță disponibilă pentru alte modele. Puteți optimiza utilizarea memoriei prin partajarea unui singur model între procesele de lucru prin setarea parametrului de configurare preload_model=true. Aici schimbi paralelismul de inferență redus (datorită unei singure instanțe de model) cu mai multă eficiență a memoriei. Această setare, împreună cu mai multe procese de lucru poate fi o alegere bună pentru cazurile de utilizare în care latența modelului este scăzută, dar aveți preprocesare și postprocesare mai grea (efectuate de procesele de lucru) per cerere de inferență.

Setați valori pentru configurațiile avansate MMS

MMS folosește un fișier config.properties pentru a stoca configurațiile. MMS folosește următoarea ordine pentru a localiza acest fișier config.properties:

1. În cazul în care MMS_CONFIG_FILE variabila de mediu este setată, MMS încarcă configurația din variabila de mediu.
2. În cazul în care --mms-config parametrul este transmis la MMS, acesta încarcă configurația din parametru.
3. Daca este o config.properties în folderul curent în care utilizatorul pornește MMS-ul, acesta încarcă fișierul config.properties fișier din directorul de lucru curent.

Dacă nu este specificat niciuna dintre cele de mai sus, MMS încarcă configurația încorporată cu valorile implicite.

Următorul este un exemplu de linie de comandă de pornire a MMS cu un fișier de configurare explicit:

multi-model-server --start --mms-config /home/mms/config.properties

Valori cheie pentru a vă monitoriza performanța punctului final

Valorile cheie care vă pot ajuta să vă optimizați MME sunt de obicei legate de utilizarea CPU și a memoriei și latența de inferență. Valorile la nivel de instanță sunt emise de MMS, în timp ce valorile de latență provin de la MME. În această secțiune, discutăm despre valorile tipice pe care le puteți utiliza pentru a înțelege și optimiza MME.

Valori la nivel de instanță de punct final (valori MMS)

De la lista de valori MMS, CPUUtilization și MemoryUtilization vă pot ajuta să evaluați dacă instanța dvs. sau clusterul MME este sau nu de dimensiunea corectă. Dacă ambele valori au procente între 50 și 80%, atunci MME-ul dvs. este de dimensiunea corectă.

De obicei, CPUUtilization scăzut și MemoryUtilization ridicat este o indicație a unui cluster MME supraprovizionat, deoarece indică faptul că modelele invocate rar nu sunt descărcate. Acest lucru s-ar putea datora unui număr mai mare decât optim de instanțe de punct final furnizate pentru MME și, prin urmare, o memorie agregată mai mare decât optimă este disponibilă pentru ca modelele accesate rar să rămână în memorie. Dimpotrivă, utilizarea aproape de 100% a acestor valori înseamnă că clusterul dvs. este subprovizionat, așa că trebuie să ajustați politica de scalare automată a clusterului.

Valori la nivel de platformă (valori MME)

De la lista completă a valorilor MME, o valoare cheie care vă poate ajuta să înțelegeți latența solicitării dvs. de inferență este ModelCacheHit. Această măsurătoare arată raportul mediu al solicitărilor de invocare pentru care modelul a fost deja încărcat în memorie. Dacă acest raport este scăzut, indică faptul că clusterul dvs. MME este subprovizionat, deoarece probabil că nu există suficientă capacitate de memorie agregată în clusterul MME pentru numărul de invocări unice de model, ceea ce face ca modelele să fie frecvent descărcate din memorie.

Lecții din teren și strategii de optimizare a MME

Am văzut următoarele recomandări de la unele dintre utilizările la scară mare ale MME la un număr de clienți.

Scalare orizontală cu instanțele mai mici este mai bună decât scalarea verticală cu instanțe mai mari

Este posibil să aveți o limitare a invocărilor de model atunci când rulați solicitări mari pe secundă (RPS) pe mai puține instanțe de punct final. Există limite interne ale numărului de invocări pe secundă (încărcări și descărcari care se pot întâmpla simultan pe o instanță) și, prin urmare, este întotdeauna mai bine să aveți un număr mai mare de instanțe mai mici. Rularea unui număr mai mare de instanțe mai mici înseamnă o capacitate totală agregată mai mare a acestor limite pentru punctul final.

Un alt beneficiu al scalării orizontale cu instanțe mai mici este că reduceți riscul de a epuiza resursele de memorie și CPU ale instanței atunci când rulați MMS cu niveluri mai mari de paralelism, împreună cu un număr mai mare de modele în memorie (așa cum este descris mai devreme în această postare).

Evitarea loviturilor este o responsabilitate comună

lovire în MME este atunci când modelele sunt descărcate frecvent din memorie și reîncărcate din cauza memoriei insuficiente, fie într-o instanță individuală, fie la nivel agregat în cluster.

Din punct de vedere al utilizării, ar trebui să dimensionați corect instanțele individuale ale punctului final și să măriți corect dimensiunea totală a clusterului MME pentru a vă asigura că este disponibilă suficientă capacitate de memorie pentru fiecare instanță și, de asemenea, la nivel agregat pentru cluster pentru cazul dvs. de utilizare. Flota de routere a platformei MME va maximiza, de asemenea, accesul în cache.

Nu fi agresiv cu împachetarea prea multor modele pe mai puține instanțe de memorie mai mari

Memoria nu este singura resursă a instanței de care trebuie să știți. Alte resurse, cum ar fi CPU, pot fi un factor de constrângere, așa cum se vede în următoarele rezultate ale testului de încărcare. În alte cazuri, am observat, de asemenea, că alte resurse de kernel, cum ar fi ID-urile de proces, se epuizează pe o instanță, din cauza unei combinații de încărcare a prea multor modele și a firelor de execuție ML subiacente (cum ar fi TensorFlow) per model care erau multipli de disponibile. vCPU-uri.

Următorul test de performanță demonstrează un exemplu de constrângere CPU care afectează latența modelului. În acest test, un punct final de o singură instanță cu o instanță mare, deși avea o memorie mai mult decât suficientă pentru a păstra toate cele patru modele în memorie, a produs latențe de model sub sarcină comparativ mai slabe în comparație cu un punct final cu patru instanțe mai mici.

latența modelului punctului final cu o singură instanță

CPU și utilizarea memoriei punctului final cu o singură instanță

latența modelului de punct final cu patru instanțe

Utilizarea CPU și a memoriei punctelor finale cu patru instanțe

Pentru a obține atât performanță, cât și eficiență din punct de vedere al costurilor, dimensionați corect clusterul dvs. MME cu un număr mai mare de instanțe mai mici, care vă oferă, în total, memoria optimă și capacitatea CPU, fiind în același timp relativ la egalitate cu costurile cu mai puține instanțe de memorie, dar mai mari.

Model mental pentru optimizarea MME

Există patru valori cheie pe care ar trebui să le luați întotdeauna în considerare atunci când vă dimensionați corect MME:

• Numărul și mărimea modelelor
• Numărul de modele unice invocate la un moment dat
• Tipul și dimensiunea instanței
• Numărul de instanțe din spatele punctului final

Începe cu primele două puncte, pentru că ele informează al treilea și al patrulea. De exemplu, dacă nu există suficiente instanțe în spatele punctului final pentru numărul sau dimensiunea modelelor unice pe care le aveți, memoria agregată pentru punctul final va fi scăzută și veți vedea o rată mai mică de accesare a cache-ului și o deplasare la nivelul punctului final, deoarece MME va încărca și descărca frecvent modelele în și din memorie.

În mod similar, dacă invocările pentru modele unice sunt mai mari decât memoria agregată a tuturor instanțelor din spatele punctului final, veți vedea o lovitură de cache mai mică. Acest lucru se poate întâmpla și dacă dimensiunea instanțelor (în special capacitatea memoriei) este prea mică.

Scalarea pe verticală cu instanțe de memorie foarte mari ar putea duce, de asemenea, la probleme, deoarece, deși modelele se pot încadra în memorie, alte resurse, cum ar fi procesele CPU și kernel și limitele firelor de execuție, ar putea fi epuizate. Încărcați scalarea orizontală de testare în pre-producție pentru a obține numărul și dimensiunea optime de instanțe pentru MME.

Rezumat

În această postare, ați înțeles mai profund platforma MME. Ați aflat pentru ce cazuri tehnice de utilizare MME este potrivit și ați revizuit arhitectura platformei MME. Ați dobândit o înțelegere mai profundă a rolului fiecărei componente în arhitectura MME și a componentelor cărora le puteți influența direct performanța. În cele din urmă, ați avut o privire mai profundă asupra parametrilor de configurare pe care îi puteți ajusta pentru a optimiza MME pentru cazul dvs. de utilizare și a valorilor pe care ar trebui să le monitorizați pentru a menține performanța optimă.

Pentru a începe cu MME, revizuiți Puncte finale cu mai multe modele Amazon SageMaker folosind XGBoost și Găzduiește mai multe modele într-un singur container în spatele unui punct final.

Despre autor

Syed Jaffry este arhitect principal de soluții cu AWS. Lucrează cu o serie de companii de la organizații mijlocii, întreprinderi mari, servicii financiare și ISV pentru a le ajuta să construiască și să opereze aplicații AI/ML scalabile și rentabile în cloud.

Saurabh Trikande este Senior Product Manager pentru Amazon SageMaker Inference. Este pasionat de lucrul cu clienții și este motivat de obiectivul democratizării învățării automate. El se concentrează pe provocările de bază legate de implementarea de aplicații ML complexe, modele ML multi-locatari, optimizări ale costurilor și de a face implementarea modelelor de învățare profundă mai accesibilă. În timpul liber, lui Saurabh îi place să facă drumeții, să învețe despre tehnologii inovatoare, să urmeze TechCrunch și să petreacă timpul cu familia sa.