Hugging Face、高速化に焦点の「tokenizers v1」リリース候補を公開 — v0.23と同一ID、数十倍高速化も

Hugging Faceは2026年9月21日、Rust製トークン化ライブラリ「tokenizers」の次期メジャーバージョン「v1」に関する解説記事を公開した。モデルの前処理でテキストを整数ID列に変える同ライブラリについて、出力の互換性を保ったまま性能刷新に注力した内容だ。リリース候補（プレリリース）はcrates.ioで提供されている。以下は同記事で確認できる範囲の整理であり、速度の数値は同記事の主張として扱う。

v1とは何か — 互換性を保ち、中身を刷新

• 互換性: v1はv0.23と同じトークンIDを生成する。API、語彙、結合（マージ）順位の維持を目標とした
• 対象の広さ: BPEに特化せず、v0.23が読み込めたものは引き続き読み込む。測定対象の10モデル系列のうち8系列がBPE、残り2系列がWordPieceとUnigram
• パイプライン: 正規化→事前トークン化→モデル（ID変換）→後処理の4段階。今回の作業の中心はモデル段階
• 高速化の主張: v0.23比で「しばしば数十倍（often by tens of times）」速いとしている（同記事の主張。独立した検証ではない）
• 測定: シングルスレッド、マルチスレッド、スレッド数スケーリング、モデル別、言語別、レイテンシ、デコードスループット、メモリヒープ、クレートサイズを比較。測定はtokbenchリポジトリから実行し、自分のハードウェアで再実行するコマンドも用意されている

高速化の柱 — ワークスペース分割と符号化パスの刷新

• ワークスペース分割: 単一クレートをtk-encode（必須ランタイム）、tk-serialize、tk-convert、tk-trainに分割し、用途に応じてリンクするものだけを選べる
• ビットストリーム分割: 符号化パスの正規表現ベースの分割を、GPT-2・cl100k・o200k・Tekken・DeepSeekをカバーするビットストリーム操作に置換
• WordCache: 処理済みの事前トークンのトークンIDを再利用するキャッシュ
• 探索・マージ構造の刷新: FlatCache、MPHF RankStore、増分マージ、BucketVocabStoreの導入
• メモリ再利用: 一時的なモデル状態をスクラッチバッファに移し、呼び出しごとの確保を避ける
• パイプラインとバッチ処理: 後処理をSTAGE_POSTとして公開、複数スパン一括のモデル呼び出し、デコードの直接書き込み・並列バッチ化、role_to_token対応、Node.jsバインディングなど
• 記事は、gigatoken・tiktoken・kitoken・tokie・fastokens・wordchipper・ai-tokenizerなど、オープンソースの高速トークナイザの取り組みから着想を得たと謝意を示している

導入方法と1.0.0に向けた位置づけ

• 導入: リリース候補は cargo add tokenizers --pre で導入できる。呼び出すAPIは従来と同じで、ビルド指定だけが変わる
• 学習機能: 学習は既定オンのfeatureの背後にあり、C++依存を伴う。符号化のみ使う場合は --no-default-features --features http で除外できる
• バッチ: 複数文書は encode_batch が複数コアにスケールする対象。記事のスケーリング測定もこの呼び出しを対象としている
• Pythonバインディング: 同じRustコードをラップするが、記事の測定値にはバインディングの呼び出しオーバーヘッドは含まれない
• 状態: 記事のベンチマークはリリース候補として実装済みの作業が対象。1.0.0に向けては、学習時検証でのtk-encode利用の統一などの残作業が列挙されている（詳細は同記事の「Progress Towards V1」を参照）
• 本記事では個別の速度数値を断定しない。用途・モデル・言語・ハードウェアで結果が変わるため、導入判断にはtokbenchでの手元測定を参照されたい

出典

• tokenizers v1: encode, decode and scaling, measured — Hugging Face Blog