AI 基礎設施
GigaToken 以 Rust、SIMD 與檔案直讀加速 BPE，GPT-2 分詞自測達 24.53 GB/s
開源專案 GigaToken 0.9.0 將預分詞、BPE 合併與資料輸入路徑重新最佳化，宣稱在雙路 144 核 AMD EPYC 主機上比 Hugging Face Tokenizers 快 989 倍。最大數字依賴原生 API、11.9 GB 批次語料及高度平行硬體，不能直接套用到線上短請求。
GigaToken 0.9.0 於 7 月 21 日上架 PyPI，提供 Rust 核心及 Python 介面，支援直接載入 Hugging Face 模型名稱，也能包裝既有 Hugging Face Tokenizers 或 tiktoken 物件。專案瞄準的不是模型解碼，而是訓練資料製備、離線語料分析與大批量 token 計數等 CPU 分詞工作。
它的高吞吐來自數項疊加最佳化：以 SIMD 加速 GPT 類正規表示式的預分詞；快取重複 pretoken 對應的 token 序列，避開反覆執行 BPE merge；依 tokenizer 規則採用專用路徑；並讓 Rust 端透過 `TextFileSource` 直接讀檔，減少 Python 字串、物件配置及跨語言邊界的成本。相容模式可降低移植門檻，但官方也明言，為精確匹配既有輸出所付出的轉換成本，會使它達不到原生 API 的最高數字。
在專案自行公布的測試中，GigaToken 於兩顆 AMD EPYC 9565、共 144 核的主機處理 11.9 GB OpenWebText：GPT-2 tokenizer 達 24.53 GB/s，Hugging Face Tokenizers 為 24.8 MB/s；Phi-4 與 OLMo 2/3 也超過 23 GB/s。這類結果顯示，當 GPU 訓練管線等待 CPU 準備 token 時，分詞器可能是值得獨立剖析的瓶頸。
但「989 倍」不是一般應用的預期加速。測試使用超大檔案、雙路伺服器及完整核心平行度，亦把檔案輸入路徑差異計入比較；短文字、串流請求、Python 記憶體輸入或 NUMA 配置不同時，收益可能大幅縮小。工程團隊下一步應檢查跨 tokenizer 的位元級輸出一致性、Unicode 與特殊 token 邊界、峰值記憶體，以及在自有 CPU 與真實批量下的端到端吞吐。