Skip to main content

Token Burn Rate (Tempo spalania tokenów)

DLA AGENTÓW AIChatGPTClaude

Kluczowa metryka inżynieryjna i finansowa określająca tempo zużycia tokenów kontekstowych i generacyjnych (oraz kosztów w dolarach na godzinę) podczas sesji deweloperskich z agentami, uwzględniająca mechanizmy cache'owania promptów.

1. Przegląd koncepcji i problem systemowy

W standardowych chatbotach zużycie tokenów jest znikome: jedno pytanie i odpowiedź pochłaniają kilkaset tokenów. Jednak w przypadku vibe codingu oraz autonomicznych cykli agentowych (Cursor Composer, Claude Code, OpenHands) dynamika zużycia zmienia się radykalnie. Agent wczytuje do kontekstu reguły projektu, fragmenty bazy kodu przez indeks, schematy narzędzi oraz logi terminala, wysyłając od 50 000 do 150 000 tokenów przy każdej iteracji.

Jeśli agent wykonuje 25 kroków, aby naprawić błąd, łączny wolumen tokenów wejściowych łatwo osiąga kilka milionów. Jeśli inżynier nie rozumie metryki Token Burn Rate (tempo spalania tokenów), projekt szybko natrafia na szok finansowy: setki dolarów dziennie na jedną stację roboczą lub zablokowanie limitów firmowego klucza API w środku dnia pracy.

2. Taksonomia architektoniczna i model mentalny

Struktura kosztów tokenów we współczesnych systemach agentowych dzieli się na cztery nierównorzędne kategorie:

┌─────────────────────────────────────────────────────────────┐
│                 KOSZTOWA STRUKTURA ZUŻYCIA TOKENÓW          │
├─────────────────────────────────────────────────────────────┤
│ 1. Tokeny wejściowe z cache (trafienie w Prompt Caching) ➔ -90% kosztu │
│    Statyczne reguły repozytorium, pliki bazowe, prompt systemowy       │
├─────────────────────────────────────────────────────────────┤
│ 2. Świeże tokeny wejściowe (brak trafienia w cache) ➔ 100% kosztu     │
│    Nowe pliki, logi terminala, bieżące wiadomości inżyniera           │
├─────────────────────────────────────────────────────────────┤
│ 3. Tokeny generowania (wyjście / bloki kodu) ➔ stawka 3-5x            │
│    Wygenerowany kod, wywołania narzędzi w formacie JSON               │
├─────────────────────────────────────────────────────────────┤
│ 4. Tokeny myślenia / rozumowania (rozszerzone CoT) ➔ Premium         │
│    Wewnętrzne ukryte procesy rozumowania modeli Claude 3.7 / o1       │
└─────────────────────────────────────────────────────────────┘
  1. Bazowe zużycie wejściowe (Context Ingestion):
    • Wolumen kontekstu, który model przetwarza na każdym kroku. Im dłuższa rozmowa, tym większa waga każdego kolejnego zapytania.
  2. Kontekst buforowany (Cached Prefix):
    • Tokeny przechowywane w pamięci KV kart graficznych dostawcy. Mają obniżoną cenę (np. $0.30 za 1M zamiast $3.00 w Claude Sonnet), o ile prefiks zapytania nie ulega zmianie przez kilka minut.
  3. Tokeny generowanego kodu (Output Tokens):
    • Kod zwracany przez model. Taryfikowany znacznie drożej niż tokeny wejściowe (od 3 do 5 razy), ponieważ wymaga sekwencyjnego obliczania autoregresyjnego na GPU.
  4. Tokeny rozszerzonego myślenia (Thinking Tokens):
    • Wewnętrzne łańcuchy rozumowania modeli nowej generacji. Skomplikowane zadanie może wygenerować 10 000 tokenów „myśli”, zanim model napisze pierwszą linię kodu.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia monitoringu i kontroli Token Burn Rate:

  1. Pre-inferencyjne liczenie tokenów (Token Counting): Lokalny tokenizer (np. tiktoken lub biblioteka tokonizacji dostawcy) oblicza długość sformułowanego promptu przed wysłaniem.
  2. Weryfikacja limitów (Circuit Breaker & Guardrails): System porównuje bieżące wydatki z ustalonym budżetem: jeśli obecna sesja przekroczyła próg $5.00, do inżyniera wysyłane jest ostrzeżenie.
  3. Optymalizacja struktury promptu dla zachowania cache: Architektura zapytania jest układana tak, aby dane statyczne (reguły, manifesty narzędzi) znajdowały się na początku, a dynamiczne (świeże wyjście terminala) – na końcu. Zapobiega to unieważnieniu cache dostawcy.
  4. Pozyskiwanie telemetrii po odpowiedzi: Z nagłówków odpowiedzi API odczytywane są dokładne wskaźniki: prompt_tokens, completion_tokens, cache_read_input_tokens, cache_creation_input_tokens.
  5. Obliczanie bieżącego tempa spalania: Wyliczana jest prędkość wydatków ($/minutę lub $/zadanie) i wyświetlana w pasku stanu IDE lub terminala.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Strukturyzacja architektoniczna promptów pod kątem zachowania 90% rabatu z cache

Inżynier konfiguruje pracę z Claude 3.7 Sonnet:

  • Umieszczenie dynamicznego timestamp lub zmiennych logów na początku systemowego promptu sprawi, że cały kontekst 100k zostanie uznany za nowy, spalając $0.30 przy każdym kroku.
  • Przeniesienie zmiennych elementów do najnowszego bloku zapytania zapewnia 95% trafień w cache (Cache Hit), obniżając koszt cyklu 20-krokowego z $6.00 do $0.80.

02. Korporacyjny gateway kontroli budżetów deweloperów

Dyrektor technologiczny firmy wdraża serwer proxy (LiteLLM / Portkey):

  • Każdy inżynier otrzymuje osobisty dzienny limit wynoszący $15.
  • Po osiągnięciu 80% limitu deweloper otrzymuje powiadomienie na Slacku.
  • Przy 100% narzędzie automatycznie przełącza nielimitujące zadania na ultra-tanie modele (DeepSeek V3 lub Claude Haiku).

03. Wykrywanie awaryjnej pętli (Infinite Loop Detection)

Autonomiczny agent wpada w cykliczną próbę instalacji nieskompatybilnej biblioteki:

  • Detektor Token Burn Rate zauważa, że w ciągu ostatnich 3 minut wysłano 8 zapytań bez zmiany wynikowego kodu, co spaliło 1.2M tokenów.
  • Proces jest awaryjnie przerywany, co chroni fundusze firmy.

5. Pułapki, typowe błędy i bezpieczeństwo

  • Przypadkowe unieważnienie cache prefiksu: Dodanie losowych UUID lub aktualnego czasu na początku rozmowy niszczy całą pamięć KV, zwiększając rachunek finansowy dziesięciokrotnie.
  • Niewidoczny overdraft w modelach myślenia (Thinking Budget Overflow): Jeśli nie ograniczymy parametru max_thinking_tokens, model może „myśleć” przez 30 000 tokenów nad trywialną zmianą nazwy przycisku, spalając środki bez dodanej wartości.
  • Zostawione sesje w tle w terminalu: Uruchomienie kilku agentów CLI w różnych zakładkach terminala bez monitoringu może prowadzić do niezauważalnego wyczerpania firmowego salda, jeśli jeden z procesów utknie.
  • Nieprawidłowa konfiguracja alertów dostawcy: Brak ustawionych sztywnych limitów (Hard Limits) w panelach Anthropic lub OpenAI stwarza ryzyko niespodziewanego naliczenia tysięcy dolarów na przypiętą kartę bankową.
/ Najczęściej zadawane pytaniaSchema.org FAQPage

FAQ: Token Burn Rate (Tempo spalania tokenów)

W każdym kroku cyklu ReAct agent jest zmuszony do ponownego wysyłania do API całej poprzedniej historii myślenia, różnic plików oraz błędów kompilatora. Sesja składająca się z 20 kroków przy kontekście 80 tys. tokenów generuje ponad 1,6 mln tokenów wejściowych w ciągu kilku minut.
/ Linki wewnętrzne
Wszystkie hasła