A three-person startup is prototyping a chatbot feature and expects only a few dozen test requests per day for the next month while early users try the concept. Request volume will be unpredictable, sometimes dropping to zero for a full day, and the team wants to avoid committing to reserved capacity while they are still validating the idea.
Select an answer to reveal the explanation.
Short Explanation
When traffic is this unpredictable, sometimes a trickle of test requests, sometimes nothing at all for a day, paying for a chunk of reserved capacity is like renting a whole conference room to hold a two-person coffee chat. The billing model that fits here charges only for what actually gets used, token by token, so quiet days cost nothing and busy days just cost a bit more. Locking in a provisioned amount of capacity, or worse, a year-long reserved cluster, only pays off once traffic is steady and predictable enough to justify the upfront commitment, and this team isn't there yet. Trying to fine-tune a smaller model to save money is also solving the wrong problem at the wrong time, since customizing a model doesn't change how deployment is billed, and it adds work before anyone even knows if the concept will stick.
Full Explanation
The correct answer is C. A pay-as-you-go, or standard/serverless, deployment bills only for the tokens actually consumed and carries no capacity commitment, which matches a workload that swings from a few dozen requests a day to none at all during an early validation phase. Option A is incorrect because provisioned throughput units are priced for reserving guaranteed capacity ahead of time, which makes sense for steady high-volume traffic but wastes money when demand is this sparse and unpredictable. Option B is incorrect for the same reason: a dedicated cluster reserved for a year assumes sustained usage that a one-month prototype with idle days does not have, locking the startup into a long-term cost before the concept is even validated. Option D is incorrect because fine-tuning is a model-customization step that adds upfront cost and engineering time; it does not address the deployment billing model at all, and doing it before the idea is validated risks investing in a version of the product that may still change.