A company has an ecommerce website with a product recommendation engine built in TensorFlow. The recommendation engine endpoint is hosted by Amazon SageMaker. Three compute-optimized instances…

Question

Options

• AConfigure the endpoint to use Amazon Elastic Inference (EI) accelerators.
• BCreate a new endpoint configuration with two production variants.
• CConfigure the endpoint to automatically scale with the InvocationsPerInstance metric.
• DDeploy a second instance pool to support a blue/green deployment of models.
• EReconfigure the endpoint to use burstable instances.

• A
  69% (25)
• B
  8% (3)
• D
  6% (2)
• E
  17% (6)

Explanation

Two independent problems must be solved: handling variable load cost-effectively. Option C (auto scaling with the InvocationsPerInstance metric) directly addresses the beginning-of-month traffic spikes and the 8 AM–6 PM weekday peaks by automatically adding and removing instances based on actual inference request volume. This is more cost-effective than always running enough instances for peak load. Option A (Amazon Elastic Inference accelerators) attaches fractional GPU acceleration to the endpoint instances, reducing the CPU bottleneck for TensorFlow inference at a fraction of the cost of full GPU instances. Together, A and C allow the endpoint to handle variable load with the right amount of compute at each moment. Option B (two production variants) is used for A/B testing, not load management. Option D (blue/green deployment) is a deployment strategy for zero-downtime updates, not a scaling solution. Option E (burstable instances like T-types) are unsuitable for consistent ML inference workloads as they throttle CPU after sustained use, worsening response times rather than improving them.

No community discussion yet for this question.