3 つのレバーとそれらが重なる理由
「LLM コストを 90% 削減する」というアドバイスのほとんどは真実であり、それは次の場合にのみ当てはまります。 一部 ヘッドラインの数値は最良のケースを想定しています。この計算機はシェアを明示します。 即時キャッシュ 入力 (システム プロンプト、RAG コンテキスト、長いドキュメント) の繰り返しのプレフィックスを入力率の 10 ～ 50% に割引します。出力トークンや呼び出しごとに変更される入力に対しては何も行いません。 バッチ処理 非同期で実行できるリクエストに対して一律 50% を与えます。分類、要約、レポート生成には最適ですが、ライブ チャットには役に立ちません。 モデルルーティング 簡単なリクエストをより小さく、はるかに安価なモデルに送信し、難しいリクエストに対してはフロンティア モデルを保持します。それぞれが実際に到達できるトラフィックのスライスに適用すると、それらが組み合わさって本当に大幅な削減になります。
実質的な割引額が見出しよりも低い理由
90% のキャッシュ、50% のバッチ、85% のルーティングがすべて請求額全体に影響する場合、ほとんど料金はかかりませんが、実際はそうではありません。キャッシュはキャッシュ可能な入力のみを処理します。バッチは非同期トラフィックのみを処理します。ルーティングは、安価なモデルが処理できるリクエストのみに対応します。これらの株式を正直に設定すると、計算機は次の値を返します。 ブレンド 実際のワークロード全体で割引を行います。この混合された数字 (多くの場合、90% ではなく 40 ～ 70%) が予算に組み込まれます。個々のレバーを検証するには、 プロンプトキャッシュ計算ツール、 バッチ節約計算機 そして モデルルーティング計算機.
操作の順序が重要
これらのレバーは相互作用します。まずキャッシュによって入力コストが削減され、次にバッチとルーティングが残ったものに適用されるため、それらを積み重ねることは単純な追加ではありません。このツールは、キャッシュ可能な入力スライスにキャッシュを適用し、バッチおよびルーティングの割引をそのシェアに適用します。 残り そのため、合計の割引額は部分の合計よりも小さくなります。最適化する前に、ベースラインを正しく設定してください。 LLM トークンコスト計算ツール そして最も安いベースモデルを見つけてください 最安の LLM API.
使い方
1. 現在の毎月の LLM 支出と、入力トークンと出力トークンのおおよその割合を入力します。
2. 反復/キャッシュ可能な入力の量と、プロバイダーのキャッシュヒット価格 (10% Anthropic、25 ～ 50% OpenAI) を設定します。
3. バッチ処理できるトラフィックのシェアと、より安価なモデルにルーティングできるトラフィックのシェアを設定します。
4. 最適化された請求書と効果的な割引を読み、次に最大の「節約」行を持つレバーを最初に実装します。
よくある質問
キャッシュとバッチ処理はスタックしますか?
はい - バッチ化されたリクエストでも、キャッシュされたプレフィックスを使用できます。このツールは、最初に入力にキャッシュを適用し、次に残りの支出にバッチ/ルーティング割引を適用するため、複合効果は加算的ではなく乗算的になります。
どのキャッシュヒット価格を使用すればよいですか?
Anthropic bills は入力レートの 10% で読み取りをキャッシュします。 OpenAI はモデルに応じて 25 ～ 50%。 Google コンテキスト キャッシュは最大 10% です。キャッシュ可能な入力スライスにはプロバイダーの図を使用します。
ルーティングは品質にとって危険ですか?
ハードリクエストを弱いモデルにルーティングする場合のみ。安全なパターンは、単純な/短いリクエストを安価なモデルに送信し、残りをエスカレーションする分類子またはルール層です。支出分割をモデル化する ルーティング計算機.
見積もりのみ。割引は、正確なトラフィック ミックスとプロバイダーの価格によって異なります。予算を立てる前に現在の料金を確認してください。