コンテキスト ウィンドウと長いプロンプトが高価になる理由

コンテキストウィンドウとは

コンテキスト ウィンドウは、トークン単位で測定される、単一リクエストに対するモデルの作業メモリです。システム プロンプト、含めるドキュメントや例、会話履歴、現在の質問、モデルの回答用に予約されたスペースなど、モデルが考慮するすべてのものを一度に保持する必要があります。これらは一緒にウィンドウのトークン制限内に収まる必要があります。

モデルは、数千トークンから数十万トークン以上まで、さまざまなサイズのウィンドウをアドバタイズします。ウィンドウが大きくなると、書籍全体や大規模なコードベースなど、一度に多くの情報を入力できますが、入力したものに対して支払うという基本的な課金ルールは変わりません。

使用したウィンドウ全体、通話ごとに料金を支払います

ここが人々を惹きつける部分です。 200,000 トークンのウィンドウがあるからといって、200,000 トークンを支払うという意味ではありません。それはあなたを意味します できる その数まで使用すると、通話ごとに実際に使用した数に応じて料金が請求されます。

So if you stuff 150,000 tokens of documents into the window and ask 10 questions, you pay for roughly 150,000 input tokens ten times, 1.5 million tokens, not once. The window is a ceiling, not a subscription. Long context is powerful, but it is billed relentlessly per call.

長いプロンプトがすぐに高価になる理由

入力トークンは通話ごとに請求されるため、プロンプトの長さは通話量に比例して増加します。プロンプトが 10 倍長いと、同じ呼び出し数に対して入力トークンのコストが約 10 倍になります。次の 2 つの習慣により、プロンプトが気付かれずに長く表示されます。

• チャット履歴が増えていく、すべてのターンで完全に再送信されるため、長い会話の後半のメッセージにはトランスクリプト全体が含まれます。
• 検索 (RAG)ここで、取得した大きなドキュメントをプロンプトに貼り付けて、モデルにコンテキストを与えます。取得しすぎると、クエリごとにすべての費用が発生します。

どちらも間違っているわけではありませんが、請求書が届くまでコストは通知されないため、どちらにも規律が必要です。

加工したイラスト

説明のための例 (100 万入力トークンあたり 3 ドルのレートを発明)。各クエリに 50,000 個のトークンが取得されたコンテキストが含まれているとします。 1 つのクエリの入力コストだけで、50,000 / 1,000,000 x 3 ドル = 0.15 ドルかかります。このようなクエリを月に 100,000 回実行すると、出力コストを除くと、再送信するコンテキストだけで 15,000 ドルかかります。

次に、より選択的に取得することで、取得されたコンテキストを 10,000 トークンにトリミングします。同じ 100,000 のクエリのコストは 3,000 ドルで、5 分の 1 になりますが、いずれにせよモデルが追加の 40,000 トークンで溺れていたため、コンテキストは同様に役立つことがよくあります。これが、コンテキストの規律がコスト管理の中で最も効果的なものの 1 つである理由です。

長い文脈も品質を損なう可能性がある

コンテキストが多ければ多いほど、必ずしも良い答えが得られるとは限りません。モデルは、非常に長いプロンプトの途中に埋もれた詳細を見失う可能性があります。これは、最初と最後にある情報がうまく活用され、途中が無視されるパターンです。そのため、コンテキスト ウィンドウが肥大化するとコストが高くなる可能性があります そして もっと悪い結果を生みます。

最も関連性の高いマテリアルのみをモデルにフィードすると、多くの場合、請求書と回答の両方が改善されます。精度は量に勝ります: タイトで適切に選択された 4,000 トークンのコンテキストは、無秩序に広がる 100,000 トークンのダンプよりも優れたパフォーマンスを発揮することがよくあります。

コンテキストを無駄なく保つ方法

コンテキストコストを制御するための実践的な戦術:

• 選択的に取得します。 RAG では、漠然と一致するすべてのチャンクではなく、最も関連性の高い上位のいくつかのチャンクのみを返します。
• 昔のターンをまとめます。 完全なトランスクリプトを再送信するのではなく、長い過去の会話を短い要約に置き換えます。
• 固定部分をキャッシュします。 コンテキストの大部分が呼び出し間で繰り返される場合、プロンプト キャッシュ (そのガイドを参照) により、再送信のコストを削減できます。
• ウィンドウのサイズを適切に調整します。 デフォルトで利用可能な最大のものを選択するのではなく、実際のニーズに合ったウィンドウをもつモデルを選択してください。

各モデルのプロンプトの長さが実際の金額にどのように対応するかを確認するには、トークン数を LLM コスト計算ツールに入力し、モデル比較ページと /models ページでモデルごとのウィンドウ価格を確認します。

学び続ける

関連ツール

よくある質問

モデルのフル コンテキスト ウィンドウに対して料金を支払いますか?

いいえ。支払いは、ウィンドウの制限を上限として、各リクエストに実際に含めたトークンに対してのみ発生します。ウィンドウは最大容量であり、その中で使用するすべてのトークンは呼び出しごとに請求されます。

コンテキスト ウィンドウが大きくなると、トークンあたりのコストも高くなりますか?

必ずしもトークンごとではありませんが、ウィンドウが大きいほど、はるかに多くのテキストを含めることができます。また、すべてのトークンは通話ごとに請求されるため、プロンプトが大きくなると合計額が増加します。プロバイダーによっては、特定のコンテキスト長を超えると、より高い料金を請求する場合もあります。

コンテキストが多いほど常に品質が向上しますか?

いいえ、モデルは非常に長いプロンプトに埋もれた詳細を見落とす可能性があるため、過剰なコンテキストによってコストが上昇し、回答の品質が低下する可能性があります。多くの場合、より小さく、適切に選択されたコンテキストの方がパフォーマンスが向上します。