Tokenization，即將原始文字轉換為語言模型實際使用的數值 token 序列的前處理步驟，仍是 ML stack 中最少被 profiling 的元件之一。隨著訓練資料集擴展到 TB 與 PB 規模，花在這項轉換上的時間可能成為資料準備 pipeline 中的實際瓶頸，但它很少成為最佳化工作的重點。Gigatoken 是 Stanford 博士生 Marcel Rød 以 MIT 授權發布的新函式庫，主張這項忽視是有代價的。該函式庫可在單機上以每秒數 GB 的速度進行文字編碼，效能超越已採用多執行緒 Rust 實作的基準方案。

基準測試結果

在配備 144 核心 AMD EPYC 9565 雙插槽系統上，使用 11.9 GB 的 owt_train.txt 語料對 GPT-2 tokenizer 進行基準測試時，Gigatoken 的資料處理速度達 24.53 GB/s。在相同硬體上，OpenAI 的 tiktoken——用於為 GPT 模型編碼文字的函式庫——達到 36.0 MB/s，而 HuggingFace tokenizers——開源 ML 生態系中實際上的標準 tokenizer——為 24.8 MB/s，分別換算為 681x 與 989x 的效能優勢。

這項加速在不同架構上也保持一致。在 16 核心 Apple M4 Max 上，相同的 GPT-2 工作負載達到 8.79 GB/s，比 HuggingFace tokenizers 快 1,268x，比 tiktoken 快 140x。在消費級 AMD Ryzen 7 9800X3D 上，Gigatoken 達到 6.27 GB/s，較對應基準分別快 106x 與 68x。

Gigatoken 是什麼

Gigatoken 是以 Rust 撰寫、並提供 Python bindings 的 byte-pair encoding（BPE）tokenizer。BPE 是現代 LLM 的主流 subword tokenization 演算法，GPT、Llama、Qwen、Mistral 等家族均採用此類方法。它以 gigatoken 名稱在 PyPI 上提供（版本 0.9.0，於 21 July 2026 發布），可透過 pip install gigatoken 安裝。其程式碼庫由 66.2% Rust 與 33.3% Python 組成。已發布的基準測試涵蓋 23 個不同 tokenizer 家族，包括 GPT-2、GPT-OSS、Llama 3 through 4、Qwen 2 through 3.6、DeepSeek V3/R1/V4、GLM 4 and 5、Kimi K2、Nemotron 3、Phi-4、OLMo 2/3、ModernBERT、Gemma 與 Mistral。

Gigatoken 提供兩種使用模式。相容模式會包裝既有的 HuggingFace 或 tiktoken tokenizer，在犧牲吞吐量的情況下保留完全一致的輸出。Rød 在 Hacker News 表示，視使用方式而定，相容模式約可帶來 200–300x 的加速，因為它仍需承擔 Python 在建立 list 以及 string-to-bytes 轉換上的開銷。已發布的基準測試數字則來自原生 Gigatoken API；該 API 允許 Rust 直接讀取檔案。

技術方法

這些效能提升並非來自更快的 BPE merge loop，而是來自多數 tokenizer 視為已解決的兩個領域。

Pretokenization 最佳化

多數實作會將 pretokenization 委派給 regex engine。Gigatoken 則手寫整個 pretokenizer。pretokenizer 最佳化紀錄 追蹤了在 100 MB OpenWebText 上單執行緒 GPT-2 pretokenizer 的吞吐量，顯示出詳細的演進過程：

• fancy-regex 基準約為 47 MiB/s。
• 手寫 state machine 約達 380 MiB/s。
• 使用 NEON SIMD intrinsics 的 winnow-combinator 實作達到 462 MiB/s。

進一步最佳化來自以直接 Iterator 取代 winnow、加入 256-byte class lookup table 以進行 O(1) first-byte dispatch，並從 NEON intrinsics 改用 SWAR（SIMD Within A Register）。SWAR 會將 8 bytes 載入為 u64，並使用無分支算術一次檢查全部 8 個位元組是否具備字母屬性，而不需要架構特定的 intrinsics。這將吞吐量推升至 830 MiB/s。

最後一步最佳化涉及雙游標 instruction-level parallelism（ILP）利用，使速度達到 1,049 MiB/s。關鍵洞見是，在約 840 MiB/s 時，瓶頸是延遲而非吞吐量。每個 token 的結束位置都取決於前一個 token，形成約 25–27 cycles 的序列鏈。透過從安全分割點啟動兩個獨立游標，out-of-order execution engine 可在閒置的 execution ports 之間交錯處理兩條資料流。

僅就 pretokenizer 而言，淨效果是：相較 winnow + NEON 基準快 2.27x，相較 regex 實作快 22.3x。

Pretoken 快取

當某個字詞曾經出現過，其編碼後的 tokens 會直接查表取得，而不是重新計算。Rød 指出，這在實務上很困難，因為快取會快速成長，而且 pretoken 分布呈現長尾型態。此外，與 Python 的互動被降到最低，threads 之間也被設計為盡量減少彼此互動。

最佳化紀錄也記載了未奏效的方法。使用 #[cold] 與 #[inline(never)] 的 hot/cold split 退化到 580 MiB/s，之後被還原，因為 inline barrier 阻止 LLVM 最佳化合併後的 ASCII 與 unicode loop。使用 SWAR transition counting 的 two-pass classification buffer 在演算法上正確，但只達 354 MiB/s，因為額外的記憶體流量抵消了分支節省。Profile-guided optimization 沒有可測量的效果，因為內部 loop 已經是無分支，而 word-boundary 分支取決於資料。

基準測試方法

這項比較並非嚴格的 apples-to-apples。Gigatoken 會對完整未分割檔案進行編碼，自行尋找文件邊界並自動平行化。HuggingFace（encode_batch_fast）則在前 100 MB 上評估，tiktoken（encode_ordinary_batch）在前 1 GB 上評估，兩者都預先以 <|endoftext|> 分割。由於基準方案未實作快取，其吞吐量保持一致。所有量測皆回報在啟用平行化、使用全新 process 的三輪交錯測試中最佳結果。

詞彙表類型也帶來限制。SentencePiece tokenizers 只獲得部分最佳化。在 EPYC 上，Gemma 1 的處理速度為 2.51 GB/s（7.3x 加速）、Gemma 3 為 3.43 GB/s（9.6x）、CodeLlama 為 3.47 GB/s（10.0x）。雖然這些增益相當可觀，但比起 BPE 的主打效能數字仍低了一個數量級。

KrabArena 上的一項獨立重現驗證了結果。在配備 4-vCPU Intel Xeon VM（2.20 GHz）並使用 174 MB OpenWebText 切片的環境中，Gigatoken 0.9.0 的中位數達 277.8 MB/s，比 tiktoken 0.13.0（10.62 MB/s）快 26.2x，比 tokenizers 0.23.1（3.33 MB/s）快 83.4x。所有試驗均成功驗證 35,356 份文件，確認效能趨勢會隨核心數擴展。

範圍與限制

Gigatoken 的加速效果同時適用於 x86 與 ARM 架構，並涵蓋全部 23 個受支援的 tokenizer 家族，而非僅限於單一調校組態。不過，SentencePiece 詞彙表的加速幅度為 7–22x，而非 1,000x 等級；WordPiece 則不受支援。相容模式可保留與 HuggingFace 完全一致的輸出，但加速約為 200–300x，而非完整的原生速度提升。

GitHub repository 與 benchmark explorer 已公開提供。