TL;DR: 繰り返し、または類似したLLM呼び出しを行っている場合、すでに支払ったトークンの代金を、さらにトークンを消費して燃やしていることになります。セマンティックキャッシュは、完全一致の重複だけでなく意味的に類似したリクエストも検知し、サブミリ秒の時間でキャッシュ済みの応答を返します。Bifrostは、RedisとWeaviateの両方のバックエンドに対応しており、ストリーミング応答のキャッシュが標準で組み込まれています。
同じ答えに対して、たぶん2回支払っています
多くのチームが請求書が届くまで気づかないことがあります。LLMへの呼び出しの大きな割合は、すでに行った呼び出しと同一か、もしくは非常に似ています。
たとえば、ある顧客が「パスワードをリセットするにはどうすればいいですか？」と聞き、別の顧客が「パスワードを変更するにはどうすればいいですか？」と聞きます。違う言葉ですが、意図は同じで、答えも同じです。キャッシュがない場合、両方に対してフルのトークンコストを支払うことになります。
セマンティックキャッシュはこれを解決します。そして正しく実装できれば、LLMの支出を大きく削減できる可能性があります。
Bifrostにおけるセマンティックキャッシュの仕組み
Bifrostは、デュアルレイヤーのキャッシュ手法を採用しています:
- 完全一致のハッシュマッチング - リクエストが過去のリクエストとまったく同一であれば、キャッシュ済みの応答を即座に返します。LLMコストはゼロです。
- セマンティックな類似度マッチング - リクエストがキャッシュ済みのリクエストに「似ている」（ただし完全には一致しない）場合、ベクトルの類似度を用いて最も良い一致を見つけます。このときのコストは、類似度チェックのための埋め込み（embedding）生成のみです。
キャッシュミスの場合は、通常のモデルコストに加えて、将来の利用のためにキャッシュへ応答を保存する際の小さな埋め込みコストが発生します。
コストの内訳
| シナリオ | 支払うもの |
|---|---|
| キャッシュヒット（完全一致） | ゼロ |
| キャッシュヒット（セマンティック） | 埋め込みコストのみ |
| キャッシュミス | モデルコスト + キャッシュ保存のための埋め込みコスト |
キャッシュを考慮したコスト計算は、Bifrostが自動的に処理します。キャッシュヒット／ミスを手作業で追跡する必要はありません。コストダッシュボードは、キャッシュ後の実際のコストを反映します。
バックエンドの選択肢
Bifrostは、セマンティックキャッシュ用の複数のベクトルストアバックエンドに対応しています:
Redis（RediSearch付き）
すでにインフラでRedisを運用しているなら、最も簡単な道です。ベクトル類似度検索のために、RediSearchモジュールを有効化する必要があります。Redisには以下が提供されます:
- サブミリ秒のキャッシュ取得（メモリ内ストレージ）
- 類似度検索のためのHNSWアルゴリズム
- 高度な接続管理によるコネクションプーリング
- TTLサポートによる自動キャッシュ期限切れ
Weaviate
専用のベクトルデータベースが欲しい場合はWeaviateがサポートされています。これはベクトル類似度検索のために作られており、大きめのキャッシュストアでもうまく機能します。
カスタム実装
別のベクトルストアを運用している場合でも、Bifrostはカスタムバックエンド実装に対応しています。独自のストレージレイヤーを差し込むことができます。
ストリーミング応答のキャッシュ
これは、多くのキャッシュソリューションが間違える機能です。LLMの応答がストリーミングされる（ユーザー向けアプリケーションならそうすべきです）と、キャッシュが難しくなります。チャンクの正しい順序を維持しながら、完全な応答をキャッシュする必要があります。
Bifrostはストリーミングキャッシュを正しく処理します。ストリーミングされた応答は、適切なチャンク順序でキャッシュされるため、キャッシュ済みの応答が返されるときも、元の応答と同じようにストリーミングされます。
セットアップ
Bifrostを使う場合、セマンティックキャッシュは設定オプションです。ベクトルストアのバックエンドを選び、接続を設定すれば、すべてのプロバイダーにまたがってキャッシュが動き始めます。
Bifrostは19以上のプロバイダー（OpenAI、Anthropic、Azure、Bedrock、Gemini、Mistral、Cohere、Groq、その他）に対応しています。それらすべてでキャッシュは一貫して機能します。キャッシュされたOpenAIの応答は、Anthropicに送られていたはずの、セマンティックに類似したリクエストを提供できます。
ゲートウェイ自体が追加するレイテンシオーバーヘッドはわずか11マイクロ秒で、5,000 RPSの持続スループットを処理します。Goで書かれているため、キャッシュレイヤーがボトルネックになりません。
TTLとキャッシュ管理
キャッシュ済みの応答が永遠に残っていてほしくないはずです。TTL（Time-To-Live）のサポートにより、キャッシュされたエントリの自動期限切れを設定できます。
変化が速いデータには短いTTLを設定してください。安定した応答（ドキュメントの問い合わせやFAQのような質問）には、より長いTTLが理にかなっています。適切なTTLはユースケース次第ですが、自動期限切れがあることで古い応答を防げます。
セマンティックキャッシュが有効なとき
セマンティックキャッシュはすべてのユースケース向けではありません。特に次の場合に効果的です:
- カスタマーサポートボット - 類似した質問が大量にある
- ドキュメントアシスタント - 同じドキュメントで、似た質問が多い
- コード生成 - よくあるパターンが開発者間で繰り返される
- 社内ツール - 同じコードベースについて、チームが類似した質問をする
セマンティックな類似度が期待できない、非常にユニークで都度限りのリクエストでは、効果は低くなります。
まず始める
Bifrostはオープンソースです。npxまたはDockerでデプロイし、ベクトルストアを設定するだけで、すぐにキャッシュを開始できます。各バックエンドオプションについてはdocsで手順を説明しています。
すでにRedisをRediSearch付きで運用しているなら、セマンティックキャッシュは10分未満で動き始めます。
GitHub: git.new/bifrost
Docs: getmax.im/bifrostdocs
Website: getmax.im/bifrost-home
