Amazon Bedrock プロンプトキャッシュについてまとめてみた
こんにちは、森田です。
本記事では、re:Invent 2024 で発表された Amazon Bedrock プロンプトキャッシュの詳細をまとめてみました。
先にまとめ
- 頻繁に入力するプロンプトをキャッシュしてくれる機能
- レイテンシーやコストメリットが期待できる
- モデルごとでキャッシュできるトークン数に違いがある
プロンプトキャッシュ
モデルへのプロンプト入力をキャッシュしてくれる機能です。
この機能を使うことで同じプロンプトが入力された場合にはキャッシュから情報を再利用できるようになります。
そのため、応答レイテンシーの短縮やコストメリットがあるとされています。
一般的なキャッシュのイメージと同じですね。
他のプロバイダー
プロンプトキャッシュの仕組みについては、他のプロバイダーでも提供されています。
プロンプトキャッシュの仕組み
では、もう少し詳細なプロンプトキャッシュの仕組みをみていきます。
プロンプトキャッシュでは、API側でキャッシュする機構を持ちます。
このキャッシュする機構は、プロンプトがキャッシュされるチェックポイント(キャッシュチェックポイント)で構成されています。
キャッシュチェックポイント
キャッシュチェックポイントでは、
- 最小トークン数
- チェックポイントの最大数
- キャッシュできるフィールド
- Time To Live (TTL)
を考慮する必要があります。
最小トークン数
キャッシュ可能なトークン数として、最小トークン数が設定されています。
この最小トークン数を超えるプロンプトのみキャッシュできるようになります。
例えば、Claudeでは、最小トークンが大きいため、短いプロンプトについてはキャッシュに載せることができません。
- Amazon Nova シリーズ
- 1トークン
- Claude 3.5 Haiku
- 2,048トークン
- Claude 3.5 Sonnet v2
- 1,024トークン
この最小トークンごとにキャッシュチェックポイントが作成されます。
チェックポイントの最大数
キャッシュできる量にも上限があります。
この上限はチェックポイントの最大数から考えることができます。
- Amazon Nova シリーズ
- 1チェックポイント
- Claude
- 4チェックポイント
Claude 3.5 Haikuでは、4チェックポイント×2,048トークン
で8,192トークン
をキャッシュすることができます。
キャッシュできるフィールド
モデルによってキャッシュできるフィールドも異なっています。
- Amazon Nova シリーズ
- system プロンプト
- Claude
- system、messages、tools プロンプト
Time To Live (TTL)
キャッシュについては、 5 分間の Time To Live (TTL) があります。
この期間中、キャッシュ内のコンテキストは保持されますが、期間中にキャッシュヒットが発生しない場合は、キャッシュは期限切れとなり、リセットされます。
API
APIからモデル呼び出しを行う際の各フィールドに追加することで可能です。
{
...
"messages": [
{
"role": "user",
"content": [
{
"image": {
"bytes": "asfb14tscve..."
}
},
{
"text": "What's is in this image?"
},
{
> "cachePoint": {
> "type": "default"
> }
}
]
}
]
...
}
料金
現状詳細な料金については、公開されていないです。
When using prompt caching, you're charged at a reduced rate for inference and a different rate for how many tokens are read from and written to the cache.
ドキュメント内に上記の文章があるため、料金体系が通常と異なりそうですが、基本はお安くなりそうな気がしています。
さいごに
現状プレビュー中のため、公開されている情報が少ないですが、ざっくりとまとめてみました。
モデルがプロンプトキャッシュに対応している場合はとりあえず有効化すると、レイテンシーやコストメリットが期待できそうです。
GAのタイミングで正式な料金なども発表されると思うので、その後利用を検討すると良いでしょう。