新開源分詞器 GigaToken 以 SIMD 與多層快取改寫 BPE 效能，在 144 核 AMD EPYC 上對 GPT-2 達 24.53 GB/s、較 HuggingFace Tokenizers 快約 989 倍，並提供 HF 與 tiktoken 相容模式可直接替代。
GB/s 等級的分詞吞吐量
開發者 Marcel Rød 在 GitHub 釋出 GigaToken，標榜是目前最快的語言模型 tokenizer，以 Rust 撰寫、透過 pip 即可安裝。官方基準在 AMD EPYC 9565 雙路 144 核平台上，對 11.9 GB 的 OpenWebText 訓練檔做 GPT-2 分詞，吞吐量達 24.53 GB/s，約 5,565 Mtok/s；同一資料上 HuggingFace Tokenizers 為 24.8 MB/s，tiktoken 為 36.0 MB/s，換算分別快 989 倍與 681 倍。換言之，整個約 130 兆 token 的 Common Crawl，理論上可在 6.5 小時內完成分詞。
GigaToken 官方基準涵蓋主流 BPE 詞表，包括 Llama 3/3.3/4、Qwen 2/3/3.5、DeepSeek V3/R1/V4、GLM 4/5、Phi-4、GPT-OSS、Kimi K2 等，在 EPYC 上多落在 18 至 24 GB/s 區間。作者強調，比較基準中 HF 與 tiktoken 本身已是多執行緒 Rust 實作，差距來自 SIMD 化的預分詞（pre-tokenization）、分支消除與多層預分詞快取，而非對手沒有平行化。
相容模式與原生 API 的取捨
GigaToken 提供兩條接入路徑。相容模式可把既有 HuggingFace 或 tiktoken 物件包進 gt.Tokenizer(...).as_hf() 或 .as_tiktoken()，幾乎不改程式即可運作，並投入大量功夫確保輸出與 HF 一致；但作者明白指出，相容模式會有「不可忽視的效能損耗」，無法拿到原生 API 的 1000 倍量級提升。原生 Gigatoken API 則讓 Rust 直接讀檔、跳過 Python 資料結構往返，搭配 encode_files 與 TextFileSource 達到最高吞吐。
現階段的限制也清楚：WordPiece 尚未支援、檔案輸出尚未實作、Windows 僅建議走 WSL。最慢的一群是 SentencePiece 系（Gemma、Mistral、CodeLlama、TinyLlama），在 EPYC 上僅約 3.4 至 4.8 GB/s，相對 HF 提升收斂到 7 至 22 倍；作者將 SentencePiece 列為低優先，主因是 Google 與 BERT 體系以外多已轉向 BPE。
所以呢：誰該換、誰要等
對每天要對 TB 級網路文本做前處理的訓練團隊，分詞從分鐘級壓到秒級，代表資料管線的 CPU 預算與等待時間可大幅縮短，重算、重洗 corpus 的成本門檻同步下降。對推論服務或單文件即時分詞的場景，受 Python 往返與 ABI3 限制，提升不會到基準的極限值，需自行用 gigatoken bench 在目標 CPU 上實測。若語料取得依賴公開網站，還要把來源端的基礎設施成本算進去；The Numbers 因 AI 爬蟲占九成流量而停機重建的案例說明，處理端吞吐提升不等於抓取端沒有外部成本。
選型上，BPE 詞表的 Llama、Qwen、DeepSeek、GLM、Phi 陣營是最大受益者；Gemma、Mistral 等 SentencePiece 用戶則應等待後續優化，或先在相容模式下評估一致性與實際增益再決定是否搬移。若瓶頸在端側記憶體與算力，而不是訓練資料前處理，可改看〈ESP32-S3 執行 28.9M 參數 LLM 的實測〉。
