A payments company runs a Foundry-hosted GPT-4o deployment that handles real-time fraud-check calls during checkout, at a steady 50,000 requests per hour, and the team needs predictable, consistent response latency even during peak shopping days. Which deployment type should they choose?
Select an answer to reveal the explanation.
Short Explanation
Think of this like staffing a checkout fraud line on Black Friday: if you rely on shared capacity, you're competing with everyone else when traffic spikes. At 50,000 steady requests per hour, you want dedicated capacity so latency stays predictable. That's what a provisioned throughput deployment gives you.
Full Explanation
The right choice is the provisioned throughput deployment, because it reserves dedicated model capacity for a Foundry project, which keeps response latency stable and predictable even when traffic holds steady at high volume, exactly the pattern described for the payments company's checkout fraud checks. The pay-as-you-go standard deployment is wrong because it draws from shared capacity; it scales without upfront planning, but under sustained heavy load its latency can fluctuate as it competes with other tenants' traffic, which is the opposite of what the team needs. The batch deployment is wrong because it processes large groups of requests asynchronously and is built for throughput on non-urgent workloads, not for a live, request-by-request fraud check during checkout. The free-tier evaluation deployment is wrong because it exists for trying out prompts and small-scale testing, not for production traffic at 50,000 requests per hour with a latency guarantee. Because the team's requirement is steady, high-volume, real-time traffic with consistent latency, reserving dedicated capacity through a provisioned throughput deployment is the only choice built for that exact tradeoff.