A logistics company runs a nightly batch job that pushes roughly 50 million tokens through a Foundry-hosted model every night between 1 a.m. and 4 a.m., with almost no traffic the rest of the day. Operations needs a guaranteed, consistent level of throughput and latency during that fixed nightly window, and cost predictability matters more than minimizing per-request price. Which deployment option best fits this need?

A provisioned throughput deployment sized for the nightly peak demand is the best fit because it reserves a fixed amount of model capacity ahead of time, giving the operations team the guaranteed throughput and predictable latency they need during their fixed nightly window, along with predictable monthly cost rather than variable per-token billing. A pay-as-you-go consumption deployment billed per token is incorrect because it scales with demand but makes no capacity guarantee; if other tenants place heavy load on the shared service at the same time, the nightly job could see degraded throughput and latency, which is exactly what the team wants to avoid. A shared free-trial deployment meant for small-scale evaluation is incorrect because free-trial or evaluation-tier deployments are meant for small-scale testing, not production workloads with tens of millions of tokens nightly, and typically carry usage caps that would block the job partway through. The smallest available SKU, with requests queued until capacity frees up, is incorrect because queueing requests against an undersized SKU trades away the guaranteed timing the team needs; the batch job would simply run slower during contention instead of getting the reserved capacity that provisioned throughput provides.