gigatoken解説｜トークナイザーをGB/sで回す1000倍高速化の中身と再現条件

LLMの前処理でテキストをトークン列に変換するトークナイザーは、長らく「Rustで書かれているのだから、もう十分速い」と思われてきた部品でした。そこへ2026年7月、HuggingFace tokenizers比で約1000倍を名乗るRust実装 gigatoken が公開され、Hacker Newsで613ポイント・119コメントを集めています。ただし「1000倍」は投稿タイトルの主張です。この記事では公式READMEの実測表と作者本人の補足を突き合わせ、どの条件で何倍出るのか、そしてそれが自分の用途で意味を持つのかを切り分けます。

この記事はLLMの前処理を担うトークナイザーの高速化実装として gigatoken を扱います。LLMそのものの仕組みや周辺技術の全体像は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

gigatokenとは：トークナイザーをGB/sで動かすRust実装

gigatokenは、LLMの学習・推論に入る前段でテキストをトークンIDの列に変換する処理だけを担う、単機能のライブラリです。GitHub APIで実体を確認すると、2026年7月25日時点で以下の状態でした。

注目したいのはGitHubのReleaseもタグも0件である一方、PyPIには0.3.0から0.9.0まで10バージョンが並んでいる点です。バージョン管理はPyPI側だけで進んでおり、GitHub上の「安定版はどれか」という手がかりはありません。バージョン0.9.0という番号が示すとおり、1.0前の実装として扱うのが妥当です。

導入自体はPythonパッケージ1つで完結します。abi3ホイールがmacOS（x86_64 / arm64）・Linux（x86_64 / aarch64）・Windows（amd64 / arm64）向けに用意されており、Python 3.10以降が要件です。

pip install gigatoken

使い方は2系統に分かれます。ひとつはHuggingFace tokenizersやtiktokenと同じ呼び出し方ができる互換モード、もうひとつはRust側にファイル読み込みごと任せる独自APIです。この2つで性能が変わることが、後述する倍率の話に直結します。

同じ「トークン化」でも、RAGの文脈で語られるチャンク分割とは対象が異なります。文書を意味のまとまりで区切る話は Chonkieとは？RAGチャンキングライブラリ 側の領域で、gigatokenが扱うのはその手前、バイト列を語彙IDに落とす処理です。

「1000倍」はどこまで本当か：実測表を3機体で読む

READMEには3種類のCPUでの実測表が掲載されています。ここが本記事の中心です。同じGPT-2トークナイザー・同じデータ（owt_train.txt 11.9GB）でも、倍率は機体によって1桁変わります。

数値を並べると次のようになります。

倍率が最大になるのは「比較相手が最も遅い機体」

表を縦に読むと、奇妙な事実が浮かびます。HuggingFace tokenizers側の数値がコア数にまったく比例していないのです。144コアのEPYCで24.8 MB/s、16コアのRyzenで59.0 MB/s——コア数が9倍の機体で、比較対象は逆に遅くなっています。gigatoken側は24.53 GB/s対6.27 GB/sと素直にスケールしているため、倍率の大きさは主にHF側がどれだけ振るわなかったかで決まっている構図です。

したがって「1000倍」という数字は、gigatokenが速いことと、比較対象が多コア環境でスケールしないことの積として現れています。手元が一般的な8〜16コアのデスクトップなら、READMEの実測表そのものが106倍という数字を提示している、と読むのが正確です。106倍でも十分に大きな改善ですが、桁がひとつ違います。

ベンチマーク条件の非対称性も押さえておく

READMEの「Benchmark details」には、3者が同じ作業をしているわけではないことが明記されています。gigatokenは11.9GBのファイルを分割せずそのまま読み、文書境界の探索と並列化まで自前で行います。対してHuggingFace tokenizersは先頭100MB、tiktokenは先頭1GBを、あらかじめ <|endoftext|> で分割した状態で受け取ります。

READMEはこれを「どちらもキャッシュを行わないため処理速度は全体を通じてほぼ一様であり、この比較は妥当」と説明しています。データ量の差そのものは合理的な説明がついている一方、gigatokenだけが分割処理も引き受けている点は、単純なライブラリ間比較ではなく「パイプライン全体としての比較」に近いことを意味します。有利にも不利にも働きうる条件差として認識しておくと、数字の読み方を誤りません。

トークナイザーの方式でも1桁変わる

機体差に加えて、どのトークナイザーを使うかでも効きが大きく変わります。EPYC機での実測表を方式別に並べると、傾向は明確です。

READMEはこの差の理由を「最も遅い行はSentencePieceベースのトークナイザーで、gigatokenでは十分に最適化されていない」と自ら記載しています。Known Issuesでも「主にGoogle系モデルやBERT系がSentencePieceを使うため優先度は低い」と位置づけられています。Gemma・Mistral・Llama 2系を主に扱っているなら、期待値は3桁ではなく1桁台に置くのが妥当です。

自分が使っているモデルが表に無い場合

実測表の各行は「同一の語彙・マージ規則・前分割器を持つ1種類のトークナイザー」を表しており、代表的なリポジトリで計測されています。READMEは「表に自分のトークナイザーが見当たらなければ、既存のどれかをベースにしている可能性が高い」として、主要な行がカバーする範囲を列挙しています。

埋め込みモデルやリランカー、マルチモーダル系も既存の語彙を流用しているケースが多いため、自分のモデル名が直接載っていなくても、ベースを辿れば該当する行が見つかる構造になっています。逆に言えば、ベースがSentencePiece系であれば、モデル名が新しくても倍率は1桁台の側に入ります。

なお同じ「トークナイザー」という語でも、音声合成の分野では離散トークンを介さない設計が模索されています。方向性の違いは VoxCPM2｜トークナイザレス多言語TTS が扱う話題で、gigatokenは逆に既存のトークナイズ処理そのものを速くする立場です。

なぜ速いのか：正規表現をSIMDに置き換え、pretokenキャッシュを積む

作者はREADMEのFAQで、速度の出どころを2つ挙げています。ひとつはpretokenization（前分割）の自前実装、もうひとつはpretokenのキャッシュです。

前提として押さえておきたいのは、比較対象がPython実装ではないことです。READMEは図の直下で「HF tokenizersもtiktokenも、すでにマルチスレッドのRustで動いている」とわざわざ注記しています。つまりこの3桁の差は「PythonをRustで書き直した」類の改善ではなく、同じRust・同じマルチスレッド前提のうえで積まれた差ということになります。ここを取り違えると、速度の出どころを見誤ります。

BPEトークナイザーは通常、まずテキストを単語やその断片へ切り分け（pretokenize）、次にそれぞれをマージ規則に沿ってトークンIDへ変換します。前段の切り分けはほとんどの実装で正規表現エンジンに任されており、作者はここが実質的なボトルネックだったと述べています。gigatokenはこの部分を、分岐を減らしたSIMD実装で置き換えました。

後段については、一度見た単語のトークン列を引き直すキャッシュを積んでいます。作者はこれを「この領域ではキャッシュが非常に難しい問題」だと補足しており、理由としてキャッシュが急速に肥大化することと、pretokenの分布が極端にロングテールであることを挙げています。加えて、Pythonとのやり取りを最小化し、スレッド間通信を避けたことも寄与しているとしています。

これらの説明は、リポジトリの構成からも裏づけが取れます。src/pretokenize/reference/ にはSIMD実装（simd.rs 約28KB）とAVX512向け実装（avx512.rs 約16KB）、状態機械（state_machine.rs）が置かれ、src/bpe/pretoken_cache.rs は約21KBあります。さらに src/pretokenize/fast/ 配下には cl100k.rs / o200k.rs / qwen2.rs / qwen3_5.rs / deepseek_v3.rs / kimi.rs / nemotron.rs / olmo3.rs / r50k.rs と、語彙ファミリーごとの個別実装が並びます。「あらゆる組み合わせに対して過剰に最適化した」というFAQの表現は、ファイル構成と整合しています。

READMEには「AI Use Disclosure」も置かれています。コードベースの大部分はAIを使わず手作業で書いたとしたうえで、最終段階では利用者向けAPIの実装、対応トークナイザーの拡張、AVX512・AVX2・NEON間でのSIMD戦略の移植、そして分岐削減とキャッシュ階層の改善による最後の約4倍分の性能向上に補助として使ったと明記されています。速度の大部分が人手の設計に由来し、仕上げにAIを使ったという整理です。

自分の環境でトークナイザーのベンチを再現する

READMEで最も実用的なのは、インストールなしでベンチマークを実行できるコマンドが用意されている点です。手元の機体がどの倍率帯に入るのかは、実測表を眺めるより自分で回したほうが早く分かります。

まず比較用のデータを取得します。READMEが例示しているのは、Stanford CS336の講義で使われるOpenWebTextのサンプルです。

wget https://huggingface.co/datasets/stanford-cs336/owt-sample/resolve/main/owt_train.txt.gz
gunzip owt_train.txt.gz

続いてベンチマークを実行します。uvx 経由なので pip install は不要です。--validate を付けると、HuggingFace tokenizersと出力が一致するかの検証まで行われます。

uvx --with tokenizers gigatoken bench 'openai-community/gpt2' owt_train.txt \
    --validate --doc-separator "<|endoftext|>"

READMEに掲載されている実行結果は次のような形式です（M4 Maxの例）。処理時間、データ量、スループット、トークン数が並び、最後に倍率と検証結果が出ます。

・gigatoken: 1.432 s | 11920.51 MB at 8327.05 MB/s | 2701.65 Mtok at 1887.23 Mtok/s
・hf: 16.250 s | 100.00 MB at 6.15 MB/s | 22.76 Mtok at 1.40 Mtok/s
・gigatoken is 1353.13x faster than hf
・validation OK: 20401 documents match

最後の行が重要です。20,401文書でトークン列が完全一致したという検証結果があるため、「速いが結果が違う」という疑いは、少なくともこの構成では否定されています。速度の主張と正しさの主張が同じコマンドで同時に確認できる設計は、ベンチマークの信頼性を判断するうえで評価できる点です。

なお本記事では、記載されている数値の出典確認（GitHub API・PyPI・リポジトリのファイル構成）までを行い、ベンチマークの実行そのものは行っていません。上記の数値はすべて公式READMEおよび作者の公開コメントに基づく引用値です。

どこに効くのか：事前学習データの前処理・TTFT・埋め込み

Hacker Newsのスレッドで最も多かった反応は、称賛ではなく「トークナイズは推論時間の0.1%未満ではないか」という疑問でした。この問いは正当で、答えは用途によって変わります。

作者自身が挙げた主用途は事前学習の実験です。データの配合・フィルタ・前処理を変えるたびにコーパス全体をトークン化し直す必要があり、DCLM規模のデータでは多数のCPUを使って数日走らせる工程になる、と説明しています。同様の指摘は他の参加者からも出ており、事前学習データはGPU時間を無駄にしないよう事前にトークン化しておくのが通例であるため、この工程の短縮は素直に効きます。学習データのトークン化に10〜15分待たされた末に軽微なバグで実行が落ちた、という経験談も投稿されていました。

スレッドには、推論以外の場面でトークナイズが実際に効いていたという報告も複数ありました。64Mパラメータ規模のBERT系分類モデルを使うシステムでは、システムの他の部分がGB/s級で処理できるのにトークナイズだけがMB/s級で足を引っ張り、モデル推論より安いはずのトークナイズが全体の実行時間の1割超を占めていたという例。検索のたびにメタデータを都度埋め込む構成で、トークナイズがCPU時間の99%以上を占めていたという例。AIプラットフォームを運用する立場からは、ルーティングやレート制限の判断を下すためにリクエストの早い段階で高速にトークン化する必要がある、という指摘も出ています。いずれも「推論全体に占める割合」ではなく「その処理系のなかでの割合」で見ると話が変わる、という構図です。

分析データベース側からの反応もあり、ClickHouseのリポジトリではgigatokenを取り込む方向のissueが立てられています。トークナイズを推論の前段としてではなく、データ処理そのものとして扱う文脈です。

推論側については、作者がTTFT（最初のトークンが出るまでの時間）の計測値を公開しています。単一のB200上で8BのQwen3を動かした条件で、入力2048トークンのとき 30.74ms → 29.05ms、約5.5%の短縮でした。作者はモデルが小さくGPUが速いほど効果が大きくなるとも述べています。1000倍という入口の数字に対し、推論の体感に効く幅は数%というのが実測の姿です。

READMEはEPYC機の速度を根拠に、Common Crawl全体（インターネット全体に相当するとされる130兆トークン）を6.5時間弱でトークン化できるという試算も載せています。これは実行結果ではなく速度からの換算値ですが、この工程を担当する立場なら意味の分かる数字です。

独自APIを使う場合、Rust側にファイルを直接読ませることで往復のオーバーヘッドを避けられます。互換モードとの差はここで生まれます。

import gigatoken as gt

tokenizer = gt.Tokenizer("Qwen/Qwen3-8B")            # HFのモデル名をそのまま渡せる
file_source = gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>")
tokens = tokenizer.encode_files(file_source)

ローカル環境でLLMを動かす際の律速がどこにあるかは、モデルサイズやランタイムによって変わります。手元の機材で何が動くかを先に確かめたい場合は llmfit完全ガイド：今のPCで動くローカルLLMを1コマンドで判定、Apple Silicon環境での推論サーバー構成は omlx徹底解説｜Apple Silicon専用のローカルLLMサーバー が参考になります。

導入前の制約とライセンス

MITライセンスで公開されており、商用利用を含めて扱いやすい部類です。一方で、1.0前の実装らしい制約がREADMEのKnown Issuesに率直に並んでいます。

最も実務に響くのが互換モードの倍率です。READMEは、互換モードでは出力がHuggingFace tokenizersと厳密に一致するよう相当な労力を払った一方、それが性能面で無視できないコストになっていると説明し、「全般に大幅な高速化は期待できるが、独自APIで得られる1000倍には届かない」と明記しています。作者はスレッド上で、互換モードの目安を200〜300倍程度と述べています。既存コードをほぼ変えずに差し替える運用なら、この帯が現実的な期待値です。

エコシステムはまだ形成の途中です。READMEには研究利用向けの引用形式（BibTeX）が置かれており、そのタイトルは「現代CPU上での1000倍高速なBPEトークナイズのためのSIMDとキャッシュ階層」と読める内容で、作者自身が技術的な主眼をこの2点に置いていることが分かります。Rustクレートは未公開で、作者は公開予定とAPI設計への意見募集を表明しています。技術的な解説記事・論文・発表動画も準備中とされています。一方で公開から数日でRuby移植（gigatoken-rb）が現れるなど、周辺の動きは早く進んでいます。GitHub Releaseが0件でバージョンの節目が読み取りにくい点と合わせ、本番投入するならPyPIのバージョンを固定し、--validate で出力一致を確認したうえで進めるのが安全です。

まとめ

トークナイザーは長らく「最適化し尽くされた枯れた部品」と見なされてきました。gigatokenが示したのは、そう思われていた領域にも1人の手で3桁の余地が残っていたという事実です。その改善が自分の用途に効くかどうかは別の問いですが、少なくとも確かめる手段は用意されているという点で、扱いやすいプロジェクトだと言えます。

参照ソース

・marcelroed/gigatoken（公式リポジトリ・README） — 3機体の実測表・ベンチマーク条件・FAQ・Known Issues・AI Use Disclosure・引用形式
・Hacker News — GigaToken: ~1000x faster Language model tokenization — 作者本人によるTTFT計測値、互換モードの倍率目安（200〜300倍）、事前学習用途の説明、Rustクレート公開予定
・PyPI — gigatoken — 配布バージョン（0.3.0〜0.9.0）・対応プラットフォーム・Python要件
・GitHub API — marcelroed/gigatoken — スター数・ライセンス・コントリビューター数・Release/タグ件数の実測（2026-07-25取得）