A költség a motor egyik mérnöki ügye, nem pénzügyi probléma. Ha egy fejlesztő egy lassú kérés trace-ét nézi és nem látja a kérés árát, akkor a költség valaki más asztalán van, és valaki más fogja későn észrevenni, ha drift indul. Ez a poszt arról szól, hogyan tettük a per-request költséget OpenTelemetry-span attribute-ra, mit tanultunk a CFO-szintű reconciliation-ról, és miért nem stimmel sosem a havi tenant-nézet az összegzett trace-költségekkel.
Per-span ár
Minden LLM-hívás egy önálló OTel-span. A span attribute-jain llm.tokens.input, llm.tokens.output, llm.model.id, llm.provider, llm.cost.eur szerepel. A llm.cost.eur egy live computation: token count × current price-per-token a eng_pricing_table táblából. Ez fontos: nem azt írjuk a span-re, hogy „az ár majd valamikor kiszámolódik”, hanem azt, amennyi a kérés pillanatában volt. A Grafana-dashboard egyetlen kattintással bemutatja a per-tenant órás költséget, a top-N legdrágább kérést, és a modell-mix költségbontását.
A cost-attribution-collector egy BullMQ worker, ami 30 másodpercenként olvassa a friss span-eket a Loki-ból, és egy aggregált sort ír a eng_cost_hourly táblába. Az aggregáció kulcsai: tenant_id, model_id, hour_bucket, request_type. Egy kérés többszöri aggregációja nem ütközik, mert van dedup_key = trace_id + span_id.
A pricing-tábla refresh job
A pricing tábla automatikusan frissül 6 óránként egy pricing-refresher worker által, ami a provider-ek nyilvános ár-API-jaiból olvas. Vannak provider-ek, akik nem publikálnak ár-API-t (lookup table embedded a kódban, manuálisan frissítjük havonta). A refresh tranzakcionális — vagy minden új ár sikeresen beíródik, vagy egy sem. A historikus árakat egy eng_pricing_history tábla őrzi, így ha valaki visszamenőleg újraszámolja egy hat hónappal ezelőtti kérés árát, kapja vissza a korabeli árat, nem a maiat. Ez audit-szintű követelmény több ügyfélnél.
Miért nem stimmel a havi nézet
A havi tenant-nézet azt mondja, hogy A tenant 4 821 EUR-t fogyasztott. A trace-szintű összegzés 4 967 EUR. A különbség 146 EUR, kb. 3%. A különbség oka: sampling. Nem minden trace-et exportálunk Loki-ba, csak egy reprezentatív minta (1:10 sampling a sztenderd kérésekre, 1:1 hibákra és lassú kérésekre). Az aggregáció a teljes esemény-streamen történik (Kafka-szintű), nem a sampled trace-eken, ezért a havi nézet pontosabb. A trace-szintű összegzés mindig kicsit eltér — ezt egy trace_coverage_pct mezővel jelöljük a Grafanán.
A negyedéves CFO-grade reconciliation
Negyedévente egy negyedéves reconciliation fut: a tenant-szintű számlázott összeget összeolvassuk a stripe/billing rekordokkal, és minden eltérést manuálisan vizsgálunk, ha 0.5%-nál nagyobb. Az elmúlt négy negyedévben háromszor találtunk bug-ot. Mindhárom a pricing-history tábla edge-case-e volt (új ár-révízió ÷ régi ár-révízió között lévő kérések). Mindhárom javítva van. A pénzügy most ezt a folyamatot „audit-quality”-nek nevezi, ami egy mérnöki csapatnak a maximális dicséret, amit valaha kaphat a pénzügytől.
Tool-call alspan költség
A top-level LLM-span mellett minden tool-call (RAG-lekérés, web-search, embedding-számítás) saját alspan, és minden alspan kap egy tool.cost.eur mezőt. Egy chat-session teljes költsége így nem a fő LLM-hívás ára, hanem a fő span + az összes alspan összege. Az embedding-pipeline egy ideig olcsónak látszott, mert csak a top-level span-eken néztük; amikor alspan-szintre mentünk, egy nagy RAG-tenant havi költségének 23%-a kizárólag az embedding-újraszámolásokból jött, egy konfigurációs bug miatt, ami minden user-üzenetnél az egész kontextust újra-embeddingelte. A bug fix 1 napos, a megtakarítás évi ~28 000 EUR — pontosan az a fajta optimalizáció, amit a span-szintű cost-attribution nélkül soha nem találtunk volna meg. A heti pénzügyi review-n ez egy bekezdéssel jött elő, három grafikonnal és egy egysoros javítási committal; a következő héten már az új baseline volt a háttérben.
A költségen túl: a fejlesztői trace-nézet
A legnagyobb haszna nem a havi nézetben van. A legnagyobb haszna abban a pillanatban, amikor egy fejlesztő egy lassú kérés trace-ét nézi, és a span-en ott az ár. Egy 8 másodperces, 0.18 EUR-os kérés más incidens, mint egy 8 másodperces, 0.002 EUR-os — ugyanaz a latencia, teljesen más probléma. A trace-szintű ár az, ami lehetővé teszi az on-call-mérnöknek, hogy hajnali 3-kor egy billing rendszer-tab nyitása nélkül szétbontsa a két történetet.