Tokeny po polsku: ten sam tekst kosztuje od 1,6 do 2,1 raza więcej

Cenniki modeli językowych liczą w tokenach. Stawka jest za milion tokenów, okno kontekstowe też ma limit w tokenach, a w rozmowach przyjmuje się zwykle, że token to mniej więcej słowo. Dla angielskiego to przybliżenie jakoś działa. Dla polskiego nie.

Chciałem wiedzieć, o ile dokładnie, więc zmierzyłem to na tekście, który istnieje w obu językach w wersji urzędowej. Ta sama treść po polsku zużywa od 1,6 do 2,1 raza więcej tokenów niż po angielsku, zależnie od tokenizatora. Poniżej metoda, wyniki i trzy wnioski, a na końcu sprostowanie do mojego własnego słowniczka.

Czym jest token

Model nie czyta liter ani słów. Tekst jest najpierw cięty na kawałki ze stałego słownika, a każdy kawałek dostaje numer. Częste słowa są jednym kawałkiem, rzadsze składają się z kilku. Ten słownik razem z regułami cięcia to tokenizator i każda rodzina modeli ma własny. Dłuższe wyjaśnienie, z analogią, jest w słowniczku.

Polszczyzna ma cechy, które tokenizatorom przeszkadzają: bogatą odmianę, przez którą jedno słowo występuje w wielu formach, i znaki diakrytyczne. Autorzy pracy o tokenizatorze dla modeli Bielik piszą, że uniwersalne tokenizatory często nie oddają morfologii języków takich jak polski. Skutkiem jest więcej tokenów na ten sam tekst, wyższy koszt i mniejsze efektywne okno kontekstowe.

Jak mierzyłem

Tekstem jest rozporządzenie (UE) 2024/1689, czyli AI Act, w oficjalnej wersji angielskiej i polskiej z EUR-Lex. Wybrałem je, bo tłumaczenie jest urzędowe i odpowiada oryginałowi jednostka w jednostkę. Porównywałem pary: 113 artykułów i osobno 180 motywów.

W artykułach polska wersja ma o 5 procent więcej znaków i o 9 procent mniej słów niż angielska. Ta druga liczba przyda się pod koniec.

Porównałem pięć tokenizatorów. Dwa pochodzą od OpenAI: cl100k_base, którego używają GPT-4 i GPT-3.5 Turbo, oraz o200k_base, którego według biblioteki tiktoken używają GPT-4o, GPT-4.1, GPT-5 i modele z serii o. Do tego trzy z modeli otwartych: Qwen2.5, DeepSeek-V3 i polski Bielik v2.3 od SpeakLeash i ACK Cyfronet AGH. Tokeny liczyłem dla każdej pary osobno, a wynik to stosunek sumy tokenów polskich do sumy angielskich.

Wyniki

Motywy wychodzą drożej niż artykuły w każdym z pięciu tokenizatorów. Są pisane bardziej opisowo, ale ważniejszy jest wniosek ogólny: mnożnik zależy od rodzaju tekstu. Nawet w obrębie jednego dokumentu rozrzut jest spory. Przy o200k_base co dziesiąty artykuł wychodzi poniżej 1,41, a co dziesiąty powyżej 1,75.

Trzy wnioski

Ta sama treść kosztuje od 1,6 do 2,1 raza więcej. Tyle razy więcej płacisz za wejście i tyle razy mniej tekstu mieści się w oknie kontekstowym. Dotyczy to też odpowiedzi: model generuje tokeny po kolei, więc polska odpowiedź o tej samej treści jest droższa i powstaje dłużej.

Nowszy tokenizator OpenAI potaniał tylko dla polskiego. Przejście z cl100k_base na o200k_base zmniejszyło liczbę tokenów w polskich artykułach o 16 procent, z 116 688 do 97 969. W angielskich spadek wyniósł 0,15 procent, z 60 923 do 60 830. Większy słownik prawie nie zmienił angielskiego, a wyraźnie pomógł polskiemu. Przy tej samej stawce za token przejście na nowszy model było dla polskich tekstów cichą obniżką ceny.

Polski model nie oznacza polskiego tokenizatora. Bielik v2.3 wypada tak samo jak cl100k_base. Ma najmniejszy słownik w zestawieniu, 32 128 pozycji, a jego model bazowy powstał z Mistral-7B-v0.2. Autorzy Bielika opisali ten problem w pracy o wersji 3. Tokenizator odziedziczony po Mistralu dzielił reprezentatywny polski tekst na 3,22 tokena na słowo. W serii Bielik v3 PL zastąpili go tokenizatorem APT4, zaprojektowanym dla polskiego, i przy podobnym rozmiarze słownika zeszli do 1,62 tokena na słowo. Na ich danych angielski wychodzi w APT4 drożej niż polski, bo 1,98 tokena na słowo. Samego APT4 nie zmierzyłem, bo pliki modeli v3 wymagają zalogowania i akceptacji warunków.

Tokeny na słowo to nie to samo co koszt tekstu

Tu muszę sprostować samego siebie. W słowniczku napisałem w maju, że polski oznacza dwu-, a nawet dwuipółkrotnie wyższy koszt za ten sam sens. Liczby, na których się oparłem, były prawdziwe: 3,22 tokena na słowo dla polskiego i 1,28 dla angielskiego w tym samym tokenizatorze, z pracy o Bieliku. Wniosek był jednak za mocny, bo porównywał słowa, a nie treść.

Polski tekst o tym samym znaczeniu ma mniej słów niż angielski. Nie używa przedimków, a część tego, co angielski wyraża osobnymi słowami, mieści w końcówkach. W moim korpusie polska wersja ma o 9 procent mniej słów. Dlatego przy o200k_base na słowo wychodzi 2,22 tokena po polsku wobec 1,26 po angielsku, czyli 1,77 raza więcej, a na tym samym tekście 1,61 raza więcej. Porównanie na słowach zawyża różnicę.

Poprawiłem słowniczek i zostawiłem w nim informację o tej zmianie.

A Claude i Gemini?

Tych nie zmierzyłem. Ich tokenizatory nie są udostępnione jako pliki do uruchomienia lokalnie, a oba API mają osobne endpointy do liczenia tokenów, do których potrzebny jest klucz.

Z dokumentacji Anthropic wiadomo jedno: modele Claude od wersji 4.7 używają nowszego tokenizatora. Dla tego samego tekstu daje on około 30 procent tokenów więcej niż poprzedni, a dokładna różnica zależy od treści. Dokumentacja nie mówi, jak ta zmiana rozkłada się między językami. Jeśli pracujesz na Claudzie, policz tokeny na własnych dokumentach przez endpoint do liczenia tokenów, zamiast przenosić moje liczby.

Co z tym zrobić

1. Zmierz mnożnik na swoim typowym dokumencie. Ta sama treść w dwóch językach, licznik tokenów od Twojego dostawcy. Pięć minut pracy, a zamiast mojego zakresu masz swoją liczbę.
2. Budżety licz w tokenach, nie w słowach ani stronach. Okno miliona tokenów to po polsku około 450 tysięcy słów przy o200k_base, a nie milion ani 750 tysięcy.
3. Przyjrzyj się instrukcji systemowej. Jedzie w każdym zapytaniu. Jeśli jest długa, a zespołowi to nie przeszkadza, wersja angielska zmniejszy jej koszt o około 38 procent przy o200k_base. Odpowiedzi nadal mogą być po polsku. Sprawdź jakość na swoich przypadkach, zanim zmienisz produkcję.
4. Porównując modele, porównuj koszt swojego tekstu, a nie stawkę za token. Weźmy model tańszy o 15 procent za token, który tnie polski tak jak cl100k_base. Zużyje 19 procent tokenów więcej niż model ze słownikiem jak o200k_base, więc na polskim tekście wyjdzie drożej.
5. Pamiętaj o cache'u. Długi, stały początek zapytania można buforować po stronie dostawcy, co zmniejsza koszt niezależnie od języka. Mechanizm i jego pułapki opisałem w tekście o cache'u po stronie dostawcy.

Tokenizator to rzecz, której na co dzień nie widać, a która po cichu ustala cenę każdego zapytania. Po polsku ta cena jest wyższa. Da się ją zmierzyć i częściowo obniżyć, ale tylko wtedy, gdy ktoś w zespole wie, że w ogóle jest.