A logistics company is moving a Foundry-hosted chatbot from a low-traffic pilot into production, where it must serve a steady 50,000 requests per hour with predictable response times under a service-level agreement, and traffic does not fluctuate much from day to day. Which deployment approach best fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
The key detail here is that the traffic is steady and predictable, fifty thousand requests an hour, day after day, not spiky or occasional. That's exactly the situation where paying for capacity as you go stops being the efficient choice, because a shared, best-effort tier can't promise the same response time every single time when it's splitting resources across many customers. The better fit is to reserve a dedicated slice of capacity sized to match that known, steady demand, so the assistant always has the throughput it needs without competing for it. Cutting down how much the model is allowed to say, or swapping in a smaller, weaker model, might shave a little time off each request, but neither one actually reserves capacity, they just quietly lower the quality of what the assistant delivers to work around a problem that reserved capacity would solve directly. When demand is steady and guaranteed performance matters, dedicated, sized-to-fit capacity beats a shared pool every time.
Full Explanation
The correct answer is D. A Provisioned Throughput Units deployment reserves dedicated capacity sized to the company's known, steady request volume, which gives consistent latency and guaranteed headroom that a shared, best-effort tier cannot promise under a contractual SLA. Option A is incorrect because pay-as-you-go serverless deployments share capacity across many customers on the same infrastructure; while convenient for a pilot with unpredictable, low volume, it does not guarantee the consistent response times a steady, high-volume SLA requires. Option B is incorrect because shrinking the response length might reduce processing time per call, but it does not change how the deployment is provisioned, and it degrades the assistant's answers to work around a capacity problem instead of solving it. Option C is incorrect because swapping to a smaller model changes the quality and capability of responses rather than addressing the underlying need for reserved, predictable throughput, and traffic volume was never a model-capability problem. Since the traffic pattern here is steady and well understood in advance, reserving dedicated capacity through a provisioned deployment is the fit that matches both the volume and the latency guarantee.