tokenizers v1のリリース候補版、エンコード処理経路を刷新　M4 Maxのテストで前版の3〜30倍の速度に

Hugging Faceは9月21日、tokenizers v1のリリース候補版とベンチマークの解説を公開し、テキストをトークンに変換するCPU処理経路を刷新した。公式測定では、Apple M4 Max上で10のモデルファミリーを対象にシングルスレッドでテストし、v0.23の約3〜30倍のエンコード速度を記録した。これはトークン化段階の結果であり、モデルの生成スループットに直接換算することはできない。[技術解説](https://huggingface.co/blog/tokenizers-v1)

変更点の一つは、認識済みの事前トークン化ルールをbitcannonで処理することだ。SIMDのビット演算でテキストの分割境界を検出し、汎用正規表現エンジンの処理を減らす。BPEのマージ処理では一時バッファを再利用し、隣接する断片をインデックスで管理することで、繰り返しのメモリ確保やデータ移動のコストを削減する。未対応のルールは従来の正規表現処理経路を使うため、効果はモデルによって異なる。[実装解説](https://huggingface.co/blog/tokenizers-v1)

マルチスレッド処理では、共有の一時バッファプールをサブプールに分割し、各スレッドが自身のバッファとテキスト片のキャッシュを優先的に再利用することで、同じロックをめぐる競合を減らす。キャッシュは事前トークン化で得られた断片に対応するトークンIDを記憶し、同じ内容のマージ処理を省く。ただし、内容の重複率が低い場合、キャッシュ参照のコストに見合うだけのヒットが得られるとは限らない。関連するプルリクエストには、接続ごとに逐次エンコードするHTTPフロントエンドでは高速化しなかった事例も記録されており、ボトルネックが別の箇所にある可能性を示している。[並行処理の変更](https://github.com/huggingface/tokenizers/pull/2365)

公開されているtokbenchは、追試のための基盤を提供する。語彙の読み込みとエンコードを別々に計測し、出力IDをハッシュで照合して、結果が一致しないものをランキングから除外する。ドキュメントでは、テキストの重複度がキャッシュの効果を左右すること、中国語と英語のコーパスに同じ高速化の結論をそのまま適用できないことを明記している。一部の内部コーパスは公開されていないため、再現する際は入手可能なデータとバージョンを固定する必要がある。[テストフレームワーク](https://github.com/huggingface/tokbench)

中国語向けサービスでは、繁体字中国語、コードが混在するテキスト、長短のリクエストをテストに含め、エンコード時間、テールレイテンシ、サービス全体のスループットをそれぞれ測定し、特殊トークン、切り詰め、オフセット情報も照合するのが妥当な検証方法となる。既存サービスの処理時間の大半がモデルの計算やネットワーク待機に費やされている場合、トークン化の高速化がユーザーの体感遅延に与える効果は限定的かもしれない。これらは導入評価に向けた提案であり、公式に実証された中国語の性能数値ではない。

現時点のGitHubタグは引き続き`v1.0.0-rc.2`となっている。メンテナーは既存のAPIとトークンIDの維持を目指しているが、公式ベンチマークにはPythonの呼び出しラッパーによる追加のオーバーヘッドが含まれておらず、Transformersエコシステムとの統合も今後の作業に挙げられている。導入する場合は、まずリリース候補版のバージョンを固定してテストし、その後、正式版の互換性と実際のアプリケーションでの効果を確認していく必要がある。[リリース告知](https://github.com/huggingface/tokenizers/releases/tag/v1.0.0-rc.2)、[今後の計画](https://huggingface.co/blog/tokenizers-v1)