GigaToken 把斷詞推進 GB/s
GigaToken 要解決的是 LLM 資料進模型前的 tokenization 瓶頸。它以 Rust 實作，針對通常交給 Regex 的 pretokenization 改用 SIMD，搭配低分支設計、pretoken 快取、減少 Python 往返與執行緒通訊。官方在 11.9GB OpenWebText 測試中，GPT-2 於雙路 AMD EPYC 達 24.53GB/s、約為 HuggingFace Tokenizers 的 989 倍；Apple M4 Max 則達 8.79GB/s。這個「約 1000 倍」是特定 tokenizer、硬體與原生 API 下的結果，不是所有情境都保證同樣提升。
現實應用
最直接的用途是 LLM pretraining、continued pretraining、資料清洗、token 數量估算，以及把 Common Crawl 等大型語料轉成訓練格式。會真正有感的是管理 TB～PB 級資料的 AI lab、模型公司與研究團隊；一般 chatbot 推論或少量文字批次，tokenization 本來就不是主要成本，換了未必有明顯差異。
期望評估
我認為低標期望是先用 HuggingFace Tokenizers 或 tiktoken 相容模式，在少改程式的前提下縮短離線資料處理時間，但速度不會等同原生 API 的千倍數字。高標期望則是資料直接由 Rust 讀檔、tokenizer 又屬於優化較完整的 BPE 類型，讓 tokenization 從 pipeline 瓶頸變成幾乎可忽略；官方甚至估算 130 兆 tokens 可在高階 EPYC 主機上約 6.5 小時完成。
商業策略分析
我猜最先受影響的是販售訓練資料處理平台、CPU preprocessing 服務，以及內部長期維護 tokenizer pipeline 的團隊。商業價值不是讓模型更聰明，而是省 CPU 時數、縮短實驗週期，並降低重複切換 tokenizer 的成本。值得有大型語料管線的團隊立刻做 benchmark；若工作量小、主要成本在 GPU 訓練或推論，就先不用為漂亮倍數重構系統。
實作細節
安裝只要 pip install gigatoken。最省事是用 gt.Tokenizer(existing).as_hf() 或 .as_tiktoken() 接回既有程式；追求最高速度則用 TextFileSource 與 encode_files() 直接讀檔。已知限制包括尚未支援 WordPiece、SentencePiece 優化較弱、原生 API 尚無 file sink，Windows 測試也不完整，官方建議先走 WSL；macOS 首次執行可能受安全掃描拖慢。