使用繁體中文評測各家 LLM Tokenizer 分詞器

Updated(2024/5/14) 更新上 GPT-4o (o200k_base)，這次 OpenAI 有更換 Tokenizer 進步非常非常多。

Updated(2024/4/21) 更新上 Llama 3，這次 Meta 有更換 Tokenizer 進步非常非常多。

話說大語言模型 LLM 的運算和推論成本都是用 Tokens 數量來計算的，輸入的內容都得轉成 Tokens 序列來運算，輸出則轉回來。

但是呢，其實每一家用的 Tokenizer (分詞器)都不太一樣，因此相同的文本，拆出來的 tokens 數量是不一樣的。因此很多模型的推論成本比較、Context window 長度限制比較等等，實際應用時都不太準確，特別是非英文的語言，各家差異非常大。

一樣的文本，若能用比較少的 Tokens 數來運算，推論速度會比較快、成本(運算資源)也會比較划算，畢竟計價也是用 tokens 數計算的，先予敘明。

具體會差多少，以下是我的測試結果，使用了繁體中文約八萬多個字(政府報告和管理學講義)做出來的實驗結果。另外也做了英文也是約八萬字(兩篇部落格文章)。

繁體中文

先看大家關心的繁體中文結果，以 OpenAI GPT3.5 (cl100k_base)為基準來比較的話:

沒想到差距竟然可以達到兩倍這麼多，除了 Llama 2 之外都比 GPT3.5 & GPT-4 還要節省 Tokens 數，GPT3.5 和 GPT-4 的 Tokenizer 對繁體中文真的很不友善啊! 直到最新的 GPT-4o 有大幅改進!

讓我換句話說:

總之，以後看各家模型的 Token 成本和 Context Window 限制時，都得分別心底換算一下了。

56% 意思就是 gpt-4 比 gpt-4o 多用 56% 的 tokens，而 Breeze -22% 則是節省 22% 的 tokens。

結果跟繁體中文差異很大，這裡 OpenAI 和 Llama 3 並列第一最省 tokens 數，其他家都會花比 OpenAI 多一些的 tokens 數。Llama 2 敬陪末座。

以下是使用的文本和數據

計算方式

OpenAI 是用 platform.openai.com/tokenizer 計算的
Gemini, Mistral, Llama 和 Cohere 是用 huggingface.co/spaces/Xenova/the-tokenizer-playground 算的，我有用 Gemini 後台跟 Cohere API 確認是一樣的。
Claude 3 沒找到工具可以自己算，我只能實際用 Claude API 呼叫後，查看回傳的 tokens usage 數
Breeze 7B 則是在我本機自己安裝跑的 huggingface.co/MediaTek-Research/Breeze-7B-Instruct-v1_0