Meridian Line's port-operations copilot endpoint needs to stay responsive during a sudden surge in queries when a major storm disrupts several ports at once, but the team also does not want to pay for reserved capacity that sits idle the other 350 days a year. Which Model Serving consideration most directly addresses this trade-off?

Balancing responsiveness during a rare traffic spike against not paying for capacity that sits idle most of the year is exactly the trade-off between pay-per-token Foundation Model APIs, which scale with demand and avoid idle reserved cost, and provisioned throughput, which guarantees fixed capacity but is paid for continuously whether traffic is high or low, and the right choice depends on weighing that trade-off against the endpoint's actual traffic shape, here mostly low steady demand punctuated by rare storm-driven surges. Increasing context length changes how much text a single request can include, it has no relationship to how many concurrent requests an endpoint can serve during a traffic spike, and does not address capacity or cost at all. Changing the embedding model size affects the cost and latency of the Vector Search retrieval step and the dimensionality of stored vectors, it is not the lever that determines how a Model Serving endpoint scales to handle a surge in incoming requests. Broadening Unity Catalog permissions on the service principal is an access-control change entirely unrelated to serving capacity or auto-scaling behavior, more permissions do not make an endpoint handle more traffic. Exam framing: matching Foundation Model API pay-per-token versus provisioned throughput to the actual traffic pattern is the core cost-versus-responsiveness decision for a serving endpoint.