この記事は後半です。前半は Qiita にあります: 同じ質問でも英語は軽く、他言語は重い——LLM推論の電力格差を読む
前半で見た「同じ質問なのに179倍」という差は、単なる外れ値ではない。論文が示したのは、総エネルギーの差が「1トークンあたりの重さ」と「出力トークン数の増加」の掛け算で膨らむことだった。英語はおおむね 0.10 J/token 前後だが、非ラテン文字の低資源言語が並ぶ長い尾では 0.4 J/token を超える。一方、低資源言語の一部は英語より 20〜25 倍も多く出力トークンを吐く。そこに約7倍のトークン単価が重なると、総エネルギーは一気に跳ねる。
図: 122言語の出力トークンあたりエネルギー（arXiv:2606.21869 Figure 1 より）
この差を支える要因はかなり地味だ。トークナイザーのカバレッジが弱いと、同じ意味でも細かい単位に割れやすい。すると入力も出力も増え、KV キャッシュも膨らむ。結果としてバッチサイズが小さくなり、GPU の使い方が悪くなる。研究が「低資源言語ほど高コスト」と言うとき、背景にあるのはこうした連鎖だ。モデルの性能だけではなく、表記体系と学習資源の偏りが、そのまま推論コストに出てくる。
この研究が重いのは、エネルギーの話だけで終わらないからだ。著者らは、高エネルギーの言語ほど精度も低いという「double cost + performance penalty」を報告している。つまり、支払いは増えるのに、返ってくる答えの質は下がる。利用者から見れば損で、提供側から見ても扱いにくい。多言語対応を進めるほど、こんな逆風が見えにくい形で積み上がる。
しかもこの傾向は、特定のモデルや特定のハードウェアに閉じた話ではない。論文では、モデル、GPU、バッチサイズ、タスクを変えてもエネルギー格差が残った。別の言い方をすれば、実装の工夫だけで消えるノイズではなく、多言語推論そのものに埋め込まれた差だ。これが厄介なのは、英語中心の評価だと見えづらいのに、運用コストにはそのまま効くことだ。
実務でこの知見が生きるのは、多言語を一括で扱う場面だ。たとえば問い合わせ応答、社内検索、海外拠点向けの業務支援のように、同じ仕組みを複数言語へ広げるとき。性能だけ見てモデルを選ぶと、英語では快適でも、別言語では急に遅く、高くなることがある。そこで必要なのは、言語ごとに同じ扱いをすることではなく、言語ごとに違う前提で流すことだ。
論文の提案もそこに寄っている。エネルギーを第一級の評価軸として扱い、言語別の値を報告し、必要なら言語に応じた配備やルーティングを使う。場合によっては、ユーザーの入力を英語へ翻訳してから一般モデルに通す手もある。ただし、それは翻訳の信頼性が十分なときだけだ。万能策ではない。翻訳でコストは下げられても、意味の取りこぼしや応答品質の変化は別問題として残る。
自分なら、この研究を「多言語対応の稟議を通すための材料」として使う。単にグローバル展開したい、では弱い。英語以外の言語では、同じ質問でも推論コストが数倍から数十倍に跳ねる。しかも一部の言語では、精度まで落ちる。ならば、どの言語を直送し、どの言語を翻訳経由にし、どの言語は別モデルで受けるのかを先に決めるべきだ。そこを決めずに運用へ入ると、あとから請求と遅延に驚くことになる。
もうひとつ大事なのは、プロダクトの公平性を「機能の有無」だけで見ないことだ。多言語対応をうたっていても、言語によって電力とレイテンシが大きく違えば、実際の利用可能性は平等ではない。論文が言うのは、まさにその配備上の不公平だ。英語以外の言語を後回しにすると、使う人が高い代償を払う。だから、言語別のエネルギーを測り、見積もり、設計に入れる。そこまでやって初めて、多言語対応を「機能」としてではなく「運用」として扱える。
この論文の価値は、派手な数字そのものよりも、差がどこから来るかを分解した点にある。トークン化の偏りがあり、出力長の膨らみがあり、バッチサイズの縮小があり、その積み重ねでエネルギーが跳ねる。だから、見るべきは「英語より何倍高いか」だけではない。「どの言語が、なぜ高いのか」まで掘らないと、対策は当たらない。
英語で静かに終わるのに、別の言語では空気が変わる。あの違和感は、気分ではなく設計の問題だった。少なくともこの研究は、それをかなりはっきり数値にした。今後の多言語LLMでは、精度と同じくらい、言語ごとの電力を見ないといけない。そこを外すと、使いやすさも公平さも、どちらも取り逃がす。
