トークナイゼーション――生のテキストを言語モデルが実際に消費する数値のトークン列に変換する前処理ステップ――は、MLスタックの中で最もプロファイリングされることのないコンポーネントの一つです。学習データセットがテラバイトやペタバイト規模に成長するにつれ、この変換にかかる時間はデータ準備パイプラインにおける実質的なボトルネックになり得ますが、最適化の対象となることはほとんどありません。スタンフォード大学の博士課程学生Marcel Rød氏がMITライセンスで公開した新しいライブラリ「Gigatoken」は、この見落としには代償が伴うと主張します。同ライブラリは、単一マシンでギガバイト/秒レベルのテキストエンコードを実現し、すでにマルチスレッドRustで実装されているベースラインを上回る性能を示しています。

ベンチマーク結果

144コアのAMD EPYC 9565デュアルソケットシステム上で、11.9 GBのowt_train.txtコーパスを使用したGPT-2トークナイザーのベンチマークにおいて、Gigatokenは24.53 GB/sでデータを処理します。同一ハードウェア上で、OpenAIのtiktoken――GPTモデル用のテキストエンコードに使用されるライブラリ――は36.0 MB/s、HuggingFace tokenizers――オープンソースMLエコシステム全体で事実上の標準トークナイザー――は24.8 MB/sを記録しており、それぞれ681倍および989倍の性能優位性を示しています。

この高速化はアーキテクチャを問わず一貫しています。16コアのApple M4 Maxでは、同一のGPT-2ワークロードが8.79 GB/sで実行され、HuggingFace tokenizersより1,268倍、tiktokenより140倍高速です。コンシューマー向けのAMD Ryzen 7 9800X3Dでは、Gigatokenは6.27 GB/sを達成し、それぞれのベースラインに対して106倍および68倍の高速化を示しています。

Gigatokenとは

Gigatokenは、Rustで記述されPythonバインディングを備えたバイトペアエンコーディング（BPE）トークナイザーです。BPEは現代のLLMにおける支配的なサブワードトークナイゼーションアルゴリズムであり、GPT、Llama、Qwen、Mistralなどのファミリーで使用されています。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が含まれます。

Gigatokenは2つの使用モードを提供しています。互換モードは既存のHuggingFaceまたはtiktokenトークナイザーをラップし、スループットを犠牲にしながら出力の完全な一致を保証します。Rød氏はHacker News上で、互換モードは使用状況に応じて約200〜300倍の高速化をもたらすと述べています。これは、リスト作成や文字列からバイトへの変換においてPythonオーバーヘッドが依然として発生するためです。Rustがファイルを直接読み取るネイティブGigatoken APIが、公開ベンチマーク数値のソースです。

技術的アプローチ

性能向上は、より高速なBPEマージループからもたらされるものではありません。むしろ、ほとんどのトークナイザーがすでに解決済みと見なしている2つの領域から生じています。

プレトークナイゼーションの最適化

ほとんどの実装はプレトークナイゼーションを正規表現エンジンに委譲しています。Gigatokenはプレトークナイザー全体を手書きしています。プレトークナイザー最適化ログは、100 MBのOpenWebTextに対するシングルスレッドGPT-2プレトークナイザーのスループットを追跡しており、詳細な進歩を示しています。

• fancy-regexベースラインは約47 MiB/sで動作します。
• 手書きのステートマシンは約380 MiB/sに到達します。
• NEON SIMD組み込み関数を使用したwinnowコンビネータ実装は462 MiB/sを達成します。

さらなる最適化は、winnowを直接のIteratorに置き換え、O(1)の先頭バイトディスパッチ用に256バイトのクラスルックアップテーブルを追加し、NEON組み込み関数からSWAR（SIMD Within A Register）に切り替えることで実現しました。SWARは8バイトをu64としてロードし、分岐なし演算を使用してすべての8バイトの文字プロパティをチェックします。これにはアーキテクチャ固有の組み込み関数は必要ありません。これによりスループットは830 MiB/sに向上しました。

最終的な最適化ステップは、デュアルカーソルによる命令レベル並列性（ILP）の活用で、1,049 MiB/sに到達しました。重要な洞察は、約840 MiB/sでのボトルネックがスループットではなくレイテンシであったことです。各トークンの終了位置は前のトークンに依存し、約25〜27サイクルの直列チェーンを形成します。安全な分割ポイントから2つの独立したカーソルを実行することで、アウトオブオーダー実行エンジンは両方のストリームをアイドル状態の実行ポートにまたがってインターリーブできます。

プレトークナイザー単体での正味効果：winnow + NEONベースラインに対して2.27倍、正規表現実装に対して22.3倍。

プレトークンキャッシュ

以前に出現した単語は、再計算するのではなく、エンコードされたトークンがルックアップされます。Rød氏は、キャッシュが急速に成長し、プレトークン分布がロングテール パターンに従うため、これを実際に実装するのは困難だと述べています。さらに、Pythonとの相互作用は最小限に抑えられ、スレッドは互いに最小限の相互作用で設計されています。

最適化ログは、うまくいかなかったアプローチも率直に記録しています。#[cold]と#[inline(never)]を使用したホット/コールド分割は580 MiB/sに劣化し、リバートされました。これは、インラインバリアがLLVMによるASCIIとUnicodeの統合ループの最適化を妨げたためです。SWAR遷移カウントを使用した2パス分類バッファはアルゴリズム的には正確でしたが、追加のメモリトラフィックが分岐削減のメリットを上回り、354 MiB/sで動作しました。プロファイルガイド付き最適化は測定可能な効果がなく、内側のループがすでに分岐なしであり、単語境界の分岐がデータ依存しているためです。

ベンチマーク方法論

この比較は厳密に同等条件ではありません。Gigatokenは分割されていないファイル全体をエンコードし、独自にドキュメント境界を見つけて自動的に並列化します。HuggingFace（encode_batch_fast）は最初の100 MBで、tiktoken（encode_ordinary_batch）は最初の1 GBで評価され、どちらも<|endoftext|>で事前分割されています。ベースラインはキャッシュを実装していないため、スループットは一定に保たれます。すべての測定値は、並列処理を有効にした新規プロセスを使用した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の高速化は、x86およびARMアーキテクチャの両方、およびサポートされているすべての23のトークナイザーファミリーにわたって維持され、単一の最適化された構成に限定されるものではありません。ただし、SentencePieceボキャブラリの高速化は1,000倍規模ではなく7〜22倍であり、WordPieceはサポートされていません。互換モードは、ネイティブの完全な高速化ではなく、約200〜300倍でHuggingFaceの出力完全一致を維持します。

GitHubリポジトリおよびベンチマークエクスプローラーが公開されています。