Serveer 3,000 deep learning-modellen op Amazon EKS met AWS Inferentia voor minder dan $ 50 per uur

Meer klanten vinden de noodzaak om grotere, schaalbare en meer kosteneffectieve machine learning (ML) inferentiepijplijnen in de cloud te bouwen. Buiten deze basisvereisten variëren de vereisten van ML-inferentiepijplijnen in productie op basis van de zakelijke use-case. Een typische inferentiearchitectuur voor toepassingen zoals aanbevelingsengines, sentimentanalyse en advertentierangschikking moet een groot aantal modellen bedienen, met een mix van klassieke ML- en deep learning-modellen (DL). Elk model moet toegankelijk zijn via een API-eindpunt (Application Programming Interface) en moet kunnen reageren binnen een vooraf bepaald latentiebudget vanaf het moment dat het een aanvraag ontvangt.

In dit bericht beschrijven we een inferentiearchitectuur, ontwikkeld in samenwerking met het Commerce Einstein Team bij Salesforce, waarop is voortgebouwd Amazon Elastic Kubernetes-service (Amazon EKS) om niet alleen de basisvereisten aan te pakken, maar ook duizenden unieke PyTorch DL-modellen in een schaalbare architectuur te verpakken. We verkennen een mix van Amazon Elastic Compute-cloud (Amazon EC2) instantiefamilies (c5, g4dn, Inf1) om een ​​optimaal ontwerp te ontwikkelen vanuit een kosten- en prestatieaspect. Om aan deze vereisten te voldoen, bouwen we de DL-inferentieservice op Amazon EKS met behulp van FastAPI, een lichtgewicht en efficiënte op Python gebaseerde API-server, en ontwikkel een model bin-packing-strategie om reken- en geheugenresources tussen modellen efficiënt te delen. Om de architectuur te laden, gebruiken we een open-source PyTorch-model voor natuurlijke taalverwerking (NLP). knuffelgezicht.co (bert-base-cased, ongeveer 800 MB) en simuleer duizenden clients die gelijktijdig verzoeken naar de servicepool sturen. We gebruiken AWS Inferentie, de aangepaste ML-chip op Inf1-instanties, om 3,000 unieke PyTorch-modellen te verpakken en te bedienen terwijl de kosten onder $ 50/uur blijven (on-demand prijzen), met een retourlatentie van 70 milliseconden (P90) versus ons doel van 100 milliseconden. U kunt deze architectuur en optimalisatiebenadering uitbreiden naar elk aangepast DL-model.

Overzicht oplossingen

Het volgende is een eenvoudige, schaalbare en zeer beschikbare architectuur op basis van een standaard Amazon EKS-infrastructuur die kan worden ingezet in beschikbaarheidszones.

Het Amazon EKS-cluster heeft verschillende knooppuntgroepen, met één EC2-instantiefamilie per knooppuntgroep. Elke knooppuntgroep kan verschillende instantietypen ondersteunen, zoals CPU (c5), GPU (g4dn) en AWS Inferentia (Inf1), en kan meerdere modellen per instantie inpakken om het aantal ondersteunde modellen te maximaliseren. Vervolgens worden de afhankelijkheden van de modelservertoepassing en het DL-framework gecontaineriseerd en worden deze containerimages opgeslagen Amazon Elastic Container-register (Amazone ECR). De container-images worden geïmplementeerd in het cluster met behulp van implementatie- en servicemanifesten, aangepast voor elke instantiefamilie. De modelservertoepassing downloadt de modelartefacten van Amazon eenvoudige opslagservice (Amazon S3) bij serverinitialisatie, waardoor de grootte van de containerafbeeldingen op Amazon ECR wordt verkleind en de modelgegevens worden losgekoppeld van de servicedefinitie.

Diensten zoals cluster-autoscaler, horizontal-pod-autoscaler, aws-load-balancer-controller, metrics-server, nginx-ingress-controller, neuron-device-plugin-daemonset en nvidia-device-plugin-daemonset worden naar behoefte in het cluster geïmplementeerd. Dit ontwerp is afhankelijk van Kubernetes coredns voor naamomzetting van de service-eindpunten binnen het cluster. Elk model is adresseerbaar via een combinatie van DNS-naam en modelnaam. Bijvoorbeeld, http://<model server ID>.<name space>.svc.cluster.local:8080/predictions/<model id>.

Voor het aanpassen van de DNS-namen kunnen we een ingangsmanifest gebruiken.

De architectuur is ingesteld om in vijf eenvoudige stappen te worden uitgevoerd: bouwen, traceren, inpakken, implementeren en testen. De coderepository is toegankelijk in de GitHub rest.

1. De bouwstap bouwt de basiscontainer voor het geselecteerde instantietype en installeert alle benodigde basislagen in de container.
2. De traceerstap compileert het model. Om de prestaties op GPU-instanties te maximaliseren, werden de modellen geserialiseerd in het TorchScript-formaat met behulp van PyTorch-bibliotheken (torch.jit.trace). Voor Inf1-instanties is de AWS-neuron De native integratie van SDK met PyTorch werd gebruikt om de modellen te compileren in een Neuron bfloat16-indeling. Het volgende is het codefragment om een ​​model te traceren dat wordt uitgevoerd in bfloat16 op AWS Inferentia of Automatic Mixed Precision (AMP) op een GPU-instantie:

print('nTracing model ...')
example_inputs = ( torch.cat([inputs['input_ids']] * batch_size,0), torch.cat([inputs['attention_mask']] * batch_size,0)
)
os.makedirs(f'traced-{model_name}', exist_ok=True)
torch.set_num_threads(6)
if 'inf' in processor: model_traced = torch.neuron.trace(model, example_inputs, verbose=1, compiler_workdir=f'./traced-{model_name}/compile_wd_{processor}_bs{batch_size}_seq	{sequence_length}_pc{pipeline_cores}', compiler_args = ['--neuroncore-pipeline-cores', str(pipeline_cores)])
else: model_traced = torch.jit.trace(model, example_inputs)

3. De pack-stap verpakt het model in een container met FastAPI, waardoor het ook mogelijk is om meerdere modellen in dezelfde container te verpakken.
4. De implementatiestap voert het model uit in de geconfigureerde runtime (zoals Kubernetes of Docker) en vergemakkelijkt het beheer van de volledige levenscyclus van de modelservercontainers. Het volgende codefragment stelt de uitvoeringsopties in en start de container in een geconfigureerde uitvoeringstijd:

echo "Runtime: $runtime"
echo "Processor: $processor" if [ "$runtime" == "docker" ]; then server=0 while [ $server -lt $num_servers ]; do run_opts="--name ${app_name}-${server} -e NUM_MODELS=$num_models -e POSTPROCESS=$postprocess -e QUIET=$quiet -P" if [ "$processor" == "gpu" ]; then run_opts="--gpus 0 ${run_opts}" fi CMD="docker run -d ${run_opts} ${registry}${model_image_name}${model_image_tag}" echo "$CMD" eval "$CMD" server=$((server+1)) done
elif [ "$runtime" == "kubernetes" ]; then kubectl create namespace ${namespace} --dry-run=client -o yaml | kubectl apply -f - ./generate-yaml.sh kubectl apply -f ${app_dir}
else echo "Runtime $runtime not recognized"
fi

5. De laatste stap voert tests uit op de modelservers die in de runtime-omgeving zijn geïmplementeerd.

Bakverpakking ML-modellen

Bin-packing van PyTorch ML-modellen in EC2-instances is essentieel om reken- en geheugenresources tussen modellen efficiënt te delen. De taak van het inpakken van de modellen kan worden geformuleerd en opgelost als een 0-1 knapzakprobleem met behulp van combinatorische optimalisatie. Het volgende is de wiskundige formulering voor het verpakken van bakken; N_modellen is onderhevig aan een beperking van maximaal processorgeheugen (M_max) en gebruik (C_max). Deze benadering beveelt optimale bin-packing van de modellen aan over een minimale set EC2-instanties.

Het aantal bakken wordt vergroot om het probleem te initialiseren met een triviale oplossing van één model per bak en gesnoeid om het doel te bereiken met een minimaal aantal bakken.

De volgende visualisatie toont een voorbeeld van een toewijzing van opslaglocaties voor 78 modellen, elk met unieke geheugen- en rekenvereisten. In dit voorbeeld zijn 78 modellen verpakt in 23 instances (g4dn, Inf1) met een gespecificeerd doel voor maximaal geheugen (7.4 GB) en rekencapaciteit (83%). De kleurenlegenda geeft de modelindex aan.

We kunnen de voorgaande methode gebruiken om modellen van verschillende instanties optimaal te bin-packen. De volgende tabel geeft een overzicht van de bin-packing-resultaten voor Inf1- en g4dn-instanties. We hebben voor deze instantiefamilies gekozen omdat het op transformatoren gebaseerde NLP-model hardwareversnelling vereist om de verwachte latentie te bereiken. We konden meer modellen inpakken in Inf1.6xlarge (48 GiB-geheugen) vergeleken met g4dn.12xlarge (192 GiB-geheugen) omdat de Auto Casting-functie van de Neuron-compiler FP32-modellen automatisch converteert naar 16-bits bfloat om de doorvoer te maximaliseren.

Testmethodiek en observaties

Om de test op schaal te laden, hebben we meer dan 40 clients gesimuleerd die gelijktijdige verzoeken naar de testpool stuurden (laden van meerdere clients). Het laden van het systeem met meer gebruikersverzoeken verhoogt de doorvoer ten koste van latentie; de tests waren ontworpen om de doorvoer-latentiecurve te doorzoeken om datapunten te vinden met geoptimaliseerd gebruik van bronnen. We hebben doorvoer en latentie gemeten (P50, P90, P95) en de resultaten samengevat in vier statistieken: latentie, doorvoer (gevolgtrekkingen per seconde), aantal modellen dat per instantie wordt aangeboden en kosten. Daarnaast hebben we tests gemaakt om single-sequential en single-willekeurige verzoeken te simuleren met behulp van curl om een ​​GET- of POST-verzoek naar elk model in de testpool te sturen. Het doel van deze experimenten was om de beste latentie te meten die we als basis kunnen verwachten.

We hebben verschillende experimenten uitgevoerd om de optimale modelpacking te vinden voor minimale sets EC2-instanties die zouden resulteren in de hoogste prestaties tegen de laagste kosten. De volgende tabel geeft een overzicht van enkele van deze testresultaten. De beste resultaten werden waargenomen bij het gebruik van 40 Inf1.6xl-instanties met DNS-caching ingeschakeld, waarbij 3,040 modellen werden bediend met een doorvoer van 6,230 verzoeken per seconde in 66 milliseconden (P90-latentie) tegen een kostprijs van $ 47.2/uur (on-demand). De beste implementatie van gemengde instanties, met 32 ​​inf1.6xl- en 21 g4dn.12xl-instanties, resulteerde in 3,048 modellen, maar met een veel lagere doorvoer van 248 verzoeken per seconde met hogere uurkosten van $ 119.91/uur. Hoewel we EC2 Spot Instances niet hebben gebruikt als hefboom voor kostenoptimalisatie in deze architectuur, raden we ten zeerste aan om Spot te gebruiken als uw inferentiewerklast tijdsflexibel en fouttolerant is. De volgende tabel geeft een overzicht van onze observaties voor verschillende instantietypen.

Conclusie

Met deze schaalbare architectuur waren we in staat om inferentie te schalen over 3,000 PyTorch-modellen, waarbij we een beoogde latentie van 100 milliseconden bereikten, terwijl we tegelijkertijd de kosten onder de $ 50/uur (on-demand) hielden door kosten te optimaliseren door modellen efficiënt in te pakken in een minimale set van EC2-exemplaren. Bij alle tests leverden Inf1-exemplaren de hoogste verwerkingscapaciteit, de laagste kosten, de snelste responstijd en de maximale bin-packing-ratio op in vergelijking met andere instanties. AWS-klanten houden van Snap, Airbnb, Sprinklr en nog veel meer hebben AWS Inferentia gebruikt om de hoogste prestaties en laagste kosten te bereiken bij verschillende implementaties. Hoewel het geteste DL-model het gebruik van hardwareversnelling op Inf1- en g4dn-instantietypen vereist, kunt u andere modeltypen afstemmen op verschillende instantietypen (Inf1, CPU, GPU) en bin pack-modellen dienovereenkomstig door de beschreven methodologie te gebruiken.

Meer informatie over de AWS Inferentia-chip en EC2 Inf1-instanties om aan de slag te gaan met het uitvoeren van uw eigen aangepaste ML-pijplijnen op AWS Inferentia met behulp van de Neuron-SDK.

Over de auteurs

Alex Iankouski is een Principal Solutions Architect met een focus op autonome workloads met behulp van containers. Alex is een hands-on full-stack infrastructuur- en softwarearchitect en heeft platformen gebouwd met behulp van Docker om het innovatietempo te versnellen door containertechnologieën toe te passen op engineering, datawetenschap en AI-problemen. De afgelopen 10 jaar heeft hij gewerkt aan het bestrijden van klimaatverandering, het democratiseren van AI en ML, en het veiliger maken van reizen, betere gezondheidszorg en slimmer energieverbruik.

Mahadevan Balasubramaniam is een Principal Solutions Architect voor Autonomous Computing met bijna 20 jaar ervaring op het gebied van met fysica doordrenkt deep learning, het bouwen en implementeren van digitale tweelingen voor industriële systemen op schaal. Mahadevan behaalde zijn PhD in Werktuigbouwkunde aan het Massachusetts Institute of Technology en heeft meer dan 25 patenten en publicaties op zijn naam staan.

Soendar Ranganathan is het hoofd van Business Development, ML Frameworks in het Amazon EC2-team. Hij richt zich op grootschalige ML-workloads voor AWS-services zoals Amazon EKS, Amazon ECS, Elastic Fabric Adapter, AWS Batch en Amazon SageMaker. Zijn ervaring omvat leidinggevende functies in productbeheer en productontwikkeling bij NetApp, Micron Technology, Qualcomm en Mentor Graphics.

Jozua Correa is een Salesforce Principal-lid van de technische staf die werkt in het Commerce Einstein-team. Joshua heeft een diepe passie voor het bouwen van een schaalbare, veerkrachtige en kosteneffectieve infrastructuur voor machine learning. Joshua werkt graag op het snijvlak van software-engineering en datawetenschap om geavanceerde modellen in productie te brengen.

Bron: https://aws.amazon.com/blogs/machine-learning/serve-3000-deep-learning-models-on-amazon-eks-with-aws-inferentia-for-under-50-an-hour/