Exam AWS Certified Machine Learning - Specialty topic 1 question 220 discussion

Batch Transform can efficiently handle this workload by splitting the files into mini-batches and distributing them across multiple instances. Batch Transform can also scale down the instances when there are no files to process, so you only pay for the duration that the instances are actively processing files. Batch Transform is more cost-effective than Asynchronous Inference because Asynchronous Inference is designed for workloads with large payload sizes (up to 1GB) and long processing times (up to 15 minutes) that need near real-time responses. Asynchronous Inference queues incoming requests and processes them asynchronously, returning an output location as a response. Asynchronous Inference also autoscales the instance count to zero when there are no requests to process. However, Asynchronous Inference charges you for both request processing and request queuing time, which may be higher than Batch Transform for your use case.

A. YES - Batch Transform can pick up new files from S3 B. NO - no need for asynch, high-throughpt queues C. NO - Processing is not for model inference D. NO - no need for scaling through multiple endpoints

Key point is data is collected every hour. seems like a batch solution is most cost effective

I will go with A. The Async inference seems promising but the size of telemetry file is not known. As per https://docs.aws.amazon.com/sagemaker/latest/dg/inference-cost-optimization.html "Use batch inference for workloads for which you need inference for a large set of data for processes that happen offline (that is, you don’t need a persistent endpoint). You pay for the instance for the duration of the batch inference job". As you pay for the batch job duration, cost should not be an issue with Batch transform. "Use asynchronous inference for asynchronous workloads that process up to 1 GB of data (such as text corpus, image, video, and audio) that are latency insensitive and cost sensitive. With asynchronous inference, you can control costs by specifying a fixed number of instances for the optimal processing rate instead of provisioning for the peak. You can also scale down to zero to save additional costs."

Based on the requirements and constraints given in the scenario, the MOST cost-effective solution for the company to use to run the model across the telemetry for all the devices is SageMaker Batch Transform. SageMaker Batch Transform is a cost-effective solution for performing offline inference, as it allows for large amounts of data to be processed at a lower cost compared to real-time inference. In this case, the telemetry data for each device is collected hourly and can be processed in batches using SageMaker Batch Transform. This can help to reduce the cost of inference, as the data is not being processed in real-time and can be processed offline.

B -- based on what Drcock87 said, as well as this: "Amazon SageMaker Asynchronous Inference is a new capability in SageMaker that queues incoming requests and processes them asynchronously. Compared to Batch Transform Asynchronous Inference provides immediate access to the results of the inference job rather than waiting for the job to complete"

Real-Time Inference is suitable for workloads where payload sizes are up to 6MB and need to be processed with low latency requirements in the order of milliseconds or seconds. Serverless Inference: Serverless inference is ideal when you have intermittent or unpredictable traffic patterns. Batch transform is ideal for offline predictions on large batches of data that is available upfront. We are introducing Amazon SageMaker Asynchronous Inference, a new inference option in Amazon SageMaker that queues incoming requests and processes them asynchronously. This option is ideal for inferences with large payload sizes (up to 1GB) and/or long processing times (up to 15 minutes) that need to be processed as requests arrive. Asynchronous inference enables you to save on costs by autoscaling the instance count to zero when there are no requests to process, so you only pay when your endpoint is processing requests. a