A small team wants to try out a lightweight open model from the Azure AI Foundry model catalog for a proof-of-concept chatbot. Usage will be low and unpredictable during testing, and the team has no interest in provisioning or managing GPU virtual machines. Which deployment approach best fits their situation?
Select an answer to reveal the explanation.
Short Explanation
When you are just kicking the tires on a model and do not know yet whether traffic will be light or nonexistent, you want to pay only for what you actually use, not for a reserved machine sitting there waiting. Renting a GPU box that is sized for busy periods means you are paying full price even when nobody is using the chatbot, which is backwards for a small test. Standing up your own cluster to run the model yourself is even more work, since now you are the one keeping the lights on for infrastructure you did not want to manage in the first place. And just poking at the model in a testing window is fine for trying out prompts, but it is not something another piece of software can actually call to get an answer back. The option that fits a small, uncertain workload is the one that charges per request and hands off all the server management, so the team can focus on whether the chatbot idea works at all.
Full Explanation
The correct answer is C. A serverless pay-as-you-go deployment bills per call rather than for reserved infrastructure, which fits a proof of concept with light, unpredictable traffic, and it requires no GPU virtual machine provisioning or maintenance from the team. Option A is incorrect because reserving GPU compute sized for peak load means paying for idle capacity most of the time, which is wasteful for a low-traffic proof of concept and also reintroduces the VM management the team wants to avoid. Option B is incorrect because standing up and manually scaling an AKS cluster requires exactly the kind of infrastructure operations the team explicitly wants to skip, and it adds substantial setup time for a quick test. Option D is incorrect because the playground is an interactive testing surface for experimenting with prompts and settings, not a callable API endpoint that an application can integrate with in production; a real chatbot needs an actual deployed endpoint to send requests to. For a lightweight, low-commitment test, the serverless option minimizes both cost and operational burden while still providing a real callable endpoint.