Koszt tokenów LLM: jak go mierzyć i optymalizować

Firma uruchamia pilota z asystentem AI. Pierwsze testy działają świetnie. Po miesiącu produkcji budżet na API przekroczony o 280%. Przyczyna nie jest techniczna, to decyzja projektowa z fazy pilota: system wysyłał do modelu pełne PDF-y zamiast fragmentów wydobytych przez RAG, a każde zapytanie zawierało instrukcję systemową o długości 2400 tokenów, kopiowaną do każdego wywołania.

Koszt tokenów LLM nie jest liniowy względem liczby zapytań. Jest liniowy względem liczby tokenów. Różnica między tymi dwoma zdaniami to różnica między budżetem do utrzymania a budżetem, który wymusza wyłączenie systemu.

Token to podstawowa jednostka rozliczeniowa modeli językowych. Jeden token to zwykle 3-4 znaki w języku angielskim, 2-3 znaki w języku polskim (polskie diacritiki, dłuższe słowa rozpadają się na więcej tokenów). Dla tekstu po polsku zakładaj 30-40% więcej tokenów niż dla ekwiwalentu angielskiego.

Wyjściowe tokeny (throughput) kosztują zwykle więcej niż wejściowe. Tabela poniżej pokazuje typową strukturę kosztów dla różnych klas modeli (ceny orientacyjne, weryfikuj w aktualnym cenniku wybranego providera).

Kluczowa obserwacja: modele premium kosztują 10-30 razy więcej niż modele mid klasy. Ale jeśli model mid wymaga dwukrotnie dłuższego promptu żeby osiągnąć ten sam wynik, różnica realna jest inna. Przed wyborem modelu zmierz oba parametry: cenę za token i wymaganą długość kontekstu do uzyskania akceptowalnej jakości.

Kalkulację dla własnych parametrów przeprowadź przez kalkulator inference, gdzie możesz wpisać realny wolumen i dostać miesięczny koszt w PLN.

W projektach produkcyjnych, które analizowaliśmy, 70-80% kosztów tokenów pochodzi z trzech źródeł, o których rzadko mówi się podczas pilota.

System prompt kopiowany do każdego zapytania. Instrukcja systemowa opisująca zachowanie asystenta to zwykle 500-3000 tokenów. Przy 10 000 zapytań dziennie i promptie 1500 tokenów daje to 15 mln tokenów miesięcznie tylko na kontekst systemowy, zanim model przeczyta choćby jedno pytanie użytkownika. Większość providera API nie cachuje systempromptów między wywołaniami automatycznie, chyba że użyjesz prompt caching.

Przekazywanie pełnych dokumentów zamiast fragmentów. Agent, któremu przekazujesz fakturę PDF jako pełny tekst (2000-8000 tokenów), zamiast wydobytych przez RAG 3-5 fragmentów (150-400 tokenów), może używać 10-30 razy więcej tokenów na operację. Różnica jest dramatyczna przy dużym wolumenie dokumentów.

Historia konwersacji bez przycinania. Interfejsy czatowe, które przekazują do modelu całą historię rozmowy, rosną liniowo z długością sesji. Rozmowa, która trwa 20 wymian, może mieć 15 000 tokenów kontekstu przy ostatnim zapytaniu, podczas gdy użytkownik pyta o coś prostego. Sliding window (ostatnie N wiadomości) lub podsumowanie starszej historii redukuje ten koszt o 60-80%.

Większość dużych providerów API oferuje prompt caching, który redukuje koszt wielokrotnie używanego prefiksu promptu (system prompt, dokumenty referencyjne, instrukcje) o 70-90%. Mechanizm polega na tym, że provider hashuje prefiks i przechowuje obliczenia stanu wewnętrznego modelu. Drugie i kolejne wywołania z tym samym prefiksem płacą ułamek ceny.

Warunki, które muszą być spełnione, żeby caching działał:

• Prefiks musi być identyczny bajtowo. Jedna zmiana znaku inwaliduje cache.
• Prefiks musi przekraczać minimalną długość (zwykle 1024-2048 tokenów zależnie od providera).
• Wywołania muszą następować w oknie czasowym (zwykle kilka minut do godziny).

W praktyce oznacza to: system prompt i instrukcje powinny stać na początku kontekstu, przed dynamiczną częścią (pytanie użytkownika, wyniki RAG). Dynamiczne elementy powinny być na końcu, żeby nie inwalidować prefiksu.

Dla systemu z 2000-tokenowym system promptem i 10 000 wywołań dziennie, prompt caching redukuje koszt tokenów wejściowych o 50-65% bez żadnej zmiany w logice aplikacji.

RAG jest często opisywany jako technika poprawy jakości odpowiedzi. To prawda, ale w kontekście kosztów tokenów RAG jest przede wszystkim strategią selekcji kontekstu.

Różnica między systemem z RAG a bez niego:

• Bez RAG: całe dokumenty firmowe (10-50 stron, 8000-40 000 tokenów) trafiają do każdego zapytania.
• Z RAG: wyszukiwanie semantyczne wyciąga 3-5 najbardziej relewantnych fragmentów (300-800 tokenów) i tylko one trafiają do modelu.

Dobry reranking po etapie wyszukiwania dodatkowo zmniejsza liczbę fragmentów przekazywanych do modelu przy zachowaniu wysokiej trafności. Wzorzec retrieve-rerank-trim (pobierz 20 fragmentów, rerankuj, wyślij top 3-5) pozwala zmniejszyć tokeny kontekstu o 70-80% względem naiwnego retrieve-wszystko.

Artykuł firmowy GPT na bazie wiedzy opisuje architekturę RAG szczegółowo. Dla pipeline'ów z dużym wolumenem dokumentów warto przeczytać jak przygotować dane firmowe pod AI, gdzie omawiane są strategie chunkingu wpływające bezpośrednio na liczbę tokenów per zapytanie.

LLM router to warstwa, która klasyfikuje zapytanie i kieruje je do najtańszego modelu wystarczającego do zadania. W produkcyjnym systemie obsługi klienta typowy rozkład zapytań wygląda następująco:

Routing oparty na klasyfikacji intencji (mały model klasyfikuje, duży realizuje tylko gdy trzeba) redukuje koszty o 50-70% w systemach z heterogenicznym typem zapytań. Wymaga testu A/B żeby potwierdzić, że jakość odpowiedzi przy routingu nie spada poniżej akceptowalnego progu.

Nasza infrastruktura OpenClaw router stosuje ten wzorzec domyślnie, kierując proste zapytania do lokalnego modelu, a złożone do modeli chmurowych z zachowaniem audytu każdego wywołania.

Bez pomiaru koszt tokenów jest niewidzialny do momentu, gdy faktura od providera API przekracza budżet. Traktuj zużycie tokenów jako metrykę operacyjną, analogicznie do latency i dostępności.

Minimalne metryki do śledzenia w produkcji:

• Tokeny wejściowe i wyjściowe per endpoint lub feature (nie tylko łącznie).
• Koszt per sesja użytkownika lub per transakcja biznesowa.
• Procentowy udział system promptu w tokenach wejściowych.
• Cache hit rate dla prompt caching (jeśli używasz).
• Rozkład długości odpowiedzi modelu (długie odpowiedzi mogą sygnalizować zbędną gadatliwość).

Alerty powinny działać na dwóch poziomach: warning przy 70% dziennego budżetu i hard limit przy 90% z automatycznym throttlingiem lub degradacją do tańszego modelu. Monitoring jakości agenta AI opisuje szerszy kontekst obserwabilności, w tym metryki observability dla warstwy AI.

Tokeny wyjściowe są droższe. Kilka wzorców, które skracają odpowiedzi modelu bez pogorszenia jakości:

Precyzyjne instrukcje formatu. „Odpowiedz w maksymalnie 3 zdaniach" działa, ale lepiej: „Wymień maksymalnie 3 punkty jako listę, bez wprowadzenia i podsumowania". Model bez instrukcji ma tendencję do generowania ceremonialnych wstępów i zakończeń, które nie wnoszą wartości.

Structured output. Gdy oczekujesz danych do przetworzenia przez kod, structured output (JSON schema) eliminuje narracyjne opakowanie. Ekstrakcja 5 pól z dokumentu jako JSON to 80-120 tokenów wyjściowych, a ta sama ekstrakcja jako narracja to 300-600 tokenów.

Temperatura a długość. Wyższa temperatura nie wydłuża odpowiedzi, ale temperature=0 z explicit długością w prompcie daje bardziej przewidywalne, krótsze odpowiedzi przy zadaniach deterministycznych.

Stop sequences. Zdefiniuj token stopu dla modelu (np. ### albo określony separator JSON), żeby model nie kontynuował po zakończeniu właściwej odpowiedzi. Szczególnie przydatne przy generowaniu listy o ograniczonej liczbie elementów.

Przy wolumenie powyżej 5-10 mln tokenów dziennie self-hosting lokalnego modelu może być tańszy niż API, nawet po uwzględnieniu kosztów infrastruktury. Granica opłacalności zależy od modelu, sprzętu i profilu zapytań.

Dla zadań, które nie wymagają modelu frontier (klasyfikacja, ekstrakcja danych, FAQ, proste streszczenia), lokalne modele klasy 7B-34B osiągają akceptowalną jakość przy koszcie zbliżonym do zera per token. Artykuł koszt local vs API LLM opisuje kalkulator progu opłacalności i typowe profile użycia.

Decyzja o self-hostingu to nie tylko koszt. To też data residency (dane nie opuszczają infrastruktury), zgodność z RODO dla danych wrażliwych i eliminacja zależności od zewnętrznego providera. Artykuł self-hosted LLM a RODO omawia te aspekty szczegółowo.

Opisz architekturę swojego systemu AI (ile zapytań dziennie, jaka długość systemprompta, czy używasz RAG) a model wskaże gdzie jest największy potencjał optymalizacji tokenów (playground: PII maskowane, zero retencji):

Nie zawsze. Tańszy model często wymaga dłuższego, bardziej precyzyjnego promptu żeby osiągnąć ten sam wynik, co model premium. Jeśli koszt per token jest 5 razy niższy, ale prompt musi być 3 razy dłuższy i model generuje dwa razy więcej tokenów wyjściowych żeby uniknąć błędów, rzeczywista oszczędność jest mała albo żadna. Przed zmianą modelu zmierz całkowity koszt per zadanie (nie per token) na reprezentatywnym zestawie testowym z co najmniej 200 przykładami.

Prompt caching to mechanizm, w którym provider API zachowuje stan wewnętrzny modelu dla wielokrotnie używanego prefiksu promptu. Każde kolejne wywołanie z identycznym prefiksem płaci za tokeny cache zamiast pełnych tokenów wejściowych, co jest zwykle 70-90% tańsze. Warunek: prefiks musi być bajtowo identyczny między wywołaniami i przekraczać minimalny próg długości (zwykle 1024 tokeny). Zmiana choćby jednego znaku inwaliduje cache. W praktyce działa świetnie dla stałego system promptu i instrukcji kontekstowych, które nie zmieniają się między zapytaniami użytkownika.

RAG zamienia drogi kontekst pełnodokumentowy na tani kontekst fragmentowy. Zamiast wysyłać cały dokument (2000-40 000 tokenów) do każdego zapytania, RAG używa wyszukiwania semantycznego żeby wybrać 3-5 relewantnych fragmentów (150-600 tokenów łącznie). Przy 10 000 zapytań dziennie z dokumentem 5000 tokenów różnica wynosi 50 mln vs 2-3 mln tokenów miesięcznie. Koszt embeddingi i wyszukiwania jest pomijalny względem oszczędności na tokenach modelu. Więcej o budowie pipeline RAG w artykule wyszukiwanie semantyczne i embeddingi w firmie.

Self-hosting eliminuje koszt per token, ale ma własne koszty: sprzęt GPU lub wynajęty serwer, utrzymanie, aktualizacje modelu i czas inżynierski. Przy małym wolumenie (poniżej 1 mln tokenów dziennie) API jest zwykle tańsze po uwzględnieniu kosztów operacyjnych. Self-hosting zaczyna być opłacalny przy stałym, dużym wolumenie i zadaniach, które nie wymagają modelu frontier. Użyj kalkulatora ROI żeby porównać oba scenariusze dla swojego profilu użycia.

Śledź tokeny na poziomie wywołania, nie sesji. W każdym wywołaniu modelu zapisuj: feature lub endpoint, który je wywołał, liczby tokenów wejściowych i wyjściowych oraz czy użyto cache. Agreguj po feature w dashboardzie (np. Grafana z metrykami Prometheus). Dzięki temu widać, który feature odpowiada za 60% kosztów, co pozwala priorytetyzować optymalizację. Wzorzec implementacji opisuje monitoring jakości agenta AI w sekcji poświęconej telemetrii wywołań LLM.