Amazon Bedrock最大90%削減

Amazonの投稿は、プロンプトキャッシュをよく知られたコスト問題に対するインフラレベルの解決策として位置づけている。キャッシュがなければ、1万トークンの契約書を50件のユーザー質問とともに送ると、内容の多くがすでに処理済みであっても、50万入力トークンが満額で課金される。記事は3つの回避策とそのトレードオフを挙げている。プロンプトを短くするとコンテキストの品質が下がる可能性があり、コンテキストウィンドウを小さくすると完全な情報に基づく推論が弱まり、レスポンスキャッシュは同じコンテキストに異なる質問を組み合わせた場合には何の役にも立たない。プロンプトキャッシュは、これらの妥協を避ける第4の道として提示されている。

仕組みが重要であるのは、そこに削減の源泉があるからだ。cachePointマーカーは、Amazon Bedrockに先行するコンテンツを既存のキャッシュエントリと比較するよう指示し、範囲は個々のAWSアカウントとリージョンに限定される。キャッシュヒットは再処理を省き、キャッシュされた状態から生成を開始する。キャッシュミスはすべてを処理し、新しいエントリを書き込む。Amazonはまた、cacheWriteInputTokensとcacheReadInputTokensという2つの新しいトークンカテゴリを挙げ、それぞれ標準入力より25%高く、90%安く価格設定している。90%の削減はキャッシュ読み取りに適用され、繰り返し使う文書で約75%の純削減という数字は、後続のリクエストがtime-to-liveウィンドウ内に収まることを前提としている。

購買者にとっての実践的な試金石は、自分たちのトラフィックパターンが実際にそのウィンドウに収まるかどうかだ。デフォルトのtime-to-liveは5分で、一部のモデルは最大1時間に対応し、期限切れ後のリクエストはより高いレートで新たなキャッシュ書き込みを引き起こす。モデルの選択も重要で、Anthropic Claude Sonnet 4.5とSonnet 4.6はチェックポイントごとに少なくとも1,024トークン、Opusモデルは少なくとも4,096トークンが必要だ。長い文書や安定したシステムプロンプトを定期的に送信するチームは最も明確な効果を得られる可能性が高い一方、散発的または小規模なペイロードのワークロードでは、書き込みの割増を正当化しにくいかもしれない。