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 the way you'd think about staffing a call center on Black Friday. If you just hire from a shared temp agency and hope enough people show up, you'll usually be fine, but on the busiest days you're competing with every other business pulling from that same pool, and your wait times can creep up right when it matters most. Reserving dedicated capacity is like hiring your own permanent staff who show up every shift regardless of what anyone else needs that day. For a fraud check running during checkout at a steady 50,000 requests an hour, latency spikes aren't just annoying, they can mean abandoned carts or missed fraud signals. A shared, auto-scaling setup is great for spiky or unpredictable traffic where you don't want to pay for capacity you're not using. But once your volume is high and steady, paying for guaranteed, dedicated capacity buys you the one thing shared pools can't promise: consistent response time no matter how busy everyone else gets.
Full Explanation
The correct answer is B. Provisioned throughput (PTU) deployments reserve 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. Option A is incorrect because a pay-as-you-go standard deployment 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. Option C is incorrect because batch deployments process large groups of requests asynchronously and are built for throughput on non-urgent workloads, not for a live, request-by-request fraud check during checkout. Option D is incorrect because free-tier or evaluation-oriented deployments exist 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 option built for that exact tradeoff.