tokenizers v1がCPUエンコード経路を刷新、リリース候補版にはPython機能の不足が残る

Hugging Faceは9月21日、tokenizers v1リリース候補版のリファクタリングとベンチマークの結果を公開した。Apple M4 Maxの単一スレッドで、10のモデルファミリーを対象に実施したテストでは、テキストのエンコード速度がv0.23の3～30倍となった。これはRustのエンコード経路での結果であり、Pythonからの呼び出しコストは含まれていない。また、モデルの生成速度に直接換算することもできない。[公式技術解説](https://huggingface.co/blog/tokenizers-v1)

新版では、テキスト分割、メモリ割り当て、ライブラリの依存関係の3点でコストを削減した。bitcannonは対応する分割ルールをビットストリーム演算に書き換え、SIMDで複数のバイトを同時に処理する。BPEのマージ処理では一時バッファを再利用し、繰り返しのメモリ割り当てを避ける。これらの変更は既存の語彙表とtoken IDの維持を目指しており、同じ中国語の文章で消費するトークン数が減ることを意味するものではない。また、ライブラリは推論、シリアライズ、旧形式からの変換、学習の各モジュールに分割され、サービス側で必要な部分だけをリンクできるようになった。[プロジェクト概要](https://github.com/huggingface/tokenizers)、[リファクタリングの詳細](https://huggingface.co/blog/tokenizers-v1)

評価方法も数値に影響する。公開されているtokbenchは、まず出力されたtoken IDのハッシュを照合し、一致しない結果をランキングから除外する。また、語彙表の読み込み時間はエンコード時間の計測に含めない。コーパスを用いた実験では、中国語は事前分割後の断片の重複度が英語より低く、キャッシュの効果が言語によって変わることが示された。一部のコードやエージェントの実行トレースのコーパスは依然として非公開であり、完全に再現できる範囲は限られる。[テストフレームワーク](https://github.com/huggingface/tokbench)

アップグレードのリスクは、インターフェースの機能がどこまで揃っているかにある。開発チームはtoken IDと既存の使い方の維持を目指しているものの、現時点のREADMEでは、Pythonでの学習、パイプライン構成要素の変更、tokenizerの保存、ペア入力、文字位置のオフセット、スライディングウィンドウが未実装の機能として挙げられている。これらに依存するデータアノテーション、ファインチューニング、長文書の分割処理では、基本的なencodeが動作するだけで互換性があると判断することはできない。[リリース候補版とロードマップ](https://github.com/huggingface/tokenizers)

エンジニアリングの観点では、今回の更新はCPUでの前処理がすでにスループットを制限しているサービスで、特に検証する価値がある。チームはまずモデル、語彙表、バージョンを固定し、自前の繁体字中国語、コード、混合コーパスでtoken IDの一致を確認したうえで、バッチ処理のスループット、テールレイテンシ、メモリ使用量を測定するとよい。例えば、短いリクエストでは呼び出しコストが支配的になり得る一方、長文書では分割処理やキャッシュの挙動が影響する可能性がある。両者を分けて測定することで、リファクタリングがどの部分のボトルネックを解消したかが見えてくる。今後の注目点は、正式版でどの機能が実装されるか、そしてTransformersへの組み込み後に、サービスの処理全体で実際にどれだけ時間を短縮できるかだ。