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 happens when your app shares capacity with everyone else on a pay-as-you-go pool and demand outstrips what's available. If the business can't tolerate that unpredictability, you need to stop sharing and reserve a dedicated slice of capacity just for this workload. That keeps it from competing with anyone else's traffic spikes and gives predictable low latency.
Full Explanation
Provisioning a dedicated throughput unit sized to reserve guaranteed capacity for the application's steady load is the best approach because provisioned throughput reserves a guaranteed slice of capacity dedicated to the application. That 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. Switching to pay-as-you-go consumption pricing 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. Moving the workload to a batch endpoint 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. Reducing the model's maximum output token limit 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.