⚡ GigaToken — トークン化を最大989倍にしたRust製BPE、ただし効くのは推論ではなくデータ側

「1000倍速い」という見出しは、まず疑ってかかる。今回のは、疑って分解した後にも面白さが残った。

GigaTokenは、言語モデルのBPEトークン化(テキストをトークンIDの列に変換する前処理)をRustで書き直したライブラリだ。作者はStanfordのPhD学生Marcel Rød。スタンフォードの有名なLLM構築講義CS336のTAで、授業でトークナイザを何度も書くうちに「これ、本気で最適化したらどこまで行くのか」をやり切ってしまったらしい。MITライセンスで公開され、HNで600ポイント、GitHubは2,000スターを超えた。

「989倍」の条件を先に言う

自己申告ベンチの数字はこうだ。AMD EPYC 9565(144コア)上でopenwebtextをGPT-2トークン化して24.53 GB/s。HuggingFace tokenizersが24.8 MB/sなので989倍、tiktoken比で681倍。比較対象は両方ともRust実装でマルチスレッド有効の条件だから、「Pythonと比べて速い」系の見せかけではない。

ただし989倍は144コアサーバーでの最良ケースで、README自身が正直に書いている通り、16コアのRyzen 7 9800X3Dでは50〜110倍程度に縮む。GPUは使っていない。純粋なCPU最適化——正規表現ベースのプリトークン化を手書きステートマシンに置き換えてSIMD命令(x86/ARM両対応)で回し、頻出語のトークンIDを積極的にキャッシュし、PythonとRustの境界越えを最小化する。地道な技の積み上げで、第三者による独立再現ベンチはまだない。

なお作者はHNで「コア実装は手書き、最終段の約4倍分の最適化はAI支援」と開示していた。この内訳を自分から言う人のベンチは、信用の初期値が高くなる。

アムダールの法則で殴られる、そして殴り返す

HNの最初の壁は身も蓋もなかった。推論の時間の99%はモデル本体で、トークン化は0.1%未満。そこが1000倍になっても全体は0.1%しか縮まない。アムダールの法則(高速化の効果は、その部分が全体に占める割合で頭打ちになる)そのものだ。

作者の返しが良かった。効かせる場所が違う、と。事前学習のデータ前処理では、数十億文書のトークン化が巨大CPUクラスタで数日回る規模になる。「学習開始前のトークン化待ち10〜15分の後に失敗した」という実務者の体験談や、「BERT運用で全実行時間の10%超がトークン化」という報告もスレッドに出ていた。GB/s級でテキストを流す世界では、前処理は立派なボトルネックだ。つまりこれは推論の道具ではなくデータエンジニアリングの道具で、そう読み替えた瞬間に1000倍の意味が変わる。

一番鋭い技術的指摘は正しさ側に刺さった。キャッシュに使う単一乗算ハッシュの42ビット出力は、メガバイト級の入力で衝突し誤ったトークンを返しうるという指摘だ。トークン化は「正しいのが当たり前」の工程なので、大規模データでの検証が済むまでは、本番投入前に手元のコーパスでHF実装と突き合わせるのが筋だろう。速さの検証より、正しさの検証。順番はいつもこっちが先だ。

前処理の速さは、試行回数に化ける

日本語圏にGigaTokenの記事はまだない。うちのパイプラインでトークン化がボトルネックになったことは一度もないので、自分はこれを使う側ではない。それでも紹介するのは、「全体の0.1%だから放置」とされてきた工程を989倍にする人がいて、その速さがデータ側の世界では前処理のやり直し回数=実験の試行回数に直結するからだ。数日が数十分になるなら、トークナイザの設計変更をもう2回試せる。速度の価値は短縮された時間ではなく、増えた選択肢のほうに出る。あなたの仕事で「遅いから1回しか試さない」ことになっている工程、ありませんか。