💬 NLP

Peek2: Regex-free Byte-level Byte-Pair Encoding Pretokenizer for LLM Inference on Edge Devices

本論文は、Byte-level BPE 用の高度に最適化された正規表現不要のプレトークナイザー「Peek2」を紹介するものであり、標準的な cl100k ベースのトークナイザーと同一の出力を維持しつつ、エッジデバイスにおいてマイクロベンチマークスループットを最大 2.48 倍、全体のエンコード速度を 1.14 倍向上させる。

原著者： Liu Zai, Iraklis Klampanos

公開日 2026-05-04

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Liu Zai, Iraklis Klampanos

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

長い手紙を友人に送ろうとしているが、その友人は短い特定のコード語しか理解できないと想像してください。手紙を送る前に、文をそれらのコード語に分解する必要があります。このプロセスをトークン化と呼び、GPT-3 や LLaMa などのコンピュータはこれによって人間の言語を理解しています。

あなたが読んでいるこの論文は、Peek2という新しいツールを紹介しています。その仕組みを簡単に説明します。

問題：「Regex」による渋滞

現在、ほとんどのコンピュータはテキストをこれらのコード語に分解するために、Regex（正規表現）と呼ばれる方法を使用しています。Regex を、クラブの入り口にいる非常に厳格で複雑な警備員だと考えてください。

その警備員は、膨大な規則リスト（分岐）を持っています。
一人の人（文字）が到着すると、警備員は規則 1 に照らしてチェックします。適合しなければ規則 2 をチェックし、それも失敗すれば規則 3 と続きます。
この「チェック、失敗、再チェック」というプロセスは、ラップトップやタブレットなどの小型で低電力のデバイス（エッジデバイス）では特に遅くなります。まるで、誰かが近づくるたびに警備員が巨大な規則書をめくって待たせているようなものです。

解決策：「Peek2」というショートカット

著者たちは、この作業をより高速かつメモリ使用量を減らして行う新しい方法としてPeek2を作成しました。

警備員が規則書をめくる代わりに、Peek2 はチートシート（ルックアップテーブル）を使用します。

「Peek（覗き見）」：文字を一つずつチェックするのではなく、Peek2 は一度に二つの文字を見て（先を覗き見るように）、
カテゴリ分類：それらの二つの文字を簡単なバケットに素早く分類します（例：「スペースか？」「数字か？」「文字か？」）。
チートシート：二つのバケットしか見る必要がないため、著者たちは小さな 7x7 のグリッド（スudoku の盤面のよう）を作成しました。二つのバケットを見て、グリッド上のマスを探せば、グリッドが次に何をすべきかを即座に教えてくれます。

比喩：

古い方法（Regex）：迷路の前に立ちます。左のドアを試します。施錠されています。右のドアを試します。施錠されています。裏のドアを試します。開いています。通り抜けます。そして、列にいるすべての人に対してこれを繰り返します。
新しい方法（Peek2）：単一の巨大な地図が描かれた壁の前に立ちます。自分の位置を指差すと、地図が即座に出口への線を描きます。推測も施錠されたドアもなく、ただの直接の経路です。

なぜこれが重要なのか

この論文は、「迷路」を「地図」に置き換えることで、プロセスがはるかに高速化されたと主張しています。

速度：一部のテストでは、分解の段階だけで2.48 倍高速でした。
全体：テキストをコード語に変換する作業全体を見ると、全体で約14% 高速でした。
精度：古い方法と全く同じ結果を出力します。「ドロップイン代替」つまり、システムを変更したり壊したりすることなく、古い警備員を新しいものに差し替えることができます。

注意点（制限事項）

この論文は、このツールが何を行わないかについて正直に述べています。

特定のデバイス向け：デスクトップコンピュータでテストされました。著者たちはスマートフォンやタブレットでも機能することを期待していますが、まだ証明されていません。
特定のモデル向け：「cl100k」スタイル（GPT-3 や LLaMa-3 など）を使用するモデル向けに機能します。すべての AI モデルを魔法のように修正するわけではありません。
バグも引き継ぐ：古い方法には、単語を誤って分割するなど、奇妙な間違いがいくつかありました。Peek2 は古い方法の動作を正確にコピーするように設計されているため、それらの同じ間違いも引き継ぎます。それらの間違いを修正するには、AI モデルの再訓練が必要となり、単にツールを差し替えるよりもはるかに大規模な作業となります。

要約：Peek2 は、AI のためにテキストを切り分けるためのより賢く高速な方法であり、スーパーコンピュータを必要とせず、日常のデバイスでスムーズに動作するように設計されています。

以下は、論文「Peek2: Edge デバイスにおける LLM 推論のための正規表現不使用のバイトレベル BPE プリトークナイザ」の詳細な技術的サマリーです。

1. 問題定義

大規模言語モデル（LLM）は、生テキストをトークン列に変換するために、バイトレベルのバイトペアエンコーディング（BPE）トークナイザに依存しています。このプロセスにおける重要な初期段階がプリトークナイズであり、ペアマージフェーズに先立ってテキストをより小さな断片に分割します。

現状: ほとんどのプリトークナイザ（GPT-3、LLaMa-3、Qwen-2.5 で使用される cl100k 標準を含む）は、**正規表現（Regex）**に依存しています。
ボトルネック: 正規表現のコンパイルと実行は高性能なサーバー CPU 上では許容範囲ですが、以下の理由によりエッジデバイス（デスクトップ、ラップトップ、組み込みシステム）では大きなオーバーヘッドをもたらします。
- 限られた処理能力。
- 制限されたメモリ。
- 複雑な正規表現エンジンに必要な特定の命令セットの欠如。
- プリトークナイズフェーズの逐次的で並列化不可能な性質。
制約: 最適化は、元のトレーニング用プリトークナイザと**バグ単位で互換性（bug-for-bug compatibility）**を維持しなければなりません。モデルの再トレーニングなしに分割境界を変更すると、BPE 圧縮率と下流タスクのパフォーマンスが低下します。

2. 手法：Peek2 アルゴリズム

著者は、cl100k プリトークナイザの正規表現不使用の実装であるPeek2を提案します。非決定性有限オートマトン（NFA）や複雑な正規表現マッチングの代わりに、Peek2 は Hopcroft の DFA 最小化アルゴリズムに触発された決定論的かつテーブル駆動のアプローチを利用します。

主要な技術的コンポーネント:

文字分類（PeekCategorize）:
複雑なパターンに対して生の Unicode スカラー値をマッチングする代わりに、Peek2 はまず各文字をその Unicode クラスに基づいて7 つの離散カテゴリのいずれかにマッピングします。
1. ASCII スペース
2. ASCII 単一引用符
3. ASCII CR/LF
4. Unicode 文字
5. Unicode 空白文字
6. Unicode 数字
7. その他のすべてのスカラー
  これにより、入力空間は $10^5$ 以上の潜在スカラーからわずか 7 つのカテゴリに削減されます。
分岐決定ルックアップテーブル:
- 元の正規表現ロジックは、エンジンが順次マッチングを試み、失敗した場合にバックトラックする階層的な分岐（Branch0 から Branch6）を含みます。
- Peek2 は、この逐次的な「試行と失敗」ロジックを $7 \times 7$ のルックアップテーブルに置き換えます。
- アルゴリズムは現在の文字と次の文字を「Peek（覗き見）」し、それらのカテゴリを決定して、そのペア（タプル）をテーブルへのインデックスとして使用します。
- テーブルエントリは、バックトラックやスタックベースの失敗処理を不要にする、実行する**分岐 ID（0–6）**を直接返します。
アルゴリズムの流れ:
1. 現在の文字と次の文字を分類する。
2. 単一のテーブルルックアップを実行して、正しい分岐ハンドラを選択する。
3. 特定の分岐ロジックを実行する（これは特定のセグメントタイプのみを処理するように簡略化されている）。
4. 残りの文字列を再帰的に処理する。

複雑性分析:

時間計算量: $O(n)$ （ $n$ は入力長）。NFA ベースの正規表現エンジンが $O(n \times k)$ または $O(n \times m)$ であるのに対し、各文字は 1 回（稀なフォールバックケースでは 2 回）訪問されます。
空間計算量: $O(1)$ 。ルックアップテーブルは固定サイズ（ $7 \times 7$ ）であり、正規表現コンパイラが生成する複雑な状態機械と比較して無視できる程度のメモリしか必要としません。

3. 主要な貢献

正規表現不使用の実装: cl100k プリトークナイザにおける正規表現依存の完全な除去。複雑なパターンマッチングを、軽量で決定論的な状態機械に置き換えました。
エッジ最適化: 低リソース環境向けに特別に設計されており、正規表現コンパイルのオーバーヘッドなしで、定数メモリ使用量と線形時間計算量を提供します。
バグ単位での互換性: このアルゴリズムは、数学的に元の正規表現ベースの cl100k トークナイザと同一の分割境界を生成することが証明されており、モデルの再トレーニングを不要にします。
オープンソース統合: 実装はHugging Face の tokenizers ライブラリ（Safe Rust）に統合され、コミュニティですぐに利用可能になりました。

4. 実験結果

著者は、Intel Core i5-13600KF CPU 上で、4 つのデータセット（英語（en）、中国語（cn）、コード（code）、数学（math））を用いて Peek2 をテストしました。

マイクロベンチマーク（プリトークナイズフェーズのみ）:
- スループット向上: 元の正規表現実装と比較して最大2.48 倍高速。
- データセットごとの変動:
  - 英語（en）: 約 2.48 倍の高速化（単語レベルのトークナイズによる最大の gains）。
  - 中国語（cn）: 約 2.20 倍の高速化（この段階での中国語の分割がより粒度的でないため、 gains は低い）。
- 正しさ: ベースラインの正規表現トークナイザとの出力が 100% 同一。
エンドツーエンドベンチマーク（完全な BPE パイプライン）:
- 全体スループット: すべてのタスク（エンコーディングと BPE トレーニング）で1.03 倍から 1.14 倍向上。
- コード/数学への影響: これらのデータセットはプリトークナイズに大きく依存し、下流のペアマージ操作が少ないため、エンコーディングタスクにおいて最も顕著な相対 gains を示しました。
- 時間短縮: code データセットでは、プリトークナイズ時間がパイプライン全体の**22.8%から14.0%**に低下しました。

5. 意義と今後の課題

意義: Peek2 は、エッジベースの LLM 推論における重要なボトルネックに対処します。逐次的なプリトークナイズフェーズを最適化することで、コンシューマハードウェア上のコールドスタート時間の短縮とスループット向上を実現し、サーバー中心からエッジ - クラウドハイブリッド推論アーキテクチャへの移行を促進します。
限界と今後の方向性:
- 現在は cl100k 様式のプリトークナイザに限定されています。
- 実験はデスクトップ CPU で実施されましたが、今後の研究では組み込みデバイスでのテストや、アルゴリズムの TPU/APU への移植を目指します。
- 著者は、Peek2 が現在の（バグを含む）正規表現の動作と互換性がある一方で、元のトレーニングデータにはいくつかの分割上の「バグ」（例えば、縮約形の誤解釈など）が存在すると指摘しています。これらを修正するにはモデルの再トレーニングが必要であり、これはこの最適化の範囲外です。

要約すると、Peek2は、複雑な正規表現ロジックを単純で分類されたルックアップテーブルに置き換えることで、モデルのパフォーマンスを犠牲にしたり再トレーニングを必要としたりすることなく、エッジデバイスにおける LLM トークナイズを大幅に加速できることを実証しています。