文字を1つずつ見るのをやめた tokenizers v1 が最大30倍速く動く

3行まとめ

• Hugging Face が tokenizers v1 の候補版を公開しました
• トークンIDは v0.23 と変わらず、1スレッドで3〜30倍速くなりました
• 正規表現での分割をやめ、処理済みの単語は計算し直しません

何が起きたか

Hugging Face が2026年9月21日、tokenizers のバージョン1候補版を公開しました。tokenizers は、文章をモデルが読む整数の並びに変換する Rust 製のライブラリです。

出すトークンIDは変わりません。Arthur Zucker ら4人の告知記事によると、v1 は v0.23 と同じIDを返します。API も語彙もマージ順位も据え置きました。

変わったのは速さです。対象の10系統のモデルを Apple M4 Max の1スレッドで測ると、v0.23 の3〜30倍の速さで処理します。伸びが一番小さかったのが t5-base、一番大きかったのが gpt2 です。

ワーカーを8本まで増やしたときの伸びは、比例したときの76%でした。

なぜ難しい・何がすごいか

Hugging Face は、トークナイザトークナイザ文章を、モデルが読む整数の並びに変換する部品。正規化・事前分割・モデル・後処理の4段階で動きます。用語集でこの語を見るがこれまで機械学習の処理の足を引っ張る場所ではなかったと書いています。計算量で見ればモデル本体の処理のほうが重く、トークン化は軽い処理です。その前提が崩れ始めました。

モデル側が速くなり、流す量が増えたためです。巨大なデータセットで学習するとき、同時に届くリクエストをさばくとき、長い入力を何度も処理するとき。

CPU側のトークン化が追いつかず、GPU はデータを待って空転します。記事は、GPU が CPU のトークン化を待って遊ぶ状態を無くしたいと書いています。

v1 はここだけを削りました。出力を1つも変えずに、待ち時間を短くしています。

たとえ話

分割のやり方が、区切りを探す読み方ごと入れ替わりました。これまでは正規表現エンジンが、文字を1つずつ前に進めながら区切り位置を判定していました。

v1 の bitcannon は、入力のバイトを並んだビットの流れとして見ます。1回のレジスタ演算で64バイト分の区切りを決めます。1行ずつ指で追う読み方から、ページを一目で見る読み方に変わりました。

用語ミニ辞典

• トークナイザ: 文章を、モデルが読む整数の並びに変換する部品。正規化・事前分割・モデル・後処理の4段階で動きます。
• プレトークン: 事前分割の段階で作る断片。マージはこの内側でだけ起き、境界を越えません。
• BPE（byte pair encoding）: プレトークンのバイトから始め、順位が一番高い隣り合う組をつなぐ操作を繰り返す方式。今回測った10系統のうち8系統が使います。残る2系統は WordPiece と Unigram です。
• SIMD（single instruction, multiple data）: 1つの命令を多数のバイトへまとめて適用する CPU の命令。
• ワードキャッシュ: プレトークンのバイトから完成したIDへの対応を、スレッドごとに覚えておく表。同じ単語の2回目以降はマージを飛ばします。

技術者向けの深掘り

マージループの書き換えが、bitcannon と並ぶもう一方の柱です。旧実装は呼び出しごとにメモリを確保し、プレトークンプレトークン事前分割の段階で作る断片。マージはこの内側でだけ起き、境界を越えません。用語集でこの語を見るごとに優先度付きキューを作り直していました。v1 は呼び出し元が持つスクラッチバッファを使い回し、シンボルをフラットな配列に置いて位置で隣同士をつなぎます。

候補のペアは64ビットの整数1つに詰め込み、マージ順位を上位ビットへ置きました。比較は整数どうしの比較で済みます。「ここにマージは無い」を最大値で表すため、ループは分岐なしに次のマージへ進みます。

速くなる範囲には条件があります。bitcannon が正規表現を置き換えた分割パターンは5つです。GPT-2・cl100k・o200k・Tekken・DeepSeek が対象です。

この5つに当てはまらないトークナイザは正規表現の経路のまま走り、高速化を受け取りません。3倍から30倍という幅は、この差から生まれています。

測り方も記事が開示しています。全エンジンが同じ計時ループを回し、語彙の読み込みは encode の外で計りました。出力IDの FNV-1a ハッシュが基準と完全一致することも確かめています。

ワーカーは8つの別々の物理コアへ固定しました。見出しの数値は、同じ文書を繰り返す条件ではなく、別々の文書を流す条件で測っています。

候補版は crates.io にあります。

cargo add tokenizers --pre
cargo add tokenizers --pre --no-default-features --features http

これは自分に関係ある？

• Rust から呼ぶ人: 呼び出すAPIは今までと同じで、入れるビルドだけが変わります。学習機能は既定で有効なフィーチャーの後ろにあり、C++依存を連れてきます。エンコードだけ要るなら、上の2行目で外せます。
• Python から使う人: Python バインディングは同じコードを包んでいます。ただし呼び出しごとのオーバーヘッドが乗り、その分はこの記事の測定に入っていません。
• AIを使うだけの人: 出てくる答えは変わりません。トークンIDが同じなので、モデルの応答も同じです。変わるのは、同じ処理を終えるまでの時間です。