Geminiにおけるコンテキストキャッシュを検討すべきタイミング #Cache – Qiita

生成AIを使用する際に同じ入力トークン（ファイルなど）をモデルに何度も渡すことがあります。この際にインプットのトークン数が多いと、プロンプトを実行するたびに入力のトークン数の処理が必要になり利用料金が増加してしまいます。
ここでコンテキストキャッシュを利用することで入力トークンをキャッシュに保存してから、キャッシュに保存されたトークンを後続のリクエストで参照することができます。
結果的にキャッシュに保存されたトークンを使用する方が、同じトークンを繰り返し渡すよりも費用が少なくなります。

一方で入力トークンの数やプロンプトの実行する回数によって毎回入力トークンを処理すべきか、コンテキストキャッシュを検討すべきかが変わってくるのではないかと考えました。

そこでどのような場合にコンテキストキャッシュを使用すべきかを検討しまとめたいと思います。

ドキュメントによるとコンテキストキャッシュを使用する状況は以下とのことです。
ユースケースとしては入力に使用するトークン数が多く、それに対して何度もクエリを行う場合が考えられます。

• 広範なシステム指示を伴う chatbot
• 長時間の動画ファイルの繰り返し分析
• 大規模なドキュメント セットに対する繰り返しのクエリ
• 頻繁なコード リポジトリの分析やバグ修正

コンテキストキャッシュは無料のサービスではなく運用コストを削減するための有料のサービスで以下の特徴があります。

• キャッシュトークン数:通常の入力トークン数と比較して割引料金で請求
• 保存期間:キャッシュに保存されたトークンの保存時間（TTL）。キャッシュに保存されたトークン数のTTL時間に基づいて課金。TTL の最小値や最大値に制限はなし
• その他の項目:入力トークンや出力トークンがキャッシュされていない場合などは別の料金が適用

また注意点としては以下もあります。

• コンテキスト キャッシュの最小入力トークン数は4,096で、最大数は指定されたモデルの最大数と同じです。
• モデルは、キャッシュに保存されたトークンと通常の入力トークンを区別しません。キャッシュに保存されたコンテンツは、プロンプトの接頭辞です。
• コンテキストキャッシュには特別なレートや使用量の上限はありません。GenerateContent の標準レートの上限が適用され、トークンの上限にはキャッシュに保存されたトークンが含まれます。
• キャッシュに保存されているトークン数は、キャッシュ サービスの create、get、list オペレーションから usage_metadata で返されます。また、キャッシュを使用している場合は GenerateContent でも返されます。

コンテキストキャッシュの料金体系