Finance notices a sudden spend jump on the city’s open-data LLM after a viral social post. Which monitoring practice best explains and contains that growth?
Select an answer to reveal the explanation.
Short Explanation
Viral fame can empty your token wallet. Watching cost across prompts, storage, responses, and processing shows where the open-data LLM bill exploded. Latency percentiles, access logs, or fine-tuning runtimes won't trace the spend for you—only dimensional cost tracking catches a weekend spike.
Full Explanation
When finance sees a sudden spend jump on the city's open-data LLM after a viral social post, monitoring AI costs across prompts, storage, responses, and processing best explains and contains that growth. Viral attention often multiplies prompt volume, context size, embedding storage, and generation tokens at once; a single yearly GPU invoice will not show which dimension exploded over a weekend. Dimensional cost meters let the city attribute spend to public apps, API keys, or features, then apply caps, caching, or retrieval limits without guessing. Cost monitoring is therefore both a FinOps and abuse/availability control for municipal generative services.
Tracking inference latency percentiles by region to map viral demand for capacity planning misses the point for spend control—latency metrics diagnose performance, not cost, so they cannot reveal which prompt, storage, response, or processing dimension drove the spike or help contain it. Auditing open dataset access logs with retention reviews to control storage volume growth targets data governance rather than the LLM's usage-based spend; it will not attribute the viral surge to prompts, responses, or processing or let you cap the drivers in time. Monitoring fine-tuning job runtimes and experiment history to forecast future serving budget needs looks at training experiments, not the live inference traffic behind the spike; it cannot explain or contain this weekend's growth.
Exam caveat: Cost monitoring must be dimensional (prompts, storage, responses, processing) and timely, not a single compute metric or a once-a-month total. Do not confuse a licensing fee with the ongoing usage-based costs that scale with viral traffic. Also separate legitimate viral public interest from abusive scraping—both can spike cost, but responses differ (scale vs block).
Operational check: Ensure open-data LLM billing meters cover prompts, storage, responses, and processing on a timely basis; alert on spend anomalies; map costs to keys/apps; enforce temporary rate limits after viral events; and keep cost dashboards broken down by dimension rather than a single compute number or a once-a-month total.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.