The maintenance-triage agent now classifies every crane log entry in near real time as terminals file them, producing a steady, high, predictable volume of requests around the clock. Which Foundation Model APIs deployment mode best fits this workload compared to the pay-per-token default?
Select an answer to reveal the explanation.
Short Explanation
Pay-per-token is the corner store, fine for occasional trips, but once you are buying in bulk around the clock, provisioned throughput is the standing order that reserves dedicated capacity for you and keeps the wait time consistent instead of competing for a shared pool.
Full Explanation
Provisioned throughput reserves dedicated model-serving capacity sized to a known, steady request volume, which delivers more predictable latency than the shared, elastic pay-per-token tier and becomes the more cost-effective choice once volume is high and steady rather than sparse or bursty, matching the near-real-time, around-the-clock classification load described. Pay-per-token is the correct default for light or unpredictable usage, but it is not universally cheaper; at sustained high volume its per-request economics work against the caller, which is exactly the trade-off provisioned throughput exists to address. External Models let Databricks route requests to a third-party-hosted model through a unified interface, which solves a model-choice or vendor problem, not a volume-and-latency-consistency problem, and it does not remove capacity planning concerns since the third party's own throughput limits still apply. A Direct Vector Access index is a Vector Search index type for self-managed vector population and has nothing to do with Foundation Model API deployment modes or embedding cost on classification requests, making it an unrelated distractor pulled from a different part of the exam guide. Choosing provisioned throughput versus pay-per-token on volume and latency predictability is a core Application Development and Deployment trade-off.