Cost-by-category dashboard — miért nem elég a totál

A „havi LLM-költség 12 800 EUR” mondat ártalmatlan, amíg meg nem kérdezed: mire? Egy szám, egy CFO, és nulla mérnöki cselekvési lehetőség. Ezért építettük meg a cost-by-category dashboardot — egy négydimenziós mátrixot, ami a totál árát szétbontja addig a pontig, ameddig már fejlesztői döntéssel optimalizálható.

A négy dimenzió

1. Tenant — melyik ügyfél kéréseit szolgáltuk?
2. Use-case — site_chat, workflow_step, voice_transcription, embedding, vagy egyedi category címke (category-checkout-assistant, category-onboarding-bot, stb.).
3. Provider — OpenAI, Anthropic, Azure, Gemini, Mistral, ElevenLabs, Hume, Deepgram.
4. Model — gpt-4o, claude-3-5-sonnet, gemini-2.0-flash, stb.

A mátrix tárolása egy eng_cost_hourly táblában történik, kulcsai: (tenant_id, use_case, provider, model_id, hour_bucket). Tartalma: request_count, tokens_input, tokens_output, cost_eur, latency_p50_ms, latency_p95_ms, error_count.

Miért NEM elég a totál

Egy konkrét eset 2026 májusából. A havi szám 11 200 EUR-ról 15 800 EUR-ra ugrott egy hónap alatt. A totál-nézet csak annyit mondott: „+41%”. Egy weekend-projekt árán épült dashboard a következő hétfőn pontosan ezt mutatta:

• A tenant-bontásban egyetlen ügyfél (let's say Tenant-X) +3 200 EUR-t adott hozzá.
• A use-case bontásban kiderült, hogy Tenant-X-nél a voice_transcription ugrott meg 8x.
• A provider-bontásban: az ElevenLabs összes hangszöveg-feladatra rátett egy retry-loop-ot, ami másodszori számlázáshoz vezetett.
• A modell-bontásban: kifejezetten az eleven_multilingual_v2 modell, nem a turbo_v2.

Öt perc alatt a probléma azonosítva, a fix egy provider adapter retry-policy fix volt, két soros változtatás. A totál-nézet nem oldotta volna meg ezt a problémát soha. A bontás oldotta meg.

A cockpit /cockpit/cost-by-category route

A dashboard alapja egy pivot-tábla, ahol a sorok és oszlopok dimenziókat választasz a négy közül, a metrika pedig cost_eur (default), request_count, cost_per_request, vagy error_rate. Filterek: dátumtartomány, tenant subset, minimum cost threshold. Egy időbeli timeseries-panel mutatja a top-5 kategória trendjét; a deploy-markerek (lásd: prompt deployment poszt) overlay-zve láthatók.

A „kategória” mező mint mérnöki primitív

A category mező teljesen szabad szöveg, és minden LLM-hívásnál opcionálisan megadható. A konvenció: <feature>-<step>. Például checkout-summary, onboarding-welcome, cart-recommendation. Az ajánlott pattern: minden új feature-höz egy új category. Ha egy fejlesztő bevezet egy új use case-t, az első kérdés a code review-n: „milyen category cimkét tettél rá?” A cimke nélkül a feature-t soha nem fogjuk tudni szétválasztani a havi nézetben.

Az alerting bekötése

Minden kategória cost_per_request átlagát napi szinten összevetjük az utolsó 7 nap mediánjával. Ha 3x-osra ugrik (és a request-szám nem esett 1/3-ára, ami egy másik magyarázat lehet), Slack-üzenet a #engine-cost csatornán. Az elmúlt két hónapban 7 ilyen riasztás történt: 5 valódi bug volt, 2 várt feature-rollout (new larger model). 70%-os pozitív arány elég jó ahhoz, hogy a csapat NE feliratkozzon le.

A mérnöki gondolkodás váltása

A cost-by-category dashboard után megváltozott a code review hangneme. „Milyen modellt fog ez használni?” és „mennyi a várt cost-per-request?” mostmár sztenderd kérdés. Korábban a költség egy CFO-szintű ügy volt, ami havonta egyszer érintette a mérnököket. Most egy PR-szintű ügy, ami minden kódváltozást érint. Ez az igazi haszna, nem a havi szám.