Monitoring kosztów LLM: jak nie przepalić budżetu na AI

Rachunek za AI rzadko eksploduje z jednego powodu. Zwykle rośnie cicho: trochę dłuższe konteksty, kilka procent retry, embeddingi przy każdym zapytaniu, prompt systemowy doklejany do każdego wywołania. Po kwartale firma płaci dwa razy więcej i nie potrafi wskazać, co konkretnie pochłania budżet. FinOps dla LLM zaczyna się od jednego założenia: nie da się optymalizować tego, czego się nie mierzy w rozbiciu.

Globalny rachunek z chmury mówi tylko, że jest drogo — nie mówi, co naprawdę kosztuje. Sensowny monitoring rozbija wydatek na trzy osie. Per token pokazuje stosunek tokenów wejściowych do wyjściowych i wyłapuje rozdmuchany kontekst. Per funkcję przypisuje koszt do konkretnego zadania: klasyfikacja, streszczenie, odpowiedź RAG, generowanie raportu. Per użytkownika (albo per klient, per zespół) odkrywa, że 5% kont generuje 40% rachunku.

Dopiero te trzy widoki razem dają decyzję. Jeśli jedna funkcja zżera połowę budżetu, optymalizujesz właśnie ją, a nie cały system po równo. To ta sama logika, którą stosujemy przy monitoringu jakości agenta AI — bez atrybucji per zadanie pomiar jest ozdobą, nie narzędziem.

Większość przepalonego budżetu nie pochodzi z „za dużego modelu”, tylko z miejsc, których nikt nie patrzy. Oto najczęstsze.

Najbardziej podstępne są długie konteksty i prompty systemowe, bo są niewidoczne — wyglądają jak „normalne” wywołanie, a po cichu mnożą tokeny wejściowe przez każdy request. Krótszy prompt systemowy i kontekst przycięty do tego, co naprawdę potrzebne, bywa większą oszczędnością niż zmiana modelu.

Dwie dźwignie dają najszybszy zwrot. Pierwsza to cache semantyczny: pytania o zbliżonym znaczeniu obsługujesz z bufora zamiast wysyłać do modelu. W scenariuszach FAQ i obsługi klienta powtarzalność jest wysoka, więc wskaźnik trafień bywa znaczący — zamiast pełnej inferencji odpowiadasz z bufora. Zasada jest prosta: zapłać raz, odpowiadaj wielokrotnie.

Druga to routing do tańszego, wystarczającego modelu. Nie każde zadanie potrzebuje największego modelu. Klasyfikacja zgłoszenia, wyciągnięcie pola z formularza czy krótkie streszczenie radzą sobie na małym, tanim modelu; mocny rezerwujesz na zadania, które naprawdę go wymagają. To rola routera LLM — pojedyncza decyzja, która często obniża koszt zmienny o 40-70% przy nieodczuwalnej zmianie jakości. Jak wybierać model do zadania, rozkładamy na czynniki w osobnym przewodniku.

Optymalizacja bez hamulca to połowa roboty. Druga połowa to budżety i alerty, które zatrzymują rachunek, zanim zrobi się drogo. W praktyce wdrażamy kilka prostych mechanizmów:

• Budżet dzienny i miesięczny per funkcja oraz per klient, z miękkim progiem (alert) i twardym (degradacja do tańszego modelu lub throttling).
• Alert na anomalię — nagły skok kosztu per użytkownika zwykle oznacza pętlę retry, nadużycie albo wyciekający kontekst.
• Tagowanie każdego wywołania identyfikatorem funkcji i tenantem, żeby atrybucja była automatyczna, nie ręczna.
• Kill-switch na poziomie obserwowalności, który odcina kosztowną funkcję bez kładzenia całego systemu.

Te mechanizmy nie zastępują optymalizacji — pilnują, żeby jeden błąd w kodzie albo nietypowy ruch nie zamienił dobrego miesiąca w przepalony budżet. Koszt jednostkowy liczymy tak samo, jak przy wycenie agenta AI: za jedno wykonane zadanie, nie za abstrakcyjny „miesiąc AI”.

Pytanie „własne serwowanie czy API z chmury” to pytanie o wolumen, nie o ideologię. Przy małym i nieregularnym ruchu chmura wygrywa — płacisz za zużycie, brak kosztu wejścia, zero utrzymania. Przy stałym, dużym obciążeniu self-hosting zaczyna wygrywać: amortyzacja sprzętu i własna inferencja dają niższy i — co ważniejsze — przewidywalny koszt jednostkowy.

Punkt przecięcia zależy od liczby wywołań miesięcznie i od tego, czy masz kto by utrzymał infrastrukturę. Nie podajemy jednej liczby, bo byłaby zmyślona — granica przesuwa się z każdą generacją sprzętu i każdą zmianą cennika chmury. Dlatego dobieramy wariant do realnego obciążenia, mierząc koszt jednostkowy w obu, zanim cokolwiek przełączymy na stałe.

Od atrybucji: tagowania każdego wywołania funkcją, tenantem i liczbą tokenów wejściowych oraz wyjściowych. Bez tego widzisz tylko globalny rachunek i nie wiesz, co optymalizować. Dopiero gdy masz koszt per funkcję i per użytkownika, wybór dźwigni (cache, routing, krótszy kontekst) staje się oczywisty.

Najczęściej nie sam model, lecz długie konteksty i prompty systemowe doklejane do każdego wywołania, brak cache na powtarzalnych pytaniach oraz pętle retry. Te koszty są ukryte, bo każde pojedyncze wywołanie wygląda normalnie — sumują się dopiero w skali ruchu.

Z naszego doświadczenia routing do tańszego, wystarczającego modelu obniża koszt zmienny zwykle o 40-70%, a cache semantyczny w scenariuszach z powtarzalnymi pytaniami potrafi przejąć od kilkunastu do ponad 50% wywołań. Łączny efekt zależy od profilu ruchu, więc traktuj te widełki jako orientację, nie obietnicę.

Na początek nie — wystarczy konsekwentne logowanie kosztu per wywołanie i prosty dashboard z budżetami oraz alertami. Dedykowane narzędzia mają sens przy wielu modelach, wielu zespołach i dużym wolumenie. Najważniejsza jest dyscyplina atrybucji, nie marka narzędzia.

Przy stałym, dużym wolumenie oraz tam, gdzie liczy się przewidywalność kosztu i rezydencja danych. Przy małym lub nieregularnym ruchu chmura zwykle wygrywa brakiem kosztu wejścia. Granicę wyznacza Twój wolumen — policz koszt jednostkowy w obu wariantach, zanim zdecydujesz.