多くのチームは LLM 推論に 3〜10 倍の過剰支出をしています。本ガイドは、出力品質を犠牲にせずコストを 60〜90% 削減するエンジニアリング手法を網羅します -- モデルルーティングとセマンティックキャッシュから、fine-tuning の経済性、self-hosting の損益分岐分析まで。
LLM のコストには指数関数的に増大する厄介な習性があります。管理可能な 1 日 200 ドルのプロトタイプとして始まったものが、すぐに 1 日 2,000 ドルの本番の悪夢になります。計算は単純ですが容赦ありません：token あたりの価格 x 増加する使用量 x コンテキストウィンドウの肥大化 = 指数関数的なコスト曲線。
繰り返し目にする実際のシナリオを紹介します：あるチームがカスタマーサポートのチャットボットを構築します。開発中は短い会話と単純なクエリでテストします。コスト：1 日 8 ドル。500 ユーザーへ公開します。会話が長くなり、コンテキストウィンドウが埋まり、タイムアウト時に再試行ロジックが発火し、エッジケースの修正ごとに system prompt が膨らみます。3 週間以内に、同じチャットボットが 1 日 2,400 ドルかかるようになります -- 誰も予算化していなかった 300 倍の増加です。
ある B2B SaaS 企業が、すべてのクエリに GPT-4o を使う AI アシスタントを公開しました。そのコストの推移は次のとおりです：
本ガイドの手法（ルーティング + キャッシュ + prompt 圧縮）を実装した後、同社は 500 ユーザーでコストを 1 日 320 ドルまで引き下げました -- 87% の削減です。
最適化の前に、お金がどこへ行くのかを理解する必要があります。LLM のコストはいくつかの異なるカテゴリに分かれ、その内訳はアプリケーションの種類によって大きく異なります。
system prompt、会話履歴、取得したコンテキスト（RAG）、few-shot の例。ここに最も多くのお金が使われ、最大の節約余地があります。
生成された応答。出力 token は入力 token より 1 token あたり 2〜4 倍高価ですが、量は通常少なくなります。冗長な応答が主なコスト要因です。
embedding の生成、fine-tuning の計算、ベクトルストレージ、ロギング、監視インフラ。単位あたりは小さいですが、規模が大きくなると積み重なります。
| モデル | プロバイダー | 入力 | 出力 | コンテキスト | 備考 |
|---|---|---|---|---|---|
| GPT-4o | OpenAI | $2.50 | $10.00 | 128K | 汎用最強、マルチモーダル |
| GPT-4o mini | OpenAI | $0.15 | $0.60 | 128K | 単純なタスクに最適、入力が 4o より 17 倍安い |
| Claude Sonnet 4.6 | Anthropic | $3.00 | $15.00 | 200K | 強力な推論、大きなコンテキストウィンドウ |
| Claude Haiku 4.5 | Anthropic | $0.80 | $4.00 | 200K | 高速、分類にコスト効率が良い |
| Mistral Large 3 | Mistral | $2.00 | $6.00 | 128K | 欧州プロバイダー、GDPR に配慮 |
| Llama 4 Maverick (self-hosted) | Meta (open-source) | ~$0.30* | ~$0.30* | 1M | GPU コストのみ、token ごとの料金なし |
* self-hosting のコストは概算で、Llama 4 Maverick を vLLM で提供する A100 GPU を ~2 ドル/時で借りた場合に基づきます。実際のコストはスループットと使用率に依存します。
GPT-4o の入力 token は 100万あたり 2.50 ドルです。GPT-4o mini は 100万あたり 0.15 ドルです。これは 17 倍の価格差です。分類、抽出、単純な Q&A では、品質差はしばしば無視できます。モデルルーティングはこのギャップを活用します。
モデルルーティングは最も影響の大きい単一の最適化です。考え方は単純です：簡単なタスクは安価なモデルへ、難しいタスクは高価なモデルへルーティングします。ほとんどの本番ワークロードは 70〜80% が小さなモデルで完璧に処理できる単純なタスクです。典型的な節約：60〜80%。
小さなモデルまたはヒューリスティックがクエリの複雑度を分類し、適切なモデル階層へルーティングします。
タスクの種類でルーティング：分類、抽出、要約、生成、推論。各タスクを最適なモデルに対応づけます。
最も安価なモデルから始めます。信頼度が低い、または応答が検証に失敗した場合は、より大きなモデルへエスカレーションします。
小さな検証モデルが、安価なモデルの出力を返す前に品質しきい値を満たしているか確認します。
軽量な分類器（embedding 上のロジスティック回帰、またはルールベースのシステム）を使い、クエリの複雑度を 0〜1 のスケールでスコアリングします。コスト：1 クエリあたり約 0.01ms。
スコア < 0.3 は GPT-4o mini（入力 0.15 ドル/100万）へ。スコア 0.3〜0.7 は Claude Haiku 4.5（0.80 ドル/100万）へ。スコア > 0.7 は GPT-4o（2.50 ドル/100万）へ。
安価なモデルが信頼度の低い出力を返す、または検証に失敗した場合は、自動的に次の階層へエスカレーションします。通常、エスカレーションするのはクエリの 5〜10% だけです。
1 日 50,000 クエリを処理するカスタマーサポートプラットフォームが、すべてに GPT-4o を使う方式からルーティング構成へ切り替えました：72% を GPT-4o mini、20% を Claude Haiku 4.5、8% を GPT-4o へ。月額コストは 38,000 ドルから 6,200 ドルに低下しました -- 評価スイートで測定可能な品質低下なしに 84% の削減です。
あるユーザーが「返品ポリシーは何ですか？」と尋ね、別のユーザーが「商品を返品するにはどうすればよいですか？」と尋ねた場合、両者は同じ回答を求めています。セマンティックキャッシュはこうした類似クエリを検出し、冗長な API 呼び出しを行う代わりにキャッシュされた応答を提供します。繰り返しのクエリパターンを持つアプリケーションでは、これだけでコストを 30〜60% 削減できます。
| アプローチ | ヒット率 | 労力 | 節約 | 最適な用途 |
|---|---|---|---|---|
| 完全一致キャッシュ | 10〜20% | Low | Low | 繰り返される同一クエリ（FAQ ボット、オートコンプリート） |
| セマンティックキャッシュ（コサイン > 0.95） | 30〜50% | Medium | High | 同じ回答になる類似質問（カスタマーサポート） |
| prompt 対応キャッシュ | 40〜60% | High | Very High | 同じ system prompt + 類似のユーザークエリ |
| プレフィックスキャッシュ（API レベル） | 自動 | None | Medium | リクエスト間で共有される system prompt（Anthropic、OpenAI） |
高速な embedding モデル（例：text-embedding-3-small、100万 token あたり 0.02 ドル）を使い、ユーザークエリの embedding ベクトルを生成します。
ベクトル検索モジュール（RediSearch）付きの Redis、または軽量なベクトル DB を使用します。高精度のため、しきい値をコサイン類似度 0.95 以上に設定します。
ヒット時：キャッシュ応答を 50ms 未満で返します。ミス時：LLM を呼び出し、結果を embedding と TTL（例：動的コンテンツは 24 時間、静的は 7 日）とともに保存します。
prompt 内のすべての token はお金がかかります。ほとんどの本番 prompt には 30〜50% の冗長な token が含まれます -- 冗長な指示、不要な例、モデルが必要としない書式。prompt 最適化は、最も労力が少なく最も見返りの大きい出発点です。
冗長な指示を削除し、略語を使い、ルールを統合します。2000 token の system prompt は、品質を一切損なうことなく 800 token に圧縮できることがよくあります。
冗長な few-shot の例を簡潔な指示に置き換えます。毎回渡す代わりに、例で小さなモデルを fine-tuning します。
JSON モードまたは function calling を使い、冗長な散文を排除します。「推論を説明してください」は応答ごとに 200 token 以上を追加します。
関連する会話履歴のみを含めます。古いターンは要約します。fine-tuning でモデルがすでに学習した system メッセージは削除します。
max_tokens を適切に設定します。prompt 内で「簡潔に」や「100 語以内で答えてください」を使います。早期終了のための停止シーケンス。
同じ挙動で、入力 token は 67% 減少します。GPT-4o で 1 日 50K リクエストの場合、これは system prompt の token だけで 1 日 ~190 ドル（月 5,700 ドル）を節約します。
ワークロードがリアルタイム応答を必要としない場合、バッチ API はエンジニアリングの手間ゼロで即座に 50% のコスト削減をもたらします。OpenAI の Batch API、Anthropic の Message Batches、そしてほとんどのプロバイダーが非同期処理に割引価格を提供しています。
混在ワークロードでは、リアルタイムとバッチ対象のリクエストを分離するキューを実装します。優先度キューを使い、レイテンシに敏感な作業を同期 API へ、それ以外をすべてバッチエンドポイントへルーティングします。
fine-tuning により、大きなモデル + 複雑な prompt を、挙動が組み込まれた小さなモデルに置き換えられます。経済性は説得力があります：fine-tuning した GPT-4o mini は、狭いタスクで GPT-4o の品質を 1/15 の推論コストで達成できます。ただし fine-tuning には初期コストがあり、十分な規模でのみ見合います。
| アプローチ | コスト/1K 呼び出し | 品質 | レイテンシ | セットアップコスト | 損益分岐点 |
|---|---|---|---|---|---|
| GPT-4o + 詳細な prompt | $25.00 | 95% | High | $0 | N/A |
| GPT-4o mini + few-shot | $1.50 | 88% | Low | $0 | N/A |
| GPT-4o mini を fine-tuning | $0.90 | 93% | Low | $50-200 | ~300 |
| Llama 4 Scout を fine-tuning（self-hosting） | $0.10 | 90% | Very Low | $500-2000 | ~2,000 |
大量の場合、オープンソースモデル（Llama 4、Mistral Large 3、Qwen）の self-hosting は token あたりのコストを 80〜95% 削減できます。トレードオフは運用の複雑さです：GPU インフラ、model serving、監視、オンコール対応が必要です。損益分岐点は量に依存します。
| 選択肢 | 100K req/mo | 1M req/mo | 10M req/mo | 長所 | 短所 |
|---|---|---|---|---|---|
| OpenAI API（GPT-4o） | $2,500 | $25,000 | $250,000 | 運用不要、常に最新モデル | 限界コストが最高、ベンダーロックイン |
| GPU レンタル（A100 80GB） | $2,000 | $2,000 | $6,000 | 規模での固定コスト、データはローカルに留まる | 運用負担、キャパシティプランニング |
| 自社ハードウェア（H100） | $4,500* | $4,500* | $4,500* | 長期的に最も低コスト、完全な制御 | 高額な初期費用（3〜4 万ドル）、減価償却 |
* 自社ハードウェアのコストは 36 か月で償却。電気代（H100 で月 ~200 ドル）、ラックスペース、運用要員は含みません。
次の場合に self-host します：(a) 1 日 100万 token を超える安定した量、(b) ML ops チームがある、または構築する意思がある、(c) データ主権の要件（GDPR、HIPAA）、または (d) API 支出が月 5,000 ドルを超える。これらのしきい値を下回る場合、運用の複雑さが節約を正当化することはほとんどありません。生の GPU レンタルにコミットする前に、中間策としてサーバーレス推論プロバイダー（Together AI、Fireworks）から始めましょう。
コスト最適化は一度きりのプロジェクトではありません。継続的な監視がなければ、prompt のドリフト、新機能、使用パターンの変化によってコストは再び上昇します。すべてのドルがどこへ行くのかをリアルタイムで可視化する必要があります。
| 指標 | 説明 | 目標 | ツール |
|---|---|---|---|
| リクエストあたりのコスト | API 呼び出しごとの総コスト（入力 + 出力 token）、機能別の内訳 | Track trend, < budget | Custom logging / Helicone |
| ユーザーセッションあたりのコスト | 1 回のユーザー操作におけるすべての LLM 呼び出しの合計コスト | < $0.05 for most apps | LangSmith / custom |
| キャッシュヒット率 | セマンティックキャッシュから提供されたリクエストの割合 | > 30% | Redis metrics / custom |
| token 効率 | 消費した token 総数に対する有用な出力 token の比率 | > 60% | Custom analysis |
| モデルルーティングの分布 | トラフィックの何パーセントが各モデル階層へ行くか | < 20% to large model | Custom dashboard |
| 日次支出レート | 急増のための異常検知付きのローリング日次コスト | < 2x daily average | Helicone / alerts |
すべての LLM 呼び出しに、それが提供する機能（例：「chat」「search」「summarization」「classification」）のタグを付けます。これにより「どの機能が最もコストがかかるか？」「ユーザー操作あたりのコストは持続可能か？」に答えられます。これがなければ、手探りで最適化することになります。次のようなメタデータを {feature: "chat", user_tier: "free"} LLM プロキシのヘッダー経由で渡します。
すべてを一度に実装しようとしないでください。労力対効果の比に基づくこの優先順位に従ってください。各ステップは前のステップの上に積み重なります。
すべての LLM 呼び出しにロギングを追加します。入出力の token、使用モデル、機能、コスト、レイテンシを追跡します。計測しないものは最適化できません。
すべての system prompt を見直して圧縮します。冗長性を取り除き、指示を短くし、不要な few-shot の例を削ります。典型的な節約：20〜40%。
基本的なルーターを構築します。タスクベースのルーティング（単純なルール）から始め、その後分類器へ進みます。トラフィックの 70% 以上を最も安価で実用的なモデルへルーティングします。
トラフィックの多いエンドポイントにセマンティックキャッシュを展開します。完全一致から始め、その後 embedding 類似度を追加します。ヒット率 30% 以上を目指します。
リアルタイム応答を必要としないワークロードを特定します。それらの呼び出しで 50% を節約するため、バッチエンドポイントへ切り替えます。
機能別の帰属を備えたコストダッシュボードを展開します。異常アラートを設定します。LLM コストを第一級の運用指標にします。
タスクごとのコストと量のデータが得られたら、最も量の多いタスクにとって fine-tuning または self-hosting が経済的に意味をなすかを評価します。
| 最適化 | 労力 | 影響 | 節約 | 実施タイミング |
|---|---|---|---|---|
| prompt 圧縮 | Low | Medium | 20〜40% | 常に最初に行う |
| モデルルーティング | Medium | Very High | 60〜80% | 月 500 ドル超の支出時 |
| セマンティックキャッシュ | Medium | High | 30〜60% | クエリが反復的な場合 |
| バッチ処理 | Low | Medium | バッチ対象で 50% | レイテンシが重要でない場合 |
| fine-tuning | High | High | 70〜90% | 1 タスクで 1 日 10K 件超の呼び出し時 |
| self-hosting | Very High | Very High | 80〜95% | 月 1 万ドル超、またはデータ主権が必要な時 |
開始時のベースライン：LLM API に月 10,000 ドル。