tokenizers v1 候選版重寫編碼路徑，M4 Max 測試達前版 3 至 30 倍

Hugging Face 於 9 月 21 日發布 tokenizers v1 候選版與測速說明，重寫文字轉 token 的 CPU 執行路徑。官方在 Apple M4 Max、十個模型家族的單執行緒測試中，量得編碼速度為 v0.23 的約 3 至 30 倍；這是分詞階段的結果，不能直接換算成模型生成吞吐量。[技術說明](https://huggingface.co/blog/tokenizers-v1)

改動之一是以 bitcannon 處理已辨識的預分詞規則，利用 SIMD 位元運算尋找文字切分邊界，減少通用正規表示式引擎的工作。BPE 合併則重用暫存緩衝區，以索引維護相鄰片段，降低反覆配置記憶體與搬移資料的成本。不受支援的規則仍走原有正規表示式路徑，因此不同模型的收益不會一致。[實作說明](https://huggingface.co/blog/tokenizers-v1)

多執行緒部分把共用暫存池拆成子池，讓執行緒優先重用自身緩衝區與詞片快取，減少爭用同一把鎖。快取會記住預分詞片段對應的 token ID，使重複內容省去再次合併；但重複率低時，查表成本未必能換來足夠命中。相關拉取請求也記錄，一個每連線逐次編碼的 HTTP 前端未因此變快，顯示瓶頸可能在其他位置。[並行改動](https://github.com/huggingface/tokenizers/pull/2365)

公開 tokbench 提供重驗入口：載入詞彙表與編碼分開計時，輸出 ID 以雜湊核對，結果不同者排除排名。其文件特別指出，文字重複程度會左右快取效益，中文與英文語料不能直接共用加速結論；部分內部語料也未公開，重現時應固定可取得的資料與版本。[測試框架](https://github.com/huggingface/tokbench)

對中文服務而言，合理的驗證方式是加入繁體中文、混合程式碼及長短請求，分別量測編碼耗時、尾端延遲與整體服務吞吐量，並核對特殊 token、截斷與位移資訊。若現行服務主要耗時在模型運算或網路等待，分詞加速對使用者感受到的延遲可能有限。這些是部署評估建議，並非官方已證實的中文效能數字。

目前 GitHub 標籤仍是 `v1.0.0-rc.2`。維護者以維持既有 API 與 token ID 為目標，但官方測速未包含 Python 呼叫包裝的額外開銷，Transformers 生態整合也列為後續工作。採用者應先固定候選版測試，再追蹤正式版相容性與實際應用收益。[版本公告](https://github.com/huggingface/tokenizers/releases/tag/v1.0.0-rc.2)、[後續規劃](https://huggingface.co/blog/tokenizers-v1)