一个开源项目把CPU分词吞吐做到了24.53 GB/s。在AMD EPYC双路144核处理器上跑GPT-2分词器,比HuggingFace Tokenizers快989倍。
这不是论文里挑出来的孤例,是作者挂在README里、任何人一条uvx命令就能现场复现的基准。989倍这种数字,第一反应通常是不信。但比"信不信"更值得问的是:分词这一环到底被通用实现拖慢了多少年,这种提速又能不能变成训练流水线里真金白银的时间。
发生了什么
项目叫GigaToken,作者Marcel Røed,开源在GitHub上。卖点很直接:CPU分词吞吐做到GB/s级别,支持HuggingFace和tiktoken两种兼容模式,原生API号称"直接替换"。
三组硬数字,都是作者自测,可用一条命令复现:
- EPYC 9565双路144核,GPT-2分词器24.53 GB/s,比HF Tokenizers快989倍,比tiktoken快681倍
- Apple M4 Max 16核,GPT-2分词器8.79 GB/s,比HF快1268倍
- 按EPYC这个速率,处理130万亿token的语料,理论只要6.5小时
提速不是均匀分布的。GPT-2、Llama、Qwen、DeepSeek这类常见BPE分词器,提速普遍在几百到上千倍。SentencePiece系——主要是Gemma和多数Google模型——只有7到22倍。WordPiece(BERT类)目前不支持。
快在哪,该打几折
作者在FAQ里说得直白:以前预分词大多外包给一个通用正则引擎去做,GigaToken换成SIMD重写,削减分支判断,再加一层缓存——常见词一旦见过,直接查表,不用重新走编码流程。
剩下的增量来自减少Python交互和线程间通信。原生API让Rust直接读文件,数据不经过Python就能完成大部分工作。
但一旦切到"兼容模式",把结果按HuggingFace或tiktoken格式吐出来,就得多一层转换。作者自己承认这里有"non-negligible"的性能损耗。你拿到的不是1000倍,是"快很多"。
| 分词器类型 | 代表模型 | 提速倍数 | 备注 |
|---|---|---|---|
| BPE | GPT-2 / Llama / Qwen / DeepSeek | 数百倍至989倍以上 | 优化最充分,是本次基准的主角 |
| SentencePiece | Gemma等Google系模型 | 7–22倍 | 提升明显收窄 |
| WordPiece | BERT类 | 尚不支持 | 无法直接迁移 |
README里没细说的部分同样重要:测试语料的规模和领域、线程配置、对照的HF Tokenizers版本号、输出正确性怎么校验、内存占用是否随之上升,这些都还是空白。这是一次作者自测,不是独立复现的第三方基准。
谁该认真看,谁该再等等
对大模型训练和数据基础设施团队,这类工具值不值得试,先看一件事:预处理阶段CPU是不是常年打满,GPU是不是在等数据。如果是,分词很可能是隐藏瓶颈。值得拿自己的语料和分词器实测一次,对照真实流水线的时间表。如果瓶颈在存储I/O、数据清洗或网络带宽,分词吞吐涨十倍,训练也不会明显提速。
对关注AI系统性能的开发者,更值得看的是它的SIMD和缓存思路本身。这套手法迁移到别的文本处理场景也可能有用,不必等项目商业化或被主流工具链收编。
生产环境接入之前,先确认三件事:分词器是不是在它优化过的BPE列表里,兼容模式的性能损耗能不能接受,输出结果是不是和原分词器逐字节一致。项目本身还年轻,WordPiece不支持、Windows测试不充分,有没有第三方独立复现,这些都是接下来该盯的地方。