AI News HubLIVE
サイト内リライト3 分で読了

Gigatoken:Rust製BPEトークナイザー、24.53 GB/sでテキストをエンコード、HuggingFace Tokenizers比989倍高速

Gigatokenはスタンフォード大学の博士課程学生Marcel Rød氏がMITライセンスで公開したRust製BPEトークナイザーで、144コアのAMD EPYC 9565上でGPT-2トークン化を24.53 GB/sで実行。HuggingFace tokenizers比989倍、tiktoken比681倍の高速化を達成。高速化の要因は、手書きのSWARプリトークナイザーとプリトークンキャッシュであり、BPEマージループの改善ではない。23のトークナイザーファミリーをサポートするが、SentencePiece語彙では7~22倍の高速化にとどまる。互換モードでは正確な出力を維持しつつ約200~300倍の高速化。

ソースMarkTechPost著者: Asif Razzaq

トークン化は、言語モデリングスタックの中でほとんどプロファイリングされない部分です。スタンフォード大学の博士課程学生Marcel Rød氏がMITライセンスで公開したGigatokenは、この見落としを是正しようとするものです。このライブラリは、シングルマシン上でテキストを毎秒ギガバイト単位でエンコードします。比較対象となるベースラインは、すでにマルチスレッドのRustで書かれています。

GPT-2トークナイザーのベンチマークでは、144コアのAMD EPYC 9565デュアルソケット構成で11.9 GBのowt_train.txtコーパスを処理し、24.53 GB/sという驚異的な速度を達成しました。比較として、OpenAIのtiktokenは36.0 MB/s、HuggingFace tokenizersは24.8 MB/sであり、それぞれ681倍および989倍の性能差です。Apple M4 Max(16コア)では8.79 GB/s(HuggingFace比1268倍、tiktoken比140倍)、コンシューマ向けAMD Ryzen 7 9800X3Dでは6.27 GB/s(同106倍、68倍)を記録しており、特定のCPUや語彙に依存しない高速化が確認されています。

GigatokenはRustで書かれ、Pythonバインディングを持つBPEトークナイザーです。PyPIにgigatoken(バージョン0.9.0、2026年7月21日リリース)として公開されており、pip install gigatokenでインストールできます。リポジトリは66.2%がRust、33.3%がPythonで構成されています。公開ベンチマークでは23のトークナイザーファミリーをサポートしており、GPT-2、GPT-OSS、Llama 3~4、Qwen 2~3.6、DeepSeek V3/R1/V4、GLM 4/5、Kimi K2、Nemotron 3、Phi-4、OLMo 2/3、ModernBERT、Gemma、Mistralをカバーしています。

使用方法は2つあります。互換モードは既存のHuggingFaceまたはtiktokenトークナイザーをラップし、出力の完全一致を維持する代わりにスループットが低下します。作者のMarcel氏によると、互換モードではPythonのオーバーヘッド(リスト作成や文字列-バイト変換)が残るため、約200~300倍の高速化にとどまります。ネイティブGigatoken APIはRustが直接ファイルを読み取り、公表されている最高速度を達成します。

高速化の要因は、BPEマージループの改良ではなく、ほとんどのトークナイザーが解決済みとみなす2つの部分にあります。

(1) プリトークン化:ほとんどの実装はこれを正規表現エンジンに委ねますが、Gigatokenは手書きで実装しています。最適化の過程では、fancy-regexベースラインの約47 MiB/sから、手書きステートマシンで約380 MiB/s、winnowコンビネータとNEON SIMDで462 MiB/s、SWAR(レジスタ内SIMD)と直接イテレータ、256バイトのクラスルックアップテーブルの導入で830 MiB/s、さらにデュアルカーソルILP活用で1,049 MiB/sにまで向上しました。プリトークナイザー単体で、winnow+NEONベースライン比2.27倍、正規表現比22.3倍の高速化です。

(2) プリトークンキャッシュ:一度見た単語のエンコード結果をキャッシュして再利用します。キャッシュは急速に成長し、プリトークン分布はロングテールであるため実装は困難ですが、Pythonとのやり取りを最小化し、スレッド間の干渉を抑える設計となっています。

最適化ログには失敗した試みも正直に記録されています。ホット/コールド分割(#[cold]と#[inline(never)])は580 MiB/sに低下して元に戻され、2パス分類バッファとSWAR遷移カウントはアルゴリズム的に正しいものの354 MiB/sと低速でした。プロファイルガイド最適化は、内部ループがすでに分岐なしであり、単語境界の分岐がデータ依存であるため、測定可能な効果はありませんでした。

ベンチマーク手法の注意点:Gigatokenは分割されていないファイル全体をエンコードし、自動的にドキュメント境界を見つけて並列化します。一方、HuggingFace(encode_batch_fast)は最初の100 MB、tiktoken(encode_ordinary_batch)は最初の1 GBで評価され、いずれも事前分割されています。また、ベースラインはキャッシュを使用しないため、スループットは一定です。測定は、並列処理を有効にした新しいプロセスを使用し、3回のインターリーブラウンドの最良値を報告しています。

語彙タイプによる制約もあり、SentencePieceトークナイザーは部分的にしか最適化されていません。EPYC上では、Gemma 1が2.51 GB/s(7.3倍)、Gemma 3が3.43 GB/s(9.6倍)、CodeLlamaが3.47 GB/s(10.0倍)と、見出しのBPE性能より1桁低い値です。

独立した再現検証(KrabArena)では、4 vCPUのIntel Xeon VM(2.20 GHz)で174 MBのOpenWebTextスライスを使用し、Gigatoken 0.9.0の中央値277.8 MB/sを記録。tiktoken 0.13.0(10.62 MB/s)の26.2倍、tokenizers 0.23.1(3.33 MB/s)の83.4倍の性能を確認しました。全試行で35,356ドキュメントの検証に成功し、性能傾向がコア数に応じてスケールすることを確認しました。

Gigatokenは、144コアEPYC上でGPT-2を24.53 GB/sで処理し、HuggingFace tokenizers比989倍、tiktoken比681倍の高速化を達成。この高速化はx86とARMの両方、および23のトークナイザーファミリーで確認されています。SentencePiece語彙では7~22倍の高速化にとどまり、WordPieceは非対応です。互換モードでは出力完全一致を維持しつつ約200~300倍の高速化を実現します。詳細はGitHubリポジトリとリリーススレッドをご覧ください。