TokenDagger – OpenAIのTiktokenより高速なトークナイザー

• OpenAIのTikTokenと100%互換の高性能トークナイザーで、大規模テキスト処理において2倍以上のスループットと4倍高速なコードトークナイズ速度を提供
• PCRE2ベースの高速正規表現パースエンジンにより、トークンパターンマッチング速度を最大化
• 簡素化されたBPEアルゴリズムで、大量の特殊トークン処理時の性能低下を最小化
• 実際のベンチマークではコードトークナイズが4倍以上高速で、既存のTikToken利用コードをそのまま置き換えて活用可能
• Python 3.8+をサポートし、PyPI pip install tokendagger で簡単にインストール可能。PCRE2依存あり

[GN⁺]

Hacker Newsのコメント

• 短期的には、AI/MLインフラの構造ではこのようにC++で中核的なボトルネックを解消する形で、まだ多くの性能最適化の余地があると思う。全体をC++で書き直すという話ではなく、賢いエンジニアリング上のトレードオフが実際の性能向上につながることが多い。特に中国のエンジニアはこうした作業が得意な印象がある
  • 昔メンターに教わったソフトウェア開発の見方がある。第1段階はとにかく動かす、第2段階は速くする、第3段階は美しくする、というもの。TransformerやLLMはもうかなり「ちゃんと動く」段階まで来ているので、今は性能向上の面で最も大きな進展が起きる時期だと感じる
  • 長期的には、Python中心から離れることにも意味があると思う。単にMLエンジニアが慣れているから使うのだとしたら、将来志向ではない
  • 実際には TikToken はRustで書かれているので、今回の改善が本当にC++移植のおかげなのかは気になる
  • 実のところ、トークナイズが最大のボトルネックではなく、計算の大半は実際のCUDAカーネル実行で発生する。Pythonオーバーヘッドはごく小さい（VLLMも主にPythonで書かれている）。C++に書き直すというのは、ほぼ常にCUDAカーネルをより効率的に書き直すことを意味する
• 既存システムを大幅に高速化するドロップイン置き換えとして作るのは、かなり美しいことだと感じる。ScyllaDBを思い出す
  • 実際、こういう代替でなければ誰も使わないと思う
• LLM全体の性能において、トークナイザーがどれほど重要なのか気になる。トークナイザー最適化には関心があるが、まだ実測はしていない。コストの大半はmatmulによるものだと推測していたが、コメントを見る限りではトークナイザーにも意味がありそうだ
  • トークナイズは普通CPUで処理され、トレーニングや推論のボトルネックになることはまれ。大半の時間はGPUカーネルで使われ、ごく小さなモデルだけが例外になる。トークナイザーのレイテンシは、CPUが次のバッチを準備する形で「隠せる」場合もある
  • トークナイズ性能は少し複雑だが、本当に実力とリソースを持つ組織は非常に高速なトークナイザーを自作している。SentencePieceとtiktokenは、その複雑さやデプロイ上の負担を受け入れてでも採用される代表例だ。実際の専門家はフレームグラフでボトルネックを確認するし、大規模学習では事前トークナイズを行うこともある。Rustの物語とは逆にC++が再浮上していることへの業界の緊張感も感じるし、何か新しい理由や洞察があるとよいと思う
  • 他のコメントと同じく、実際にはトークナイザーがボトルネックではない。ただ、推論パイプラインの最初の段階なので先に手を付けたということだ
  • テキストのトークナイズは全体の計算の中では本当にわずかな割合にすぎない。それでも、ペタバイト級のデータ処理では少しでも速いなら無条件で良い
• tiktokenに合わせるにはvocabフォーマット変換が必要だが、この要件もなくなれば、使う上でもっと良い完全互換のドロップイン代替になるはずだ。また、tiktokenを初期化した後にtokendaggerを初期化して、結果が同じか確認できる双方向の例もあるとよい
  • 0.1.1バージョンからは真のドロップイン代替になった。まもなく例も追加する予定だ
  • 指摘が的確だったので、すぐに更新した
• このプロジェクトが BPE crate とどう比較されるのかも気になる。そのcrateの強みは、テキストを段階的に再トークナイズできる機能があり、tiktokenより速いことだ
  • 次は段階的再トークナイズ機能を追加し、そのcrateとのベンチマークも行う予定だ
• 他のLLM向けにローカルトークナイザーを入手する方法も気になる。たとえばGeminiはリモートAPIしか公開していない。これが独自仕様なのか、それともAPIを大量に叩いてトークン対応を推定できるのか気になる
  • Geminiは SentencePiece を使っており、Gemmaと同じトークナイザーvocabularyを共有している（参照1、参照2、参照3）。大手ラボの中でローカルトークナイザーがないのは、Claude 3以降を使うAnthropicだけだ
  • モデルごとのトークナイザーは、たいていSentencePieceやByte-pair encoding（BPE）のような中核アルゴリズムを共有しつつ、ラッパー層で特殊トークン処理などだけが異なる。tiktokenとTokenDaggerもBPE実装だ。ライブラリ側でモデルごとの特徴を反映してくれれば、わずかな性能向上と統合のしやすさにつながる。大きな仕事ではないので、新モデルに合わせる負担も小さい。参考例としては llamaの tokenizer.py、Mistralトークナイザー
  • GeminiがSentencePieceを使っているのは知っていた SentencePiece
• 以前、似たようなことを試した経験がある: tokie。実際にはトークナイザー実行コストの大半はプリトークナイズ（正規表現）で発生する。もっと速いregex方式を見つけたようだが、実際にregexエンジンだけを置き換えてBPEはtiktokenのままにした場合の性能変化も比較したのか気になる。もしそうならupstreamへの貢献も可能ではないかと思う
  • 素晴らしいプロジェクトだ。tiktokenの管理者には連絡しておいた
• Huggingface tokenizers との性能比較もしてほしい。tiktokenのreadmeにあるベンチマークは情報が古すぎる
  • 個人的には、tiktokenはhuggingface tokenizersより常に遅かった。なぜそうなのか、まだtiktokenを深く掘ってはいないが、HF Rustトークナイザーのユーザーとしてはそう感じる
• tiktoken のWASMバインディングも見てみたい。あるいは、純粋なjs実装で「b」から出た性能向上も適用できるのか気になる
• 本当に素晴らしいプロジェクトだ。こちらでもtiktokenを使っているが、ドロップイン互換で性能向上があるなら効果が気になる。ドロップイン方式を選んだのは見事だ