Optimize AI/ML workloads for sustainability: Part 3, deployment and monitoring
AWS Architecture BlogOptimize AI/ML workloads for sustainability: Part 3, deployment and monitoringby Benoit de Chateauvieux, Eddie Pick, Dan Ferguson, and Brendan Sisson | on27 APR 2022| inArtificial Intelligence,AWS Well-Architected,AWS Well-Architected Framework,Sustainability|Permalink|ShareWe’re celebrating Earth Day 2022 from 4/22 through 4/29 with posts that highlight how to build, maintain, and refine your workloads for sustainability.AWS estimates that inference (the process of using a trained machine learning [ML] algorithm to make a prediction) makes up90 percent of the cost of an ML model. Given with AWS you pay for what you use, we estimate that inference also generally equates to most of the resource usage within an ML lifecycle.In this series, we’re following the phases of theWell-Architected machine learning lifecycle(Figure 1) to optimize your artificial intelligence (AI)/ML workloads. In Part 3, our final piece in the series, we show you how to reduce the environmental impact of your ML workload once your model is in production.If you missed the first parts of this series, inPart 1, we showed you how to examine your workload to help you 1) evaluate the impact of your workload, 2) identify alternatives to training your own model, and 3) optimize data processing. InPart 2, we identified ways to reduce the environmental impact of developing, training, and tuning ML models.Figure 1. ML lifecycleDeploymentSelect sustainable AWS RegionsAs mentioned in Part 1, select an AWS Region with sustainable energy sources. When regulations and legal aspects allow, choose Regionsnear Amazon renewable energy projectsand Regions where the grid has low published carbon intensity to deploy your model.Align SLAs with sustainability goalsDefine SLAs that support your sustainability goals while meeting your business requirements:If your users can tolerate some latency, deploy your model onasynchronous endpointstoreduce resources that are idle between tasks and minimize the impact of load spikes. Asynchronous endpoints will automatically scale the instance count to zero when there are no requests to process, so you only maintain an inference infrastructure when your endpoint is processing requests.If your workload doesn’t require high availability,deploy it to a single Availability Zoneto reduce the cloud resources you consume. Adjusting availability is an example of aconscious trade offyou can make to meet your sustainability targets.When you don’t need real-time inference, use AmazonSageMaker batch transform. Unlike persistent endpoints, clusters are decommissioned when batch transform jobs finish so you don’t continuously maintain an inference infrastructure.Use efficient siliconFor CPU-based ML inference, use AWSGraviton3. These processors offer the best performance per watt inAmazon Elastic Compute Cloud (Amazon EC2).They use up to60% less energythan comparable EC2 instances. Graviton3 processors deliver up to three times better performance compared to Graviton2 processors for ML workloads, and theysupport bfloat16.For deep learning workloads, the Amazon EC2 Inf1 instances (based on custom designedAWS Inferentiachips) deliver 2.3 times higher throughput and 80% lower cost compared to g4dn instances.Inf1 has 50% higher performance per watt than g4dn, which makes it the most sustainable ML accelerator Amazon EC2 offers.Make efficient use of GPUUseAmazon Elastic Inferenceto attach just the right amount of GPU-powered inference acceleration to any EC2 or SageMaker instance type orAmazon Elastic Container Service (Amazon ECS)task.While training jobs batch process hundreds of data samples in parallel, inference jobs usually process a single input in real time, and thus consume a small amount of GPU compute. Elastic Inference allows you to reduce the cost and environmental impact of your inference by using GPU resources more efficiently.Optimize models for inferenceImprove efficiency of your models by compiling them into optimized forms with the following:Various open-source libraries (likeTreelitefor decision tree ensembles)Third-party tools likeHugging Face Infinity, which allows you to speed up transformer models and run inference not only on GPU but also on CPU.SageMaker Neo’s runtime consumes as little as one-tenth the footprint of a deep learning framework and optimizes models to perform up to 25 time faster with no loss in accuracy (example with XGBoost).Deploying more efficient models means you need fewer resources for inference.Deploy multiple models behind a single endpointSageMaker provides three methods to deploy multiple models to a single endpoint to improve endpoint utilization:Hostmultiple models in one container behind one endpoint. Multi-model endpoints are served using a single container. This can help youcut up to 90 percentof your inference costs and carbon emissions.Hostmultiple models that use different containers behind one endpoint.Host a linear sequence of containers in aninference pipeline behind a single endpoint.Sharing endpoint resources is more sustainable and less expensive than deploying a single model behind one endpoint.Right-size your inference environmentRight-size your endpoints by using metrics fromAmazon CloudWatchor by using theAmazon SageMaker Inference Recommender. This tool can run load testing jobs and recommend the proper instance type to host your model. When you use the appropriate instance type, you limit the carbon emission associated with over-provisioning.If your workload has intermittent or unpredictable traffic,configure autoscaling inference endpoints in SageMakerto optimize your endpoints. Autoscaling monitors your endpoints and dynamically adjusts their capacity to maintain steady and predictable performance using as few resources as possible. You can also tryServerless Inference(in preview), which automatically launches compute resources and scales them in and out depending on traffic, which eliminates idle resources.Consider inference at the edgeWhen working on Internet of Things (IoT) use cases, evaluate if ML inference at the edge can reduce the carbon footprint of your workload. To do this, consider factors like the compute capacity of your devices, their energy consumption, or the emissions related to data transfer to the cloud. Whendeploying ML models to edge devices, consider usingSageMaker Edge Manager, which integrates with SageMaker Neo andAWS IoT Greengrass(Figure 2).Figure 2. Run inference at the edge with SageMaker EdgeDevice manufacturing represents32-57 percent of the global Information Communication Technology carbon footprint. If your ML model is optimized, it requires less compute resources. You can then perform inference onlower specification machines, which minimizes the environmental impact of the device manufacturing and uses less energy.The following techniques compress the size of models for deployment, which speeds up inference and saves energy without significant loss of accuracy:Pruningremoves weights (learnable parameters) that don’t contribute much to the model.Quantizationrepresents numbers with the low-bit integers without incurring significant loss in accuracy. Specifically, you can reduce resource usage by replacing the parameters in an inference model with half-precision (16 bit), bfloat16 (16 bit, but the same dynamic range as 32 bit), or 8-bit integers instead of the usual single-precision floating-point (32 bit) values.Archive or delete unnecessary artifactsCompress and reduce the volume of logs you keep during the inference phase. By default, CloudWatch retains logs indefinitely. Bysetting limited retention timefor your inference logs, you’ll avoid the carbon footprint of unnecessary log storage. Also delete unused versions of your models andcustom container imagesfrom your repositories.MonitoringRetrain only when necessaryMonitor your ML model in production and only retrain if it’s required. Because of model drift, robustness, or new ground truth data being available, models usually need to be retrained. Instead of retraining arbitrarily, monitor your ML model in production, automate yourmodel drift detectionand only retrain when your model’s predictive performance has fallen belowdefined KPIs.ConsiderSageMaker Pipelines,AWS Step Functions Data Science SDK for Amazon SageMaker, or third-party tools to automate your retraining pipelines.Measure results and improveTo monitor and quantify improvements during the inference phase, track the following metrics:Resources provisioned for your endpoints(InstanceTypeandAcceleratorType)Efficient use of these resources(CPUUtilization,GPUUtilization,GPUMemoryUtilization,MemoryUtilization, andDiskUtilization) in theCloudWatch ConsoleFor storage:The total size of thedata capturedbyAmazon SageMaker Model MonitorusingAmazon S3 Storage LensThesize of your CloudWatch log groupsConclusionAI/ML workloads can be energy intensive, but ascalled out by UNand mentioned in the lastIPCC report, AI can contribute to mitigation of climate change and the achievement of severalSustainable Development Goals. As technology builders, it’s ourresponsibilityto make sustainable use of AI and ML.In this blog post series, we presented best practices you can use to makesustainability-conscious architectural decisionsand reduce the environmental impact for your AI/ML workloads.Other posts in this seriesOptimize AI/ML workloads for sustainability: Part 1, identify business goals, validate ML use, and process dataOptimize AI/ML workloads for sustainability: Part 2, model developmentAbout the Well-Architected FrameworkThese practices are part of theSustainability Pillar of the AWS Well-Architected Framework. AWS Well-Architected is a set of guiding design principles developed by AWS to help organizations build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads. Use theAWS Well-Architected Toolto review your workloads periodically to address important design considerations and ensure that they follow the best practices and guidance of the AWS Well-Architected Framework. For follow up questions or comments, join our growing community onAWS re:Post.TAGS:Optimize AI/ML workloads for sustainability,SustainabilityBenoit de ChateauvieuxBenoit de Chateauvieux is a Startup Solutions Architect at AWS, based in Montreal, Canada. As a former CTO, he enjoys helping startups build great and sustainable products using the cloud. Outside of work, you’ll find Benoit in canoe-camping expeditions, paddling across Canadian rivers.Eddie PickEddie Pick is a Senior Startup Solutions Architect at AWS based in Montréal, Canada. As an ex co-founder and former CTO, his goal is to help startups build great products faster on the Cloud, particularly using machine learning.Dan FergusonDan Ferguson is a Solutions Architect at AWS, based in New York, USA. As a machine learning services expert, Dan works to support customers on their journey to integrating ML workflows efficiently, effectively, and sustainably.Brendan SissonBrendan Sisson is a Principal Sustainability Solutions Architect at AWS based in London, UK. As a contributor to the Sustainability Pillar of the AWS Well-Architected Framework, he supports customers on how they can optimize their workloads running in the AWS Cloud and how they can use the AWS Cloud to help solve their wider sustainability challenges.
We’re celebrating Earth Day 2022 from 4/22 through 4/29 with posts that highlight how to build, maintain, and refine your workloads for sustainability. AWS estimates that inference (the process of using a trained machine learning [ML] algorithm to make a prediction) makes up 90 percent of the cost of an ML model. Given with AWS you […]
Benoit de Chateauvieux
Artificial Intelligence AWS Well-Architected AWS Well-Architected Framework Sustainability