A public-works department must run inference on scanned permit application PDFs that are individually large and can take several minutes to process, exceeding the payload size and timeout limits of a real-time endpoint. Which inference option should the team use?
Select an answer to reveal the explanation.
Short Explanation
A form that takes minutes to process and megabytes to upload has already outgrown what a quick, synchronous request-response endpoint is built for. Asynchronous inference queues the job, lets it run as long as it needs, and hands back the result when it's done — no one's sitting there waiting on the connection. It's built exactly for large, slow, one-off jobs like this.
Full Explanation
Asynchronous inference accepts large payloads by having the caller submit a request pointing at the input in object storage, queues the job, and returns the result once processing completes, which is the pattern built for requests too large or too slow for a synchronous call — exactly the scanned-PDF workload described. A real-time endpoint's timeout can be extended somewhat, but it's still built around a synchronous request that holds a connection open, and its payload limits weren't designed for multi-minute document processing; stretching it fights the tool rather than picking the right one. Serverless inference solves a different problem — scaling compute up and down with unpredictable traffic — but it doesn't remove payload or timeout constraints the way the scenario requires. Batch transform forces every PDF to wait for a full weekly collection before any of them get processed, which throws away the ability to process each application as it arrives, something asynchronous inference preserves per-request. Scope note: asynchronous inference still needs a completion-notification mechanism (such as a queue or event) so downstream systems know when a result is ready. Operational check: confirm the queue's depth and average completion time stay within the department's processing SLA as PDF volume grows.