コスト最適化

LLM 運用は意外とコストがかさみます。以下のレバーを意識しましょう。

1. モデル選択 (Routing)

簡単なタスクは Haiku, ほどほどは Sonnet, 難しいときだけ Opus。

2 段階ルーティング

wzxhzdk:2

2. Prompt Caching

固定的な system / RAG コンテキストはキャッシュ。 ヒット率 60-80% を目標に (第4章参照)。

3. Output 削減

• 不要な前置き「承知しました、〜」を出さないよう指示。
• 出力は 最小限の構造化形式 (JSON / 短いリスト)。
• max_tokens を適切に絞る。
• stop_sequences で早期停止。

4. Batch API

リアルタイム不要な処理は Batch で 50% 引き。

5. 入力削減

• RAG のチャンク数を絞る (Top-K=3 で十分なことが多い)。
• 長い履歴は要約で圧縮。
• 不要な空白・コメントは事前に削除。
• system に重複情報を書かない。

6. キャッシング (アプリレベル)

• 同じ質問は アプリ側でも結果キャッシュ (Redis 等)。
• 質問正規化 (lowercase, 句読点除去) でヒット率向上。
• 短時間の再質問だけ 60 秒キャッシュなど。

7. ガードレール

• ループや無限呼び出しを検知 (max iterations)。
• ユーザーごとの クォータ を設ける。
• 異常パターンをアラート。
• 過剰な max_tokens をリクエスト時に拒否。

8. 監視と継続改善

• リクエスト単位で usage を記録。
• ダッシュボードで モデル別・エンドポイント別コスト を可視化。
• 月次でチューニング。
• 上位 10 ユーザーの使い方をスポットチェック。

コスト計算ツール

Anthropic 価格ページ で モデル別の token 単価を確認できます。 ざっくり計算式:

wzxhzdk:3

典型的な節約パターン

組み合わせれば 元コストの 5-10% まで圧縮可能。

Anti-pattern

❌ 何でも Opus を使う ❌ システム入力をキャッシュしない ❌ 出力に max_tokens を設定しない ❌ ユーザー間で無制限に呼び出させる ❌ 監視せずデプロイ

試す

コスト改善の提案を Claude に。

リクエスト 1 件のトークン消費を見積もって月間コストを算出するスクリプトを書いてください。

入力: - system 文字数, 平均 user 文字数, 平均 assistant 文字数 - 1 日のリクエスト数 - モデル選択 (haiku/sonnet/opus) - prompt cache のヒット率

出力: 月間コスト (USD) と内訳。