トークナイザー拡張：モデルのトークナイザーをその場でアップグレードする

本日は、LFM2.5-8B-A1B の新しいトークナイザーの背後にあるレシピをご紹介します。学習済みモデルのトークナイザーを、ゼロから再学習することなくそのままアップグレードする手法です。元のトークナイザーが細かく分割しすぎていた言語を改善するため、語彙を 65K から 128K へ倍増させました。ヒンディー語とベトナム語はトークン数がそれぞれおよそ 2.4 分の 1、2.6 分の 1 に、タイ語は最大 4.0 分の 1 になり、これらの言語のオンデバイスでの 1 文字あたりのデコードは 2.2〜3.7 倍高速になると見積もっています。もともと十分に扱えていた言語の品質は維持されています。

LFM2.5-8B-A1B は Hugging Face で公開しており、拡張した 128K トークナイザーも同時に公開しています。手法の詳細、アブレーション、デバイスごとの数値はテクニカルレポート.

論文を読む

オンデバイスのトークナイザーが小さいままである理由

トークナイザーは事前学習の開始時に固定され、その時点の学習コーパスの構成に比例して語彙を分割します。当時サンプルが少なかった言語は、トークナイザーが調整対象とした言語に比べ、1 単語あたりはるかに多くのトークンに分割されてしまいます [1, 2]。モデルは出力トークン 1 つごとにデコーダを 1 回走らせるため、この余分な断片化は、それらの言語の利用者にとって実際のレイテンシ、計算量、消費電力の増加として跳ね返ります。

クラウドのモデルは、埋め込み行列と出力（LM ヘッド）行列がパラメータ全体のごく一部にすぎないため、大きな語彙でこのコストを覆い隠せます。しかし小さなオンデバイスモデルではそうはいきません。オンデバイスで多く問題になるバッチサイズ 1 では、デコードはメモリ帯域に律速され、LM ヘッドは 1 ステップごとに語彙全体を読み出します。語彙が大きいほど、トークンごとに転送し RAM に保持する行列も大きくなるため、エッジ向けモデルはコンパクトな語彙を採用し、優先言語以外の断片化を受け入れているのです。

LFM2 の元の 65K バイトレベル Byte Pair Encoding（BPE）[3, 4] トークナイザーは、英語、コード、および一定範囲の言語向けに構築されており、ヒンディー語、ベトナム語、タイ語に割ける余地はほとんどありませんでした。私たちはこれを、すでに学習済みのチェックポイント上で解決したいと考えました。トークナイザーを作り直して事前学習をやり直せばその計算資源が無駄になり、無関係なサードパーティ製のトークナイザーを差し込めば、必要以上に難しい転移の問題を解くことになります [5]。

レシピ：置き換えるのではなく拡張する

私たちのトークナイザー拡張レシピは、新しいトークナイザーの構築と、モデルのそれへの適応という 2 つの部分から成ります。トークナイザーを自社で設計しているため、新しいものを既存のものの直接の拡張として構築でき、以降の工程がすべてシンプルになります。

Figure 1. The tokenizer expansion pipeline. We extend the source tokenizer's BPE merges to build the 128K vocabulary (top), reinitialize the model's embeddings from it, and adapt the model in two stages before mid-training and post-training (bottom).

1. BPE のマージを継続する

BPE トークナイザーは、小さなトークンを大きなトークンに結合するマージ規則の順序付きリストによって定義されます。本レシピでは、新しいトークナイザーのマージテーブルに元のマージを取り込んで固定し、多言語コーパス上で BPE の学習を続けます。これにより 2 つの有用な性質が得られます。第一に、元の 65K トークンの大部分がそのまま引き継がれるため、学習済みの表現が直接転移します。第二に、新しいトークンはすべて、元のトークン列へ厳密に分解できます。

2. モデルがすでに知っていることから新しい埋め込みを初期化する

この厳密な分解のおかげで、新しいトークンの埋め込みは簡単に初期化できます。引き継がれたトークンは元の埋め込み行をそのまま保持し、新しいトークンは構成するサブトークンの行の平均を受け取ります。ランダム初期化は一切なく、トークナイザー間のアライメントを解く必要もありません。LFM2.5-8B-A1B は入力埋め込みと出力埋め込みを結合しているため、1 つの行列で両方をカバーできます。

3. モデルを 2 段階で適応させる

すべてのパラメータを一度に学習させると、すでにうまく動いていた部分が劣化したため、適応を 2 段階に分け、いずれも通常の中間学習・事後学習の前に実施しました。

  • ステージ 1：埋め込みのみ モデルの残りを固定したまま、新しい行のみを 600B トークンで学習します。本体を乱すことなく新しいトークンが落ち着き、これだけで置き換え時に失われた品質の大半を回復できます。
  • ステージ 2：全体の継続事前学習 すべてのパラメータの固定を解除し、バランスの取れた多言語配合の 400B トークンで事前学習を続けます。これにより新しい語彙がモデル本体に馴染み、残る差が埋まります。

ステージ 2 の後、チェックポイントはそのまま通常の LFM2.5 パイプラインに投入でき、他に変更は必要ありません。

新しいトークナイザーがもたらすもの

最大の成果は、必要な場所での圧縮です。英語とコードは設計どおり同等を保ち、すでに対応していた言語はわずかに改善し、これまでトークン化が不十分だった言語は大幅に改善しました。
Figure 2. Encoding-length reduction of the expanded tokenizer over the source, per language (source token count ÷ expanded token count on the same text). Higher is better. 1.0× is parity.

削減幅が最も大きいのはタイ語（4.0 倍）、ベンガル語（3.4 倍）、ベトナム語（2.6 倍）、ヒンディー語（2.4 倍）です。

以下は、同じ文をいくつかの言語で、旧トークナイザーと新トークナイザーそれぞれでトークン化したものです。
Figure 3. The sentence "The train is running ten minutes late." encoded by the source 65K tokenizer and the expanded 128K tokenizer. Each box is one token, and every token is one decoder step. A character that spans several adjoining boxes is split by the source tokenizer into that many byte-level tokens. The reduction shown next to each language is for this sentence. Corpus-level averages are 2.4× for Hindi, 3.4× for Bengali, 2.6× for Vietnamese, and 4.0× for Thai.

トークンが減れば、デコードは速くなる

1 単語あたりのトークンが減っても、それが語彙拡大のコストを上回らなければ意味がありません。65K から 128K への拡大により、参照デバイス（M4 Max の CPU と GPU、および Snapdragon 8 Elite Gen 5）でトークンあたりのデコードは 7〜10% 遅くなります。LM ヘッドが大きくなり、毎ステップ読み出されるためです。しかしユーザーが実際に体感するのは、トークンあたりではなく文字あたりの時間です。この圧縮率とトークンあたりのコストを合わせると、以下の正味の結果になります。
Figure 4. Synthesized decode speedup per character of generated output (M4 Max GPU shown, the other devices are within a few percent). Values above 1.0× mean the same text is produced faster with the expanded tokenizer.

これは私たちが意図して選んだトレードオフです。これまで手薄だった文字体系は大きく高速化し、旧トークナイザーがすでにうまく扱えていた言語は、トークンあたりの小さく一様なコストを負担して、デコードで最大 9% 程度の後退が生じます。私たちが対象とする言語とデバイスにおいて、この交換は十分に見合うものです。語彙をこれ以上大きくすると、スマートフォンでのスループット低下（Snapdragon の 256K では最大 37%）が追加の圧縮効果を上回るため、128K で止めました。

品質は維持される

その場でのアップグレードは、モデルがすでにできていたことを損なわずにカバー範囲を広げられて初めて意味があります。トークナイザーの変更とその後の学習の効果を切り分けるため、元モデル、ゼロショットでの置き換え、ステージ 1、ステージ 2 という 4 つの管理された時点で、8 つのベンチマークの総合値を追跡しました。
Figure 5. Aggregate quality (unweighted mean of eight benchmarks) across the adaptation stages. The zero-shot swap loses about 6 points, stage 1 recovers most of it, and stage 2 closes the gap and passes the source.

回復は着実です。置き換えで総合 5.8 ポイントを失い、ステージ 1 でそのうち 4.8 ポイントを取り戻し、ステージ 2 で残りを回復して元モデルを上回りました。元モデルを超えた分は、語彙の変更そのものよりも、ステージ 2 で追加した 400B トークンの事前学習によるものと考えられます。重要なのは、128K トークナイザーを使いながら、拡張後のモデルが知識・数学・コード・多言語の各ベンチマークで水準を維持ないし改善している点です。

言語別の Global-MMLU [6] は、目標の両面を同時に示しています。すでに対応していた言語は水準を保ち、トークン化が不十分だった言語は伸びています。

Figure 6. Global-MMLU accuracy (5-shot, chance = 25%). Under-tokenized languages see large gains. Previously supported languages hold steady.

この手法が使える場面

本レシピが適合するのは特定のケースです。トークナイザーを自社で所有しており、元の BPE マージを継続できること — つまり元のマージ規則と特殊トークンの設定が手元にあることが前提です。既製のサードパーティ製トークナイザーへ移行する場合には役立たず、その場合はゼロショット転移の手法が適切です [5]。またステージ 2 には継続事前学習の計算コストがかかるため、元の学習が十分に高価で、それを再利用する方が一からやり直すより有利な場合に最も効果を発揮します。

はじめに

LFM2.5-8B-A1B は Hugging Face にて LFM Open License v1.0 のもとでオープンウェイトとして公開しており、llama.cpp、MLX、vLLM、SGLang 向けの導入ガイドも用意しています。拡張した 128K トークナイザーも重みとあわせて公開しています。手法の詳細、アブレーション、デバイスごとの数値はテクニカルレポート.

引用

本成果を利用される場合は、次の技術レポートを引用してください：

Jimmy T.H. Smith, Tarek Dakhran, Alberto Cabrera, Simon S. Lee, Paul Pak, Aditya Tadimeti, Tim Seyde, Maxime Labonne, Alexander Amini, and Mathias Lechner (2026). In-Place Tokenizer Expansion for Pre-trained LLMs. arXiv:2607.15232.

@article{smith2026inplace,
  title   = {In-Place Tokenizer Expansion for Pre-trained LLMs},
  author  = {Smith, Jimmy T.H. and Dakhran, Tarek and Cabrera, Alberto and Lee, Simon S. and Pak, Paul and Tadimeti, Aditya and Seyde, Tim and Labonne, Maxime and Amini, Alexander and Lechner, Mathias},
  journal = {arXiv preprint arXiv:2607.15232},
  year    = {2026},
  url     = {https://arxiv.org/abs/2607.15232},
}

参考文献

[1] Aleksandar Petrov, Emanuele La Malfa, Philip H. S. Torr, and Adel Bibi. (2023). Language model tokenizers introduce unfairness between languages. NeurIPS. https://arxiv.org/abs/2305.15425

[2] Phillip Rust, Jonas Pfeiffer, Ivan Vulić, Sebastian Ruder, and Iryna Gurevych. (2021). How good is your tokenizer? On the monolingual performance of multilingual language models. ACL-IJCNLP. https://arxiv.org/abs/2012.15613

[3] Rico Sennrich, Barry Haddow, and Alexandra Birch. (2016). Neural machine translation of rare words with subword units. ACL. https://arxiv.org/abs/1508.07909

[4] Alec Radford, Jeff Wu, Rewon Child, David Luan, Dario Amodei, and Ilya Sutskever. (2019). Language models are unsupervised multitask learners. OpenAI Technical Report. https://shorturl.at/hHoQR

[5] Benjamin Minixhofer, Edoardo M. Ponti, and Ivan Vulić. (2024). Zero-shot tokenizer transfer. NeurIPS. https://arxiv.org/abs/2405.07883

[6] Shivalika Singh et al. (2024). Global MMLU: Understanding and addressing cultural and linguistic biases in multilingual evaluation. arXiv. https://arxiv.org/abs/2412.03304