Google の Gemini API にコンテキストキャッシングを最近追加したことは、長文コンテキスト言語モデル (LLM) の主要な制限の一部に対処することを目的としています。LLM は大量の情報を保持できますが、いくつかの問題に悩まされています:

• 処理時間の増加: クエリごとに、全体のコンテキストを LLM に送る必要があるため、大量のデータを処理することになり、処理時間が増加します。
• 高レイテンシ: 各クエリに必要な大量のデータ転送により、高レイテンシが発生します。
• コストの上昇: API プロバイダーがトークン数に基づいて課金するため、データ転送の増加によりコストが上昇します。

Google のコンテキストキャッシングの機能はこれらの問題を軽減しようとしています。以下がその仕組みです:

1. キャッシュの初期化: システム命令や大量のコンテキスト (文書、ビデオファイル、オーディオファイルなど) をキャッシュしたいものを提供します。
2. キャッシュの識別: 各キャッシュには一意の識別子 (キャッシュの名前と考えられる) と、キャッシュの有効期限を決める "Time to Live" パラメーターがあります。
3. キャッシュの取得: Gemini API がユーザークエリを受け取ると、利用可能なキャッシュデータセットを分析し、適切なキャッシュを取得し、ユーザークエリと組み合わせて処理します。

このアプローチにはいくつかの利点があります:

• 処理時間の短縮: キャッシュデータを再利用することで、システムはユーザークエリのみを処理すればよくなり、全体の処理時間が短縮されます。
• レイテンシの低下: 全コンテキストではなくユーザークエリのみを送信するため、レイテンシが低下します。
• コスト削減: 各クエリで送信するトークン数を減らすことで、コストが削減されます。

Google は、最大 2,128,000 トークンまでキャッシングを使用すると、全コンテキストを毎回送信する場合と比べて、ほぼ 4 倍コストが削減できると主張しています。

コンテキストキャッシングを使用する際には、いくつかの制限と考慮事項があることに注意が必要です:

• 最小入力トークン数: コンテキストキャッシングの最小入力トークン数は現在 32,000 トークンに設定されています。
• 最大トークン数: キャッシュできる最大トークン数は、モデルの最大コンテキストウィンドウ (Gemini Pro および Flash モデルでは約 2 百万トークン) によって制限されます。
• ストレージコスト: キャッシュされたコンテンツには、1 百万トークンあたり 1 ドルの時間当たりのストレージコストがかかります。

全体として、Google の Gemini API におけるコンテキストキャッシングの機能は、大量のコンテキストを扱う LLM ベースのアプリケーションの性能とコスト効率を大幅に向上させる価値のある追加機能です。