Skip to main content
Prompt Caching (プロンプトキャッシング) は、繰り返し使用されるプロンプトのプレフィックス (先頭部分) に対する計算結果をキャッシュすることで、処理時間を削減します。キャッシュされるのはプロンプトのテキストそのものではなく、その処理に要した計算結果です。複数のリクエストがシステムプロンプトやドキュメントのような同じ冒頭テキストを共有している場合、SambaNova はそれらのトークンを一から再処理する代わりに、キャッシュされた結果を返します。最初の数リクエストで提供ノード上にキャッシュが構築され、同じプレフィックスが繰り返し観測されるにつれて削減効果が高まります。継続的なトラフィックでは、プレフィックスが数回観測された後、ヒット率は通常 90% 以上に達します。
Prompt Caching は、SambaCloud の MiniMax-M2.7 と MiniMax-M3 で利用できます。自動プレフィックスキャッシング (Automatic Prefix Caching; APC) はデフォルトで有効であり、リクエストの変更は不要です。

Prompt Caching を使用すべき場面

Prompt Caching は、入力の大部分がリクエスト間で繰り返される場合に、最も大きな削減効果を発揮します。 リクエストを重ねても cached_tokens が 0 のままの場合、入力がキャッシュ可能なプレフィックスを共有していません。システムプロンプトやコンテキストブロックが呼び出し間で安定しているかをご確認ください。

仕組み

自動プレフィックスキャッシング (APC) は、MiniMax-M2.7 と MiniMax-M3 では常に有効です。リクエスト間で共有されるプレフィックスを検出し、キャッシュされた計算結果を透過的に再利用します。API の変更は不要です。キャッシュヒットを最大化するには、メッセージの先頭部分をリクエスト間で安定した一貫性のある内容に保ってください。 プレフィックスは、messages 配列の先頭トークンシーケンスがキャッシュ済みのリクエストと同一である場合に一致と判定されます。システムプロンプトの言い換え、その前へのメッセージの挿入、コンテンツの並べ替えなど、プレフィックスへの何らかの変更があると、新しいキャッシュエントリが開始されます。システムプロンプトを同一に保ったままユーザーメッセージだけを変更した場合は、キャッシュ済みのプレフィックスが再利用されます。 キャッシュの状態は、各提供インスタンスに対してローカルです。複数インスタンスのデプロイメントでは、プレフィックスは各インスタンスで提供された後に、それぞれのインスタンス上で独立してキャッシュされます。

レスポンスからのキャッシュ使用状況の確認

すべてのレスポンスには、キャッシュから提供されたトークン数を示す prompt_tokens_details オブジェクトが含まれます。
cache_creation_tokens は、キャッシュエントリを構築する最初のリクエストでは 0 以外の値になり、以降のキャッシュヒット時には 0 になります。キャッシュされていない入力トークン数は prompt_tokens - cached_tokens です。

請求

キャッシュされたトークンは、標準の入力トークンよりも低いレートで請求されます。キャッシュ済み入力レートとキャッシュ書き込みレートを含む、お使いのモデルの全料金は、/v1/models エンドポイントおよび SambaCloud 料金ページ で確認できます。
キャッシュが有効なリクエストの請求計算式は以下のとおりです。
たとえば、入力トークンの合計が 5797 で、そのうち 4096 がキャッシュから提供されたリクエストでは、標準入力レートで請求されるのは 1701 トークンのみであり、4096 トークンはより低いキャッシュ済みレートで請求されます。出力の請求は変わりません。

サンプルコード

キャッシングは、共有プレフィックスが 4096 トークンに達した場合にのみ有効になります。以下のシステムプロンプトは読みやすさのために短くしています。実際にキャッシュヒットを観測するには、実際のドキュメントに置き換えてください。

制限事項

  • Prompt Caching は MiniMax-M2.7 と MiniMax-M3 のみで利用できます。他のモデルでは、usage オブジェクトにキャッシュ済みトークンのフィールド自体が含まれません。
  • キャッシュの状態は単一ノードに対してローカルであり、ノード間で共有されません。
  • キャッシュ可能なプレフィックスの最大長: 192000 トークン。
  • キャッシングの対象となるには、プレフィックスに最低 4096 トークン が含まれている必要があります。
  • キャッシュの削除 (eviction) には LRU (least recently used) ポリシーが使用されます。キャッシュの保持はシステム負荷によって変動し、保証されません。