Make Your Mastra Agent Cheaper and Faster with Prompt Caching
6分 24秒
LLMのコストを90%削減!プロンプトキャッシュを最大活用する最適化戦略
この記事は動画の内容を元にAIが生成したものです。正確な情報は元の動画をご確認ください。
ポイント
- •LLMの運用コストとレイテンシを削減したい方向けに、プロンプトキャッシュの仕組みと効果的な活用法を解説します。
- •OpenAIのキャッシュはプロンプトの冒頭が完全に一致する場合にのみ有効で、動的な要素を先頭に置くと効果が失われるのが要点です。
- •静的な指示や知識ベースを上部に、可変的な情報を下部に配置する最適化戦略で、最大90%のコスト削減と高速化を実現できます。
LLMのコストを90%削減!プロンプトキャッシュを最大活用する最適化戦略
大規模言語モデル(LLM)の利用が増えるにつれて、その運用コストは無視できない課題となっています。特に、OpenAIなどのプロバイダでは、入力および出力トークンの数に基づいて料金が課金されるため、コスト管理は非常に重要です。本記事では、LLMのコストを最大90%削減し、レイテンシを80%改善する可能性を秘めた「プロンプトキャッシュ(Prompt Caching)」の仕組みと、その効果を最大化するための最適化戦略について詳しく解説します。
多くの人がプロンプトキャッシュについて誤解している点は、「OpenAIが自動的に処理してくれるから、特に考慮する必要はない」と考えていることです。しかし、プロンプトの構成を最適化することで、キャッシュヒット率を大幅に向上させ、より多くのコストと時間の節約を実現できます。
プロンプトキャッシュの基本を理解する
まずは、プロンプトキャッシュがどのように機能するのか、その基本的な概念から見ていきましょう。
トークン課金の仕組み
OpenAIのようなLLMプロバイダは、処理するトークンの数に基づいて課金します。例えば、GPT-3.5-Turboでは、入力トークン100万あたり5ドル、出力トークン100万あたり30ドルといった料金体系が適用されます(料金は変動する可能性があります)。
出力トークンに対して料金が発生するのは理解しやすいでしょう。これはモデルが計算を行い、私たちが求める価値を生成するからです。しかし、なぜ入力トークンに対しても個別に課金されるのでしょうか?
入力トークンもまた、モデルによる計算リソースを使用します。すべてのトークンは、モデルの「アテンションメカニズム」で使用される「KV表現(Key-Value representations)」を生成するために、事前にモデルを介して処理される必要があるためです。この前処理は計算コストを伴います。
プロンプトキャッシュのメリット
ここで朗報です。もしOpenAIが、過去10分以内に全く同じプロンプトのプレフィックスを既に処理している場合、その高価な前処理作業をスキップできる可能性があります。なぜなら、それらのトークンを処理した結果が既に計算済みだからです。
OpenAIはこの節約分をユーザーに還元し、キャッシュされた入力トークンに対しては90%低い料金を請求します。これはコスト削減だけでなく、特に長いプロンプトの場合にはレイテンシ(応答時間)の削減にもつながります。
プロンプトキャッシュの仕組みと実践
では、プロンプトキャッシュは具体的にどのように機能し、実践ではどのような点に注意すればよいのでしょうか?これはLLMプロバイダによって異なりますが、OpenAIのケースを見てみましょう。
OpenAIの場合、プロンプトキャッシュは1024トークン以上のプロンプトに対して自動的に有効になります。
例えば、私がMastorエージェントで約10,000トークンの長い知識ベースシステム命令を使用しているケースを考えてみます。
- コールドスタート時: エージェントを初めて実行する場合、OpenAIはその正確なプロンプトプレフィックスを最近見ていないため、キャッシュに再利用できるものはありません。この場合、10,000トークンすべての入力トークンに対して全額を支払うことになります。
- フォローアップメッセージ時: その後、続けてメッセージを送信すると、新たに送信した入力トークンに対してのみ全額を支払います。以前の約10,000トークンのコンテキストはキャッシュされ、はるかに低いコストで再利用されます。
プロンプトキャッシュを最大化するための最も重要な原則
ここで最も重要なポイントであり、この記事の核心です。
プロンプトキャッシュは、プロンプトの冒頭が正確に一致する場合にのみ機能します。
つまり、キャッシュは、最初に変更されたトークンまでの部分にのみ適用されます。
- もしプロンプトプレフィックスの冒頭で何かを変更すると、キャッシュ全体が無効になります。
- もしプロンプトプレフィックスの途中で何かを変更すると、その変更点より前の部分については部分的なキャッシュヒットが得られる可能性がありますが、それ以降の部分は新しいものとして処理されなければなりません。
この原則を理解せずにプロンプトを構築すると、大きなコストを無駄にしてしまう可能性があります。
失敗事例: Project Discovery (Neqo) の教訓
自律型セキュリティテストプラットフォーム「Neqo」を開発しているProject Discoveryチームは、当初わずか7%のキャッシュヒット率しか得られていませんでした。彼らのワーキングメモリがほぼすべてのステップで変更されたため、それがキャッシュの大部分を無効化し続けていたのです。
この問題を修正したところ、彼らのキャッシュヒット率とコスト削減は劇的に増加しました。この事例は、プロンプト構成がいかに重要であるかを明確に示しています。
プロンプトキャッシュを最大活用する最適化戦略
では、どうすればこの点を正しく理解し、無駄な出費を避けることができるのでしょうか?効果的な最適化戦略を2つご紹介します。
1. プロンプトの先頭に動的な値を置かない
私の最初のヒントは、時間やリクエストIDのような動的な値をシステムプロンプトの冒頭に置かないことです。
例えば、プロンプトの先頭に現在時刻を埋め込んでいる場合、時計が1分進むだけでプロンプトの冒頭が変化し、事実上60秒ごとにキャッシュが無効化されてしまいます。これではキャッシュの恩恵をほとんど受けられません。
2. プロンプトの構造を最適化する:静的なものを上部へ、可変的なものを下部へ
次に推奨するのは、プロンプトを構造化し、最も静的なコンテキストを上部に、最も可変的なコンテキストを下部に配置することです。これにより、キャッシュの再利用を最大化できます。
例えば、ワーキングメモリのように時々変化する動的なデータをプロンプトの冒頭に近い位置に挿入しているとします。このワーキングメモリが変更されると、それ以降のすべてのデータはキャッシュされなくなってしまいます。
私のケースでは、大規模で安定した知識ベースのコンテキストがワーキングメモリの後に来ていました。これは、ワーキングメモリが変更されるたびに、その知識ベースのコンテキストも無効化され、キャッシュの大部分が失われることを意味しました。これは望ましくありません。
ここでの教訓は、常に最も安定したコンテンツを最初に配置し、より可変的なコンテンツを最後の方に配置することです。この小さな変更を行うことで、ワーキングメモリが更新された際に無効になるのはその時点以降のキャッシュのみとなり、私たちが本当にキャッシュしたい大部分の情報を維持することができます。
プロンプトを「ブロック」として考える
さらに一歩進んで、プロンプトを「ブロックのシリーズ」として考えることが役立ちます。
-
ウルトラステーブルなコンテキストブロック(Ultra-stable Context Block):
- システム命令や、決して変更されないFew-shot examplesなどがこれに該当します。
- 理論的には、このブロックはキャッシュを埋め尽くし、ユーザーが繰り返し利用することで営業中は「ウォーム」状態を維持するはずです。これにより、一度だけ料金を支払えば済むことになります。
- ただし、キャッシュヒットは保証されるものではありません。キャッシュミスを引き起こす制御不能な理由も多く存在しますが、私たちは制御可能な範囲で最適化を目指します。
-
安定したユーザー固有の情報ブロック(Stable User-specific Information Block):
- 次に、ユーザーごとに変化するものの、時間とともに変化しない安定したユーザー固有の情報を追加します。
- これらの値はユーザーセッションを超えてキャッシュできる可能性があります。
-
セッションまたはタスク固有のコンテキストブロック(Session or Task-specific Context Block):
- 下部には、メモリ、検索データ、中間状態など、頻繁に変化するセッションまたはタスク固有のコンテキストを追加します。
-
最後のNメッセージブロック(Last N Messages Block):
- もちろん、最後のNメッセージ(例えば過去20メッセージなど)もプロンプトに含めたいと思うでしょう。
- ただし、これは必ず最下部に配置するようにしてください。これは「スライディングウィンドウ」であるためです。
- Nメッセージの閾値を超えると、新しいメッセージが来るたびにこのブロックは無効化されます。そのため、この部分は比較的「揮発性」が高いと言えます。
まとめ
本記事では、プロンプトキャッシュの基本的な理解から、その効果を最大化するための重要な最適化戦略までを解説しました。プロンプトキャッシュはOpenAI固有の機能ではなく、Anthropicのような他のプロバイダでもサポートされています。各プロバイダには独自のメカニズム、料金体系、ニュアンスがありますが、今回の基礎知識があれば、それぞれのドキュメントを参照したり、LLMに詳細を問い合わせたりする際に役立つでしょう。
プロンプトの構成を意識的に最適化することで、LLMの利用コストを大幅に削減し、アプリケーションの応答速度を向上させることが可能です。ぜひ、今日からあなたのLLMアプリケーションにプロンプトキャッシュの最適化を取り入れてみてください。