Czym jest token w modelu językowym?
Duże modele językowe (LLM) nie „czytają" tekstu tak, jak robi to człowiek. Nie przetwarzają pojedynczych liter ani całych słów — posługują się jednostkami pośrednimi zwanymi tokenami. Token to najmniejszy fragment tekstu, do którego redukowane są dane wejściowe (prompt) w trakcie przetwarzania języka naturalnego, a z którego model konstruuje swoje odpowiedzi.
Jeden token może oznaczać:
- Pojedynczy znak — literę, cyfrę, znak interpunkcyjny lub spację (spacja przed słowem tworzy inny token niż samo słowo),
- Fragment słowa (subword) — rzadkie lub złożone słowa są rozkładane na mniejsze cząstki; np. „unbelievable" → „un", „believ", „able",
- Całe słowo — popularne słowa jak „the", „dog", „fast" stanowią zazwyczaj jeden token.
Warto odróżnić tokeny językowe od kryptowalutowych tokenów AI — choć obie klasy noszą tę samą nazwę, są to fundamentalnie odmienne technologie. Kryptowalutowe tokeny AI funkcjonują na platformach blockchain i służą jako środki płatnicze lub prawa głosu. Niniejsze opracowanie dotyczy wyłącznie tokenów w kontekście modeli językowych.
Jak powstają tokeny? Algorytm Byte-Pair Encoding
Za zamianę tekstu na tokeny odpowiadają wyspecjalizowane algorytmy zwane tokenizerami. Dominującym podejściem we współczesnych modelach — stosowanym m.in. przez OpenAI, Anthropic i Google — jest Byte-Pair Encoding (BPE).
BPE to iteracyjny algorytm statystyczny działający w czterech krokach:
- Na starcie każdy pojedynczy znak korpusu tekstu jest traktowany jako odrębny token.
- System skanuje tekst i wyznacza najczęściej współwystępujące pary znaków.
- Najczęstsza para zostaje połączona w jeden nowy token (np. „t" + „h" → „th").
- Kroki 2–3 powtarzają się aż słownik osiągnie docelowy rozmiar — zazwyczaj od 50 000 do 100 000 unikalnych tokenów.
Wynikiem jest słownik, w którym powszechne słowa języka angielskiego stanowią jeden token, a słowa rzadkie lub nieznane są rekonstruowane z mniejszych znanych cząstek. BPE rozwiązuje klasyczny problem OOV (Out-Of-Vocabulary) — nawet nieznane słowo da się złożyć z fragmentów istniejących w słowniku.
Różne tokenizery, różne wyniki
Każda firma stosuje własną implementację tokenizera — ten sam tekst może dać różną liczbę tokenów w zależności od modelu. Przykładowe zdanie testowe „Artificial intelligence is transforming software development today.” (7 słów) rozkłada się następująco:
| Model / Tokenizer | Słownik | Liczba tokenów | Uwagi |
|---|---|---|---|
| GPT-4 (cl100k) | 100 000 | 9 | „Artificial” → „Art” + „ificial” |
| GPT-4o / o1 (o200k) | 200 000 | 8 | „Artificial” jako jeden token |
| Claude (Anthropic) | zastrzeżony | ~9 | Zbliżony wynik do GPT-4 cl100k |
| Llama 2 (SentencePiece) | 32 000 | ~11 | Mały słownik = więcej fragmentów |
Ile słów to jeden token? Zasady kciuka
Precyzyjne przeliczenie tekstu na tokeny wymaga użycia tokenizera danego modelu. Na co dzień wystarczają jednak orientacyjne „zasady kciuka” — szybkie heurystyki pozwalające oszacować, ile tokenów zajmie dany fragment tekstu bez uruchamiania żadnych narzędzi. Poniższe wartości odnoszą się do standardowego tekstu angielskiego.
| Miara | Przybliżona wartość |
|---|---|
| 1 token | ≈ 4 znaki |
| 1 token | ≈ 0,75 słowa |
| 100 tokenów | ≈ 75 słów |
| 1 akapit | ≈ 100 tokenów |
| Strona A4 (500 słów) | ≈ 650–700 tokenów |
| 1 000 słów | ≈ 1 333 tokeny |
Dlaczego język polski jest droższy?
Tokenizerów trenowano głównie na angielskich korpusach, co powoduje deficyt wielojęzyczności — języki o bogatszej morfologii lub innym alfabecie są rozkładane na więcej, mniejszych fragmentów. Skutki są wymierne: język angielski to 1 słowo na 1,3 tokena, języki romańskie (hiszpański, francuski) to 1 słowo na 2 tokeny, a język polski, hindi czy chiński wymagają mnożnika 1,5×–3× w stosunku do angielskiego.
W praktyce oznacza to, że polskojęzyczny prompt zużywa znacznie więcej miejsca w oknie kontekstowym i generuje wyższe koszty API niż analogiczny tekst angielski.
Okno kontekstowe — pamięć operacyjna modelu
Każdy model generatywny działa w ramach okna kontekstowego — twardego limitu wyrażonego w tokenach, który określa maksymalną objętość danych przetwarzanych w jednej sesji. Limit obejmuje łącznie tokeny wejściowe (cały prompt: instrukcje, historia konwersacji, dołączony kontekst pobrany przez architekturę Retrieval-Augmented Generation) oraz tokeny wyjściowe — przestrzeń zarezerwowaną na generowaną odpowiedź.
Po przekroczeniu limitu model albo odrzuca zapytanie błędem API, albo „zapomina" najstarszą część konwersacji, co prowadzi do niespójności i halucynacji.
| Model | Okno kontekstowe (tokeny) | Przybliżony ekwiwalent słów |
|---|---|---|
| GPT-3 (Davinci) | 4 096 | ≈ 3 000 |
| GPT-3.5 Turbo | 16 385 | ≈ 12 000 |
| GPT-4o | 128 000 | ≈ 96 000 |
| OpenAI o3 | 200 000 | ≈ 150 000 |
| Llama 3.1 (Meta) | 128 000 | ≈ 96 000 |
| Claude 3.7 Sonnet | 200 000 | ≈ 150 000 |
| Gemini 2.0 Flash | 1 000 000 | ≈ 750 000 |
Reasoning Tokens — ukryty pochłaniacz kontekstu
W modelach wnioskujących pojawia się dodatkowy czynnik: tokeny wnioskowania (Reasoning Tokens). Zanim model wygeneruje widoczną odpowiedź liczącą 200 tokenów, wewnętrznie może wyprodukować nawet 10 000 „myślowych" tokenów roboczych — i wszystkie one odliczają od limitu okna kontekstowego oraz są fakturowane na użytkownika. Praktycy zalecają rezerwowanie nawet 25 000 tokenów zapasu na takie operacje wewnętrzne.
Token Budget — jak kontrolować głębokość rozumowania
Niekontrolowane rozumowanie wewnętrzne może pochłonąć ogromną część budżetu tokenowego i wielokrotnie zwiększyć koszt zapytania. Dlatego nowoczesne modele reasoning udostępniają mechanizm jawnej kontroli nazywany token budget — możliwość ustawienia górnego limitu na tokeny wnioskowania przed wygenerowaniem odpowiedzi. W API Anthropic parametr thinking z polem budget_tokens określa maksymalną liczbę tokenów, którą Claude 3.7 Sonnet może przeznaczyć na wewnętrzny „ciąg myśli”. Przy budget_tokens = 5000 model myśli płycej, ale szybciej i taniej; przy 16 000 umożliwia się mu rozbudowane, wieloetapowe rozumowanie. W API OpenAI analogiczną rolę pełni parametr reasoning_effort (low / medium / high) dla modeli o1 i o3 — określa intensywność rozumowania w sposób pośrednio przekladający się na zużycie tokenów. Dla modeli o1-pro i o3-pro dostępny jest także bezpośredni parametr max_completion_tokens, który obejmuje zarówno tokeny reasoning, jak i tokeny widocznej odpowiedzi. Praktyczna konsekwencja: aplikacje produkcyjne powinny zawsze jawnie ustawiać token budget — pozostawienie go bez ograniczeń grozi nieoczekiwanymi skokami kosztów, szczególnie gdy model napotka niejednoznaczne lub wieloetapowe zapytanie.
Różnica między poziomami reasoning_effort jest wymierna finansowo. Przykład: analiza 500-słownego dokumentu modelem o3-mini (ceny wg OpenAI, maj 2025: $1,10 / 1M tokenów wejściowych, $1,10 / 1M reasoning, $4,40 / 1M wyjściowych) przy założeniu ok. 667 tokenów wejścia i 300 tokenów odpowiedzi:
| reasoning_effort | Reasoning tokens | Koszt reasoning | Koszt łączny | Mnożnik vs low |
|---|---|---|---|---|
| low | ≈ 500 | $0,0006 | $0,0021 | 1× (baseline) |
| medium | ≈ 3 000 | $0,0033 | $0,0048 | 2,3× |
| high | ≈ 15 000 | $0,0165 | $0,0180 | 8,6× |
Dla jednego zapytania różnica wygląda marginalnie. Przy 10 000 zapytań dziennie poziom high generuje koszt reasoning ok. $165 / dzień — wobec $6 przy low. Dobrą praktyką jest stosowanie high wyłącznie do zadań rzeczywiście wieloetapowych (np. analiza prawna, dowody matematyczne), a low lub medium do rutynowych klasyfikacji i ekstrakcji danych.
| Dostawca / Model | Parametr | Zakres / Wartości | Uwagi |
|---|---|---|---|
| Anthropic / Claude 3.7 Sonnet | thinking.budget_tokens | 1 024–100 000 | Min. 1 024; musi być mniejszy niż max_tokens |
| OpenAI / o1, o3 | reasoning_effort | low / medium / high | Pośrednio steruje liczbą reasoning tokens |
| OpenAI / o1-pro, o3-pro | max_completion_tokens | liczba całkowita | Obejmuje reasoning + odpowiedź |
| Zalecana rezerwa (praktyka) | N/D | ≥25 000 tokenów | Dla złożonych, wieloetapowych zadań |
Ekonomia tokenów — jak modele rozliczają koszty
Komercyjne API stosują model pricing per token, przy czym koszty są asymetryczne: tokeny wyjściowe są zazwyczaj 3–5 razy droższe od wejściowych. Wynika to z autoregresywnej natury generowania — każdy kolejny token musi być obliczony sekwencyjnie, co ogranicza możliwość równoległego przetwarzania i pochłania więcej zasobów GPU/TPU.
Prompt Caching — redukcja kosztów wielokrotnych zapytań
Gdy aplikacja wielokrotnie wysyła ten sam duży blok tekstu (np. regulamin, system prompt), dostawcy oferują mechanizm Prompt Caching: raz przetworzony prefix jest przechowywany w cache i ponownie używany z rabatem sięgającym 90%. Inne techniki optymalizacji to batching zapytań oraz architektura Retrieval-Augmented Generation, która pozwala wstrzyknąć do kontekstu tylko istotne fragmenty dokumentów zamiast całości.
Znaczenie tokenów dla inżynierii AI
Zrozumienie tokenów to nie akademicka wiedza — to praktyczna umiejętność inżynierska z bezpośrednim przełożeniem na koszty i jakość systemów. Cztery obszary, w których ta wiedza ma realne konsekwencje:
- Projektowanie promptów — kompaktowe, anglojęzyczne prompty są tańsze i mieszczą więcej treści w oknie kontekstowym. Każde zbędne zdanie w system prompcie kosztuje każde pojedyncze wywołanie API.
- Architektura aplikacji — każde zapytanie wymaga jawnego „budżetu tokenowego”: ile tokenów przeznaczamy na system prompt, historię konwersacji, dane RAG i przestrzeń na odpowiedź. Przekroczenie limitu okna kończy się błędem lub utratą najstarszego kontekstu.
- Ewaluacja modeli — porównywanie modeli bez ujednolicenia tokenizacji daje fałszywe wyniki. Ten sam tekst daje inną liczbę tokenów w GPT-4 i Llama 3, co bezpośrednio wpływa na mierzone koszty i długość wyjścia.
- Wielojęzyczność — systemy kierowane do użytkowników polskich, arabskich czy chińskich muszą uwzględniać 2–3-krotnie wyższe zużycie tokenów niż analogiczne treści angielskie. Ignorowanie tego prowadzi do niedoszacowania kosztów i błędnego wymiarowania okna kontekstowego.
Przyszłość tokenizacji
Tokenizacja oparta na BPE dominuje w dzisiejszych modelach, ale nie jest rozwiązaniem ostatecznym. Badacze aktywnie eksplorują trzy kierunki, które mogą zasadniczo zmienić sposób reprezentacji tekstu — i nie tylko tekstu — w modelach generatywnych.
Tokenizacja na poziomie bajtów
Zamiast uczyć się słownika fragmentów tekstu, modele byte-level operują bezpośrednio na surowych bajtach UTF-8. Podejście to eliminuje problem OOV (Out-Of-Vocabulary) całkowicie — każdy możliwy ciąg znaków da się wyrazić sekwencją 256 możliwych wartości bajtu. Model ByT5 (Google, 2021) pokazał, że tokenizacja bajtowa osiąga jakość porównywalną z BPE przy jednoczesnej przewadze na językach niskozasobowych i szumliwym tekście. Główna wada to długość sekwencji: ten sam tekst zajmuje 3–4 razy więcej pozycji niż w BPE, co drastycznie zwiększa koszt obliczeniowy mechanizmu uwagi (attention).
Modele bez tokenizacji — SSM i Mamba
Architektura Transformer wymaga tokenizacji, bo przetwarza dane w dyskretnych krokach przez mechanizm uwagi. Alternatywne architektury — State Space Models (SSM), w szczególności Mamba (2023) i RWKV — modelują sekwencje w sposób ciągły, bez konieczności dzielenia wejścia na dyskretne jednostki. W teorii otwiera to drogę do modeli operujących bezpośrednio na strumieniach sygnału — audio, sygnałach czujników, szeregach czasowych — z pominięciem etapu tokenizacji. W praktyce modele SSM są wciąż znacznie słabsze od Transformerów na zadaniach językowych, a architektura hybrydowa (Mamba + attention) wydaje się najbardziej obiecującym kierunkiem.
Tokenizacja multimodalna — obrazy i audio jako tokeny
Współczesne modele multimodalne rozszerzają pojęcie tokenu daleko poza tekst. DALL-E 3 i GPT-4o stosują dyskretne tokeny wizualne — obraz jest dzielony na siatkę patchów (np. 16×16 pikseli), każdy kodowany przez encoder wizualny do jednego wektora, a następnie traktowany jak token tekstowy przez warstwy Transformera. Gemini 1.5 i Claude 3 stosują analogiczne podejście do obrazów, a modele audio (Whisper, Gemini Audio) tokenizują sygnał dźwiękowy jako sekwencje spektrogramów. Oznacza to, że „okno kontekstowe” staje się wspólną przestrzenią dla tokenów tekstowych, wizualnych i audio — z jednolitym budgetem, który wszystkie również zużywają.
Token był i pozostanie centralną jednostką ekosystemu modeli językowych — miarą pracy, walutą rozliczeń i granicą pamięci operacyjnej. Nawet jeśli przyszłe architektury ogranczą jego rolę w warstwie obliczeniowej, pojęcie „ile to kosztuje tokenów” jeszcze długo pozostanie pytaniem, które każdy inżynier AI będzie musiał umieć precyzyjnie odpowiedzieć. Rozumienie tokenizacji to dziś nie wiedza akademicka — to podstawowa kompetencja każdego, kto projektuje, wdraża i optymalizuje systemy oparte na dużych modelach językowych.
Źródła
OpenAI Documentation, Anthropic Claude API Reference, Google Gemini Technical Reports, Tiktoken GitHub Repository, aioutlooks.com, moreonlinetools.com, medium.com