ハクソク

世界を動かす技術を、日本語で。

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

329日前原文(github.com)

概要

TokenDagger は、OpenAIの TikToken と互換性を持つ高速トークナイザー。 C++17 で実装され、Pythonバインディングを提供。 正規表現エンジン最適化 により大幅な性能向上を実現。 コードサンプルでは 4倍高速化、大規模テキスト処理で 2-3倍スループット向上。 BPE や特殊トークンルールも完全サポート。

TokenDagger: OpenAI TikTokenの高速互換実装

  • TokenDagger は、OpenAIの TikToken に完全互換のトークナイザー
  • 大規模テキスト処理 やLLM用途に最適化
  • C++17 で実装、Pythonからも利用可能なバインディング提供
  • PCRE2 （Perl Compatible Regular Expressions 2）を利用した 高速正規表現パーシング
  • BPE（Byte Pair Encoding） や特殊トークンルールもTikTokenと同一仕様
  • 大規模特殊トークン語彙 にも対応した簡略化アルゴリズム
  • ベンチマーク 環境：AMD EPYC 4584PX（16コア/32スレッド、4.2GHz）

主な特徴

  • 正規表現処理高速化 ：JITコンパイル対応PCRE2エンジンでトークンパターンマッチングを最適化
  • 完全なドロップイン互換性 ：OpenAI TikTokenの既存コードをそのまま置き換え可能
  • BPEアルゴリズム簡素化 ：特殊トークンの正規表現照合をスキップし、パフォーマンスを最大化
  • コードサンプルのトークナイズで4倍の高速化
  • 1GBの自然言語テキストで2-3倍のスループット向上

テスト実行方法

  • クリーンビルド＆テスト
    • make clean && make
    • pip3 install tiktoken
    • python3 tests/test_tokendagger_vs_tiktoken.py --tokenizer llama
    • python3 tests/test_tokendagger_vs_tiktoken.py --tokenizer mistral
    • python3 tests/performance_benchmark.py --tokenizer llama
    • python3 tests/performance_benchmark.py --tokenizer mistral
    • python3 tests/code_performance_benchmark.py --tokenizer llama
  • ベンチマーク結果 ：コードトークナイズで 4.02倍高速化 を記録

インストール手順

  • PyPIからの推奨インストール
    • pip install tokendagger
  • 開発用インストール
    • git clone git@github.com:M4THYOU/TokenDagger.git
    • sudo apt install libpcre2-dev
    • git submodule update --init --recursive
    • sudo apt update && sudo apt install -y python3-dev
    • （テスト実行には）pip3 install tiktoken

依存ライブラリ

  • PCRE2 ：Perl Compatible Regular Expressions 2
  • Python3-dev ：Python開発用ヘッダ
  • tiktoken ：互換性テスト用

TokenDagger開発背景と技術的ポイント

  • TikToken （Llama 3、Mistral、GPT-3.*等で使用）の高速互換実装
  • C++17 でゼロから実装し、Pythonバインディングで呼び出し
  • BPE語彙・特殊トークンルール もTikTokenと完全互換
  • LLM内部構造の学習 を目的に再実装
  • TikToken のPython/Rust実装のプロファイリング結果から、正規表現処理がボトルネックであることを発見
  • パフォーマンス向上の主因 ：
    • a) JITコンパイル正規表現エンジン の利用による高速化
    • b) 特殊トークンの正規表現照合省略 によるアルゴリズム簡素化
  • ベンチマークコード も同梱、再現性確保
  • 主な成果 ：
    • コードサンプルのトークナイズで 4倍高速化 （シングルスレッド）
    • 1GB自然言語テキストで 2-3倍スループット向上

利用シーン・推奨ユーザー

  • 大規模言語モデル入力前処理 の高速化
  • コードや自然言語の大規模バッチトークナイズ 用途
  • OpenAI TikToken を既存で利用している開発者・研究者
  • LLM内部実装の学習・検証 を行いたい技術者

まとめ

  • TokenDagger は、 TikToken の完全互換かつ大幅な高速化を実現
  • 大規模テキスト処理やLLM前処理 でのパフォーマンス改善に最適
  • インストールや導入も容易、既存コードの置き換えもシンプル
  • ベンチマーク・テストコード も充実、性能検証も容易

Hackerたちの意見

パフォーマンスを大幅に向上させるドロップインの置き換えを作るって、なんか美しいよね。ScyllaDBが思い浮かぶな。

└

そうだね。そうじゃなきゃ誰も使わないと思ったよ。

いいね！短期的には、AI/MLインフラの一部をC++でコーディングすることで、かなりのパフォーマンス最適化ができると思う。リライトじゃなくて（絶対にやめて！）、ドロップインで重要なボトルネックを直す感じ。誰かがC++で何かを出してるのを見ると（中国のエンジニアが得意みたい）、しっかりしたエンジニアリングのトレードオフがあって、劇的な改善が見込めると思う。

└

同意だね。昔のメンターがソフトウェア開発を見つめるいい方法を教えてくれたんだ：1. 動くようにする。2. 速くする。3. きれいにする。トランスフォーマーやLLMはかなりうまく動くように開発されてきたと思う。今はパフォーマンス面での大きな進展がある段階にいる気がする。

└

そういえば、Pythonから完全に離れようぜ。長い目で見れば、MLエンジニアが慣れてるからってだけで選ぶのは意味ないよね。

└

まあ、そうだね。ボトルネックはトークン化じゃなくて、実際のCUDAカーネルを実行するところにあるんだ。Python自体はほとんどオーバーヘッドがないし。（主にPythonで書かれてるVLLMを見てみて。）だから、（deepseekみたいに）「C++で書き直す」って言ってる人たちは、効率を上げるためにCUDAカーネルを再実装してるだけなんだよね。

ここでWASMバインディングが見られたらクールだね。https://github.com/dqbd/tiktoken それか、純粋なJS実装の「b」からのスピードアップもいいかも。

これってBPEクレート[1]と比べてどうなの？BPEの主な売りは、テキストを段階的に再トークン化できることだけど、tiktokenよりも速いんだよね。[1] https://crates.io/crates/bpe

└

次はインクリメンタルな再トークナイゼーションに取り組んでる。その後、このクレートに対してもベンチマークを実行するつもり。

他のLLM用のローカルトークナイザーを手に入れる方法ってある？例えば、GeminiはトークナイザーのリモートAPIしか提供してないけど、これはプロプライエタリなの？たくさん呼び出して、トークンマッピングを効率的に推測できるかな？

└

ジェミニはSentencePieceを使ってると思ってた。 https://github.com/google/sentencepiece

└

ジェミニはSentencePieceを使ってるよ[1]、そして独自のジェミニモデルはGemmaと同じトークナイザーの語彙を共有してる[2, 3, 4]。大手の西洋AIラボ（OpenAI、Anthropic、Google）の中で、ローカルトークナイザーがないのはClaude 3以降のAnthropicだけだね。[1] https://github.com/google/sentencepiece [2] https://github.com/googleapis/python-aiplatform/blob/main/ve... [3] https://storage.googleapis.com/deepmind-media/gemma/gemma-2-...: 「私たちは大きなジェミニの語彙（256kエントリー）を引き継いでいます。」 [4] https://storage.googleapis.com/deepmind-media/gemma/Gemma3Re...: 「私たちはジェミニ2.0と同じトークナイザーを使っています。」

└

多くのモデル特有のトークナイザーにはリファレンス実装があるよ([0], [1])。その背後にはSentencePieceやバイトペアエンコーディング（BPE）みたいなコアアルゴリズムがある。tiktokenとTokenDaggerはBPEの実装だね。ラッピングされた「トークナイザー」は、主に語彙の特異性や特別なトークンの扱いに関わってる。このプロジェクトでは、こういったモデル特有の特性をライブラリに組み込む価値があると思う。ちょっとしたパフォーマンス向上が見込めるし、統合もしやすくなると思う。新しいモデルに追いつくのもそんなに大変じゃないはずだし。トークナイザーはあまり頻繁には変わらないからね。[0] https://github.com/meta-llama/llama-models/blob/01dc8ce46fec... [1] https://github.com/mistralai/mistral-common/tree/main/src/mi...

いいね！tiktokenに対するテストで見た語彙フォーマットの変換要件をなくすことってできる？詳細を考えずに完全互換のドロップイン置き換えがあればいいな。それと、逆に動作する例もあれば嬉しい：通常通りにtiktokenを初期化して、標準トークナイザーの特別な拡張を含めて、それを使って新しいtokendaggerを初期化して、結果の同一性をテストする感じ。

└

あ、いい指摘だね。今すぐ更新するよ。

└

よし、0.1.1は本当に置き換え可能なバージョンになったはず。近いうちにいくつか例を書いてみるね。

あなたのパフォーマンス改善をtiktoken自体に反映させることって可能なのかな？

└

多分やるよ。最初はちょっと躊躇ったけど、PCRE2を依存関係に追加すると既存のプロジェクトに影響が出るかもと思ってね。これについては、他のパフォーマンス改善と一緒にクローズドPRでちょっと話し合われた気がする。

いい仕事だね！前に似たようなことを試したことがあるよ： https://github.com/kevmo314/tokie そこで気づいたのは、実行コストはプレトークナイゼーション（正規表現）がかなり支配してるってこと。正規表現をより早く実行する方法を見つけたのはすごいけど、正規表現エンジンを入れ替えて、実際のBPEはtiktokenに任せるパフォーマンスを比較してみた？それが上流に持っていけるか気になるな。

└

いいね！Tiktokenをメンテナンスしてる人に連絡して、このことについて話そうと思ってる。

https://github.com/huggingface/tokenizers/ とパフォーマンスを比較してもらえる？ tiktokenのREADMEにあるベンチマークはかなり古いみたいだから、助かるよ。

└

個人的には、tiktokenはhuggingfaceのトークナイザーよりもずっと遅いと感じてる。なんでかはわからないけど、tiktokenを深く掘り下げたことはないし、HFのRustトークナイザーをヘビーユーザーだから。

LLMのパフォーマンスに詳しい人、これが全体のパフォーマンスにどれくらい重要か教えてくれない？ トークナイザーの最適化に興味があって、まだ測定はしてないんだ。一般的にはマトリックスの掛け算がコストの大部分を占めると思ってたけど、コメントの反応を見てちょっと励まされたよ。

└

テキストのトークン化は、リクエストを処理するための全体の計算の中ではほんの小さな部分に過ぎないよ。とはいえ、ペタバイトのデータを扱ってるなら、速いものを持っておくのは悪くないよね。

└

トークン化は通常CPUで行われていて、トレーニングや推論のボトルネックになることはほとんどないよね。GPUカーネルが時間的には圧倒的に優位だから、例外はごく小さなモデルくらいかな。だから、トークン化の遅延は基本的に「隠す」ことができて、CPUが次のバッチを準備している間にGPUが現在のバッチを終わらせる感じだね。