A three-person startup wants to add a chat feature powered by a large language model deployed through Azure AI Foundry. Traffic is unpredictable, sometimes zero requests for days and then a burst of hundreds in an hour, and the team has no one available to manage server capacity. Which deployment option should they choose for the model?
Select an answer to reveal the explanation.
Short Explanation
Picture a tiny team with no ops person and traffic that goes from zero to a flood without warning. Paying for a machine that sits there 24/7 waiting for that flood is money burned on quiet days, and building your own server fleet just hands the team a full-time job they don't have people for. A daily batch process is also out since a chat feature needs answers right now, not tomorrow morning. What actually fits is a pay-per-use option: it scales itself up when the burst hits and scales back down when things go quiet again, and nobody has to babysit it. That's the whole appeal for a small team like this one: the billing follows the actual traffic instead of a guess about how big to build the server ahead of time, and there's no capacity plan to maintain at all.
Full Explanation
The correct answer is B. A serverless API endpoint in Azure AI Foundry bills per token consumed and scales automatically, which fits a workload that swings between idle and bursty without anyone available to plan or manage capacity. Option A is incorrect because sizing a dedicated managed-compute endpoint for the peak burst and running it continuously means paying for idle capacity during the many quiet days, which is wasteful for a three-person team's budget and still requires someone to monitor and resize it over time. Option C is incorrect because self-hosting model weights on a virtual machine scale set shifts all patching, scaling, and capacity planning onto the team, exactly the operational burden they explicitly cannot take on. Option D is incorrect because a once-a-day batch job cannot support a chat feature, which needs responses within seconds of a user typing a message, not a daily processing window. The serverless option removes infrastructure management and aligns cost with actual usage, making it the right fit for this scenario's combination of unpredictable traffic and limited staff.