Tokenizers v1候選版：編碼最快提速30倍
Hugging Face Blog · 2026-09-21
背景
Hugging Face 的 tokenizers 函式庫幾乎是每個 transformers 模型的前處理入口，訓練與推論管線的第一步都要經過它把文字切成 token。長期以來單執行緒的正規表示式（regex）切分，加上每次呼叫都重新配置記憶體的合併（merge）迴圈，是拖慢大批次前處理的主因。這個瓶頸在多執行緒批次推論或大規模資料前處理時尤其明顯，因為每個執行緒都得重複付出相同的配置與比對成本。
過去整個函式庫是單一大型 crate，效能調整往往牽一髮動全身，難以針對編碼、序列化、格式轉換等不同路徑分別優化。這也是這次改版選擇先動刀內部架構，而不是急著更動對外介面的原因。
核心改動
這次釋出的v1候選版把重心放在效能重寫而非介面變動：官方明確保證「v1 會產出與 v0.23 相同的 token ID」，也就是輸出、API、詞表與合併順位都維持不變。內部架構被拆成 tk-encode、tk-serialize、tk-convert、tk-train 等模組化 crate，分別對應編碼、詞表序列化、格式轉換與訓練四條路徑，切分邏輯也從 regex 改為位元流（bitstream）切分。
另外還加入執行緒本地的詞彙快取（thread-local word caching），讓重複出現的前綴詞不用每次都重新比對；合併迴圈也改成不配置記憶體的版本，改用預先配置好的暫存緩衝區，模型處理則從逐字改為批次進行。這幾項改動疊加起來，才換來單執行緒下數倍到數十倍的編碼速度提升。
解碼路徑同樣受惠：位元組會直接寫入可重複使用的緩衝區，並支援平行批次解碼，但官方文章並未附上解碼吞吐量的具體數字，只列出了編碼端的量測結果。這代表想確認解碼是否同步加速的團隊，得自行跑一次基準測試才能拿到數字。
影響範圍
官方在十個模型家族上量測編碼速度，測試機器是單執行緒的 Apple M4 Max，結果是 v1 比 v0.23 快3到30倍，其中 t5-base 是提升最少的一端、gpt2 則是提升最多的一端。多執行緒下的擴展性也有數據，八個工作執行緒下達到76%的線性擴展效率。
| 項目 | v0.23 | v1候選版 |
|---|---|---|
| 單執行緒編碼速度（t5-base，低端） | 基準 | 約 3 倍 |
| 單執行緒編碼速度（gpt2，高端） | 基準 | 約 30 倍 |
| 八執行緒擴展效率 | — | 76% of linear |
| Token ID／詞表／合併順位 | — | 與 v0.23 完全相同 |
因為 API 與輸出完全相容，transformers 與 tokenizers 的使用團隊不需要改任何呼叫程式碼，只要用 cargo add tokenizers --pre 安裝候選版，重新跑一次既有的單元測試即可驗證行為一致。真正該檢查的是多執行緒批次前處理管線的 worker 數設定與吞吐量監控，既然擴展效率只有 76%，把 worker 數盲目調高不會等比例換來更快的處理速度，訓練資料前處理與線上推論的批次排程都值得重新量測一次。
負責資料集前處理與微調管線的團隊，也該留意批次呼叫是否已經改成一次送入整批文字，才能吃到批次模型處理帶來的效能紅利，而不是沿用逐筆呼叫的舊寫法。目前這仍是候選版而非正式的 1.0.0，正式環境升級前建議先在自己實際使用的模型家族上跑一次基準測試，因為加速幅度落在 3 到 30 倍之間，t5-base 與 gpt2 這兩端已經證明實際收益因模型而異，不能只看官方公佈的上限數字。