世界を動かす技術を、日本語で。

GigaToken: 約1000倍速の言語モデルトークン化

2026年7月23日原文(github.com)

概要

Gigatoken は、既存のHuggingFaceやtiktokenトークナイザーよりも最大 1000倍高速 なトークナイザー。 幅広いCPUや多様なトークナイザーに対応し、 GB/s級のスループット を実現。 HuggingFaceやtiktokenとの 互換モード も用意されており、最小限のコード変更で導入可能。 ベンチマーク で一貫した高速性を証明、特に大規模データ処理で圧倒的なパフォーマンスを発揮。 既存の課題や既知の問題も明記されており、今後の改善予定も記載。

Gigatokenとは

  • Gigatoken は、言語モデル向けの 最速トークナイザー

    • 多様な CPUアーキテクチャ (x86, ARMなど)に対応
    • 主要な BPEベースのトークナイザー を広範にサポート
    • 特に 大規模テキストデータ の高速処理に最適
  • インストール方法

    • pip install gigatokenで簡単導入
  • 主な特徴

    • HuggingFaceやtiktokenの既存コードに 最小限の変更 で導入可能
    • 独自API使用時は 最大パフォーマンス を発揮
    • Rust製・SIMD最適化 による圧倒的なスピード

使い方

  • 互換モード(最も簡単)

    • 既存のHuggingFaceやtiktokenトークナイザーと 同じインターフェース で利用可能
      import gigatoken as gt
      hf_tokenizer = ...
      tokenizer = gt.Tokenizer(hf_tokenizer).as_hf()
      tokens = tokenizer.encode_batch(["This is a test string", "And here is another"])
      
    • tiktokenとの互換も同様に実現
  • Gigatoken API(最速)

    • 直接GigatokenのAPIを使うことで 最大限のスループット を実現
      import gigatoken as gt
      tokenizer = gt.Tokenizer("Qwen/Qwen3-8B")
      file_source = gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>")
      tokens = tokenizer.encode_files(file_source)
      

ベンチマーク結果

  • AMD EPYC 9565 144コア

    • GPT-2: 24.53 GB/s (HFの989倍、tiktokenの681倍)
    • Llama 3: 22.15 GB/s (HFの457倍)
  • Apple M4 Max 16コア

    • GPT-2: 8.79 GB/s (HFの1,268倍、tiktokenの140倍)
    • Llama 3: 7.60 GB/s (HFの676倍)
  • AMD Ryzen 7 9800X3D 16コア

    • GPT-2: 6.27 GB/s (HFの106倍、tiktokenの68倍)
  • 各種モデル・バージョン の詳細なスループットも公開

ベンチマークの補足

  • OWT (OpenWebText) データセットを使用
    • Gigatokenは 分割前の生データ 全体を並列処理
    • HFは最初の100MB、tiktokenは最初の1GBを使用(<|endoftext|>で事前分割)
  • SentencePiece系 は最適化が弱いが、BPE系は圧倒的な高速化を実現

よくある質問(FAQ)

  • 特定CPUやトークナイザーだけ最適化?

    • いいえ、 全組み合わせで徹底的に最適化
    • SIMD 活用、分岐最小化、キャッシュ最適化で高速化
    • Pythonとのやりとり削減、スレッド間通信の回避
  • 自分のトークナイザーが対応しているか確認したい

    • インストール不要で CLIベンチマーク が可能
      uvx --with tokenizers gigatoken bench 'openai-community/gpt2' owt_train.txt --validate --doc-separator "<|endoftext|>"
      
    • 結果例:EPYC 144コアで HFの989倍高速、Apple M4 Maxで 1,353倍
  • バグや遅いケースを見つけた場合

    • GitHub Issue で報告を推奨

既知の課題・注意点

  • Pythonとのインターフェース におけるオーバーヘッド(今後改善予定)
  • File sink未実装
  • WordPiece未対応
  • SentencePiece系は最適化が限定的
  • Windowsは未検証 (WSL推奨)

AI利用開示

  • コードベースの大部分は手作業
    • 最終段階で一部AI支援を活用
      • API実装、互換性拡張、SIMD最適化戦略の移植など

参考文献

  • 研究用途での利用時は 以下の形式で引用を推奨
    @software{roed2026gigatoken,
      author = {Marcel R{\o}d},
      title = {{G}igatoken: SIMD and Cache Hierarchies for 1000x Faster Byte-Pair Encoding Tokenization on Modern CPUs},
      url = {https://github.com/marcelroed/gigatoken},
      year = {2026},
    }
    

Gigatoken は、 大規模データ処理 を劇的に高速化したい研究者・開発者にとって、現状最強クラスのトークナイザー。 パフォーマンス重視 の現場で、ぜひ導入を検討。

Hackerたちの意見

トークナイザーの速度に制約されるセットアップって、みんなどんなの使ってるの?

モデルに送る前に入力トークンの使用状況をチェックするのに役立つかも。例えば、特定のトークン制限を超える呼び出しを防いだり、リクエストをバッチにまとめたりすることができるよ。LLMが異なるAPIで入力と出力のトークン数を提供するのにも使えるけど、これが llama.cpp や他のOpenAI系APIがリクエストの入力/出力トークンを計算する方法かどうかはわからないな。

え、いつからハイパー最適化されてるかどうかが役に立つか重要になったの?面白い問題に対してコンピュータが「ブーン」って動くこと自体が目的じゃないの?

ここに作者がいるよ!私の場合、主にプレトレーニングの実験で、データの混合やフィルタリング、トレーニングデータの処理を変更したいことがあるんだ。分割は通常、テキストレベルではなくトークンレベルで行われるよ。この場合、DCLMのトークナイゼーションを終わらせるために、何日もかけて大量のCPUを使って実行することが多いんだ。私が見る限り、fastokensが報告しているように、最初のトークンまでの時間(TTFT)を考慮すると、推論にも役立つみたい。プロプライエタリな推論エンジンについてはわからないけど、オープンソースのものでは、テキストシーケンスがKVキャッシュに存在するかを調べる前にトークナイゼーションが行われるよ。もし以前に見たことがある長いプレフィックス(例えばシステムプロンプト)があれば、そのトークナイゼーションにかかる時間がTTFTの大部分を占めることになる。こういう場合、トークナイザーのキャッシュは温めておくべきだから、Gigatokenのスループットはリポジトリで報告されているよりもかなり高くなるはずだよ。

プレトレーニングデータは、GPUの計算を無駄にしないためにあらかじめプレトークナイズされてるんだ。こんなに大きなスピードアップは、確かにデータパイプラインの効率的な節約になるね。

LLMをトレーニングするなら、トレーニング前にテキストをトークン化しなきゃいけないんだ。でも、GPUを使えば並行してできることが多いよ。トレーニングデータセットのトークン化に10〜15分も待たされて、その後ちょっとしたバグでクラッシュするのには本当に時間を無駄にしたなぁ。(もっと賢かったら、最初に小さいバッチでテストするんだけどね。)

メタデータを保存できないデータがあって、意味的に検索するために毎回検索時に静的埋め込みで埋め込んでるんだけど、トークン化がCPU時間の99%以上を占めてたんだ。これはデフォルトのトークナイザーの実装が単純すぎて、ドキュメントの長さに対してo^2だったからなんだけど、ちゃんとしたスキャナーに切り替えたら大半が解決したよ。SIMDとかは使わずにね。でも、それでもまだ大変だった。

面白いね! Q: 特定のCPUとトークナイザーに対して過剰最適化しちゃったの?なんでそんなに速いの?いや、実はこれらの組み合わせ全てに対して過剰最適化してるんだ!結果は、CPU(現代のx86やARM)や特定のトークナイザーに関わらず、すごく一貫してるよ。主な改善点は、通常はRegexエンジンに外注される実装(プレトークナイゼーション)をSIMDを使って徹底的に最適化すること、分岐を最小限に抑えたり、他のトリックを使ったり、プレトークンマッピングのキャッシングを徹底的に最適化することだね(もし単語を以前に見たことがあれば、そのエンコードされたトークンを効率的に探す)。この分野ではキャッシングがすごく難しい問題で、キャッシュがすぐに大きくなっちゃうし、プレトークンの分布は非常に長い尾を持ってるからね。最後に、Pythonとのやり取りを最小限に抑えて、スレッド同士の相互作用も最小限にしてるよ。

これめっちゃクールだね、素晴らしい仕事!

あのチャートを見つめて、数字を理解するのにちょっと時間がかかったよ。本当に驚くべきことだね、素晴らしい!

すごいけど、トークン化は通常、推論時間の0.1%未満なんだよね。たぶん、トークン化だけが必要なアプリケーションがたくさんあると思うから、そういうのにはめっちゃいいかも!

いつも0.001%にするのはいいことだよね。

Hacker Newsで議論の続きを見る