tokenizers v1：编码、解码与扩展性实测
来自 Hugging Face · 期号 2026-09-21
摘要
Hugging Face 发布了 tokenizers v1 的候选版本。 tokenizer 过去不是 ML 工作流的瓶颈，但随着模型变快、规模变大，它可能让 GPU 空转等待 CPU 完成分词。v1 的目标是让 tokenizer 不再拖后腿。 v1 与 v0.23 输出完全相同的 token ID，但编码速度提升了 3 到 30 倍（Apple M4 Max 单线程）。关键改动包括：用位流运算替代正则表达式做预分词、用线程本地缓存避免重复合并、合并循环不再分配内存、一次处理一批预 token。 v1 在 8 个 worker 上达到 76% 的线性扩展。 本文是性能详解，附有可复现的基准测试工具。
深读
导读 Hugging Face 发布了 tokenizers v1 的候选版本。随着模型推理速度加快、训练数据规模增长，分词环节正从“从不拖后腿”变成 GPU 空转的潜在原因。v1 在保持与 v0.23 完全相同的 token ID 输出的前提下，通过四项核心改动将单线程编码速度提升了 3 到 30 倍，并在 8 个 worker 上达到 76% 的线性扩展。读完本文能清楚知道这些加速来自哪里、在什么条件下有效、以及如何在自己的项目里试用。 关键信息 - 单线程编码速度提升幅度：t5-base 为 3 倍（低端），gpt2 为 30 倍（高端），测试硬件为 Apple M4 Max。 - 多线程扩展效率：8 个 worker 上达到 76% 的线性扩展，worker 被固定到 8 个不同的物理核心，不使用 SMT 超线程。 - 核心改动之一“bitcannon”用位流运算和 SIMD 指令替代正则表达式引擎做预分词，每次操作处理 64 字节。 - 核心改动之一“word cache”是一个线程本地缓存，将已处理过的 pre-token 字节到 token ID 的映射保存下来，重复词直接命中，跳过合并循环。 - 核心改动之一“merge-loop rewrite”将合并工作集放在调用者拥有的 scratch buffer 中，合并循环不再分配新内存；候选 pair 被打包成单个 64 位值，比较时只需比较整数，且“无合并”状态用最大值表示，无需分支判断。 - 覆盖的模型家族：GPT-2、cl100k、o200k、Tekken、DeepSeek 等 10 种，其中 8 种使用 BPE，另外两种使用 WordPiece 和 Unigram。 逐节讲解 为什么需要 v1 分词在传统 ML 工作流中不是瓶颈，计算量远小于模型本身。但随着模型变快、训练数据变大、并发请求增多，分词可能让 GPU 空转等待 CPU 完成分词。v1 的目标是让分词不再拖后腿，同时保持与 v0.23 完全相同的 token ID 输出、API、词表和合并排名。 四项核心加速改动 bitcannon（预分词加速）：BPE 模型用正则表达式将输入文本切分成 pre-token，合并只在 pre-token 内部进行。这个正则表达式是模型训练时确定的固定参数，运行时不会改变，因此不需要通用正则引擎。bitcannon 用位流运算和 SIMD 指令实现等价的分割函数，一次操作处理 64 字节。该加速只对已知的几种正则模式生效，不在覆盖范围内的模型仍走原来的正则路径。 word cache（重复词缓存）：BPE 对同一 pre-token 总是输出相同的 token ID。v1 用一个线程本地缓存保存已处理过的 pre-token 字节到 token ID 的映射，后续遇到相同 pre-token 时…