Perplexity AI在github.com/perplexityai/pplx-garden下以MIT许可证开源了Rust Unigram tokenizer,报告p50延迟比HuggingFace tokenizers crate降低5.5倍。514 tokens(512 + BOS/EOS)上的具体数字:HuggingFace 349µs,Perplexity 63µs。在16K tokens,参考实现做299,171次分配;Perplexity版本做零次。生产声明是在每次请求评分数百个候选文档的rerankers上CPU利用率降低5-6倍,其中GPU计算在single-digit毫秒内完成,而tokenization成为瓶颈。
工程模式是speedup之下的实质。基于HashMap的trie遍历被替换为双数组trie(Aoe,1989),它将trie打包到两个连续的整数数组中以实现cache友好的索引。添加基于bitmap的字节验证以提早跳过无效前缀路径,并添加2MB huge-page backing以将trie保留在TLB-thrashing区域之外。Unigram tokenization本身在每个词汇token的学习log-probabilities上运行一个most-probable-path Viterbi——与BPE的迭代merge不同——所以trie模式自然适合Unigram。代价是内存:trie从约9MB增长到约50MB。没有报告质量退化;输出与参考完全相同。
对运行reranker或embedding stacks的构建者的生态系统解读:tokenization是CPU-bound路径中的可测量瓶颈,大多数团队都没有对其进行instrumentation。如果你的reranker扇出到每个查询200个候选文档,tokenization每个request运行200次——几百微秒变成数十毫秒,在GPU服务的推理上与模型本身同级。狭窄的警告:Perplexity的tokenizer针对XLM-RoBERTa的250K-token SentencePiece Unigram词汇,所以它使Unigram词汇用户(大多数rerankers和许多多语言embedders)受益但不帮助BPE-tokenized stacks(大多数当前前沿LLMs)。更大的教训——Rust + 双数组trie + huge-page backing + 零分配路径——可移植到任何tokenizer热点路径,如果你的CPU预算紧张,可能值得为BPE tokenizers复制。
如果你周一早上运行reranker或embedding推理:针对推理wall-clock instrumentation tokenizer wall-clock;如果tokenization超过后者的20%,这很重要。如果你专门使用Unigram词汇模型:pplx-garden是替换HuggingFace crate的drop-in候选。50MB的内存成本是要预算的tradeoff。