Clawy / ガイド / LLM API コストを削減

回答の質を落とさず LLM API コストを削減する方法

OpenAI または Claude の請求を下げる 6 つのレバー——効果順。多くのチームは最初の 2 つを使っていません。

LLM 請求は退屈な理由で膨らみます：簡単なタスクに不相応なモデル、上限なしの出力、毎コール同じコンテキストをキャッシュせず再送信。どれも回答の質を犠牲にする必要はありません。お金が実際どこへ消えるか、最大のレバーから示します。

1. タスクに合うモデルを選ぶ

これは群を抜いて最大のレバーで、しかも無料です。フロンティアモデルはフロンティア作業向けの価格設定です。多くの本番コールはフロンティア作業ではありません。Claude の料金は入力・出力で 5× の幅があります：

大量・低難度のコールを Opus ではなく Haiku にルーティングすれば、それらのコストは品質を落とさず 5× 削減——もともと Opus は不要だったからです。高価なモデルは、品質指標を実際に動かすリクエストにだけ使いましょう。（どれを選ぶか迷う？どの Claude モデルを使うかを参照。）

2. 繰り返すコンテキストをキャッシュする

毎リクエストが同じ大きなシステムプロンプト・few-shot 例・文書を再送信すると、同一トークンに入力フル価格を払うことになります。プロンプトキャッシュは、ヒット時にキャッシュ済みプレフィックスを 通常の入力価格の約 10% で課金します。1 万トークンの固定前文を持つエージェントなら、入力コストの大半が消えます。

落とし穴は、キャッシュがプレフィックス一致であること：プレフィックスのどこかで 1 バイト変わると、それ以降すべてが無効になります。監査すべき静かなキャッシュキラー：システムプロンプト内の datetime.now() や UUID、未ソートの JSON シリアライズ、リクエストごとに変わるツールリスト。レスポンスの cache_read_input_tokens フィールドでヒットを確認——同一プレフィックスのコールでゼロなら、何かが無効化しています。

3. 出力に上限を設ける

出力はトークンあたり入力より 3〜5× 高く、上限なしの max_tokens は 1 つの饒舌な応答で請求を膨らませます。仕事に合った max_tokens を設定——分類器に必要なのは 50 トークンで、4,000 ではありません。拡張/適応思考を有効にしている場合、それらの推論トークンも出力として課金される点に注意。

4. コンテキストを減らす

入力トークンは本物のお金で、「文書を丸ごと詰め込む」は最も多い無駄です。全体ではなく関連するチャンクだけを取得して送信しましょう。会話履歴は長くなったら削る（または要約する）。Opus に送らない 1 万トークンごとに、1 コールあたり $0.05 が手元に残ります。

5. 急ぎでない作業をバッチ化する

ワークロードが即時回答を必要としないなら——夜間の分類、一括要約、評価——Batch API は同じリクエストを 50% オフで実行し、通常 1 時間以内に完了します。レイテンシを許容できるものはこれを通すべきです。

6. デフォルトは機能する最安モデルに

"安い"をデフォルトにし、意図的にエスカレーションする——その逆ではなく。シンプルなルーター——まず安いモデルを試し、タスクが必要とするときだけ強いモデルにフォールバック——だけで、レバー 1 の大半を自動的に取り込めます。

どれも品質をコストと引き換えにはしません——フロンティアでない作業にフロンティア価格を払うのをやめ、同じトークンに二重払いするのをやめるだけです。まず測定し（コール単価を把握）、それからレバーを順に引きましょう。