An enterprise runs a mission-critical internal application on a Foundry-hosted model with steady, very high request volume throughout the business day and a strict contractual requirement for predictable low latency on every call. Consumption-based deployment has occasionally throttled requests during peak hours. Which deployment approach best addresses this?
Select an answer to reveal the explanation.
Short Explanation
Throttling during busy hours is what happens when an application is sharing capacity with everyone else on a pay-as-you-go pool and demand outstrips what is available at that moment. If the business truly cannot tolerate that unpredictability, the fix is to stop sharing and instead reserve a dedicated slice of capacity just for this workload, so it is not competing with anyone else's traffic spikes. Staying on the same shared consumption model does not change anything, that is the setup already causing the problem. Moving to a queued, process-when-ready style deployment solves a completely different problem, one where nobody is waiting on an immediate answer, which is the opposite of what a low-latency contractual requirement demands. And trimming how much text the model is allowed to generate might shave a little time off each individual response, but it does nothing about the real bottleneck, which is contention for capacity during the busiest hours.
Full Explanation
The correct answer is A. Provisioned throughput reserves a guaranteed slice of capacity dedicated to the application, which is exactly what removes the throttling risk of shared consumption-based capacity and gives the predictable low latency the contract requires for a steady, high-volume business-day workload. Option B is incorrect because pay-as-you-go consumption pricing is the shared-capacity model already causing the throttling described; switching to it, or staying on it, does not solve the predictability problem and instead is the source of it. Option C is incorrect because a batch endpoint processes requests asynchronously as capacity allows, trading away the low-latency, real-time responsiveness this mission-critical application requires. Option D is incorrect because shortening output length might marginally reduce generation time per call, but it does not address capacity contention during peak hours, which is the actual cause of the throttling, so predictable latency under load still would not be guaranteed.