Stanford学生が高速BPEトークナイザー「Gigatoken」公開

言語モデルの構築において、トークナイゼーションはほとんど誰も詳細を分析しない部分です。スタンフォード大学の博士課程学生であるマルセル・ロッド氏が MIT ライセンスの下で公開した「Gigatoken」は、この過ちを正すものだと主張しています。このライブラリは単一のマシン上で秒間ギガバイト単位の速度でテキストエンコードを実現し、すでにマルチスレッド化された Rust ベースのベースラインを上回っています。

GPT-2 トークナイザーのベンチマーク結果は驚異的なものです。144 コア構成の AMD EPYC 9565 デュアルソケット環境で、11.9 GB の「owt_train.txt」コーパスを評価したところ、Gigatoken は秒間 24.53 GB という圧倒的な処理速度を記録しました。同じハードウェア構成において、OpenAI の tiktoken は 36.0 MB/s、HuggingFace トークナイザーは 24.8 MB/s に留まります。これは、それぞれ 681 倍、989 倍の性能差を示す結果です。

Apple M4 Max（16 コア）では、同じ GPT-2 ワークロードで秒間 8.79 GB を達成し、HuggingFace トークナイザーに対しては 1,268 倍、tiktoken に対しては 140 倍の高速化を実現しました。また、一般消費者向けの AMD Ryzen 7 9800X3D では秒間 6.27 GB を記録し、それぞれ 106 倍、68 倍の性能向上となりました。この速度向上は、特定の CPU や語彙に依存した一時的な現象ではありません。

Gigatoken とは

Gigatoken は、Rust で書かれ Python バインディングを備えたバイトペアエンコーディング（BPE）トークナイザーです。PyPI には「gigatoken」という名前で公開されており（バージョン 0.9.0、2026 年 7 月 21 日リリース）、pip install gigatoken でインストールできます。リポジトリのコード構成は Rust が約 66%、Python が約 33% です。

公開されたベンチマークでは、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 など、計 23 の異なるトークナイザーファミリーに対応しています。

利用方法は主に 2 つあります。1 つ目は互換性モードで、既存の HuggingFace や tiktoken トークナイザーをラップし、出力結果を完全に一致させます。ただし、スループットには実質的なコストがかかります。著者（Marcel）は Hacker News で、このモードでもリスト作成や文字列からバイトへの変換に伴う Python のオーバーヘッドが発生するため、利用状況にもよりますが 200〜300 倍程度の高速化になると述べています。

もう 1 つがネイティブな Gigatoken API です。こちらは Rust がファイルを直接読み込むため、公開されている数値の根拠となっているのがこのモードです。

インタラクティブなベンチマークエクスプローラー

以下のすべての数値は、リポジトリ内のベンチマークセクションとプレトークナイザー最適化ログから抽出されたものです。CPU を切り替えて最適化履歴を確認したり、ご自身のコーパスがどれくらいの時間を要するか見積もったりできます。

(function(){var f=document.getElementById("gigatoken-explorer-frame");if(!f)return;
window.addEventListener("message",function(e){
  if(e&&e.data&&typeof e.data.gigatokenHeight==="number"){f.style.height=e.data.gigatokenHeight+"px;";}
});})();

どうやって実現しているか

この性能向上は、より優れた BPE マージループによるものではありません。むしろ、多くのトークナイザーが「解決済み」と見なしている 2 つの領域からのものです。

(1) プリートークン化：ほとんどの実装では、これは正規表現エンジンに任されています。しかし Gigatoken はこれを自前で実装しています。その最適化ログには、OpenWebText の 100 MB を対象としたシングルスレッド GPT-2 プリートークナイザーのスループット推移が記録されており、その過程は非常に示唆に富んでいます。

「fancy-regex」ベースラインでは約 47 MiB/s ですが、手書きの状態機械では約 380 MiB/s に達します。さらに NEON SIMD インストリクションを用いた winnow-combinator 実装では 462 MiB/s を記録しました。

ここで winnow を直接の Iterator に置き換え、最初のバイト dispatch を O(1) で行うための 256 バイト分のクラスルックアップテーブルを追加し、NEON インストリクションから SWAR（SIMD Within A Register）へ切り替えると、スループットは 830 MiB/s まで向上します。SWAR は 8 バイトを u64 として読み込み、分岐のない算術演算でそのすべてが文字かどうかを同時にチェックします。これにはアーキテクチャ固有のインストリクションは不要です。

最終段階では、デュアルカーソルによる ILP（命令レベル並列性）の活用を行い、1,049 MiB/s を達成しました。ここで得られた洞察は、約 840 MiB/s でボトルネックになっていたのがスループットではなくレイテンシだったという点です。各トークンの終了位置は直前のトークンに依存するため、約 25〜27 サイクルの連続処理チェーンとなっていました。安全な分割点から独立した 2 つのカーソルを走らせることで、アウト・オブ・オーダー実行エンジンが両方のストリームをアイドル状態の実行ポートに割り込むことが可能になります。

この結果、プリートークナイザー単体でも、winnow＋NEON ベースラインに対して 2.27 倍、正規表現実装に対しては 22.3 倍の性能向上となりました。

(2) Pretoken キャッシュ：一度見た単語のエンコード済みトークンは、再計算せずにキャッシュから参照します。著者（Marcel）は、これが実務では難しいと指摘しています。キャッシュが急速に肥大化することや、事前トークンの分布がロングテールになることが理由です。さらに、Python との相互作用を最小限に抑え、スレッド間も可能な限り独立して動作するように設計されています。

最適化ログには、何が失敗したかについて異例ほど正直な記述があります。#[cold] と #[inline(never)] を使ったホット/コールド分割は、インラインバリアが LLVM による ASCII と Unicode のループ統合最適化を阻害したため、580 MiB/s に後退し、結局取り消されました。SWAR による遷移カウントを用いた2パス分類バッファはアルゴリズム上は正しいものの、追加のメモリアクセスが分岐節約を上回ったため、354 MiB/s という速度に留まりました。プロファイル指向最適化（PGO）には目に見える効果はありませんでした。内側ループがすでに分岐なしであり、単語境界における分岐もデータ依存であるためです。

ベンチマーク手法に関する注記

比較は厳密には同等条件ではありません。Gigatoken は分割されていないファイル全体をエンコードし、独自のドキュメント境界を検出して自動的に並列化します。一方、HuggingFace（encode_batch_fast）は最初の 100 MB を対象に評価され、tiktoken（encode_ordinary_batch）は最初の 1 GB を対象に評価されます。これらは両方とも pre-split 済みです。ベースラインではキャッシュを省略しているため、スループットは一定のままです。測定値は、並列化を有効にした新鮮なプロセスで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 倍）で処理します。これらの数値は確かに大幅な改善ですが、 headline で紹介された BPE の性能にはまだ一桁低い水準です。

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 トークナイザーより 989 倍、tiktoken より 681 倍高速です。
• この速度向上は x86 と ARM の両アーキテクチャ、そして 23 のトークナイザーファミリー全体で確認されており、特定のチューニング設定に依存しません。
• 性能の源泉は、手書きの SWAR プリトークナイザーとプリトークンキャッシュによるものであり、BPE マージループ自体を高速化したものではありません。
• SentencePiece 語彙では 7〜22 倍の高速化が得られますが、1,000 倍には届かず、WordPiece はサポートされていません。
• 互換性モードでは HuggingFace と完全な出力整合性を保ちつつ、約 200〜300 倍の速度向上を実現します（最大速度ではありません）。

詳細は GitHub リポジトリとリリーススレッドをご覧ください。本研究のすべての功績は、このプロジェクトの著者に帰属します。