「モデルは十分速い。しかしトークナイザーが遅い」――これが2026年夏、LLMサービング業界を席巻している合言葉である。100万トークン級の長文脈モデルとエージェンティック・ワークフローが本番投入されるにつれ、これまで無視されてきた「トークン化レイテンシ」がTTFT（Time-to-First-Token）の主要な支配要因として浮上してきた。本記事では、この分野の主要4プレイヤー――Basetenkenizer、fastokens、Gigatoken、TokTier――を、一次情報に基づき徹底比較する。

なぜ今「トークン化レイテンシ」がボトルネックなのか

従来のLLM推論では、モデル本体のプリフィル・デコード処理が全体のレイテンシを支配し、トークナイゼーションは「無視できるほど短い前処理」と扱われてきた。しかし2026年、状況は一変している。プレフィックスキャッシュ（KVキャッシュ）ヒット率がフリートレベルで94.1%に達する現代のエージェンティック・サービングにおいて、モデル側のプリフィルは数ミリ秒で完結する。一方、トークン化は毎リクエスト律儀に走り続けるため、相対的な支配率が跳ね上がる。

ASU研究チームがClaude CodeおよびCodex CLIの153,951コール（10ヶ月分）を分析した結果、キャッシュヒット率が0.99に近づくとトークン化がTTFTに占める割合は10%から64%へと激増することが判明した。コンテキスト長86K〜123Kトークン、中央値追記量約1.4K文字というエージェント特有のワークロード特性が、この現象の背景にある。

1. Basetenkenizer ― Kimi K3特化のサービングパス最適化

Basetenが2026年7〜8月に公開したBasetenkenizerは、Moonshot AIのKimi K3（2.8Tパラメータ）モデルのサービングパスに完全特化した設計を採る。PyPIのbasetenkenizer、Hugging FaceのHubにbaseten/kimi-k3-tokenizerとして即座に導入可能である。

核心となる革新は、「単一ネイティブencode_segments呼び出し」という設計思想にある。従来のtiktokenベース実装では、Kimi K3特有の54個のタイプ付きセグメント、allow_specialポリシー、400k文字ごとのチャンク分割、25k文字での空白／非空白ラン分割といった複雑な安全ルールを、すべてPython側でループ処理する必要があった。Basetenkenizerはこれら一切をRust側の単一境界内で完結させる。

Basetenkenizerの6大最適化要素

1. 特化プリトークナイゼーションスキャナー：Kimi分割正規表現を事前認識し、汎用regexエンジンをバイパス
2. スタック常駐BPEマージティア：32バイト以下のプリトークンをスタック確保リンクドリスト＋線形最小ランク探索で処理し、ヒープ・優先度キューを完全回避
3. マルチコアセマンティクス：同一プリトークンを同一CPUコアへルーティング、400k文字チャンクは別コアで並列スケジュール
4. ネイティブタイプ付きセグメント：特殊トークンポリシーと互換性ルールをRust側で実行
5. ゼロコピーNumPy所有権移転：中間Python整数リストを完全排除
6. スマートポインタPyO3バインディング：abi3-py310、Cow値による文字列借用

ベンチマーク結果（52 vCPU Intel Xeon Platinum 8480+）

短シーケンス（〜10kトークン）でカスタムPython tiktokenパス比6倍以上高速、1MトークンシーケンスでKimi K3完全サービングパス比最大18倍高速という驚異的な数値を叩き出している。特筆すべきは、1Mトークン時点でオフライン特化のGigatokenをも1.41倍上回る点だ。

2. fastokens ― Crusoe × NVIDIA Dynamo製、TTFT削減のエース

fastokensはCrusoe CloudとNVIDIA Dynamoチームが共同開発したオープンソースRust BPEトークナイザーで、Apache 2.0ライセンスで公開されている。NVIDIA DynamoおよびSGLangにネイティブ統合済みという点で、汎用サービング分野で頭一つ抜けた存在だ。

3つのコア最適化戦略

戦略①：CPUMaxxing（CPUフル活用アーキテクチャ）
プリトークナイゼーションを「権限ゾーン」に分割（スレッドごと1つ、境界で1KBオーバラップ）し、本質的に逐次的だった正規表現スキャンを完全並列化。BPEエンコードには2段階キャッシュ（L1：スレッドローカルの64K固定スロットオープンアドレッシングハッシュ／L2：64シャードのグローバル共有キャッシュ）を導入した。L1ヒットはゼロ同期であり、マルチコア環境でニアリニアな速度向上を実現する。

戦略②：動的メモリ削減
GPT系のバイト→Unicodeマッピングをコンパイル時256エントリLUTに事前計算。内側ループから分岐を完全排除し、2バイト書き込みで完結させる。BPEマージヒープのエントリを16バイト（u64キー＋u64値）にパックし、単一整数比較で最小ランク探索を実行する徹底ぶりだ。

戦略③：正規表現エンジン最適化
PCRE2（JIT付き高性能正規表現ライブラリ）を優先採用し、非対応時はfancy-regexへフォールバック。スレッドごとにコンパイル済み正規表現を1コピー事前確保することで、ロック競合を排除しつつDFAキャッシュを温存する。

fastokensベンチマーク詳細

DeepSeek-V3.2、GPT-OSS-120B、MiniMax-M2.1、Mistral-Nemo-Instruct-2407を対象に、ShareGPTおよびLongBench-v2データセットで測定した結果：

• HF Tokenizer比 平均9.1倍高速、50kトークン以上では平均17.4倍（ピーク31倍）
• Grace CPU、バッチ=1、100kトークン条件で：HF 149-165ms → fastokens 6-13ms（92%以上削減）
• エンドツーエンドTTFT：GPT-OSS-120Bで最大40%削減、DeepSeek V3で18%削減

3. Gigatoken ― Marcel Rød製、GB/s級のオフライン超スループット

Gigatokenは「言語モデリング向け最速トークナイザー」を掲げるRust実装で、GitHub（marcelroed/gigatoken）で公開、pip install gigatokenで導入可能である。その数値は狂気の域に達している。

圧倒的オフラインスループット（AMD EPYC 9565 144コア環境）

Apple M4 Max（16コア）でもGPT-2で8.79 GB/s（HF比1,268倍）を叩き出す。SIMD最適化プリトークナイゼーション、階層的プリトークンキャッシュ、Pythonインタラクション最小化（encode_filesでRust側からファイル直接読み取り）が奏功している。

ただし注意点：Gigatokenはオフライン・データセット前処理特化であり、単一リクエスト低レイテンシ、タイプ付きセグメント、ゼロコピーNumPy引き渡しといったサービング特化機能を持たない。SentencePiece系（Gemma、ModernBERT、Mistral等）では最適化が未成熟で、3〜15倍程度に留まる点も要注意だ。

4. TokTier ― ASU製、ステートフル増分修復＋GPU完全トークン化

Arizona State Universityの張・曹両氏が2026年に発表したTokTier（arXiv:2607.29678）は、「セッション継続（小さな追記）」と「セッション初期化／再構築（巨大コンテキスト）」という2つのモードに完全対応したステートフル・トークン化サービスである。CPU増分修復とGPU完全トークン化のハイブリッド設計が最大の特徴だ。

パスA：CPU増分修復（セッション継続用）

前回のトークン列とバイトスパンを保持し、新規追記Δと直前サフィックス（デフォルト512文字）のみを再トークン化する。「安定境界チェック」により安全にスプライス可能かを判定し、失敗時はウィンドウを倍増（最大5回）してリトライ、最終的にフルリファレンス・トークン化へフォールバック。実測値は100K〜3M文字で0.5〜1.1ms、HF比437倍、ウォーム状態のGigatokenをも1M文字で2.1倍、2M文字で3.0倍上回る。

パスB：GPU完全トークン化（セッション初期化用）

GPT系正規表現プリトークナイゼーションを「ラン分解」へ再定式化することで、逐次的だった正規表現スキャンを完全並列化。文字を4クラス（letter/number/whitespace/other）に分類し、最大同クラスラン形成後にプレフィックススキャンで並列処理する。ピース長別に専用CUDAカーネル（スレッド／ワープ／ブロック per piece）で並列BPEマージを実行、CUDAグラフ捕獲でホスト同期を8→2回に削減。1M文字フルコンテキストを0.87msでエンコード、HF比491倍、持続スループット3.8〜4.7 GB/sを達成している。

正しさの保証と実測効果

17トークナイザーファミリ、1.5×10¹⁰スプリットチェック、12.4TB実テキスト全掃討、93,000+リプレイエージェントステップでゼロ乖離という驚異的な検証を経ている。vLLM統合時のエンドツーエンド効果は、負荷時中央値TTFTで16〜34%低減、バースト到着時P99 TTFTで23%低減。4コアCPU修復プール＋1GPUで50ms P99目標下1,821 req/sを維持し、16コアステートレスCPUフロントエンドが40 req/sで飽和するのに対し圧倒的優位を示す。

【徹底比較】4大トークナイザー画像比較表

比較表①：アーキテクチャ特性の対比

比較表②：ヘッドライン性能数値

比較表③：最適ユースケース対応マトリクス

比較表④：ハードウェア・環境依存性

比較表⑤：導入容易性と統合エコシステム

実務での選定ガイドライン ― どれを選ぶべきか

シナリオ別最適解

◆ Kimi K3本番サービングを運用中なら → Basetenkenizer一択
K3特有の54タイプ付きセグメント、allow_specialポリシー、K3制御文字列のリテラル出現などの複雑なセマンティクスに完全対応する唯一のライブラリだ。1MトークンでオフラインチャンピオンのGigatokenをも上回る点は特筆に値する。

◆ 汎用長文脈サービングでTTFT削減を狙うなら → fastokens
DeepSeek、Qwen、GLM、Nemotron、Mistralといった主流モデル群に幅広く対応し、SGLangやDynamoへのネイティブ統合で導入摩擦が極小。Grace CPU環境での100kトークン処理を149msから6msへ削減する劇的効果は、実運用で最もインパクトが大きい。

◆ データセット前処理・オフラインコーパス処理なら → Gigatoken
GB/s級の圧倒的スループットにより、数TB規模の事前学習コーパストークン化を桁違いの速度で完了できる。encode_files APIによるRust側直接ファイル読み取りは、Pythonループでは到達不可能な領域だ。

◆ 高頻度追記のエージェントセッションなら → TokTier
コーディングエージェント、リサーチエージェントなど、中央値1.4K文字の小規模追記が支配的なワークロードでは、ステートフル増分修復の0.5〜1.1msという値が決定的優位となる。GPU完全パスとのハイブリッド設計により、初期化時の巨大コンテキストにも対応する。

ベンチマーク解釈における5つの落とし穴

1. ハードウェア依存性：コア数、NUMAピン留め、コールド／ウォームキャッシュ、CJK含有率で数値は大きく変動する
2. マーケティング数値の希釈：Gigatokenの1,000倍という数値は144コアEPYC＋大規模ファイルでのピーク値であり、控えめハードウェアでの独立再現はtiktoken比20〜30倍程度に落ち着く
3. 比較対象の非対称性：Basetenの18倍は「完全K3サービングパス vs 従来tiktoken実装」であり、純粋BPEマイクロベンチではない
4. 正規表現バックエンド依存：fastokensはPCRE2 JIT非対応ケース（Kimi正規表現等）でフォールバックスキャナーとなり性能低下する
5. GPUパスの対応範囲：TokTierのGPU完全パスは現状cl100k／o200k／DeepSeek系のみ、未対応はCPUリファレンスへフォールバック

2026年後半以降の技術トレンド予測

今回の4大トークナイザー分析から見えてくるのは、以下5つの共通進化ベクトルである。

①ステートフル化の標準化：TokTierが示した「セッション・トークン状態の保持と増分修復」パラダイムは、vLLMやSGLangなどのサービングフレームワークへのネイティブ統合が進むはずだ。KVキャッシュ生存を超えた「トークン状態キャッシュ」が次世代の標準となる。

②GPUトークン化の汎用化：ラン分解アプローチのSentencePiece系への拡張研究が既に進行中であり、CPUオンリー時代の終焉が視野に入る。

③サービング特化APIの標準化：Basetenkenizerのencode_segmentsのような「タイプ付きセグメント一括エンコード＋ゼロコピー配列引き渡し」インターフェースが、HF Tokenizers本体にも取り込まれる可能性は高い。

④ハイブリッドCPU/GPUスケジューリング：TokTierの「小セグメントはCPU、大セグメントはGPU、バックプレッシャー時はCPUフォールバック」という適応的ルーティングが標準化へ向かうだろう。

⑤検証済み正しさのインフラ化：バージョン固定差分テスト、実テキスト全掃討、ランタイム・シャドー検証の三点セットが、プロダクション・トークナイザーの品質保証ベースラインとなる。

まとめ ― トークナイザー選定は「用途特化」の時代へ

2026年8月現在、トークナイザーの世界には用途に応じた明確な勝者が存在する。もはや「万能トークナイザー」という幻想は捨て、ワークロード特性に応じた最適解を選ぶ時代となった。オフライン大量処理ならGigatoken、汎用オンラインサービングならfastokens、Kimi K3特化本番ならBasetenkenizer、ステートフル・エージェントセッションならTokTier――この4象限マッピングを頭に叩き込んでおけば、貴社のLLMインフラは確実に一段階上のパフォーマンスへ到達できるはずだ。

特に注目すべきは、キャッシュヒット率が0.99に近づく本番サービング環境において、トークナイザー選定次第でTTFTが40%変動するという事実である。これはもはや些末な最適化ではなく、UX・コスト・スケーラビリティを直撃する経営マターと言ってよい。今こそ、自社ワークロードのトークン化レイテンシを実測し、適切な選択肢へ移行するタイミングである。

参考リンク

• Basetenkenizer公式ブログ
• Basetenkenizer Hugging Face
• fastokens公式ブログ（Crusoe）
• fastokens GitHub
• Gigatoken GitHub
• Gigatokenベンチマーク詳細（MarkTechPost）
• TokTier論文（arXiv）