GigaToken - 言語モデルのトークン化を約1,000倍高速化

 (github.com/marcelroed)
3 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • さまざまなCPUと広く使われているトークナイザーに対応し、テキストをGB/s単位で処理するTiktokenおよびHuggingFace Tokenizersの代替ツール
  • 正規表現エンジンが担っていた事前トークン化をSIMDで最適化し、分岐・スレッド通信・Pythonとの相互作用を減らしつつ、過去に見た単語のトークンマッピングを効率的にキャッシュする
  • 11.9GBのOpenWebTextベンチマークで、GPT-2のスループットはAMD EPYC 9565で24.53GB/s、Apple M4 Maxで8.79GB/s、Ryzen 7 9800X3Dで6.27GB/sを記録
  • HuggingFace・Tiktoken互換モードは既存コードをほぼそのまま維持できるが、出力一致のコストにより性能は低下し、Rustがファイルを直接読むGigatoken APIが最大の並列性と最高速度を提供する
  • WordPieceとファイル出力はまだ未対応で、SentencePiece最適化とWindows検証も不足しているため、現時点ではBPEトークナイザーとLinux・macOSまたはWSL環境により適している

対応範囲と使い方

  • Gigatokenは言語モデル向けの高速トークナイザーで、現代的なx86・ARM CPUと、ほぼすべての一般的なトークナイザーを対象としている
  • pip install gigatokenでインストールし、独自APIとHuggingFace Tokenizers・Tiktokenの互換モードを提供する
  • 互換モードは既存のトークナイザーをラップし、それぞれ.as_hf()または.as_tiktoken()に変換する
    • HuggingFace Tokenizersと出力が正確に一致するよう、相当な処理を適用している
    • 互換性処理には無視しにくい性能コストがあり、独自APIの約1,000倍高速化には及ばないが、全体として既存実装より高速
  • 独自APIは"Qwen/Qwen3-8B"のようなHuggingFaceモデル名とTextFileSourceを受け取り、ファイルを直接エンコードする
    • Rust実装がデータを直接読み取り、不要なオーバーヘッドを避けて並列性を最大化する
    • Pythonのデータ構造を渡すと、Python側でデータを読むコストが残る

速度を高める実装

  • 最大の改善は、通常は正規表現エンジンに任せる事前トークン化をSIMDベースで直接高度化した点から来ている
  • 分岐を最小化し、すでに見た単語のエンコード済みトークンを探す事前トークンマッピングキャッシュを重点的に最適化している
    • キャッシュは急速に大きくなり、事前トークン分布がロングテール形状のため扱いが難しい
  • Pythonとの相互作用およびスレッド間通信を減らし、追加の性能を確保している
  • 特定のCPUや単一のトークナイザーに合わせた実装ではなく、現代的なx86・ARM CPUと複数のトークナイザーの組み合わせをそれぞれ最適化しており、結果もCPUとトークナイザー全般で一貫している

11.9GB OpenWebTextベンチマーク

  • AMD EPYC 9565 144コア環境でのGPT-2のスループットは24.53GB/sで、HuggingFace Tokenizersの24.8MB/sより989倍、Tiktokenの36.0MB/sより681倍高速
    • 主要なBPE系はおおむね約15.49〜24.00GB/sを記録
    • SentencePieceベースの項目は約2.51〜4.82GB/sで相対的に遅い
  • Apple M4 Max 16コアでGPT-2は8.79GB/sで、HuggingFace比1,268倍、Tiktoken比140倍
    • OLMo 2/3はHuggingFace比1,299倍、Qwen 2/2.5は1,105倍を記録
  • AMD Ryzen 7 9800X3D 16コアでGPT-2は6.27GB/sで、HuggingFace比106倍、Tiktoken比68倍
    • 主要なBPE系は約4.21〜6.09GB/s、相対的に最適化が進んでいない系統は約1.12〜2.84GB/s

測定条件と解釈

  • OWT（OpenWebText）はCommon Crawl文書を抽出して得られるテキストをおおよそ代表するものとして、ベンチマークデータに選ばれた
  • Gigatokenはファイル全体を事前に分割せずに処理するため、分割境界の探索と自動並列化まで直接実行する
  • 比較対象は<|endoftext|>基準で事前に分割されたデータを処理する
    • HuggingFaceのencode_batch_fastは先頭100MBを使用
    • Tiktokenのencode_ordinary_batchは先頭1GBを使用
    • どちらの実装もキャッシュしないため、処理中の速度はおおむね一定であり、この比較条件を使用している
  • Tiktokenの結果は公式対応トークナイザーにのみ含まれる
  • 各行は、語彙・マージ・事前トークナイザーが同一の、1つの固有トークナイザーを表す
    • Llama、Qwen、DeepSeek、GLM、Nemotron、Kimi、Phi、Gemma系の複数バージョンと派生モデルが同じトークナイザー行にまとめられている
  • 最も遅い項目は、Gigatokenでまだ十分に最適化されていないSentencePieceベースのトークナイザー

対応可否の検証と大規模処理

  • インストールなしでuvx --with tokenizers gigatoken benchコマンドにより、HuggingFaceモデルリポジトリのトークン化を検証し、時間を測定できる
  • GPT-2の検証例では、20,401件の文書の出力が一致した
    • Apple M4 Maxでは11,920.51MBを1.432秒、8,327.05MB/sで処理し、HuggingFaceより1,353.13倍高速だった
    • AMD EPYC 9565では同じデータを0.486秒、24,532.45MB/sで処理し、989.21倍高速だった
  • EPYCの処理率なら、130兆トークン規模のCommon Crawl全体を6.5時間未満でトークン化できる
  • 例ではStanford CS336 OWTサンプルを使用し、CLIはデフォルトで検証とHuggingFace比較にファイル先頭100MBを利用する
  • macOSでの初回実行はセキュリティ検査のためRustコードが遅くなる可能性があり、正確な測定にはコマンドを2回実行する必要がある場合がある
  • 出力不一致や遅いケースはGitHub Issueで報告するよう求めている

既知の制約

  • Pythonの反復処理はRustで実行するが、内部のCPythonバージョン別APIより遅いABI3を使用している
    • Pythonバージョン別の特化を計画しており、初期実験ではオーバーヘッドが支配的なケースで2倍高速になった
  • Gigatoken APIにはまだファイル出力シンクが実装されていない
  • WordPieceは対応していない
  • SentencePieceベースのトークン化は、一般的なBPEより最適化レベルが低い
    • 主にGoogleモデルとBERT系が使うという理由で、現時点での優先度も低い
  • Windowsでのテストが十分ではないため、現時点ではWSLの使用を推奨している

AIの使用範囲

  • コードベースの大部分はAIなしで直接書かれており、プロジェクトのGit履歴で確認できる
  • プロジェクト最終段階ではAIを次の作業に活用した
    • ユーザー向けAPIの実装
    • より多くのトークナイザー向けの事前トークナイザー一般化・移植と互換性拡大
    • パディング、切り詰め、Unicode正規化対応
    • AVX512・AVX2・NEON間のSIMD戦略の移植
    • 分岐削除と事前トークンキャッシュ階層の改善による最後の約4倍の性能向上
    • リファクタリングとコード再利用の改善

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの反応

  • 「コードの大半はAIなしで自分で書いたし、Git履歴でも確認できる」とのことで、人間のプログラミングは終わったという宣言も色あせる

  • 特定のCPUや1つのトークナイザーだけではなく、最新のx86・ARMと複数のトークナイザーの組み合わせ全体を過剰なくらい最適化して、一貫した性能を得たということ
    通常は正規表現エンジンに任せる事前トークン化をSIMDで直接最適化し、分岐を最小化し、さらに既出単語のエンコード結果を高速に引けるよう事前トークンのマッピングキャッシュも改善している。この分野のキャッシュはすぐ巨大化し、分布の裾も長いため扱いが難しい
    Pythonとの相互作用やスレッド間通信も最小化している

  • 創造的なプログラミングで信じがたい速度を出す simdjson を思い出す。広く使われれば電力・コスト・炭素排出を大きく減らせるので、Rustクレートも配布してくれたらうれしいし、必要なら自分も手伝いたい

    • トークン化が意味のあるボトルネックだったことはほとんどなく、JSONシリアライズもだいたい同じ。シリアライズやトークン化より、入出力やストレージのほうにずっと多くのエネルギーを使っている
      経済性や環境を考えるなら、リクエストのバッチ処理のほうが効果が大きい。最も高価なのはGPU利用率の低下で、処理をバッチ向きに整えれば現状のOAIでも50%節約できる。すべての応答が即時でなくてよいなら、一部は数日待ってもよく、ツール呼び出しはタイムアウトせず、LLM自体には壁時計時間というものがない

  • リポジトリをクローンして見てみたが、事前トークン化の正規表現置き換えとキャッシュ最適化は一般的にも有用なアプローチだ。トークン化コミュニティ全体がこうした高速化の秘訣を知りたがるはずで、本当に素晴らしい仕事

    • 近いうちにプロジェクトの技術解説と論文、発表動画を作ってDiscordにも共有する予定とのこと
    • 推論だけでなく、独自データセットを使った学習にも価値が大きく、しかもこれを一人でやり切った点も印象的

  • 素晴らしい成果だが、トークン化は通常、推論全体時間の 0.1%未満。ただし、トークン化自体が必要なアプリケーションには非常に有用そう

    • 推論方式によっては、トークン化の比率もかなり大きくなりうる。単一のB200で8B Qwen3を動かした初期計測では、gigatokenに切り替えると最初のトークン生成時間（TTFT） が入力長2,048で平均5.5%、8,192で8.4%、32,768で7.8%短縮した
      小さいモデルや高速なGPUほど効果は大きく、READMEに載せる前に追加検証が必要。ベンチマーク出典は fastokens
    • AIプラットフォームでは、その後のルーティングやレート制限などを決めるため、リクエスト初期に高速にトークン化する必要がある。リクエスト全体時間に占める比率が小さくても、効率は重要
    • トークン化は大半が直列処理なので、初期プロンプトが大きいと入力処理時間のかなりの部分を占めうる。モデル推論に渡した後は、すべてのトークンを並列処理できるため
    • 推論計算の1/1,000でも、規模が大きくなれば無視しにくい。Gartnerは2026年の推論支出を約280億ドルと見積もっているので、先の前提を当てはめると年間2,800万ドル規模になる
      出典: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
    • 特に小型モデルでは、最初のトークン生成レイテンシを大幅に下げられる。GroqやCerebrasのような推論プロバイダーにとっては、総スループットと同じくらいレイテンシも重要

  • 推論時点より、オフラインの事前学習データ準備でさらに有用に見える。学習コーパスとして数テラバイトのテキストをトークン化するときに時間とコストを節約でき、データセット調整の反復サイクルも短縮できる

  • 実行時間全体の0.1%を占める部分を 1,000倍高速化するために工学力を注ぎ込む姿こそ、いかにもソフトウェア開発者らしい振る舞い

    • Rustで高解像度のワードクラウドを約100msで作り、追加最適化で約16msまで縮めた。世の中にそこまで速いワードクラウド生成器が必要なわけではないが、作るならできるだけ速いほうがいい
    • 「卓越性の追求に正当化は不要」
      https://x.com/mitchellh/status/2074225453217505494
    • ワークフロー次第。テキストをそのままモデルに入れず、トークン化だけを行う用途もある
    • 下位コンポーネントでも1,000倍改善されれば、質的に新しい機能が可能になる。その部分が全体の0.1%にすぎない理由自体が、プロジェクト全体で「全体性能に影響しないのになぜきちんと作るのか」という態度を繰り返した結果であることも多い
      LLMは1,000倍改善の限界にずっと近いが、基本的なPyTorch演算でさえ単純な書き直しより2倍遅いことは珍しくなく、より良いスケジューリングアルゴリズムが5〜10倍の改善を出すこともある。高速トークン化によって、これまで実現不可能で無視されていた別の機能が開けるかもしれない
    • ルーティング用の超小型言語モデル（SLM）を動かすためにトークン化するなら、比率は0.1%どころかずっと大きくなりうる。これは「PCはたいていデスクトップで遊んでいるのだからGPUドライバ最適化は重要ではない」という考え方と同じ

  • グラフの数値を理解しようとしばらく見つめてしまうほど、信じがたい性能

  • ClickHouseにもまさに必要な機能なので、https://github.com/ClickHouse/ClickHouse/issues/108247 で試してみる予定
    READMEはコアあたり性能をもっと強調するとよさそうだし、実際のアルゴリズムには完全ハッシュテーブル照合が役立つのかも気になる

  • だとすると、推論パイプラインのほかの部分にはまだ1,000倍最適化の余地がどれだけ残っているのか気になってくる

    • トークン化層と違って、推論の他の変更は正確かどうかを単純に判定しにくい
    • そういう部分は多く、ほぼすべてのコンポーネントに専任チームと研究が付いている。今後も大きなブレークスルーが多数出る可能性は高い
    • 推論時間のより大きな割合を占める部分には、すでにずっと多くの最適化努力が投入されているはず