【2026年最新】LLMの推論コスト削減×論文4選｜「APIの請求額が怖い」を解く小型モデル・ルーティング・量子化

【2026年最新】LLMの推論コスト削減×論文4選｜「APIの請求額が怖い」を解く小型モデル・ルーティング・量子化 AIニュース
2026.09.18

生成AIの業務利用が当たり前になった一方で、多くの現場で問題になり始めているのが「推論コスト」です。推論コストとは、学習済みのモデルに質問を投げて回答を得るたびにかかる費用のことで、API利用料やGPUサーバー代として毎月積み上がっていきます。

特にAIエージェントは、1つの業務をこなすためにLLMを何十回も呼び出します。「PoCでは問題なかったのに、全社展開したら請求額が桁違いになった」という声も珍しくありません。とはいえ、単純に安いモデルへ切り替えると精度が落ちますし、モデルを圧縮すると目に見えない品質劣化が起きることもあります。

この記事では、各社の公式ドキュメントをもとに推論コストの決まり方と削減策の全体像を整理し、品質を保ったままコストを下げる方法を扱った論文4本を紹介します。結論を先に言うと、割引の仕組みを先に使い切り、そのうえで「どの処理にどのモデルを何回使うか」を設計し、圧縮は業務に直結する観点で確かめてから入れるのが基本です！

推論コストとは何か：請求額は「トークン数×単価」で決まる

課金の単位は「トークン」

LLMのAPIは、文字数ではなくトークンという単位で課金されます。トークンはモデルが文章を処理するときの細かな区切りで、Google の Gemini API の説明では、英語ならおよそ4文字が1トークンにあたるとされています。同じ説明の中で、API呼び出しの費用は入力と出力のトークン数で決まるとも書かれています（Google「Understand and count tokens」）。

つまり請求額の基本は、「送った量（入力）」と「返ってきた量（出力）」に、それぞれの単価を掛けたものです。ただし、Web検索のような事業者側で動くツールを使うと、検索1回ごとの料金などが別に加わります（Anthropic「Pricing」）。長い資料を毎回まるごと渡したり、エージェントが何度も往復したりすると、1回は小さな金額でも合計は大きくなります。

入力より出力が高く、モデルの格で単価が何倍も違う

単価には2つの特徴があります。1つ目は、出力の単価が入力より高いことです。Anthropic の料金表（2026年10月時点）では、標準の料金表に載っているモデルはすべて、出力の単価が入力の5倍です。Gemini API の料金表では、出力の単価に「思考（thinking）」のトークンも含むと明記されています。考えさせるほど費用が増えるということです（Anthropic「Pricing」、Google「Gemini Developer API pricing」）。

2つ目は、同じ事業者の中でもモデルの格によって単価が大きく違うことです。同じく Anthropic の料金表では、入力100万トークンあたりの単価が、小型の Claude Haiku 4.5 で1ドル、最上位の Claude Fable 5.1 で10ドルと、10倍の開きがあります（Anthropic「Pricing」）。

推論コストを下げる手段の全体像

推論コストを下げる手段は、大きく次の4つに分けられます。上の2つは事業者の割引の仕組みで品質を犠牲にせず、下の2つは品質との兼ね合いを確かめる必要があります。

手段何を減らすか品質への影響
バッチ処理急がない処理の単価なし（待ち時間が延びる）
プロンプトキャッシュ毎回同じ前置きの入力費用なし
モデルの使い分け・ルーティング高いモデルを呼ぶ回数振り分け次第
量子化（自前で動かす場合）GPUのメモリと計算量削り方次第

バッチ処理：急がない処理は半額に

夜間の一括要約のように、すぐに結果が要らない処理はバッチ処理に回せます。Anthropic、OpenAI、Google の3社とも、バッチで送ったリクエストを通常の50%の料金で処理し、結果は24時間以内を目安に返すと説明しています（Anthropic「Batch processing」、OpenAI「Batch API」、Google「Batch API」）。

プロンプトキャッシュ：毎回同じ前置きを安くする

指示文や参照資料など、毎回同じ内容をプロンプトの先頭に置いている場合は、プロンプトキャッシュが効きます。一度処理した先頭部分（プレフィックス）を保存しておき、次のリクエストで同じ先頭部分が来たら再利用する仕組みです。Anthropic の料金表では、キャッシュへの書き込みは通常の入力単価の1.25倍、読み出しは0.1倍で、1回再利用すれば元が取れると説明しています。OpenAI も GPT-5.6 以降のモデルで同様の倍率を示し、Gemini API は 2.5 以降のモデルで暗黙的なキャッシュが既定で有効になっています（Anthropic「Pricing」、OpenAI「Prompt caching」、Google「Context caching」）。

各社とも、キャッシュが当たる前提は先頭部分が一致していることです。日時やユーザー名のように毎回変わる情報を先頭に置くと、キャッシュは当たりません。また、キャッシュできる最小の長さ（モデルにより数百〜数千トークン）や保持時間は、事業者とモデルごとに違います。

モデルの使い分けとルーティング、そして量子化

割引の次に効くのが、設計で下げる方法です。処理ごとにモデルを使い分ける、質問の難しさで振り分ける（ルーティング）、自前のGPUで動かすモデルを圧縮する（量子化）などで、どれも品質を保てるかが問題になります。ここからは、その問いに取り組んだ論文を見ていきます。

研究で見る「安いモデルをどこまで使えるか」

📄 論文: エージェントの呼び出しの多くは、小型モデルで足りる

Small Language Models are the Future of Agentic AI（Peter Belcak ほか、2025年6月投稿・2026年9月改訂、arXiv:2506.02153）は、査読前の論文（プレプリント）です。

NVIDIA の研究者らによる、実験ではなく主張を述べる「ポジションペーパー」です。AIエージェントの処理の多くは、決まった形式でのツール呼び出しや情報の抜き出しのような、少数の専門的な作業の繰り返しです。著者らは、そうした呼び出しには小型言語モデル（SLM）で十分で、しかも経済的だと論じています。会話の幅広さが必要な場面だけ大型モデルを使い、残りを小型モデルに任せる「混成」の構成を勧め、既存のエージェントを移行する手順として、呼び出しの記録を集める→作業の種類ごとに分ける→小型モデルを選んで追加学習する、という流れを示しています。付録では、公開されている3つのエージェントについて、呼び出しのおよそ40〜70%は小型モデルに置き換えられると見積もっています（実測ではなく著者らの見積もりです）。

運営者にとっての意味は、「エージェントの全ステップに最上位モデル」は前提ではないということです。まず呼び出しの中身を記録して、定型的な処理がどれだけあるかを数えるところから始められます。

📄 論文: 安いモデルに「何回答えさせるか」まで決めるルーティング

BEST-Route: Adaptive LLM Routing with Test-Time Optimal Compute（Dujian Ding ほか、2025年6月、arXiv:2506.22716）は、ICML 2025 採録（abs のコメント欄の記載）です。

ルーティングは定番の削減策ですが、小型モデルの1回の回答では大型モデルにかなわないことが多く、結局は大型モデルばかり呼んでしまう問題がありました。この論文は、小型モデルに複数の回答を作らせて小さな採点用モデルで一番良いものを選ぶと、大型モデル1回より安いまま品質を上げられる点に着目し、「どのモデルを使うか」と「何個の回答を作らせるか」を質問の難しさに応じて同時に決める仕組みを提案しました。質問応答・コード生成・安全性評価などを含む約1万件の指示を使い、8つのモデルで、常に GPT-4o を使った場合と比べた結果、品質の低下を1%未満に抑えたままコストを最大60%削減できたと報告しています。

運営者にとっての意味は、ルーティングを設計するときは「どのモデルか」だけでなく「何回試すか」も調整のつまみになる、ということです。

量子化はどこまで削ってよいか

📄 論文: 推論モデルは「8ビット」「重み4ビット」までなら、ほぼ劣化しない

Quantization Hurts Reasoning? An Empirical Study on Quantized Reasoning Models（Ruikang Liu ほか、2025年4月、arXiv:2504.04823）は、COLM 2025 採録（abs のコメント欄の記載）です。

量子化とは、モデルの重みなどの数値を少ないビット数で表して、メモリと計算量を減らす技術です。長く考えてから答える「推論モデル」でも同じように使えるのかを確かめるため、この論文は1.5B〜70Bパラメータの公開モデルを対象に、重み・KVキャッシュ・活性化の量子化をさまざまなビット幅で試し、数学・科学・プログラミングの試験問題で正答率を測りました。対象としたモデルと試験問題では、重みと活性化を8ビットにする設定（W8A8）や、重みだけを4ビットにする設定（W4A16）で、正答率の低下が1%以内の「ほぼ劣化なし」に収まりました。一方、それより低いビット幅では劣化の危険が大きく、その度合いはモデルの大きさや出自、問題の難しさで変わります。量子化しても思考が長くなることはおおむねありませんでしたが、3ビットのような攻めた設定では出力が長くなる傾向があり、特に小さなモデルで目立ったと本文で述べています。

運営者にとっての意味は、自前でモデルを動かすなら、8ビットや重み4ビットが評価を始める候補になるということです。ただし別のモデルや業務の質問でも同じとは限らないので、自分の用途で確かめます。攻めた設定では、出力が長くなって節約分が目減りすることもあります。

📄 論文: 平均的な指標では見えない「偏り」の劣化

Quantization Undoes Alignment: Bias Emergence in Compressed LLMs Across Models and Precision Levels（Plawan Kumar Rath ほか、2026年5月、arXiv:2605.15208）は、IEEE Cloud Summit 2026 採録（abs のコメント欄と関連 DOI の記載）です。

量子化したモデルの品質確認では、パープレキシティ（モデルの予測の外れにくさを表す指標）などの全体的な数値を見て「ほとんど変わらない」と判断するのが一般的です。この論文は、3つの指示追従モデル（Qwen2.5-7B、Mistral-7B、Phi-3.5-mini）を5段階の精度で量子化し、社会的な偏りを測る質問集（BBQ）の約1万2千問を条件を変えて5回ずつ解かせて、問題ごとの変化を追いました。元のモデルでは偏りのない答えをしていた問題のうち、3ビットでは6〜21%で新たにステレオタイプに沿った答えが出るようになりました。また、あるモデルでは4ビットでパープレキシティの悪化が2.8%にとどまった一方で、5.6%の問題に新たな偏りが出ていました。なお、結果はこの3モデルと評価条件でのもので、量子化の方法と実行環境も1種類に限られている、と著者ら自身が述べています。

運営者にとっての意味は、平均的な指標が「問題なし」を示していても、公平性や安全性に関わる答え方は変わりうるということです。量子化したモデルを出す前に、業務で困る種類の質問で個別に確かめる必要があります。

現場でやること

まず請求の内訳を見る

最初に、入力と出力のトークン数を処理の種類ごと（チャット応答、夜間の要約、エージェントのツール呼び出しなど）に集計してみてください。思考のトークンが多いのか、毎回同じ長い前置きを送っているのかで、効く手段が変わります。

割引の仕組みを先に使い切る

  • すぐに結果が要らない処理は、バッチ処理に回して半額にする
  • 指示文や参照資料など毎回同じ部分はプロンプトの先頭にまとめ、日時などの変わる情報は後ろに置いてキャッシュを当てる
  • 応答のログでキャッシュが実際に当たっているかを確認する

使い分けとルーティングは「記録→小さく試す」

1本目の論文の手順にならい、まず呼び出しを記録して、定型的な処理を洗い出します。次に一部の処理だけを小型モデルに切り替え、同じ質問で元のモデルとの答えを比べます。ルーティングを入れる場合は、小型モデルに複数回答えさせて選ぶ方法も選択肢に入れます。判断は「1回あたりの料金」ではなく「1件の業務を終えるまでの料金」で行いましょう。安いモデルでやり直しが増えれば、かえって高くつきます。

量子化は「劣化の小さい設定」と「業務の質問」で確かめる

自前のGPUでモデルを動かす場合は、8ビットや重み4ビットから試し、さらに削るときは慎重に進めます。品質確認では、パープレキシティや平均正答率だけでなく、次のような質問を少数でよいので用意して、量子化の前後で答えを比べます。

  • 答えようがない質問に「分からない」と言えるか
  • 性別や年齢、国籍などに関わる質問で、偏った答えが増えていないか
  • 社内規程や顧客対応で、間違えると困る質問に正しく答えられるか

推論コスト削減の鍵は次の3点です

  1. 割引の仕組みを先に使い切る
    バッチ処理とプロンプトキャッシュは、品質を落とさずに費用を下げられます。設計を変える前に、まずここから始めます。
  2. 「どの処理にどのモデルを何回使うか」を設計する
    定型的な処理は小型モデルに任せ、難しい判断だけを大型モデルに回します。ルーティングでは試行回数も調整のつまみになります。
  3. 圧縮は業務に直結する観点で確かめてから出す
    量子化は論文で劣化が小さかった設定から試し、平均的な指標だけでなく、公平性や安全性に関わる質問でも劣化がないかを確かめます。

まとめ：コスト削減は「安いモデルへの乗り換え」から「設計」の問題へ！

推論コストは入力と出力のトークン数に単価を掛けたもので、出力や上位モデルほど高くつきます。まずはバッチとキャッシュという割引の仕組みが最初の一手です。そのうえで、小型モデルの活用、試行回数まで含めたルーティング、確かめたうえでの量子化を組み合わせれば、品質を保ったまま費用を下げる余地は大きく残っています。

まずは今月の利用ログから「どの処理に、どのモデルで、何トークン使っているか」を一覧にしてみてください。どこから手を付けるべきかが見えてきます！

参考文献

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、量子化と出力の長さ、量子化による偏りの数値、小型モデルへの置き換えの見積もりの記述の誤りを修正しました

タイトルとURLをコピーしました