GigaToken、Hugging Faceに挑戦し、トークン化が最大989倍高速と主張

GigaTokenは、144コアのAMDサーバー上でGPT-2のテキストを24.53 GB/sで処理したとされる言語モデル用トークナイザーを公開した。開発者のベンチマークでは、GigaTokenのトークナイザーはHugging Face Tokenizersより989倍高速だった。また、OpenAIのtiktokenを681倍上回った。

これらの数値は、幅広い用途での代替を主張するものに聞こえる。しかし、実際には、高度に最適化されたファイルベースのワークロードにおいて、トークン化がどれほど高速になり得るかを示したものと捉えるのが適切だ。GigaTokenは、専用のCPU命令、積極的なキャッシュ、並列処理、そしてPythonとのデータ往復の削減を活用している。

この違いが重要なのは、最速のインターフェースがそのまま置き換え可能な互換レイヤーではないためだ。注目を集めた性能はプロジェクト独自のAPIによるもので、Hugging Faceとの互換性を利用すると追加のオーバーヘッドが発生する。独立した再現テストでも大幅な優位性が確認されたが、Hugging Faceに対する性能差は、はるかに小さい83.4倍だった。

それでも、この結果は既存のトークン化ライブラリに圧力をかけるものだ。ただし、すべてのモデルリクエストが数百倍高速になるわけではない。真の可能性があるのは、データセットの準備、大規模な文書取り込み、モデル学習など、トークン化が継続的なインフラ処理となるパイプラインである。

GigaTokenが実際に公開したもの

GigaTokenは、最新のCPU上で大規模なテキストコレクションを毎秒数ギガバイトの速度で処理するよう設計された、オープンソースのRust製トークナイザーである。

トークナイザーは、テキストを言語モデルが処理する整数識別子に変換する。バイトペアエンコーディング（BPE）は、一般的なバイト列を繰り返し結合し、語彙トークンへと変換する。GPT-2、Llama、Qwenをはじめ、多くのモデルファミリーがこの処理の派生方式を使用している。

開発者のMarcel Rødによると、GigaTokenは、一般的に使用される多数のトークナイザーに加え、最新のx86およびArmプロセッサーをサポートしている。ソフトウェアはPythonパッケージとして配布され、性能が重視されるコンポーネントはRustで実行される。

プロジェクトのリポジトリでは、2つの利用方法が紹介されている。互換モードでは、既存のHugging Faceまたはtiktokenトークナイザーをラップする。ネイティブAPIはモデル識別子を受け取り、テキストファイルを直接読み込むことができる。

このネイティブ経路が、性能に関する主張の中核となっている。これにより、RustはPythonオブジェクトを繰り返し変換せずにソースデータを読み込める。また、バッチ処理、メモリアクセス、並列実行をライブラリ側でより細かく制御できる。

互換インターフェースの目的は異なる。開発者は既存のトークナイザーをラップし、Hugging Face Tokenizersやtiktokenと同様の形式のAPIを利用できる。これにより、すでにこれらのライブラリを中心に構築されたアプリケーションの移行作業を軽減できる。

ただし、開発者は互換性によって性能が低下することを明確に警告している。Hugging Faceの動作に合わせ、使い慣れたPythonのデータ構造を返すには、ネイティブAPIでは不要な処理が発生する。import文を1つ変更するだけで、宣伝されている989倍の向上が得られると考えるべきではない。

このリリースは、多数のBPEモデルファミリーをサポートしている。公開されたベンチマークには、GPT-2、Llama、Qwen、DeepSeek、GLM、Phi、OLMo、Kimi、Gemma、Mistral、ModernBERTの各トークナイザーが含まれている。性能はモデルファミリーによって大きく異なる。

GigaTokenには、いくつかの領域で未完成な部分が残っている。WordPieceはサポートされておらず、SentencePieceのトークン化はBPEほど最適化されていない。ネイティブAPIにはファイル出力機能が実装されておらず、WindowsユーザーにはWindows Subsystem for Linuxの利用が推奨されている。

また、公開時点ではGitHubに正式なリリースが掲載されていない。これはPythonパッケージ経由でのインストールを妨げるものではないが、プロジェクトがまだ初期段階にあることを示している。本番環境を担うチームは、APIの安定性と互換性の範囲を未解決の課題として扱うべきだ。

したがって、GigaTokenは単なる合成的な速度実験以上の存在ではあるものの、万能なトークナイザーの代替には至っていない。互換性を確保する橋渡し機能、文書化された制約、そして並外れて大きなベンチマーク上の主張を備えた、意欲的なシステム実装である。

GigaToken対Hugging Face Tokenizers：注目のベンチマーク

989倍という結果は公開されたテスト内では事実だが、その数値の意味は、ハードウェア、データ経路、比較方法によって決まる。

開発者は、11.9 GBのOpenWebTextファイルを使用してGPT-2のトークン化をテストした。主要なサーバーには2基のAMD EPYC 9565プロセッサーが搭載され、2ソケット合計で144個のCPUコアを備えていた。

この構成で、GigaTokenは24.53 GB/sを記録した。Hugging Face Tokenizersは24.8 MB/s、tiktokenは36 MB/sだった。これらの測定値から、それぞれ989倍と681倍という比率が算出された。

リポジトリによると、出力検証は20,401件の文書を対象に行われ、Hugging Faceの結果と一致した。この検証は重要だ。同じ入力に対して異なるトークン識別子を割り当てるのであれば、どれほど高速なトークナイザーでもほとんど価値がないためである。

GigaTokenは、それほど極端ではないマシンでのテストも公開した。Apple M4 Maxでは、GPT-2データを8.79 GB/sで処理したと報告されている。これに対し、Hugging Faceは6.9 MB/s、tiktokenは62.8 MB/sだった。

これは、Hugging Faceに対して1,268倍、tiktokenに対して140倍の優位性に相当する。AMD Ryzen 7 9800X3Dでは、GigaTokenは6.27 GB/sを記録し、Hugging Faceの結果の106倍だったと報告している。

これらの数値は、その優位性が単一のサーバーアーキテクチャに限定されないことを示している。ただし、ハードウェア、トークナイザー、文書サイズ、アプリケーションインターフェースを問わず適用できる単一の倍率を証明するものではない。

性能はトークナイザーファミリーによっても変化する。デュアルEPYCシステムでは、Llama 3のトークン化が22.15 GB/sに達し、Hugging Faceより457倍高速だったと報告されている。DeepSeekのトークン化は19.69 GB/sに達し、750倍の優位性を示した。

他のトークナイザーでは、差はより小さかった。GigaTokenはMistral 7B v0.3で3.57 GB/sを記録し、Hugging Faceのスループットのおよそ10倍だったと報告している。Gemma 3は3.43 GB/sに達し、9.6倍の優位性となった。

約10倍から1,000倍近くまで広がるこの範囲こそ、より有用な要点である。基盤となるトークナイザーのルールによって、GigaTokenの最適化された事前トークン化とキャッシュ戦略がどの程度効果を発揮できるかが決まる。

独立したテストは、別の参考点を提供している。再現ベンチマークでは、4コアのIntel Xeon仮想マシンと174.07 MBのOpenWebTextサンプルが使用された。

GigaTokenは3回の実行で中央値277.77 MB/sに達した。tiktokenは10.62 MB/s、Hugging Face Tokenizersは3.33 MB/sだった。テストされた35,356件の文書は、すべて一致する出力を生成したと報告されている。

この独立した結果では、GigaTokenはtiktokenより26.2倍、Hugging Faceより83.4倍高速だった。開発者の主張の方向性は確認されたが、最大の倍率までは再現されなかった。

独立テストでは、データ量が少なく、コア数も少ないうえ、異なるホストが使用されている。その絶対的なスループットをデュアルEPYCの結果と直接比較すべきではない。このテストの価値は、元の環境以外でも優位性が維持されたことを示した点にある。

したがって、ベンチマークの証拠は慎重な結論を支持している。GigaTokenは、サポート対象となるバッチ指向のワークロードで大幅に高速であると考えられる。正確な倍率は、ハードウェア、入力、トークナイザー、インターフェース、測定方法の組み合わせごとに異なる。

GigaTokenトークナイザーが高速に動作する理由

GigaTokenの優位性は、異なるトークン化アルゴリズムの発見ではなく、CPU実行を中心にデータ経路を再設計したことから生まれている。

最初の主要な最適化対象は、事前トークン化である。この段階では、BPEが語彙のマージを適用する前に、テキストをより小さな単位へ分割する。多くのトークナイザー実装では、この処理を汎用正規表現エンジンに任せている。

GigaTokenは、その経路の多くを専用コードに置き換えている。このプロジェクトではSIMDを使用しており、1つのCPU命令で複数のデータ要素を同時に処理する。実装はAVX-512、AVX2、Arm NEONの各命令セットを対象としている。

この特化により、柔軟な正規表現エンジンが実行しなければならない処理が削減される。また、特に大量のテキストが類似したトークン化ルールに従う場合、プロセッサーにとって動作を予測しやすくなる。

分岐の削減も、もう1つの優位性をもたらす。分岐では、プロセッサーが異なる実行経路から1つを選択する。分岐予測を誤るとパイプラインが停滞する可能性があるため、予測困難な判断を減らすことでスループットを維持しやすくなる。

2つ目の主要な仕組みはキャッシュである。自然言語では、単語、断片、空白パターン、句読点の並びが繰り返される。GigaTokenは事前トークンを一度エンコードすると、同じシーケンスが再び現れた際にその結果を再利用できる。

この考え方は単純に聞こえるが、プロジェクトの開発者は、より難しい工学的課題があると説明している。事前トークンの分布にはロングテールがあり、キャッシュは急速に拡大する可能性がある。設計の悪いキャッシュは、検索ミスを頻発させながらメモリを消費してしまう。

GigaTokenは、一般的なマッピングを低コストで取得できるように設計されたキャッシュ階層を使用している。リポジトリでは、分岐の除去とこの階層の改良が、最終的な性能向上の一因だったとしている。

3つ目の仕組みは並列処理である。ネイティブインターフェースにより、Rustはファイル入力と文書処理を直接制御できる。ワーカースレッド間の通信を抑えながら、CPUコア全体に処理を分散できる。

これは144コアのサーバーで特に重要となる。各コアに独立した処理を継続的に供給できないソフトウェアでは、マシンの大部分がアイドル状態になる。GigaTokenは、利用可能なハードウェアを稼働させるのに十分な大規模バッチを継続的に処理することを前提に設計されている。

4つ目の仕組みはPythonとの境界である。数百万個の小さな文字列、リスト、整数オブジェクトをPythonとネイティブコードの間で移動させると、オーバーヘッドが発生する。中核となるトークン化ループが高速化すると、このオーバーヘッドが支配的になる可能性がある。

GigaTokenのネイティブAPIは、Rust内でファイルを読み込むことで、こうした境界をまたぐ処理を減らしている。入力バイト、中間状態、トークン出力を、最適化された実装の近くに維持できる。

この設計は、互換モードが遅くなる理由も説明している。そのまま置き換え可能なラッパーでは、期待されるメソッド、出力構造、特殊トークンの処理、切り捨て動作、パディング、正規化を維持しなければならない。互換性に関する約束の1つひとつが、最適化を制約する。

Hugging Face Tokenizersは、すでに主としてRustで実装され、並列処理をサポートしている。Tiktokenもネイティブコードを利用している。GigaTokenが勝っているのは、競合製品がPythonでトークン化を実行しているからというだけではない。

そうではなく、より限定された経路に最適化している。ユーザーが多くの場合、サポートされているトークナイザーの動作を用いて、オブジェクト単位のやり取りを最小限に抑えながら大規模なコレクションを処理したいという前提に立っている。この前提は、対話型アプリケーションよりもデータセットパイプラインに適している。

このプロジェクトは、開発の最終段階でAIの支援を受けたことも開示している。リポジトリによると、AIはSIMD戦略の移植、互換性の拡大、コードのリファクタリング、そして最後のおよそ4倍の性能向上の特定を支援した。

開発者によれば、コードベースの大部分はAIの支援なしで記述された。この開示は正確性を保証するものではないが、最適化と互換性対応がどのように完了したかを明らかにしている。

これらのエンジニアリング上の選択は、有用なトレードオフを生み出す。特化された実行は、汎用フレームワークを劇的に上回る可能性がある。その代償として、機能サポートの範囲が狭くなり、アーキテクチャ固有のコードが増え、テストの負担も大きくなる。

トークン化の高速化はモデル推論の高速化を意味しない

GigaTokenは前処理のボトルネックを解消できるが、モデルの回答を生成するニューラルネットワーク自体を高速化するものではない。

オンライン言語モデルへのリクエストは通常、複数の段階を経ます。サーバーがテキストを受信し、トークン化し、モデルのプリフィルを実行し、出力トークンを生成してデコードした後、レスポンスを返します。

トークン化が担うのは、その一連の処理の一部にすぎません。モデルのプリフィルでは入力をトランスフォーマー層に通し、生成では次のトークンを繰り返し予測します。こうしたGPUやアクセラレーターの処理が、リクエストのレイテンシーの大部分を占めることがよくあります。

短いチャットプロンプトでは、トークン化にかかる時間がごくわずかなため、相対的に大幅な改善があっても、実際に短縮できる時間はほとんどありません。極めて短い前処理時間を99パーセント削減しても、遅いモデルや混雑したサービングキューの影響を打ち消すことはできません。

この制約は、コミュニティでの議論でもすぐに指摘されました。ある開発者は、通常はモデルの実行のほうが遅く感じられるとして、そもそもトークン化がボトルネックなのかと疑問を呈しました。別の開発者は、トークン化の高速化で変わるのは推論前の時間であり、推論そのものではないと指摘しました。

最も有力なユースケースは、大量のテキストを継続的に処理するワークロードです。モデルの学習では、サンプルを学習パイプラインに投入する前に、大規模なコーパスをトークン化する必要があります。反復的な実験では、同じコーパスを複数の語彙設定で処理することもあります。

データセットのフィルタリングや重複排除も、トークン数に依存する場合があります。チームは、コンテキスト上限を超えるサンプルを除外したり、トークン長に基づいてドキュメントをグループ化したり、エンコード済みデータセットから学習予算を見積もったりします。

検索システムも、別の有望なワークロードです。大規模な取り込みジョブでは、数百万件のファイルをモデルに適したサイズのチャンクに分割し、各チャンクのトークン境界を計算することがあります。エンコードの高速化により、この前処理段階を短縮できます。

エージェントシステムについては、効果がやや不確実です。エージェントは、ツールの結果、ログ、コード、取得したドキュメントを含む長大なプロンプトを繰り返し組み立てることがあります。こうしたコンテキストが非常に大きくなれば、トークン化時間の短縮によって入力準備のレイテンシーを削減できる可能性があります。

ただし、対話型エージェントのリクエストには、ネットワーク呼び出し、ツールの実行、モデルのプリフィル、生成も含まれます。目立った遅延の原因をトークン化に求める前に、チームは処理全体のトレースをプロファイリングする必要があります。

GigaToken独自のベンチマークがファイルベースの処理を重視しているのは、その環境が設計上の強みを最も明確に示すためです。ネイティブパスを通じて11.9 GBのコーパスを読み込むことは、数千件の独立したWebリクエストをエンコードすることと同じではありません。

「ドロップイン置換」という表現にも条件があります。互換性ラッパーは一般的なAPIとの互換を目指しており、プロジェクトは出力の完全な一致に向けて多大な取り組みを行ったと報告しています。しかし、最大の高速化が得られるのはネイティブインターフェースです。

したがって、本番環境への移行では選択が必要になります。チームは既存のインターフェースを維持して比較的小さな改善を得るか、GigaTokenのファイル指向APIを中心にデータパスを再設計するかを選べます。

機能の対応範囲も制約になります。WordPieceを使用するワークロードは、現時点では移行できません。SentencePieceのユーザーは最適化の効果が小さいと見込むべきであり、Windows環境でのテストも限定的です。

出力の同等性についても、継続的な検証が必要です。トークナイザーには、特殊トークン、正規化ルール、切り詰め、パディング、オフセット、モデル固有の事前トークナイザーが含まれます。正しいトークン識別子は必須ですが、一部のアプリケーションはメタデータにも依存しています。

トークナイザーのドキュメントは、その機能範囲がいかに広がっているかを示しています。Hugging Faceは、学習、正規化、事前トークン化、後処理、パディング、切り詰め、アラインメント追跡、複数言語向けのバインディングを提供しています。

GigaTokenが有用になるために、すべての機能を複製する必要はありません。ただし、どの動作が完全に一致し、どの動作が異なり、どの動作が未対応なのかを明確にする必要があります。

セキュリティチームは、トークナイザーのアーティファクトを実行可能な設定として扱うべきです。変更された語彙や正規化ルールは、モデルの重みを変えることなく、モデルによる入力の解釈を変える可能性があります。

最近の改ざんに関する研究では、変更されたトークナイザーのマッピングによって、デコードされたURLやツール引数を操作できることが示されました。GigaTokenがこの問題を生み出すわけではありませんが、移行時にはアーティファクト検証の管理策を維持すべきです。

主なリスクは、性能数値が必ずしも虚偽であることではありません。トークン化時間、互換性、セキュリティの重要度が異なるシステムに、読者がスループットベンチマークをそのまま当てはめてしまうことです。

GigaTokenによって圧力を受けるのは誰か

GigaTokenは、汎用性によってどの部分でスループットが犠牲になっているのか、一般的なバッチ処理を大幅に高速化できるのかを、既存ライブラリに説明するよう迫っています。

Hugging Face Tokenizersは、単一の性能プロファイルではなく、幅広いエコシステムに対応しています。新しいトークナイザーの構築、既存設定の読み込み、テキストアラインメントの追跡、モデルツールとの統合をサポートしています。

この幅広さは、研究者やアプリケーション開発者にとって価値があります。一方で、特化型バッチエンコーダーなら回避できる抽象化が追加されることもあります。GigaTokenによって、こうした抽象化に伴う性能コストは無視しにくくなりました。

Tiktokenは異なる位置づけにあります。OpenAIはBPEトークン化を中心にTiktokenを構築し、オープンソースライブラリとして公開しました。OpenAI互換のワークフローでトークン数を見積もり、テキストをエンコードする際の一般的な選択肢となっています。

そのリファレンス実装は、性能が重視される処理にすでにRustを使用しています。GigaTokenが報告した優位性は、ネイティブコードを採用するだけでは性能競争の決着がつかないことを示唆しています。

競争上の焦点は、既存プロジェクトがAPIを損なうことなく、同様のアイデアを採用できるかどうかです。SIMD事前トークナイザー、改良されたキャッシュ、より優れたファイル取り込みによって、差を縮められる可能性があります。

ただし、既存プロジェクトは異なる目標を優先しているかもしれません。Hugging Faceは、多数のモデル設定、実行環境、ユーザーの期待に対応しなければなりません。Tiktokenは、OpenAIのツール全体で使用されるトークンエンコーディングについて、予測可能な動作を維持する必要があります。

GigaTokenは、性能を最優先する小規模なプロジェクトであるため、より迅速に進化できます。その利点は同時に、保守責任の集中も意味します。アーキテクチャ固有の最適化には、プロセッサ、コンパイラ、OS、入力分布をまたぐテストが必要です。

このリリースは、インフラストラクチャチームにも再考を迫ります。多くの組織は、トークン化を解決済みのライブラリ呼び出しとして扱っています。独立した検証で26倍または83倍の差が再現されたことは、その前提を実測すべきであることを示しています。

ビジネス上の影響は、ワークロードの規模に左右されます。たまにプロンプトを処理する程度であれば、トークナイザーを置き換えても、目に見えるメリットがないまま移行リスクだけが増える可能性があります。数テラバイト規模の取り込みでは、数時間の前処理が数分になる可能性があります。

テストする動機が最も明確なのは学習チームです。彼らは固定されたデータセットを定期的に処理し、計算環境を管理でき、学習を開始する前に出力を検証できます。こうした条件は、GigaTokenの強みによく合致しています。

データプラットフォームチームにもメリットがあるかもしれません。トークン数は、ストレージ形式、バッチ処理、フィルタリング、スケジューリングに影響します。エンコードの高速化により、反復的な変換処理のクリティカルパスからトークン化を外せる可能性があります。

アプリケーション開発者は、選択的であるべきです。サービスのレイテンシーの大部分がモデル生成、データベース、外部APIに費やされているなら、トークナイザーの最適化でシステム全体の問題を解決することはできません。

だからこそ、最大の見出しよりも独立した検証結果が重要です。一般的なクラウドハードウェア上でtiktokenに対する26倍の優位性を再現できるなら、1000倍という主張がなくても評価に値します。

既存ライブラリが突然時代遅れになったわけではありません。それらには、成熟したAPI、コミュニティからの信頼、より幅広いサポート、深い統合という強みがあります。GigaTokenは、そうした強みが評価される際の性能基準点を引き上げました。

GigaTokenリリース後に注目すべきこと

次に注目すべき3つのシグナルは、より広範な独立ベンチマーク、互換性テストの結果、実際のデータパイプラインでの採用です。

最初のシグナルは、より多様なハードウェアとデータでの再現です。デュアルEPYCのベンチマークはGigaTokenの性能上限を示し、4コア環境での再現結果は、より小規模な独立サンプルを提供しています。

有益な追試では、同等のインターフェース、同一のデータセット、固定されたスレッド数、一致する出力を比較すべきです。短いドキュメント、多言語テキスト、コード、不正なUnicode、特殊トークンを多く含む入力も対象に含める必要があります。

こうした条件全体で一貫した優位性が確認されれば、中心的な主張の信頼性が高まります。性能が大きく変動したり、出力が一致しなかったりすれば、GigaTokenの実用範囲は限定されます。

2つ目のシグナルは、互換性の対応範囲です。開発者は、正規化、オフセット、パディング、切り詰め、特殊トークン、あまり一般的でないHugging Face設定に関する問題報告を注視すべきです。

WordPieceに対応すれば、対象となるモデルの範囲が広がります。SentencePieceの性能が向上すれば、最も得意とするBPE以外のモデルファミリーでも、プロジェクトの有用性が高まります。

正式リリースと明文化された互換性保証も、導入リスクを軽減します。下流システムが正確なトークン識別子に依存する場合、安定したバージョニングポリシーが重要です。

3つ目のシグナルは、本番環境での採用です。学習パイプライン、データセット構築ツール、推論プロバイダー、検索プラットフォームによって、トークナイザーのスループットが現在、実質的な作業の制約になっているかどうかが明らかになります。

実際の導入事例では、エンコーダーのスループットだけでなく、エンドツーエンドの所要時間を報告すべきです。トークン化が100倍高速化しても、パイプライン全体の完了時間が10パーセントしか短縮されない場合、マイクロベンチマークとは異なる実像が見えてきます。

チームは、メモリ消費量とスケーリング効率も報告すべきです。キャッシュを多用する設計では、メモリと速度がトレードオフになり得ます。また、マルチソケットシステムでは、帯域幅や連携処理の制約が生じる可能性があります。

現在GigaTokenを評価している開発者が次に行うべきことは明確です。トークン化を個別にプロファイリングし、既存ライブラリと出力を照合し、本番環境で使用する予定のものと同じインターフェースをテストしてください。

989倍という数値を期待値として出発点にしてはいけません。どのような倍率にも意味があるかを決める問い、つまり現在トークン化が実時間のどれだけを占めているか、という問いから始めるべきです。

その割合が大きければ、GigaTokenトークナイザーを管理された条件でベンチマークする価値があります。モデル推論が支配的であれば、最適化の労力は別の場所に向けるべきです。この違いが、このリリースがLLMインフラストラクチャの中核になるのか、それとも優れた特化型エンジンにとどまるのかを決定します。