Skip to content
Published on

トークナイザの内部 — 日本語がトークンを多く食う理由とその代価

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに

同じ内容を英語で書くと 100 トークン、韓国語で書くと 190 トークンになります。API の料金も、文脈窓が埋まる速さも、その分だけ違います。この記事では、その差がどこから来るのかを、実際のトークナイザをダウンロードして測った数字で説明します。

この記事の測定値は論文の引用ではなく、直接実行した結果です。公開されたトークナイザファイルをダウンロードして同じ文章をトークン化したものなので、誰でも再現できます。

数値は 2026-08-12 に論文・公式レポート・config.json で直接確認しました。モデルは更新されるため、原典を再度確認してください。

バイトレベル BPE

いま出ているモデルはほぼすべてバイトレベル BPE を使います。Qwen3 レポートは、Qwen のトークナイザがバイトレベルのバイトペア符号化を実装しており、語彙サイズは 151,669 であると記しています(arXiv:2505.09388)。

動作は二段階で理解すれば十分です。まずすべてのテキストを UTF-8 バイトに変換します。次に学習コーパスで頻繁に共起するバイト対を繰り返し併合して、より長い断片を作ります。どんな文字が来ても少なくともバイト単位では表現できるため、未登録語の問題が消えます。

ここから CJK の不利が始まります。ASCII の英字は 1 バイトですが、ハングル音節や大半の CJK 文字は UTF-8 で 3 バイトを占めます。併合規則が学習されていない断片はそのままバイトへ分解され、一文字がトークン三つになります。

直接測る

公開リポジトリからトークナイザファイルをダウンロードし、同じ意味の文章をトークン化しました。英語 392 文字、韓国語 199 文字で同じ内容を収めた段落です。

                英語 392 文字      韓国語 199 文字
                (UTF-8 392B)       (UTF-8 489B)

Qwen3-8B          76 トークン        148 トークン    -> 1.95 倍
DeepSeek-V3       76 トークン        142 トークン    -> 1.87 倍
Mixtral-8x7B      81 トークン        218 トークン    -> 2.69 倍

文字あたりトークン (韓国語)
Qwen3-8B      1.34 文字/トークン
DeepSeek-V3   1.40 文字/トークン
Mixtral-8x7B  0.91 文字/トークン

Mixtral の最後の行を見てください。文字あたりトークンが 1 を下回っています。ハングル一文字を表すのにトークンが一つより多く要るという意味で、併合規則が不足してバイト単位に分解されている合図です。

短い文で言語別の比較もしてみました。同じ意味の一文です。

言語      文字数  UTF-8   Qwen3   DeepSeek-V3   Mixtral
英語        73     73B      13         13          13
韓国語      29     73B      22         19          32
日本語      28     84B      19         20          29
中国語      19     57B      12         10          20

中国語が最も効率的です。一文字が担う意味が大きく、よく使われる漢字が単一トークンへ併合されているためです。この短文では日本語と韓国語はいずれも英語よりトークンを多く消費しており、どちらが有利かはトークナイザによって入れ替わります。短い一文の測定なので、傾向としてのみ受け取ってください。

語彙サイズのトレードオフ

三つのトークナイザの語彙サイズはそれぞれ 151,669、128,815、32,000 です。差がそのまま結果に出ています。語彙 32,000 の Mixtral は韓国語の段落に 218 トークンを使い、語彙 15 万規模の Qwen3 は 148 トークンで済みます。

では語彙を無制限に増やせばよいのでしょうか。そうではありません。代償があります。

第一に、埋め込み行列が大きくなります。Qwen3-8B は幅が 4096 なので、埋め込み一つで約 6.2 億パラメータです。語彙を二倍にすると、ここだけで 6 億パラメータが増えます。小さいモデルほどこの比重が大きくなります。

第二に、出力ソフトマックスが大きくなります。トークンごとに語彙全体に対する確率を計算するため、語彙サイズがそのまま最終層の演算量になります。

第三に、まれなトークンは学習信号をあまり受け取りません。語彙を増やして作ったトークンがコーパスにまれにしか現れなければ、その埋め込みは十分に学習されません。

Llama 3 の事例がこの均衡をよく示しています。レポートは語彙サイズを 128,000 とし、既存のトークナイザに 28K トークンを追加して非英語をより良く支援するようにし、英語サンプル基準の圧縮率がトークンあたり 3.17 文字から 3.94 文字へ改善したと記しています。同じ箇所では、選ばれた非英語言語から 28K トークンを追加したことが圧縮率と下流性能の両方を改善し、英語のトークン化には影響がなかったとも述べています(arXiv:2407.21783)。

config の vocab_size は語彙数ではない

最初の記事で指摘した罠をここで確認します。Qwen3-8B の config は vocab_size が 151936 です。ところがレポートが示した語彙サイズは 151,669 であり、トークナイザファイルを直接開いて確認した値も 151,669 でした。

モデル           config vocab_size    実際のトークナイザ語彙
Qwen3-8B             151,936                 151,669
DeepSeek-V3          129,280                 128,815
Mixtral-8x7B          32,000                  32,000

差は埋め込み行列をハードウェアに合わせて切り上げた余白です。Mixtral のようにぴったり合う場合もあります。パラメータを数えるときは config の値を、トークン数を論じるときはトークナイザの値を使えば足ります。

実務では何を意味するか

トークン効率は三か所でコストに変わります。

第一に文脈窓です。128K 文脈といっても、CJK の文書を入れれば同じ窓に収まる原文の分量は英語の半分程度になります。前の記事で見たとおり、文脈が長くなればプリフィルの演算は二乗で、KV キャッシュは線形で増えます。トークンが二倍ならキャッシュのメモリも二倍です。

第二に生成速度です。トークン単位で生成するため、同じ分量の日本語や韓国語の回答は英語より多くのデコードステップを必要とします。

第三に学習データの効率です。Llama 3 レポートが圧縮率の改善について、同じ学習計算量でより多くのテキストを読めるようにすると表現したのは、まさにこの意味です。

モデルを選ぶときに確認すること

CJK を多く扱うなら、ベンチマークのスコアより先に確認すべきことがあります。実際に扱う文書をそのモデルのトークナイザでトークン化してみることです。トークナイザファイルはたいてい公開されているので、モデルの重みをダウンロードしなくても確認できます。

同じ文書があるモデルでは 1.9 倍、別のモデルでは 2.7 倍になります。この差はベンチマークの表には出てきませんが、運用コストにはそのまま反映されます。

おわりに

トークナイザはモデル構造のなかで最も注目されない部分ですが、CJK の利用者にとっては最も体感の大きい部分です。バイトレベル BPE において 3 バイト文字は構造的に不利であり、語彙サイズを上げれば改善しますが埋め込みとソフトマックスのコストも一緒に増えます。自分で測ってみるのが最も確実です。再現するのも難しくありません。

参考資料

試してみる

シリーズ

Discuss on Twitter • View on GitHub