tokenizers v1 候选版：把分词器变成不再拖慢模型的一环

背景

分词历来不是机器学习流水线的瓶颈，但当模型变快、数据集变大、并发请求增多时，CPU 侧的分词可能供不上数据，让 GPU 空等。Hugging Face 因此把性能作为 tokenizers v1 的重点，并发布候选版对比 v0.23。

保持不变的部分

v1 的目标是输出不变：同样的 token ID、API、词表和合并优先级，加载能力覆盖 v0.23 支持的全部分词器家族，不专门针对 BPE。原文给出的对比均在候选版上进行。

主要改动

• 工作区拆分：拆成 tk-encode 运行时与 tk-serialize、tk-convert、tk-train 等按需链接的部分。
• 无分配模型：合并所需工作区放在调用方提供的 scratch buffer 中，循环不再触碰分配器。
• bitcannon：用位流上的布尔运算配合 SIMD 代替正则引擎完成切分。它依赖能识别具体模式；不在已覆盖文法内的分词器仍走正则路径，享受不到这部分加速。
• 合并循环重写：符号存在扁平数组中，以索引构成双向链表，合并只需更新两个索引。
• 词缓存：线程本地的前 token 字节到 token ID 映射，重复词只需合并一次；重复少时可能只有查找开销。
• 原生并行：多个线程共享同一分词器编码，各自使用独立 scratch buffer 与缓存。

测量结果与条件

在 Apple M4 Max 上单线程编码，覆盖的十个模型家族比 v0.23 快 3 至 30 倍（低端 t5-base，高端 gpt2）；八 worker 下扩展效率为线性的 76%。方法上要求各引擎跑同一计时循环、加载不计入编码、用 FNV-1a 校验输出 ID 一致、只统计共同单元的中位数、worker 绑定到八个物理核。原文强调基准需说明是重复编码同一文档还是编码不同文档流，两种“热”负载结果可能差别很大。

获取与后续

候选版已发布在 crates.io，普通安装用 cargo add tokenizers --pre；若只需编码，可关闭默认开启的训练特性。批量编码调用 encode_batch 是扩展性所在。Python 绑定包的每次调用开销不在上述测量内。1.0.0 之前计划把更多模型家族迁移到新合并循环；1.0.0 还列有训练与推理共用同一编码实现、可选 offsets 与 masks、简化 Python 绑定、面向 ExecuTorch 与 llama.cpp 的推理专用 C/C++ 绑定等事项；GPU 编码属于 1.0.0 之后的探索方向。