skeskinen/hf-tokenizer-testing

Simple test suite for various tokenizers

7

stars

6

commits

Python

primary language

May 30, 2023

updated

README

hf-tokenizer-testing

A simple script to test if GPT tokenizers from various popular models can encode+decode documents losslessly.

Documents tested are:

  • QQQ_0: Simple sanity test
  • QQQ_1: A sample from TinyStories dataset that looks innocent, but most tokenizers seem to fail because of a little bit unusual punctuation.
  • QQQ_2: Another, easier, sample from TinyStories
  • QQQ_3: Markus Kuhn's UTF-8 stress test, with couple lines removed b/c python encoder couldn't handle them. Correctly encoding/decoding this document is a very good sign of "correctness".
  • QQQ_4: Wikipedia page source for Snow Leopard
  • QQQ_5: Book Pride and Prejudice from The Project Gutenberg
  • QQQ_6: stb_image.h. C source code file
  • QQQ_7: Japanese book from The Project Gutenberg, 苦悶の欄(Kumon no ran)

Why?

Does it matter if tokenizers can/can't reproduce the input exactly? I guess this is subjective, but I'd say it's at least a nice feature. A feature that some tokenizers out there don't seem to have.

NOTE: When decoding, it's important to pass clean_up_tokenization_spaces=False to tokenizer.decode. Otherwise you will get a lot of missmatches related to tokenizer eating whitespace.

Results

Pass Fail

Tokenizer NameVocab SizeQQQ_0QQQ_1QQQ_2QQQ_3QQQ_4QQQ_5QQQ_6QQQ_7
EleutherAI/polyglot-ko-5.8b30003✔️✔️✔️✔️✔️✔️✔️✔️
huggyllama/llama-7b32000✔️✔️✔️✔️✔️✔️✔️✔️
openlm-research/open_llama_7b_400bt_preview32000✔️✔️✔️✔️✔️✔️✔️✔️
bigcode/starcoder49152✔️✔️✔️✔️✔️✔️✔️
facebook/galactica-6.7b50000✔️✔️✔️✔️✔️
gpt2-large50257✔️✔️✔️✔️✔️✔️✔️✔️
EleutherAI/gpt-neox-20b50277✔️✔️✔️✔️✔️✔️✔️
tiiuae/falcon-40b65024✔️✔️✔️✔️✔️✔️✔️
bigscience/bloom-560m250680✔️✔️✔️✔️✔️✔️✔️✔️

Tokenized length

Tokenizer NameVocab SizeQQQ_0QQQ_1QQQ_2QQQ_3QQQ_4QQQ_5QQQ_6QQQ_7
EleutherAI/polyglot-ko-5.8b300033643642818310292044390318197049144043
huggyllama/llama-7b3200012231223546518779319681311528488333
openlm-research/open_llama_7b_400bt_preview320003022521815452189579197971148109210463
bigcode/starcoder4915211240240467817971320684210481772613
facebook/galactica-6.7b50000112482365158216860196171127599145842
gpt2-large50257282172131478117502119610713998599792
EleutherAI/gpt-neox-20b5027711216210489716787718399710636476410
tiiuae/falcon-40b65024112262145486171417181700112559102247
bigscience/bloom-560m2506801023021040821276791820749215366894

My Takeaways

  • Llama tokenizer is really good. Small vocab, lossless, good compression, shown to work well in a real LLM. But downside with the Llama tokenizer is that it runs significantly slower than some of the other tokenizers (runtime speed is not shown here, but I've observed this elsewhere)
  • Open Llama is ok in English but has drastically worse compression than Llama in the utf8 test and Japanese. In my opinion, this is a pretty bad look.
  • Only other lossless tested here was bloom, but 250k vocab is kind of a lot for me. All the extra tokens lower the tokenized lengths, but is it worth it? Also there is some tradeoffs with regards to how the models learns rarely seen tokens.

Duplicates

Many models use the same tokenizers. Listing some of the relationships here for future reference to myself.

  • gpt2: EleutherAI/gpt-j-6b, facebook/opt-66b (plus couple extra tokens), EleutherAI/gpt-neo-125m, roneneldan/TinyStories-8M
  • EleutherAI/gpt-neox-20b: EleutherAI/pythia-2.8b,

Contributors

skeskinen

6 commits

skeskinen/hf-tokenizer-testing

Simple test suite for various tokenizers

7

stars

6

commits

Python

primary language

May 30, 2023

updated

README

hf-tokenizer-testing

A simple script to test if GPT tokenizers from various popular models can encode+decode documents losslessly.

Documents tested are:

  • QQQ_0: Simple sanity test
  • QQQ_1: A sample from TinyStories dataset that looks innocent, but most tokenizers seem to fail because of a little bit unusual punctuation.
  • QQQ_2: Another, easier, sample from TinyStories
  • QQQ_3: Markus Kuhn's UTF-8 stress test, with couple lines removed b/c python encoder couldn't handle them. Correctly encoding/decoding this document is a very good sign of "correctness".
  • QQQ_4: Wikipedia page source for Snow Leopard
  • QQQ_5: Book Pride and Prejudice from The Project Gutenberg
  • QQQ_6: stb_image.h. C source code file
  • QQQ_7: Japanese book from The Project Gutenberg, 苦悶の欄(Kumon no ran)

Why?

Does it matter if tokenizers can/can't reproduce the input exactly? I guess this is subjective, but I'd say it's at least a nice feature. A feature that some tokenizers out there don't seem to have.

NOTE: When decoding, it's important to pass clean_up_tokenization_spaces=False to tokenizer.decode. Otherwise you will get a lot of missmatches related to tokenizer eating whitespace.

Results

Pass Fail

Tokenizer NameVocab SizeQQQ_0QQQ_1QQQ_2QQQ_3QQQ_4QQQ_5QQQ_6QQQ_7
EleutherAI/polyglot-ko-5.8b30003✔️✔️✔️✔️✔️✔️✔️✔️
huggyllama/llama-7b32000✔️✔️✔️✔️✔️✔️✔️✔️
openlm-research/open_llama_7b_400bt_preview32000✔️✔️✔️✔️✔️✔️✔️✔️
bigcode/starcoder49152✔️✔️✔️✔️✔️✔️✔️
facebook/galactica-6.7b50000✔️✔️✔️✔️✔️
gpt2-large50257✔️✔️✔️✔️✔️✔️✔️✔️
EleutherAI/gpt-neox-20b50277✔️✔️✔️✔️✔️✔️✔️
tiiuae/falcon-40b65024✔️✔️✔️✔️✔️✔️✔️
bigscience/bloom-560m250680✔️✔️✔️✔️✔️✔️✔️✔️

Tokenized length

Tokenizer NameVocab SizeQQQ_0QQQ_1QQQ_2QQQ_3QQQ_4QQQ_5QQQ_6QQQ_7
EleutherAI/polyglot-ko-5.8b300033643642818310292044390318197049144043
huggyllama/llama-7b3200012231223546518779319681311528488333
openlm-research/open_llama_7b_400bt_preview320003022521815452189579197971148109210463
bigcode/starcoder4915211240240467817971320684210481772613
facebook/galactica-6.7b50000112482365158216860196171127599145842
gpt2-large50257282172131478117502119610713998599792
EleutherAI/gpt-neox-20b5027711216210489716787718399710636476410
tiiuae/falcon-40b65024112262145486171417181700112559102247
bigscience/bloom-560m2506801023021040821276791820749215366894

My Takeaways

  • Llama tokenizer is really good. Small vocab, lossless, good compression, shown to work well in a real LLM. But downside with the Llama tokenizer is that it runs significantly slower than some of the other tokenizers (runtime speed is not shown here, but I've observed this elsewhere)
  • Open Llama is ok in English but has drastically worse compression than Llama in the utf8 test and Japanese. In my opinion, this is a pretty bad look.
  • Only other lossless tested here was bloom, but 250k vocab is kind of a lot for me. All the extra tokens lower the tokenized lengths, but is it worth it? Also there is some tradeoffs with regards to how the models learns rarely seen tokens.

Duplicates

Many models use the same tokenizers. Listing some of the relationships here for future reference to myself.

  • gpt2: EleutherAI/gpt-j-6b, facebook/opt-66b (plus couple extra tokens), EleutherAI/gpt-neo-125m, roneneldan/TinyStories-8M
  • EleutherAI/gpt-neox-20b: EleutherAI/pythia-2.8b,

Contributors

skeskinen

6 commits

Languages

Python

100.0%