Ile kosztuje godzina twojego LLM-a? Śledzenie tokenów bez czarnej skrzynki

# Ile kosztuje godzina twojego LLM-a? Śledzenie tokenów bez czarnej skrzynki

Wczoraj klient z Wrocławia zapytał nas, dlaczego jego chatbot oparty na GPT-4 nagle zaczął pożerać 12 tysięcy złotych miesięcznie. Po trzech dniach debugowania okazało się, że jeden z łańcuchów odpowiedzi zapętlał się na pustych promptach. Problem, którego nie wychwyciłby żaden dashboard dostawcy API – bo dostawcy nie widzą, co dzieje się po twojej stronie kodu.

## Dlaczego śledzenie kosztów LLM stało się problemem dla developerów?

Koszt jednego tokenu w GPT-4-turbo spadł w ostatnim roku o 40%, ale liczba tokenów zużywanych przez typową aplikację AI wzrosła o 300% [4]. To nie paradoks – to efekt coraz dłuższych łańcuchów odpowiedzi, retriesów i agentów działających równolegle. W Aion Automation widzieliśmy projekty, gdzie 60% kosztów generowały nie same odpowiedzi modelu, ale pętle debugujące i nieoptymalne prompty.

### Jak rosnące zużycie tokenów przekłada się na realne koszty projektów AI?

Przyjmijmy założenie: aplikacja korzystająca z GPT-4-turbo (0,01 PLN za 1000 tokenów wejścia, 0,03 PLN za 1000 tokenów wyjścia) przetwarza średnio 500 zapytań na godzinę. Każde zapytanie to 1500 tokenów wejścia i 500 tokenów wyjścia. W skali miesiąca (720 godzin) daje to:
- 540 milionów tokenów wejścia (5400 PLN)
- 180 milionów tokenów wyjścia (5400 PLN)
Razem: **10 800 PLN miesięcznie** – i to bez uwzględnienia kosztów infrastruktury czy retriesów.

W praktyce widzieliśmy projekty, gdzie rzeczywiste koszty były 2-3 razy wyższe z powodu:
1. Nieoptymalnych promptów (np. powtarzanie kontekstu w każdym zapytaniu)
2. Pętli debugujących (logowanie każdej iteracji agenta)
3. Braków w cache'owaniu odpowiedzi

### Przykład: Ile kosztuje jeden dzień pracy aplikacji z GPT-4?

Weźmy konkretny case – polską firmę z sektora e-commerce, która wdrożyła asystenta do obsługi zwrotów oparty na GPT-4. Aplikacja:
- Obsługuje 2000 zapytań dziennie
- Średnia długość promptu: 2000 tokenów
- Średnia długość odpowiedzi: 300 tokenów
- Dodatkowe tokeny na logowanie i debugowanie: 500 tokenów na zapytanie

Koszt dzienny:
- Wejście: 2000 zapytań × 2500 tokenów × 0,01 PLN/1000 = **50 PLN**
- Wyjście: 2000 zapytań × 300 tokenów × 0,03 PLN/1000 = **18 PLN**
- Razem: **68 PLN dziennie**, czyli **2040 PLN miesięcznie**.

Problem? Firma zakładała budżet na poziomie 800 PLN miesięcznie. Różnica wynikała z tego, że nikt nie śledził, ile tokenów faktycznie zużywa każdy łańcuch odpowiedzi – a jeden z nich generował dodatkowe 1200 tokenów na każde zapytanie przez błąd w logice retriesów.

### Dlaczego dotychczasowe narzędzia nie radzą sobie z łańcuchami odpowiedzi?

Dostawcy API (OpenAI, Anthropic) oferują podstawowe dashboardy, które pokazują tylko:
- Całkowite zużycie tokenów
- Średni czas odpowiedzi
- Liczbę zapytań

Brakuje w nich:
1. **Śledzenia łańcuchów odpowiedzi** – nie widać, które zapytanie wygenerowało kolejne zapytanie (np. agent decyzyjny wywołujący podagent)
2. **Kontekstu promptów** – nie da się sprawdzić, dlaczego dany prompt zużył więcej tokenów niż zwykle
3. **Integracji z kodem** – dashboardy nie pokazują, która linijka kodu wygenerowała dany koszt

Narzędzia takie jak LangSmith czy Weights & Biases rozwiązują część tych problemów, ale:
- Wymagają modyfikacji kodu (np. dodawania wrapperów)
- Są płatne od pewnego poziomu zużycia
- Nie integrują się z lokalnymi bazami danych (np. SQLite), co utrudnia analizę historyczną

## Czym jest datasette-llm-accountant i jak działa?

Datasette-llm-accountant to plugin do Datasette – narzędzia open-source do eksploracji danych stworzonego przez Simona Willisona [5]. W wersji 0.1a4 naprawiono krytyczny bug związany ze śledzeniem łańcuchów odpowiedzi (issue #7 w repozytorium Datasette) [3], który powodował, że narzędzie gubiło kontekst między kolejnymi wywołaniami modelu.

### Architektura narzędzia: integracja z Datasette i LLM

Narzędzie działa jako pośrednik między twoim kodem a API LLM. Zamiast bezpośrednio wywoływać `openai.ChatCompletion.create()`, używasz wrappera z biblioteki `llm-accountant`, który:
1. Loguje każde zapytanie do lokalnej bazy SQLite
2. Przypisuje unikalne ID do każdego łańcucha odpowiedzi
3. Śledzi, które zapytanie wygenerowało kolejne (np. agent decyzyjny → podagent)

Dane są przechowywane w tabeli `llm_usage` o strukturze:

CREATE TABLE llm_usage (

id INTEGER PRIMARY KEY,

timestamp DATETIME,

model TEXT,

prompt_tokens INTEGER,

completion_tokens INTEGER,

cost REAL,

chain_id TEXT, -- ID łańcucha odpowiedzi

parent_id INTEGER, -- ID zapytania, które wygenerowało to zapytanie

prompt TEXT, -- pełny prompt (opcjonalnie, można wyłączyć)

response TEXT -- pełna odpowiedź (opcjonalnie)

);

### Kluczowe funkcje wersji 0.1a4: naprawa bugów w śledzeniu łańcuchów

W poprzednich wersjach narzędzia występował problem z przypisywaniem `parent_id` w łańcuchach odpowiedzi. Jeśli agent decyzyjny wywoływał podagenta, a ten kolejny podagent, narzędzie gubiło kontekst i przypisywało wszystkie zapytania do jednego `chain_id` [3]. W wersji 0.1a4:
- Każde zapytanie w łańcuchu otrzymuje poprawne `parent_id`
- Można śledzić pełną ścieżkę od pierwszego do ostatniego zapytania w łańcuchu
- Dodano obsługę asynchronicznych wywołań (np. w LangChain)

### Jak narzędzie różni się od alternatyw?

| Funkcja                     | datasette-llm-accountant | LangSmith          | Weights & Biases   |
|-----------------------------|--------------------------|--------------------|--------------------|
| Śledzenie łańcuchów         | ✅ (od 0.1a4)            | ✅                 | ❌                 |
| Lokalna baza danych         | ✅ (SQLite)              | ❌ (chmura)        | ❌ (chmura)        |
| Koszt                       | Darmowe                  | Od $0.50/1000 zapytań | Od $1/1000 zapytań |
| Integracja z Datasette      | ✅                       | ❌                 | ❌                 |
| Wymagane modyfikacje kodu   | Minimalne (wrapper)      | Znaczące           | Znaczące           |

## Jak datasette-llm-accountant pomaga kontrolować koszty LLM?

### Śledzenie zużycia tokenów w czasie rzeczywistym: case study

W jednym z projektów dla polskiego startupu z branży HR narzędzie pomogło zidentyfikować, że 30% kosztów generuje jeden łańcuch odpowiedzi – agent odpowiedzialny za parsowanie CV. Analiza danych z `llm_usage` pokazała, że:
- Średnia długość promptu: 3200 tokenów (zamiast zakładanych 1500)
- Przyczyna: Agent dodawał pełne CV do każdego zapytania, zamiast wyciągać tylko istotne fragmenty
- Koszt miesięczny tego łańcucha: **1800 PLN** (przy 500 CV dziennie)

Po optymalizacji (wyciąganie tylko istotnych sekcji CV):
- Długość promptu spadła do 800 tokenów
- Koszt miesięczny spadł do **450 PLN**

### Analiza łańcuchów odpowiedzi: jak identyfikować nieefektywne zapytania?

Kluczową funkcją jest możliwość wizualizacji łańcuchów odpowiedzi w Datasette. Przykładowe zapytanie SQL, które pokazuje najdroższe łańcuchy:

SELECT

chain_id,

COUNT(*) as query_count,

SUM(prompt_tokens + completion_tokens) as total_tokens,

SUM(cost) as total_cost

FROM llm_usage

GROUP BY chain_id

ORDER BY total_cost DESC

LIMIT 10;

Wyniki dla jednego z projektów:
| chain_id | query_count | total_tokens | total_cost (PLN) |
|----------|-------------|--------------|------------------|
| abc123   | 12          | 45000        | 12.60            |
| def456   | 8           | 32000        | 8.96             |
| ghi789   | 5           | 25000        | 7.00             |

Dalsza analiza łańcucha `abc123` pokazała, że:
1. Pierwsze zapytanie (agent decyzyjny) zużyło 5000 tokenów
2. Drugie zapytanie (podagent do weryfikacji) zużyło 8000 tokenów
3. Trzecie zapytanie (podagent do formatowania) zużyło 12000 tokenów – i okazało się zbędne

### Integracja z popularnymi frameworkami

Narzędzie integruje się z:
- **LangChain**: poprzez `LLMAccountantCallbackHandler`
- **LlamaIndex**: poprzez `LLMAccountantQueryEngine`
- **Bezpośrednio z OpenAI API**: poprzez wrapper `llm_accountant.openai`

Przykład integracji z LangChain:

from langchain.callbacks import LLMAccountantCallbackHandler

from langchain.chains import LLMChain

handler = LLMAccountantCallbackHandler()

chain = LLMChain(llm=llm, prompt=prompt, callbacks=[handler])

response = chain.run("Analizuj to CV")

## Kto powinien używać datasette-llm-accountant?

### Zespoły developerskie: jak narzędzie wspiera debugowanie?

Dla developerów największą wartością jest możliwość:
1. **Śledzenia pełnej historii promptów i odpowiedzi** – bez konieczności logowania ich ręcznie
2. **Identyfikacji pętli w łańcuchach odpowiedzi** – narzędzie pokazuje, które zapytanie wygenerowało kolejne
3. **Porównywania kosztów różnych modeli** – np. GPT-4 vs GPT-3.5-turbo dla tego samego zadania

Przykład z życia: W jednym z projektów narzędzie pomogło odkryć, że agent odpowiedzialny za klasyfikację zapytań użytkowników generował średnio 3 dodatkowe zapytania na każde główne zapytanie – tylko po to, by "upewnić się" co do odpowiedzi. Koszt tych dodatkowych zapytań: **2400 PLN miesięcznie**.

### Decydenci: jak raporty pomagają w planowaniu budżetu?

Dla menedżerów i product ownerów narzędzie dostarcza:
- **Prognozy kosztów** – na podstawie historycznych danych
- **Alerty o przekroczeniach budżetu** – można ustawić limity dzienne/miesięczne
- **Porównania efektywności** – np. koszt na jedno udane rozwiązanie problemu użytkownika

Przykładowy raport dla decydenta:

Miesiąc: Maj 2026

Całkowity koszt: 8 450 PLN

Najdroższy łańcuch: "analiza_sentimentu" (1 200 PLN)

Najtańszy łańcuch: "odpowiedzi_faq" (150 PLN)

Średni koszt na zapytanie użytkownika: 0.42 PLN