LLMトークナイザー税：言語がAIのコストとコンテキストに与える影響

LLMトークナイザー税は、測定可能なコストとコンテキストのペナルティです。二つのプロンプトは同じ意味を持ちながら、異なる言語を使用するために非常に異なるトークン数を消費することがあります。

2026年7月の研究では、6つのトークナイザーを使用して997の整列した文をテストしました。OpenAIの古い`cl100k_base`エンコーディングを使用した場合、10のインドの言語は英語に対して平均8.0倍の単語生産性税を持っていました。マラヤーラム語は13.04倍に達しました。新しい`o200k_base`は平均を2.1倍に削減しました。この研究は、トークン化だけが悪い回答を引き起こすことを証明するものではありませんが、価格と使用可能なコンテキストがモデルが推論を開始する前に乖離する可能性があることを示しています。

対象者： 中級者

直接的な回答： 英語のトークン数から多言語AI製品を推定しないでください。整列した生産テキストで正確なトークナイザーをテストし、リクエスト全体を測定し、品質を別々に評価し、モデルやトークナイザーが変更されるたびにテストを再実行してください。

LLMトークナイザー税が測定するもの

言語モデルは、単語や文字ではなくトークンIDを受け取ります。トークナイザーはテキストをトークンユニットに分割し、それらをIDにマッピングします。一部のトークナイザーは、最初にテキストを正規化します。一般的なフラグメントは1つのトークンに収まることがあります。あまり表現されていないスクリプトや単語の形は、いくつかのトークンやバイトに分かれることがあります。

この論文の主要な指標は単語生産性です：空白で区切られた単語あたりのトークン数です。そのトークナイザー税は、ある言語の単語生産性を同じトークナイザーの下での英語の単語生産性で割ったものです。

生産画面の場合、整列したトークン数比はしばしば使いやすいです：

text 整列したトークン数比（言語Lの場合） = 整列したコンテンツのトークン数（言語L） ÷ 英語版のトークン数

これらの指標は関連する質問に答えますが、互換性はありません。報告する指標の名前を明示してください。両方の比較には意味的に整列したテキストが必要です。無関係な文や一般的な単語のリストを数えると、実際のアプリケーションについてはあまり意味のない魅力的な数字が得られることがあります。

研究者はまた、生産性を使用しますが、これはしばしば単語あたりのトークンとして定義されます。単語生産性は直感的ですが、単語の境界は言語によって同じように明確ではありません。ギャップが存在する理由を診断する必要がある場合は、文字生産性、トークンあたりのバイト数、未結合バイトの割合を追加してください。

この区別は重要です。なぜなら、トークン数にはいくつかの異なる結果があるからです：

最後の行は、過剰に主張しやすいものです。

2026年の研究が見つけたこと

新しいトークナイザー税の研究は、FLORES-200からの整列した文を使用しました。英語、アラビア語、スペイン語、フランス語とともに10のインドの言語を6つのトークナイザーで比較しました。著者たちは、単語と文字の生産性、トークンあたりのバイト数、未結合の単一バイトトークン、固定されたコンテキスト予算を超えたソーステキストの量を測定しました。

エンジニアリングの決定に重要な3つの結果があります：

高税率の言語は、トークンの27〜43%に対して未結合の単一バイトトークンを生成しました。有効な単語境界を持つサンプル言語全体で、その割合は`r = 0.89`で単語生産性税と相関していました。著者たちは、このギャップをそれらのスクリプトに対する語彙のカバレッジ不足に起因しています。

2023年のNeurIPS論文は、言語間で最大15倍のトークン化の長さの違いを見つけました。EMNLP 2023の研究は、22の言語間でコストとユーティリティを測定し、トークンベースのAPI価格設定が一部の言語コミュニティに対して比較可能なコンテンツに対してより多く請求する可能性があることを発見しました。

最近の研究はまた、このギャップが設計の選択であり、スクリプトの避けられない特性ではないことを示しています。パリティ対応バイトペアエンコーディング（BPE）は、現在最も圧縮されていない言語を助けるためにマージの目的を変更します。その著者たちは、グローバルな圧縮にほとんど変化がない状態で、クロス言語のジニ係数で測定されたトークンコストの不平等を最大89%削減したと報告しています。別の11の東南アジア言語にわたる制御された研究は、パリティ対応BPEを比較可能な15億パラメータのベースモデルの効率–公平性パレートフロンティアに配置しました。その結果は、フロンティアスケールや整列後の同じトレードオフを確立するものではありません。

精度の主張には抑制が必要

7月の研究は、13の言語ポイントに対する生産性と読解力の精度の間に`r = -0.61`の生の相関を見つけました。言語リソースレベルを制御した後、部分相関は`r = 0.25`になりました。

因果関係のある見出しを避ける理由は他にもあります：生産性の数値と精度スコアは異なるトークナイザー/モデル設定から来ており、サンプルは小さく、翻訳されたベンチマーク文は生産ワークロードではありません。この論文は、トークン数、コンテキスト、およびトークン価格のコストに関する強い主張を支持していますが、トークナイザーの生産性を低い回答品質の原因として特定することはありません。

自分の多言語トークンコストを測定する

この研究は警告を与えますが、あなたの生産比率ではありません。サポートアシスタント、検索システム、またはコーディングエージェントには独自の言語ミックスとプロンプト構造があります。

このワークフローを立ち上げ前とモデル変更後に使用してください。

1. 整列したサンプルを構築する

初期スクリーニングのために、期待されるワークロードから100〜1,000の例を収集します：

同じ意味のレビューされた翻訳を使用してください。すべての言語バリアントを接続するIDを保持してください。別々の言語コーパスから引き出されたランダムなテキストを比較しないでください。このスクリーニング範囲は統計的な最小値ではありません：必要なサンプルは言語の数、ワークロードの変動、およびテールの挙動をどれだけ正確に推定する必要があるかによって異なります。

サンプルをJSON Linesとして保存します：

{"id":"support-001","language":"en","text":"Reviewed English text"} {"id":"support-001","language":"sv","text":"Reviewed Swedish translation"} {"id":"support-001","language":"tr","text":"Reviewed Turkish translation"}

2. トークナイザーを固定する

トークナイザーはモデルバージョンに属します。両方を記録してください。OpenAIの公式`tiktoken`リポジトリは、`cl100k_base`と`o200k_base`を公開しています。また、そのモデルマッピングは、モデルファミリーが異なるエンコーディングを使用できることを示しています。クローズドモデルの場合、公式のカウンターが存在する場合はそれを優先してください。たとえば、GoogleのGemini APIは`countTokens`メソッドを公開しています。オープンモデルの場合は、モデルの文書化されたトークナイザーパイプラインを使用して正確なアーティファクトをロードします。たとえば、Hugging Face Tokenizers APIに記載されているものです。

同じベンダーからの2つのモデルがトークナイザーを共有していると仮定しないでください。昨日リリースされたモデルがローカルライブラリに既に知られていると仮定しないでください。

3. 一つの比率ではなく分布を計算する

カウンターをインストールして固定します：

bash python -m pip install "tiktoken==0.13.0"

次に実行します：

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} has no {BASELINE} baseline")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} has an empty baseline")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

平均は、コンテキストウィンドウをオーバーフローするいくつかの長いリクエストを隠す可能性があります。容量計画に結果を使用する前に、p50（中央値）、p95（95パーセンタイル）、および最大値を確認してください。

*デプロイされたトークナイザーで整列した生産テキストを測定し、分布を使用してコストとコンテキストの制限を設定します。品質は別の評価として残ります。*

4. 完全なリクエストを測定する

可視のユーザーメッセージはAPI呼び出しの一部に過ぎません。以下を含めてください：

これは特にエージェントにとって重要です。大きなJSONツールスキーマは短いユーザーリクエストを支配する可能性があります。ローカライズされたRAGパッセージは英語のシステムプロンプトを支配する可能性があります。プロバイダーがその表現を公開するたびに、最終的なシリアライズされたリクエストを測定してください。

5. トークンを運用制限に変換する

シンプルなトークン価格のAPIの場合：

text 月間入力コスト = 月間呼び出し × 平均入力トークン × 価格（百万トークンあたり） ÷ 1,000,000

仮想のAPIが百万トークンあたり1ドルを請求するとしましょう。100万リクエストで1,000入力トークンの場合、1,000ドルのコストがかかります。別の言語で整列したリクエストが平均2,500トークンの場合、入力部分はキャッシュや割引の前に2,500ドルになります。

コンテキストには別の計算が必要です：

text 使用可能な入力予算 = コンテキストウィンドウ

観察された言語比率をコンテンツ部分に適用し、リクエスト全体に盲目的に適用しないでください。

AI推論トークンコストガイドは、トークン予算がモデル制限だけでなく製品制限を必要とする理由を説明しています。RAGおよびコーディングシステムの場合、クロスリポジトリコンテキスト設計は、より多くのコンテキストを送信することが自動的に有用ではない理由を示しています。APIの選択がまだオープンである場合、既存の無料AI APIケーススタディは、より広範な比較フレームワークを提供します。

多言語受け入れゲートを設定する

低いトークン比率は、モデルが製品要件を満たしている場合にのみ有用です。4つの別々のゲートを使用してください：

多言語RAGシステムの場合、共有の文字数ではなく、デプロイされたトークナイザーによってチャンクします。エージェントの場合、最初のリクエストだけでなく、ツールのトレースと再試行を測定します。サポート製品の場合、呼び出しごとのコストではなく、解決されたケースごとのコストを追跡します。これらの選択肢は、トークン指標が虚栄のベンチマークになるのを防ぎます。

完全なスコアカードを改善する場合にのみ、言語特有のルートを使用してください。安価なトークナイザーと弱いモデルを組み合わせることで、入力トークンを節約し、再試行を増やすことができます。大きなコンテキストウィンドウは、請求書が増えるまで不十分なチャンクを隠すことができます。正しい単位は、完了したユーザータスクです。

チームが変更できること

アプリケーションチームは商業モデルのトークナイザーを再訓練することはできませんが、まだ選択肢があります：

独自のモデルをトレーニングしているチームは、より深い選択肢を持っています。パリティ対応BPEの結果は、トークナイザーの目的が、全体の圧縮をあまり犠牲にすることなく、言語間の不平等を減少させることができることを示唆しています。東南アジアの研究は、公平性と効率が必ずしも反対方向に動く必要がないという制御された証拠を追加します。

トークナイザーをモデル契約の一部として扱います。バージョンを付け、ベンチマークを行い、移行レビューに含めます。

証拠の限界

最新の研究はプレプリントです。翻訳されたFLORES-200文を使用しており、言語のセットは控えめであり、空白ベースの単語指標はすべての書き方に均等に適合するわけではありません。そのバイト検出方法はトークナイザー特有です。

最も強い結論はモデルに依存しません：一つの整列した言語がより多くのトークンを生成すると、固定トークンウィンドウに入るテキストが少なくなります。このコストの結論は、プロバイダーがそれらの追加トークンを同じ単位価格で請求する場合に保持されます。キャッシュポリシーやボリュームディスカウントは最終請求書を変更する可能性があります。

精度には独自のテストが必要です。トレーニングデータのカバレッジ、モデルアーキテクチャ、ポストトレーニング、評価デザイン、文化的コンテキストはすべて結果に影響を与えます。トークンの生産性はギャップに寄与する可能性がありますが、7月の論文はその因果効果を特定していません。

多言語トークナイザーのチェックリスト

よくある質問

なぜ一部の言語はより多くのLLMトークンを使用するのですか？

サブワード語彙はそのトレーニングデータとマージルールを反映しています。一般的な英語のフラグメントは効率的に表現されることが多いですが、あまり表現されていないスクリプトは小さな部分やバイトに分割されることがあります。ギャップの大きさは正確なトークナイザーとテキストによって異なります。

トークン数が多いと悪い回答を意味しますか？

いいえ。これはトークン価格のコストとトークンウィンドウに収まるテキストの量に直接影響しますが、回答の品質が低下することを証明するものではありません。各言語のレビューされた例で品質を別々にテストしてください。

API呼び出しの前にトークンをカウントするにはどうすればよいですか？

利用可能な場合は、プロバイダーの公式カウントエンドポイントを使用してください。OpenAIのエンコーディングの場合、`tiktoken`はローカルでカウントできます。オープンモデルの場合は、モデルと共に出荷された正確なトークナイザーアーティファクトをロードします。バージョンを固定して、後の更新が測定を静かに変更しないようにします。

モデルを切り替えることでトークナイザー税を取り除くことができますか？

ギャップを減少させることができます。7月の研究では、`cl100k_base`と`o200k_base`の間で大きな改善が見られました。モデルの切り替えは品質、出力コスト、キャッシュ、レイテンシー、運用の挙動も変更するため、トークン数だけでなく完全なワークロードを比較してください。

ソース

主張のチェック