A transit authority's ridership-prediction workload requires a preprocessing container to run ahead of the model-inference container on every request, with both steps served from one endpoint invocation. Which deployment pattern fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
Two steps that always have to happen in order, on every single request, belong chained together behind one call — not left for the client app to coordinate by hand. A serial inference pipeline runs the preprocessing container straight into the inference container inside one endpoint invocation. One request in, one finished prediction out.
Full Explanation
A multi-container serial inference pipeline lets multiple containers run in a defined sequence behind a single SageMaker endpoint, passing the output of one container as the input to the next, which matches a workload where preprocessing must run ahead of inference on every request with both served from one call. A multi-model endpoint solves a different problem: it hosts multiple interchangeable models and loads one at a time per request, rather than running two different containers in sequence as one pipeline. Two standalone endpoints called separately by the application shifts the sequencing responsibility, and the network round-trip, onto client code, which adds latency and operational complexity the transit authority explicitly wanted served from a single invocation. Asynchronous inference decouples timing and lets steps proceed independently at their own pace, which breaks the requirement that preprocessing and inference happen together, in strict order, per request. Scope note: every container in a serial pipeline shares the endpoint's instance resources, so size the instance for the combined load of both steps. Operational check: confirm end-to-end latency across both containers still meets the prediction workload's response-time target.