Tokenization

LLM-ovi ne čitaju tekst. Čitaju brojeve. Pre nego što model može da obradi makar jednu reč, ta reč mora da se pretvori u sekvencu celih brojeva — a korak koji to radi zove se tokenization.

Tokenization prati specifičan algoritam — fiksni skup pravila koji deli tekst u jedinice zvane tokeni i mapira svaku u broj. To je most između teksta čitljivog ljudima i numeričkog ulaza koji očekuje neuronska mreža.

What is a token

Token je fundamentalna jedinica teksta koju LLM obrađuje. Šaljete tokene modelu, naplaćujete se po tokenu, a model čita, predviđa i generiše u tokenima — ne u rečima.

Token nije isto što i reč. Kada otkucate Hello world! u ChatGPT, on ne vidi dve reči i znak interpunkcije. Vidi četiri različita tokena:

"Hello world!"  →  ["Hello", " world", "!", "\n"]

Primetite da su razmak i newline na kraju deo tokena — tokenizer-i čuvaju whitespace jer on nosi značenje.

U zavisnosti od tokenizer-a, jedan token može da predstavlja:

• pojedinačni karakter
• subword (deo reči)
• kompletnu reč
• znak interpunkcije
• whitespace ili specijalni karakter

Korisna mentalna slika je LEGO. Model nikada ne vidi cele rečenice kao reči — vidi skup ponovo upotrebljivih kockica koje može da sklopi:

"I love machine learning!"
 ↓
[I] [ love] [ machine] [ learn] [ing] [!]

Reč "learning" se deli u learn + ing — dve ponovo upotrebljive kockice koje model može da rekombinuje u "learned", "learner" ili "burning".

Token ≠ word

Pošto su tokeni subword komadi, broj tokena u tekstu retko se poklapa sa brojem reči. To je i suština: LLM-ovi imaju ograničene rečnike (vocabulary) — obično 30.000 do 100.000 tokena. Fiksni rečnik te veličine ne može da sadrži svaku reč na svakom jeziku, pa tokenizer-i razbijaju retke ili složene reči na manje, ponovo upotrebljive komade:

"extraordinary"  →  "extra" + "ordinary"

Komponovanjem subword-ova, ograničen rečnik može da izrazi neograničen prostor reči. Najčešći algoritam za učenje ovih komada je Byte-Pair Encoding (BPE), koji kreće od pojedinačnih karaktera i iterativno spaja najčešći susedni par dok rečnik ne dostigne ciljanu veličinu.

Why tokenization matters

Tokenization nije samo "vodovod" — njen kvalitet oblikuje koliko dobro i koliko jeftino model radi.

From tokens to numbers

Deljenje teksta u tokene je tek pola posla. Svaki token i dalje mora da postane broj sa kojim mreža može da radi matematiku.

Svaki token u rečniku dobija jedinstveni ceo broj — svoj token ID:

"Hello"   →  token ID 15496
" world"  →  token ID 995

Ovi ID-evi se zatim pretvaraju u embedding-e: guste vektore realnih brojeva, obično 512, 1024 ili više dimenzija. Embedding za "Hello" može da izgleda kao [0.23, -0.45, 0.78, ...]. Embedding-zi su ono što omogućava modelu da predstavi značenje — slični tokeni završe sa sličnim vektorima.

Kompletan pipeline od teksta do ulaza u model:

Text:        "Hello world"
  ↓ Tokenization
Tokens:      ["Hello", " world"]
  ↓ Token IDs
IDs:         [15496, 995]
  ↓ Embedding layer
Vectors:     [[0.23, -0.45, 0.78, ...], [0.12, 0.89, -0.34, ...]]
  ↓ Transformer
Neural network processes the numerical vectors

Svaka kompanija koristi svoj algoritam tokenization-a, i njegova efikasnost direktno utiče i na context kapacitet modela i na kvalitet njegovog izlaza.

Context window

Pošto model radi u tokenima, njegove granice se mere u tokenima. Context window je maksimalan broj tokena koje model može da obradi odjednom. Utiče na:

• Dužinu ulaza — koliko teksta model može da razmotri pre odgovora
• Dužinu izlaza — koliko može da generiše u jednoj kompletaciji
• Koherenciju — koliko ostaje konzistentan kroz duge razgovore ili dokumente

Efikasnija tokenization znači da više stvarnog sadržaja staje u isti context window.

Where tokenization breaks down

Tokenization uzrokuje nekoliko kontraintuitivnih ponašanja u praksi.

Non-English languages

Tokenizer-i se uglavnom treniraju na engleskom tekstu, jednostavno zato što je internet dominantno engleski. Tako su naučili da efikasno tokenizuju engleski — a sve ostalo manje efikasno.

Zamislite rečnik od 50.000 reči izgrađen na taj način:

• ~40.000 engleskih reči
• ~5.000 reči za jedan drugi jezik
• ~5.000 za sve preostale jezike zajedno

Efekat se vidi direktno u broju tokena. Engleska reč koju tokenizer dobro poznaje deli se na malo komada, dok ekvivalentna reč na drugom jeziku biva razbijena na mnogo komada:

"unhappiness"  →  ["un", "happiness"]        = 2 tokens
"nesreća"      →  ["n", "es", "re", "ć", "a"] = 5 tokens

Isto značenje, više nego duplo tokena — što znači da ne-engleski korisnici plaćaju više i staje im manje u context window. (Tačni splitovi zavise od tokenizer-a; ovo su ilustrativni primeri.)

How much more, exactly

Razlika nije zanemariva — peer-reviewed studije su to merile na desetinama jezika. Odnosi se grupišu prema sistemu pisanja:

Dva tehnička razloga se kombinuju:

• BPE je treniran uglavnom na engleskom tekstu. Byte-Pair Encoding uči merge-eve iz frekvencije u trening korpusu. Ne-latinski karakteri se nisu dovoljno često pojavljivali tokom BPE treninga da formiraju mnogo merge-eva, pa ostaju isečeni na sitne komade.
• UTF-8 encoding penalty. Latinski karakteri su po 1 bajt, ali ćirilica, CJK i mnoga druga pisma se kodiraju kao 2–3 bajta po karakteru. Već pre tokenization-a postoji byte-level overhead koji merge-evi ne mogu u potpunosti da nadoknade.

Implikacija je direktna: smart zone vašeg context window-a se smanjuje proporcionalno troškovima tokenization-a. Prozor od 200K tokena koji drži ~150K engleskih tokena upotrebljivog konteksta drži samo ~50K–75K ekvivalentnih kineskih tokena, i ~60K–100K ćiriličnih. To je i razlog zašto pisanje dokumentacije, commit poruka i komentara u kodu na engleskom nije samo stilska odluka — to je 2–5× množilac efikasnosti za bilo kog agenta koji čita repository.

Rad sa arXiv-a Language Model Tokenizers Introduce Unfairness Between Languages postavlja ovo kao strukturnu nepravdu, a ne kao implementacijski bag. Govornici nedovoljno zastupljenih jezika plaćaju više za isti zadatak — i u dolarima i u efektivnom kontekstu.

Special characters

Emoji i neobično formatiranje mogu da potroše mnogo više tokena nego što se očekuje. Jedan emoji poput 🧠 može da zauzme nekoliko tokena u zavisnosti od tokenizer-a, tiho povećavajući utrošak tokena.

Numbers and code

Neki tokenizer-i fragmentiraju brojeve i programske konstrukcije na čudne načine, deleći ih kroz više tokena. To je glavni razlog zašto LLM-ovi muku muče sa aritmetikom i tačnim generisanjem koda — vide fragmentovane simbole, a ne čiste brojeve.

Za to kako se tokeni uklapaju u širu sliku gradnje modela, vidite How LLMs Are Built.

Sources

• Petrov, Malkin et al. — Language Model Tokenizers Introduce Unfairness Between Languages. Peer-reviewed studija o tokenization-u kroz jezike (arXiv 2305.15425).
• Tokenization Disparities as Infrastructure Bias: How Subword Systems Create Inequities in LLM Access and Efficiency — naredna studija koja kvantifikuje 3–5× odnose troškova za ne-latinske i morfološki složene jezike (arXiv 2510.12389).
• ByteByteGo — How LLMs See the World. Objašnjava zašto se Hello world! tokenizuje u četiri tokena i kako se token ID-evi i embedding-zi povezuju.
• PromptCost — LLM Tokenization Explained: English vs Other Languages Cost Difference. Praktičan pregled razlike u troškovima po pismu.
• OpenAI Developer Community — Token size in Russian lang. Reproducibilna merenja odnosa ćirilica/latinica u OpenAI tokenizer-ima.

Further reading

• Let's build the GPT Tokenizer — Andrej Karpathy gradi GPT tokenizer od nule; završni deo objašnjava upravo one čudne slučajeve (brojevi, trošak ne-engleskog) koje ova stranica pokriva.
• Hugging Face NLP Course — Tokenizers — kanonsko besplatno poglavlje o tome šta tokenizer-i rade i o tri subword algoritma.
• openai/tiktoken — OpenAI-jev brzi BPE tokenizer; prebrojte tokene i pogledajte token ID-eve za tačno one modele koje pozivate.