frontier AI

LLMのトークナイザ高速化は、どのモデルと入力で効くのか

2026/10/3

🤖 AIが執筆しています

二つの道具は、出力の番号を変えないことを設計の条件に置いた

専用コードやキャッシュを使っても出力のトークン番号を変えないことを、二つの道具の作り手は設計の条件として書いている。Hugging Faceは2026年9月21日の記事で、v1がv0.23と同じトークン番号を出すと書く¹。目標は、出力、API、語彙、マージの順位を保ったまま、改善できるところをすべて改善することだった¹。作り手は利用者から見た変化を「encodingは変わらない。同じ呼び出し、同じ番号」とまとめる¹。

キャッシュを使っても番号が変わらない理由も、同じ記事にある。BPEは、同じ前トークンに対して常に同じ番号を出す¹。同じ前トークンが2回目に現れたときに保存した結果を返しても、マージ処理をやり直した場合と同じ番号になる。

gigatokenも、既存の道具と同じ番号を出す設定を持つ。READMEは、HF tokenizersより約1000倍速く、呼び出し側のコードを変えずに差し替えられると主張する（作り手の主張）²。gigatokenは独自のAPI（Gigatoken API）に加えて、HF tokenizersやOpenAIのtiktoken⁵と同じ呼び出し方で使える互換モードを持つ²。互換モードについて作者は、HF tokenizersと出力が完全に一致するよう多くの労力を払ったと書く⁴。

gigatokenでは、出力の完全一致に速さの費用が伴う。作者は、互換モードで出力をHF tokenizersと完全に一致させたことが、速さに無視できない費用を伴うと書く。互換モードでも全般に速くなるが、Gigatoken APIほどではない⁴。作者はこの費用を互換モードという設定に限って書いており、完全一致を求める実装すべてに残るとまでは原典から言えない。

分割の段が速くなるのは、規則が専用コードの対象に入っているモデルである

分割規則は、トークナイザとともに出荷され、実行中には変わらない。そうであれば、どんな規則でも解釈できる汎用の正規表現エンジンを毎回動かす必要はない。Hugging Faceは、モデルが実際に使う規則に対して、同じ結果を出すコードを一度だけ手で書けると述べる¹。このコードが専用コードである。専用コードが使われるかどうかが入力の文章によらず決まるのは、どちらを使うかを決める規則がモデルの側で固定されているからである。

CPUには、1つの命令で複数のデータをまとめて処理する命令（SIMD命令）がある。手で書いたコードは、この命令を使える。v1の専用コードは、入力を1文字ずつ進んで調べる代わりに、1回の演算で64バイトをまとめて判定する¹。

専用コードが書かれているのは、一部の規則だけである。Hugging Faceによれば、専用コードを使えるかどうかは、規則を認識できるかどうかで決まる。少数の規則がバイト単位のBPEを使うモデルの大半を覆うが、規則がその中に無いトークナイザは正規表現エンジンでの処理に残り、分割の段の高速化を受けない³。リリース候補の時点で、v1の専用コードの対象はGPT-2、cl100k、o200k、Tekken、DeepSeekの規則である¹。

GPT-2の規則を使うモデルでは、どんな文章を入れても専用コードが切り分ける。五つの規則のどれも使わないモデルでは、どんな文章も正規表現エンジンが切り分け、分割の段は速くならない。

作り手は、計測結果の伸びの幅が大きく違う理由を、規則が対象に入っているかどうかに置いている³。同じ記事の結論節は、1スレッド・Apple M4 Maxで、v1が対応する10のモデル族においてv0.23の3〜30倍とする。下端はt5-base、上端はgpt2というモデルである¹。

対象外という状態は、対応が広がれば変わる。新しい規則は、専用コードが書かれるまで従来の正規表現エンジンで処理される。作り手が次の優先に挙げるのは対応するモデル族の拡大で、1.0.0までの作業として具体的に書くのは、ほかのモデルを新しいマージ処理の実装へ移すことである¹。

専用コードの対象の一覧は、道具ごとに違う。gigatokenのREADMEは、よく使われるトークナイザのほぼすべてに対応すると書く²。そのgigatokenにも、最適化が及んでいない方式がある。READMEは既知の問題として、WordPieceという別の方式にはまだ対応しておらず、SentencePieceというライブラリで作られたトークナイザは一般的なBPEほど最適化されていないと書く²。READMEの表では、GPT-2の規則の倍率が機械によって106倍から1,268倍であるのに対し、SentencePiece系の行の倍率はどの機械でも7〜22倍にとどまる²。

キャッシュが省くのは、同じ前トークンが繰り返した分だけである

v1は、一度処理した前トークンの結果を保存し、同じ前トークンが再び現れたときにマージ処理を省く¹。省ける回数の上限は、前トークンの総数から種類の数を引いた数である。どの種類も、初めて現れたときには1回マージ処理を要するからである。

入力が大きくなると、繰り返しの割合は上がりうる。Hugging Faceは、入力が大きくなるにつれ、単語の種類の数は単語の総数よりゆっくり増えうると書く。そうなれば、繰り返す単語が入力に占める割合が増える。ただし新しい単語も現れ続ける¹。新しく現れる単語は種類の数を増やし、省ける回数が総数に占める割合を押し下げる。割合が上がるか下がるかは、新しく現れる単語がどれだけ混ざるかで決まる。

繰り返しの少ない入力では、キャッシュの費用だけが残ることがある。作り手は、キャッシュは繰り返す前トークンが多い入力で最もよく効き、繰り返しの少ない入力は検索の費用を払っても当たりが少ないことがあると書く³。前トークンがすべて異なる入力では、前トークンの数だけ検索が加わり、マージ処理は1回も減らない。gigatokenの作者も、速さの主な出所として、分割の段を正規表現エンジンの代わりにSIMD命令で処理することと、一度見た前トークンの結果を引くキャッシュを挙げる²。作者は、キャッシュはすぐ大きくなり、前トークンの分布は裾が長いので、キャッシュは難しいとも書く²。READMEは既知の問題として、CJK（中国語・日本語・韓国語）の多いデータはトークン化がずっと遅く、多くの分割規則がこの場面でキャッシュを難しくすると書き、改善に取り組んでいるとも添える²。

倍率は、計測に使う入力の選び方でも変わる。キャッシュが省ける回数は、入力の中の繰り返しで決まるからである。作り手は、ベンチマークの設計の小さな違いがトークナイザの性能に大きな違いを生みうると書く。同じ文書を繰り返し処理する計測は、別々の文書を流す計測より速いことがあり、二つの計測が測っている仕事は違う³。同じ文書を2回続けて処理する計測では、文書がキャッシュに収まる大きさなら、2回目の前トークンはすべて保存済みである。作り手の見出しの数値は別々の文書を流した計測で、計測に使った文書の全体はキャッシュに収まらない大きさである³。

処理の回数に入っていない費用は、別に測る

v1の変更には、マージ処理や検索の回数を変えずに、1回あたりの費用を下げるものもある。Hugging Faceは、v1の速さが四つの変更の組み合わせから来て、それぞれが処理の流れの別の箇所で仕事を減らすと書く¹。四つのうち二つは、分割の段の専用コードとBPEの段のキャッシュである。

残りの二つは、マージ処理が使うメモリと、呼び出しの回数を変える。v1は、呼び出し側が用意した作業用の領域にマージ処理の作業データを置き、マージ処理のたびにメモリを確保し直すことをやめた¹。またv1は、BPEを実行する部品の呼び出しを、前トークンごとに1回から、前トークンのまとまりごとに1回へ減らした¹。

Pythonから呼ぶときの負荷は、作り手の計測値に入っていない。tokenizersをPythonから呼ぶための層は、計測されたものと同じコードを包んで作られているが、呼び出しごとの負荷が加わる。Hugging Faceの記事の計測値には、その負荷が含まれていない³。専用コードとキャッシュが減らすのも、分割の段とBPEの段の中の処理だけである。

gigatokenには、ファイルをRustの実装が直接読む呼び出し方がある。READMEによれば、Gigatoken APIを使うとRustの実装がデータを直接読み、オーバーヘッドを可能な限り省きつつ並列性を最大にできる²。ただし同じAPIでも、Pythonのデータ構造を渡せば、Pythonから読む負荷はかかると作者は書く²。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。