詳しい解説 · 読了目安 8 分
AWSがBedrockエージェントのプロンプトキャッシュを解説：固定プレフィックスと別々の費用例
明示的な共有プレフィックスと暗黙的な履歴キャッシュを組み合わせ、ツール変更、補助エージェント、費用モデル、エンドポイント別監視を整理する。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
AWSのClaudio Mazzoniが10月26日の技術ガイドで、Amazon Bedrock上のOpenAIモデルを使うエージェントの計算再利用を説明した。新モデルの発表ではない。本文全体と費用図に基づく分析であり、AISubHubはコードの実行、費用・遅延・利用可能性の独立測定を行っていない。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- 対象プレフィックスは最低1,024 tokens。AWSは書き込みまたは成功した再利用後に最低30分保持され、書き込み料金は通常入力の1.25倍と説明する。
- 図4の相対入力費用は例示された暗黙方式が0.38、ローリング境界が0.39、キャッシュなしが1.00。特定負荷での結果である。
- 別のモデル化例は8,000 tokensの初期文脈に各2,000 tokensを6ターン追加し、費用は未使用0.87ドル、固定0.50ドル、ローリング0.32ドルとなる。
1. 計算の再利用は永続的な記憶ではない
エージェントは通常、ツール定義、指示、過去のやり取りを毎回送信する。prefillで入力からキー・バリュー状態を構築し、キャッシュは一致するプレフィックスの状態を再利用して新しい末尾を処理する。入力tokenの一致が必要なため、定義の直列化と順序を固定し、日時、名前、リクエストIDなど可変要素は共有部分の後ろに置く。
明示マーカーはツールと指示の後に共有終点を設け、暗黙モードは対象となる会話末尾を追う。併用できるが、最低1,024 tokensが必要だ。例のstore=Falseは履歴管理をアプリに残す設定で、キャッシュを無効にはしない。この最適化は永続記憶を作るものでも、必要な履歴を送らずに済む仕組みでもない。
2. 履歴を伸ばしても前の境界を残す
ループは暗号化された推論を含むモデル出力と対応するツール結果を追加し、過去メッセージを変えない。明示方式だけを使う場合、最新結果のまとまりに境界を追加し、古い境界も残す。固定境界だけでは後の履歴を再処理し、単一境界を最新ターンへ移す方法も再利用を失う可能性がある。あるタスクの末尾までの暗黙保存は、別タスク用の短い共有終点を必ず残すわけではない。
図4はGPT-6 Astraで6ターン、各ターン約2,000 tokensのツール出力を扱う負荷だ。相対入力費用は例示された暗黙方式0.38、ローリング0.39、固定のみ0.61、最新ターンのみ0.72、キャッシュなし1.00。約62%と61%の削減はこれらの構成に属し、図9の別のモデル化例の64%に置き換えてはいけない。
3. 初期カタログを変えずに呼び出しを選ぶ
既知のツールは同じ順序のTOOLSを維持し、tool_choiceのallowed_toolsで呼び出し対象を絞る。autoは許可ツールを呼ぶかどうかモデルに判断させ、requiredは最低1回の許可された呼び出しを要求する。キャッシュ対象のカタログ自体は変わらない。AISubHubはこれをプロンプト構成と解釈し、アプリ側の認可や安全な実行が保証された証拠とは扱わない。
途中で追加するツールについて、AWSはRuntimeとMantleがGPT-6 Astra、GPT-6.1 Sol、GPT-5.6 Lunaのadditional_toolsを受け付けると説明する。初期定義を変更せずスキーマを履歴に追加し、以後もその項目を残す。項目自体には境界を置けず、明示方式の例では後続input_textに置き、古い境界も保持する。役割ごとに異なる安定カタログを選ぶが、全モデル・全Regionで利用できるという意味ではない。
4. 補助エージェントの並列起動前に温める
通常のウォームアップ要求が完了してから並列処理を始める。暗黙モードでも準備要求と補助側の両方に共有プレフィックスのマーカーを置き、ツール、モデル、キーをそろえ、先にusageで活動を確認する。要約側は親の履歴全体をコピーして指示を追加できるため親を変更しない。ただし追加した指示が自動的に新しいキャッシュ終点になるわけではない。
再利用には同じモデル、AWSアカウント、Region、キー、一致するプレフィックスと、まだ利用可能なエントリーが必要だ。セッション専用キーは一致する会話も分離し、共有グループの安定キーは意図した再利用を可能にする。AWSは最新の書き込み・成功した再利用から最低30分、場合によりそれ以上と説明する。更新要求にも費用があり、永久保持や会計分離による安全保証にはならない。
5. 入力費用モデルと実際の請求を分ける
図9はGPT-6 Astraのサポートエージェントを、8,000 tokensの初期プレフィックスと各2,000 tokensを追加する6ターンでモデル化する。ガイドのオンデマンド価格の仮定では、累積入力費用はキャッシュなし0.87ドル、固定境界0.50ドル、ローリング0.32ドル。64%はこのモデル化例の削減率であり、図4やAISubHubが測定した実運用の値ではない。
書き込みは通常入力の1.25倍で、読み取り単価はモデルによる。短い処理や頻繁に変わる前半では、書き込みと準備費用を回収できない可能性がある。作者は読み取り削減と書き込み費用を合わせて確認するよう勧める。入力費用の比率からは出力tokenを除き、総請求には別途含める。例示額は現在の見積もりや総支出削減の保証ではない。
6. エンドポイントに合う監視とガバナンス
応答usageのcached_tokensとcache_write_tokensをまず確認する。RuntimeにはCloudWatchのCacheReadInputTokenCount、CacheWriteInputTokenCountもあり、呼び出しログで要求単位の検証ができる。ガイドによればMantleのCloudWatch名前空間には現在独立したキャッシュカウンターがなく、アプリが応答usageを記録する。Cost ExplorerではUsage typeで読み取り、書き込み、未キャッシュ入力を分ける。
作者はツール定義やシステムプロンプトの流出・悪用の可能性を挙げ、キャッシュもガバナンス対象とする。AISubHubの解釈では、共有範囲、権限、監視には個別審査が必要だ。記事は特定の漏えいや完全な防御策を証明していない。リンク先の補足文書の独立読解やコード実行は行っておらず、モデル、端点、地域、費用、遅延は各環境で確かめる必要がある。
注目する理由
設計上の要点は、固定した共有プレフィックス、追加だけで成長する履歴、補助エージェントへの意図的な共有を分けることだ。節約はオプションの有効化だけでなく、境界の維持と実際の読み書き計測に依存する。
制約と提供状況
完全な公式ガイドと必要な費用図を根拠とする。AWSの負荷結果とモデル化費用は異なる証拠で、どちらも出典に帰属させた。コード、補足文書、現在価格、実環境の独立検証はしていない。
出典と根拠
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。