英語で投げると静かに終わるのに、別の言語だと空気が変わる
画像: ml.energy より
同じ内容を聞いているはずなのに、英語ではあっさり返るのに、別の言語では妙に重くなる。しかも差は「少し遅い」程度ではない。公開された研究では、推論時の出力トークン1個あたりのエネルギーが言語によって最大8.3倍、固定したリクエスト集合の総エネルギーは最大179倍まで開いた。ここで問題なのは、単なる翻訳の手間ではなく、モデルが質問を受け取って答えを出す、その内部処理そのものに差があることだ。
この手の話は、まず「トークン」を押さえると見通しがよくなる。LLMは文章を文字列のまま扱わず、トークンという単位に区切って読む。英語は比較的少ないトークンで済むことが多いが、他言語では同じ意味でも細かく割れやすい。すると入力も出力も増え、計算量とメモリ使用量が膨らむ。言い換えると、同じ質問でもモデルの中では「読む量」と「書く量」が違う。
研究では、122言語を含む読解データセットや、翻訳された数学・会話タスクを使い、同条件で推論エネルギーを測っている。英語が最安で、パシュトー語が最も高かった。本文では英語が19.5ジュール/応答、パシュトー語が3,496ジュール/応答とされ、差は179倍になる。ここで見えてくるのは、これがたまたま一部のモデルで起きた話ではなく、言語を変えるだけで負荷が大きく動くということだ。
日本の現場でも、この差は他人事ではない。問い合わせ応答、社内ナレッジ検索、海外向けサポートのように、多言語対応はすでに「あると便利」ではなくなっている。ところが、性能だけを見て導入すると、英語では問題ないのに、別言語ではコストが急に跳ねることがある。翻訳精度の話に見えて、実際には推論基盤の採算に触れる。ここで効いてくるのが、どの言語を、どのモデルに、どんな条件で流すかという設計だ。
179倍の正体は、単発の高コストではなく、二つの膨らみが重なった結果
179倍という数字だけを見ると、何か極端な失敗でも起きたように聞こえる。だが論文の説明はもっと地味で、しかも厄介だ。差を作っているのは、ひとつは「1トークンを処理するのにかかるエネルギーが高いこと」、もうひとつは「そもそも出力トークン数が増えること」だ。どちらか一方だけでも痛いが、両方が同時に起きると総エネルギーは掛け算で膨らむ。
手計算に近い形で見ると、英語はおおむね0.10ジュール/トークン前後だが、非ラテン文字の低資源言語が並ぶ長い尾では0.4ジュール/トークンを超える。低資源言語の一部は、英語より20〜25倍も多く出力トークンを生成し、さらにトークンあたりコストも約7倍に寄る。ここまでくると、総エネルギーの比は単純な加算ではなく、「20〜25倍×約7倍」の世界に入る。論文は、この掛け算で1応答あたり約170〜179倍に届くと説明している。
なぜトークン数が増えるのか。論文では、トークナイザーのカバレッジ不足や、事前学習での表現の薄さが背景にあると説明している。非ラテン文字の言語では、同じ意味を表すのにより細かい単位へ分割されやすい。分割が増えると、KVキャッシュも膨らみ、同じGPUでも載せられるバッチが小さくなる。すると、1回あたりの処理がより非効率になり、エネルギーが押し上がる。
ここで重要なのは、これは「高級なモデルほど何でも解決する」という話ではないことだ。実際、研究ではモデルやハードウェア、タスクを変えてもこの格差が残った。つまり、ある一社の実装の癖ではなく、多言語推論そのものに埋め込まれた差として現れている。英語中心で設計された評価軸では見えにくいが、運用費の請求書にはそのまま出る。そこが厄介だ。
低資源言語ほど、遅い・高い・当たりにくいが同時に起きる
この研究が重いのは、エネルギーだけの話で終わっていないからだ。著者らは、エネルギーが高い言語ほど精度も低いという「double cost + performance penalty」を示している。つまり、負担が増えるのに、得られる答えの質も下がる。利用者から見れば、料金は上がるのに体験は悪化する。事業者から見れば、売上に直結しにくいのに計算資源だけ食う、扱いづらい領域になる。
この構図は、他の研究ともきれいにつながる。2023年の研究では、トークナイザーの段階だけで言語間に最大15倍の長さ差が生まれうると示された。今回の論文は、その「前段の不利」が推論時のエネルギーにまで伸びていることを見せた形だ。要するに、入口で細切れにされる言語は、その後ずっと不利を背負う。翻訳の上手さだけでは覆せない層がある。
さらに、同じ研究では、代表的な生成例として一部の言語で1質問あたり最大約4,700出力トークンに達するループも観測されている。ここだけ聞くと極端だが、実運用では「たまに暴走する」事例が一番厄介だ。平均値では見えず、しかしピーク時のコストとレイテンシを押し上げる。日本のエンジニアにとっては、グローバル対応のサポート窓口や、社内の多言語検索、海外拠点向けの業務AIで、この振れ幅がそのまま運用の読みづらさになる。
別の言い方をすると、これは公平性の問題でもある。使う言語によって、同じ会社の同じサービスなのに、支払う計算資源が変わる。研究はその差を「部署内の最適化」で済ませず、配備の公平性として扱うべきだと促している。ここまで来ると、論点はモデル精度だけでは足りない。言語ごとのエネルギーを、評価項目として最初から数えるべきかどうかに移る。
ここから先は、測り方ではなく「どう扱うか」の話になる
著者らの提案は、かなり実務寄りだ。エネルギーを第一級の評価軸として扱い、言語ごとに個別の値を報告し、場合によっては言語に応じた配備やルーティングを使えという。さらに、必要なら英語へ翻訳してから一般モデルに流す選択肢もある。ただし、ここで本当に知りたいのは「何をすればいいか」より、なぜそれで差が縮むのか、どこで限界が来るのかだろう。論文はその直前までを示している。
たとえば、英語と同じ質問でも、ある言語では出力トークンが20倍以上に膨らみ、しかも1トークンあたりの処理が7倍重くなる。そのとき配備側は、単純にGPUを増やせば済むのか。あるいは翻訳して英語に寄せればよいのか。そこには、精度の損失、遅延、サービング設計、そして「どの言語を優先するか」という判断が絡む。答えは一つではないが、少なくとも179倍という数字は、もはや感覚論では片付かない。
実際、この論文が示したのは、英語中心の見方では隠れてしまう地形だ。トークン化の不公平があり、推論時のエネルギー格差があり、そのうえ精度差まで重なる。では、どの条件なら差が縮み、どの条件なら残るのか。モデルの種類、GPU、バッチサイズ、タスクの違いは本当にどう効くのか。ここを掘ると、話は一気に実装の細部へ入っていく。そこで初めて、179倍の内訳が見えてくる。
👉 続き（核心はここから）は PaPoo で読めます: https://papoo.work/doc/734d033dfe3c9c89