Gigatoken：把分詞吞吐推到 GB/s 級別的 Rust 實作，以及它的代價

誰在為分詞速度付錢

分詞通常不是訓練流程裡最慢的一步，但它是每次資料前處理都要重跑的一步。當語料規模到十 GB 以上、而且你要反覆調整清洗規則或換模型重跑時，分詞的絕對時間就會變成排程上的固定成本。Gigatoken 針對的正是這個場景：不是推論時對單句做一次 encode，而是批次掃過整份語料檔。README 的範例直接寫成 `gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>")`，搭配 `tokenizer.encode_files(file_source)`，可以看出設計重心放在檔案層級的吞吐，而不是單筆呼叫的延遲。它的目標讀者因此很明確：預訓練或繼續預訓練的資料管線維護者、需要重複產出 token 快取的團隊。相對地，如果你在服務端只對使用者輸入做一次 encode，這個專案的價值主張跟你的瓶頸無關。

兩種路徑：相容模式與原生檔案 API

Gigatoken 提供兩條互斥的使用路徑，選擇直接決定你拿到多少加速。第一條是相容模式，把既有的 tokenizer 物件包起來：`gt.Tokenizer(hf_tokenizer).as_hf()` 之後，得到的物件可以放進原本使用 HuggingFace tokenizer 的位置，呼叫 `encode_batch`。tiktoken 也走同一套，改用 `as_tiktoken()`。README 明確指出這條路徑「at a non-negligible cost to performance」，也就是說為了讓輸出與 HuggingFace 逐位元一致，付出了可觀的效能代價，拿不到原生 API 那種倍數。第二條是原生 API，用 `gt.Tokenizer("Qwen/Qwen3-8B")` 直接吃 HuggingFace 的模型名稱，再交給 `TextFileSource` 讀檔。README 對此的說明是，原生路徑讓 Rust 端直接讀取資料，跳過盡可能多的額外開銷以換取最大平行度；同時它也提醒，若你把 Python 的資料結構傳進這個 API，仍然要付讀取 Python 物件的成本。換句話說，原生 API 的加速前提是資料留在檔案或 Rust 這一側，一旦你從 Python 逐批餵字串，優勢就會被侵蝕。

安裝與最小可執行範例

安裝只有一行：`pip install gigatoken`。README 沒有列出 Python 版本下限、wheel 平台或是否需要本機 Rust 工具鏈，這些在採用前需要自行從套件頁面確認。相容模式的完整流程是：先取得既有的 tokenizer 物件，例如 HuggingFace 的 `hf_tokenizer = ...`，再包成 `tokenizer = gt.Tokenizer(hf_tokenizer).as_hf()`，之後呼叫 `tokens = tokenizer.encode_batch(["This is a test string", "And here is another"])`。tiktoken 版本把中間那行換成 `gt.Tokenizer(tiktokenizer).as_tiktoken()`，其餘呼叫方式相同。原生 API 則是三行：`tokenizer = gt.Tokenizer("Qwen/Qwen3-8B")`、`file_source = gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>")`、`tokens = tokenizer.encode_files(file_source)`。這裡唯一出現的設定鍵是 `separator`，以位元組字串傳入，用來標示文件邊界；README 沒有說明它與模型本身 special token 之間的關係，若你的語料分隔符與訓練時的定義不同，需要自己驗證。

README 自己的數字裡藏著什麼

專案最容易被引用的是「~1000x faster」這個標語，但把三張表放在一起看，結論會收斂很多。在雙插槽 AMD EPYC 9565 的 144 核環境上，GPT-2 是 24.53 GB/s 對上 HuggingFace 的 24.8 MB/s，約 989 倍；同一張表裡 Gemma 4 只有 4.82 GB/s 對 334.1 MB/s，約 14 倍。到了 Apple M4 Max，GPT-2 的倍率升到 1,268 倍，但 Mistral 7B v0.3 只剩 21 倍、Gemma 3 是 17 倍。AMD Ryzen 7 9800X3D 上，GPT-2 是 106 倍，Gemma 3 掉到 13 倍。可以看出兩件事：倍率高度取決於基線有多慢，而 HuggingFace 在 Gemma 與 Mistral 這些 tokenizer 上本來就快得多（M4 Max 上 Mistral 7B v0.3 的 HF 基線是 95.1 MB/s，是 GPT-2 基線的十幾倍），所以加速空間自然被壓縮。另外 README 自己在標題下方註明，HF tokenizers 與 tiktoken 本身都已經是多執行緒的 Rust，這代表對比並非「Rust 對 Python」，而是兩種 Rust 實作在平行策略與記憶體存取上的差距。

ARM 與舊式 tokenizer 是它的弱區

把 M4 Max 那張表單獨拉出來，會看到一個和 x86 不同的形狀。在 144 核 EPYC 上，Gemma 4 到 Gemma 1 這一段都還有 2.5 到 4.8 GB/s；在 M4 Max 上，同一批模型降到 1.4 到 1.8 GB/s，而 Mistral 7B v0.3、CodeLlama、TinyLlama 也都在 1.7 到 2.0 GB/s 之間。相較之下，GPT-2 在 M4 Max 上仍有 8.79 GB/s。這表示 Gigatoken 的加速在 ARM 上對不同 tokenizer 的落差更大，若你的部署環境是 Apple Silicon 而模型屬於 Gemma 或 Llama 2 世代，實際收益會遠低於標語給人的預期。這是選型時最該先查的一格，而不是看總表的最大值。

相容模式的代價與基準的邊界

相容模式是這個專案最實用的部分，也是最需要保留態度的部分。README 的說法是「A substantial amount of effort has been put into making sure the outputs match exactly」，同時承認這帶來不可忽略的效能損失。它沒有給出相容模式本身的吞吐數字，所以無法判斷在該模式下還剩幾倍，只能確定低於原生 API。這對需要嚴格重現既有 token 序列的團隊是必要的保險，但如果你只是要產生訓練資料、且能接受重新驗證一次輸出，原生 API 才是加速的來源。另一個邊界在基準方法本身：README 說明 OWT 被選為代表 CommonCrawl 抽取後文字的樣本，且「Gigatoken encodes the whole file un-spli...」，這句在提供的材料中被截斷，因此無法確認它是否整檔不切分、以及 HF 與 tiktoken 的基線是否以相同方式餵資料。跨工具比較時，輸入切分方式與執行緒設定會直接影響結果，這點在材料中沒有交代清楚。

替代方案與維護面的現實

最直接的替代就是 HuggingFace Tokenizers 本身。它的優勢不在速度，而在生態：模型支援範圍、與 transformers 的整合、社群文件與既有 bug 回報都成熟得多，而 Gigatoken 目前沒有檢索到任何正式 release，代表版本節奏與相容性承諾都還沒有可觀察的紀錄。tiktoken 是另一條路，它在 GPT-2 這類 BPE 上表現穩定，但 README 的表格顯示它只覆蓋部分模型（多數欄位是破折號），且在多數情境下仍慢於 Gigatoken。真正的差別在架構：HuggingFace 與 tiktoken 是通用函式庫，輸入輸出以 Python 物件為主；Gigatoken 的原生 API 把檔案讀取搬進 Rust，用平行度換吞吐，代價是你必須接受它的資料來源抽象。授權是 MIT，屬於寬鬆條款，可商用與修改，但這不構成法律意見，若你要把它併入發行產品，仍應自行確認相依套件的授權疊加。維護成本方面，材料只顯示最後推送時間為 2026 年 9 月，沒有 release、沒有 changelog，因此升級風險無法從現有資訊評估。

編輯結論

如果你的工作是把十 GB 級別的語料反覆分詞成訓練用的 token 序列，而且模型落在 GPT-2、Qwen、Llama、Phi、OLMo 這條清單上，Gigatoken 的原生 API 值得先進沙盒跑一輪；若你的模型是 Gemma 系列或 Mistral 7B v0.3，README 自己列出的加速只有 7 到 21 倍，換取一個新依賴未必划算。反之，如果你只是線上服務裡對單筆 prompt 做一次 encode，或需要串流、增量解碼這類狀態化介面，這個專案沒有對應說明，不要假設它涵蓋。採用前先確認三件事：你的 tokenizer 是否在支援清單內、你的硬體是否為 ARM，以及相容模式與原生 API 的輸出是否在你自己的語料上逐 token 相同。

官方來源

1. Issues
2. License: MIT
3. marcelroed/gigatoken on GitHub
4. README