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。