リアクティブインフラストラクチャとは、流入する観測情報を視聴者の体験の変化につなげる、共通のパターンを指します。フィードのパーソナライズ、体感品質（QoE）の監視、不正視聴の検知といった具体的な機能は、ライブメディアシステムの異なる部分に関わりますが、いずれも何らかのクライアントの行動を適時の判断につなげます。

共通の課題は、CDN を使わずに、変動の大きい CDN 規模のトラフィックを取り込むところから始まります。テレビ、ブラウザー、モバイル端末は、観測した情報を収集エンドポイントに直接送信します。視聴者の急増は取り込みトラフィックの急増につながり、受け付けたイベントはすべて、そのエンドポイントより先でも処理を発生させます。そして、データの収集は出発点にすぎません。生データを数秒以内に活用できる状態にし、別の場所で利用できるよう届ける必要があります。

この作業を整理するのが、取り込み → 処理 → ストレージ → 意思決定という4段階のパターンです。収集する情報、データのグループ分け、利用するストア、導き出す判断を変えることで、各段階をそれぞれのユースケースに合わせられます。段階ごとの責任を明確にすると、各段階で特に重要な設計上の選択肢を見極めやすくなります。

4つの段階でフィードバックループを閉じる

リアクティブなアーキテクチャは、クライアント上での観測からデータパイプラインを経て、クライアントの体験の変化に戻る閉じたループを形成します。その変化から新たな観測情報が生まれ、サイクルが再び始まります。

このアーキテクチャは、次の4つの段階で構成されます。

1. 取り込みはクライアントのイベントを受け付け、流入するトラフィックを整えます。
2. 処理はイベントの断片を、整理された検証済みのストリームにまとめます。
3. ストレージは、データを利用する側に適した形式で、分析に使えるよう提供します。
4. 意思決定は、そこから得た情報を製品の動作につなげます。

共通の4段階のパターンが、クライアントの行動をメディア体験に影響する判断につなげます。

各段階のクラウドコンポーネントは、それぞれの責任に集中します。インターネットに公開されたゲートウェイが、クライアントからビーコンを受信します。その背後では Valkey（コミュニティが支える Redis のフォーク）が共有の収集プールを提供し、軽量な関数とコネクターが下流のストア向けにデータを準備します。判断を行うコンポーネントは、必要な情報を使い、ビジネスロジック、エッジ関数、またはオペレーターの操作を通じて体験に働きかけます。

図中の Gateway or CDN の経路は、視聴者に体験を届ける外向きの方向、つまりエグレスを表しています。クライアントの観測情報がアーキテクチャに入る内向きの経路、つまりイングレスと対になるものです。

データはこのアーキテクチャを取り込みから意思決定へと流れますが、設計のプロセスは実際に導き出したい判断から逆算すべきです。その判断にはどの情報が必要か。どれほど迅速に体験へ反映する必要があるか。データ損失をどこまで許容できるか。これらの答えが、各段階の選択を決めます。

取り込みはクライアントのトラフィックから下流サービスを保護する

取り込みの段階は、インフラストラクチャと数百万人の視聴者をつなぐ接点です。そのゲートウェイは、公開インターネット上の端末からの接続を処理し、トラフィックの急激な変動を吸収して、その変動が内部サービスを圧迫しないようにする必要があります。

HTTP ビーコンは、最終的にユーザー体験に関する判断につながる情報を運ぶ手段です。ビーコンのサイズと頻度は、ゲートウェイの負荷に直接影響します。判断に必要な情報を選び、各ペイロードを小さく保ちます。判断に新たな観測情報が必要となる速さに合わせてビーコンの送信間隔を設定し、必要以上に収集することなく、有用な更新情報をシステムに届けます。

ゲートウェイは、トラフィックをバックエンドへ安全に届ける方法を制御します。流入したイベントを短時間保持してまとめて転送し、大量に押し寄せる個別リクエストを、より扱いやすいマイクロバッチに変えます。データの流れを整えることで、ゲートウェイは下流のインフラストラクチャを保護し、負荷に備えた過剰な容量確保の必要性を減らします。

バッファリングの時間が判断のレイテンシ予算に対して小さい場合、マイクロバッチ処理による短い遅延は、エンドツーエンドのレイテンシの中では無視できるほど小さいものです。ただし、データ損失が起こる機会はわずかに増えます。バッファー内のイベントにはコピーが1つしかないため、転送前にゲートウェイのノードが停止すると、それらは失われます。最終的に、バッチ処理の方針は、データ損失リスクのわずかな増加と引き換えに、全体の信頼性を大幅に高め、インフラストラクチャのコストを削減します。

Momento Valkey Router は、この境界でコネクションプーリング、認証、スロットリング、シャードを考慮したルーティングを提供します。これらの仕組みは、アーキテクチャ上のビーコンのバッチ処理とともに、ゲートウェイによる保護を支えます。バックエンド接続を再利用することで、収集層はクライアントごとに上流への接続を個別に維持せずに、はるかに多くの端末を扱えます。

処理はイベントを整理し、利用する側に振り分ける

バッチは異なるゲートウェイのノードを経由して到着するため、関連する行動の断片が別々のバッファーに残ります。処理の段階では、その断片を Valkey を基盤とする複製された共通の収集プールに集め、下流で使えるように準備します。軽量な関数と非同期コネクターが変換と振り分けを担います。

ストリームは、セッション ID や地域など、ビーコンの何らかの属性によって識別されます。ストリームキーが関連するイベントを適切なシャードに送ると、そこで断片が整理されたストリームにまとめられます。この整理の段階を経ることで、下流の利用先は、ストレージへの保存と分析に使える、関連する行動の一貫した流れを受け取れます。

この段階では、準備の処理を軽量に保つ必要があります。稼働中の利用先に届く前にレコードを検証し、データの形式を少し調整して、適切な出力先に振り分けます。負荷の高い結合、探索的なクエリ、複雑な分析は、それらの作業に適した下流システムで行います。生データのアーカイブはリアルタイムの検証処理とは独立して保持し、不正な形式のレコードも調査や再処理に利用できるようにします。

Momento の軽量な WASM 関数は、このような短時間の検証や変換をバッチで実行します。非同期のシンクコネクターは Valkey からデータを取り出し、完成したファイルを S3 などの送信先に書き出します。これにより、その転送処理をクライアントリクエストから切り離します。

ストレージは利用する側に合わせてデータを提供する

イベントを整理したら、次に考えるのはその使い方です。1つのデータベースですべての問いに答えようとするのではなく、利用する側のアクセスパターンに合わせてストレージを選びます。同じイベントの流れを利用していても、クエリの形、必要な応答時間、保持期間は大きく異なる場合があります。

QoE 監視は、この違いをよく示しています。数秒以内に作動させるべき自動アラームには、Valkey の移動時間窓のカウンターを利用します。一方、インシデントを調査するオペレーターには、1分未満でアドホッククエリを実行するために ClickHouse などの分析用ストアが必要です。それと並行して、イベントを Parquet 形式の S3 アーカイブに送り、過去の分析、再処理、監査に利用します。範囲を限定したカウンター参照、探索的なクエリ、過去データのスキャンでは、ストレージに求めるものが大きく異なります。

パーソナライズでは、クエリの形がさらに変わります。ユーザーやコンテンツの表現に対する類似検索には、ベクトルを扱うストレージが必要です。データの表現と検索方法を変えても、アーキテクチャ上のストレージの責任は変わりません。具体的な保存先は、利用する側の要件に合わせて選びます。

Valkey は、収集と高速な運用データストレージの両方の役割を担います。この2つの役割は、異なる作業を行いながら、同じ層で実現しても構いません。処理の段階で導入した非同期コネクターがアーカイブ用ストレージへの独立した転送経路を提供する一方、稼働中の利用先は、それぞれのニーズに合わせて用意されたビューを使います。

カウンターの参照やクエリの実行にかかる時間は、クライアントの行動から結果が反映されるまでの時間の一部にすぎません。ビーコンの送信間隔、バッファリング、準備の処理、判断のタイミングも影響します。必要な情報が遅れて届くパイプラインは、高速なストアを選ぶだけでは補えません。

意思決定は体験を妨げずに結果を反映する

意思決定は、準備された情報をメディアシステムの動作につなげます。ポリシーエンジンやオペレーターなど、判断を行う側がその情報を評価し、実行するアクションを選びます。製品のビジネスロジックやエッジ関数が、順位付け、配信経路、セッションポリシーなどのアプリケーションの動作に結果を適用します。

分析のワークロードは、稼働中のリクエスト処理のクリティカルパスから外します。視聴者のリクエストごとに複雑なクエリを必須にすると、製品の応答時間と可用性がそのクエリシステムに依存します。視聴者のリクエスト経路の外で判断を計算し、その結果をリクエスト処理のロジックから利用できるようにします。そのロジックは、リクエストごとに新たな分析クエリを待たずに結果を適用します。判断が影響を与えるべき結果に合わせて、判断を更新する頻度を選びます。

不正視聴の検知は、このタイミングの関係を示す例です。セグメントのリクエストと次のリクエストの間にポリシー分析を行い、その後の制御に使う結果を用意します。セグメントの応答ごとに同じ分析を加えずに、判断のための時間を確保できます。既存のアクセス認可は、引き続き配信システムの一部です。

パーソナライズでも、タイミングを意図的に決める理由があります。関心を示すデータが継続的に更新されても、画面を更新するたびに異なる順位付けを返す必要はありません。裏側で分析を続けながら、公開済みの順位付けを一定に保ちます。どちらの場合も、判断の更新頻度は体験に必要な条件に合わせます。

製品が判断を反映すると、その後のクライアントの観測情報が効果を示します。その観測情報は取り込みを経由して戻り、サイクルが再び始まります。

判断に合わせてアーキテクチャを調整する

このリアクティブなアーキテクチャの4つの段階が連携することで、CDN 規模の観測情報を数秒以内にユーザーが体験する変化へとつなげます。

ゲートウェイのバッチ処理は、内部サービスにデータが届く前にリクエストのオーバーヘッドを減らします。収集プールは関連する行動の情報を整理されたストリームにまとめ、下流の利用先ごとに適切なデータストアへ送ります。その情報を分析エンジンが判断につなげ、アプリケーションのビジネスロジックが判断を反映することで、ユーザー体験に変化をもたらします。

フィードのパーソナライズ、QoE 監視、不正視聴の検知など、さまざまなユースケースで、少し調整するだけで同じアーキテクチャを活用できます。求める結果から始め、アーキテクチャをさかのぼりながら、判断を適用する方法を決め、それに伴う制約を各段階に反映することが大切です。データによってユーザーの体験が変わるとき、このループはリアクティブに機能します。

CDN を使わずに CDN 規模のトラフィックを処理するシステムの構築は、専門家にとっても難しい課題です。Momento のエンジニアは、ミッションクリティカルな状況でシステムがどのように障害を起こすかを理解し、毎秒数百万件のリクエストを処理できるように Momento プラットフォームを設計しました。このプラットフォームは、FOX、Paramount、Warner Bros. Discovery などの主要なプロバイダーで、サッカーワールドカップ、スーパーボウルをはじめとする世界規模のメディアイベントのライブ体験を支えてきました。

製品をよりリアクティブにする方法を検討したい方は、お問い合わせください。

ビーコンには、後段の分析に必要な信号を選んで収めた端末のテレメトリが含まれます。そのイベントデータは、視聴品質の監視、不正視聴の検知、パーソナライゼーションなどに使えます。どの信号を選ぶかは、分析だけでなく取り込みにも影響します。フィールドを追加するたびにペイロードが増え、その追加バイト数が、システムで受信して保持するビーコン全体にわたって積み重なります。

そのため、ビーコン取り込みには、端末のトラフィックと内部処理の間に保護のための境界が必要です。このアーキテクチャでは、Momento Valkey Router がゲートウェイ層でビーコンを受信し、端末の接続を管理して、転送するデータをバッチ化します。共有のオープンソース Valkey が関連するイベントを集め、後段のサービスで処理できるまでバッファリングします。ゲートウェイと Valkey を組み合わせることで、予測しにくい大量のビーコンを、内部サービスが無理のないペースで消費できる整理されたデータへと変えます。

Valkey Router と共有 Valkey によるイベント収集が、端末のトラフィックと後段のサービスの間に取り込みの保護境界を作ります。図中の Kafka、ClickHouse、S3 は後段の処理先の例です。

端末のトラフィックから内部サービスを保護する

ゲートウェイは、視聴者の端末接続と、内部インフラが支える接続を分離します。この境界がなければ、端末数の増加によって、ビーコン量とデータベースへの接続負荷の両方が増える可能性があります。この 2 つは異なる要求です。内部サービスにイベントを処理する能力が十分あっても、それを届ける接続の管理に苦労することがあります。

Valkey Router は端末の接続を処理し、Valkey への接続プールを再利用します。プールを使うことで、端末ごとに Valkey 接続を個別に作る必要がなくなります。ゲートウェイは、多数の端末からトラフィックを受けながら、データベースへの接続数を制御できます。Momento は、Valkey のオープンソースのストレージ基盤とともにこのゲートウェイ層を提供し、共有のイベント収集よりも手前に、端末向けの接続処理機能を配置します。

ゲートウェイは、イベント収集へのアクセスも制御します。認証とアクセスチェックによって、入ってきたトラフィックを内部インフラへ通してよいか判断します。HTTPS と TLS 終端が端末からゲートウェイまでの通信を保護し、カスタム証明書を使えば、デプロイ先で求められる証明書をエンドポイントに設定できます。こうした機能によって、端末のトラフィックがシステムに入る境界で接続とアクセスを処理します。

流入するトラフィックが次の処理段階を圧倒しそうな場合には、スロットリングで転送レートを制限します。ゲートウェイが、過剰なトラフィックがデータベースやコンシューマーに届く前に取り込みを制御します。コネクションプーリングとスロットリングは、同じ保護境界の異なる課題を担います。一方はデータベースへの接続数を制御し、もう一方は内部サービスへ届くデータのレートを制御します。

小さなビーコンをまとめて転送のオーバーヘッドを分担する

接続を管理しても、転送すべき小さなペイロードは大量に残ります。ビーコンを 1 件ずつ送ると、通信やリクエスト処理のオーバーヘッドが繰り返し発生します。この反復的な処理が取り込み能力の大きな部分を占めると、イベントデータを効率的に集める代わりに、小さなテレメトリを個別に運ぶことにリソースを費やしてしまいます。

Valkey Router は、一緒に扱えるビーコンをローカルでバッチ化してから転送します。複数のビーコンでバッチのオーバーヘッドを分担することで、ビーコン 1 件あたりの転送コストの反復を減らします。含まれるイベントデータは、引き続き収集できます。バッチ化はデータの運び方を変えるものであり、分析に必要な観測データをアプリケーションから削る必要はありません。

バッチ化には、まとめて送るデータがたまるまでゲートウェイで短時間待つという側面があります。ゲートウェイは、その待ち時間と蓄積するデータ量に上限を設けます。件数のトリガーは、十分な数のビーコンがたまるとバッチを送信します。タイマーは、待機間隔が終わると、それまでにたまったデータを送信します。混雑時には件数のトリガーによって、バッチがすぐに埋まります。閑散時にはタイマーによって小さなバッチも先に進められ、すぐには来ないかもしれない追加のトラフィックを待ち続けずに済みます。

サイズの上限によって、バッチに含めるデータ量を制限することもできます。選択した信号によってビーコンのサイズが変わるため、この制限は重要です。件数が適切でも、個々のビーコンのペイロードが大きければ、バッチのバイト数が多すぎることがあります。件数、時間、サイズの上限は互いに補完し合います。これらの上限でローカルの蓄積を制限しながら、転送効率と待機によって加わる遅延のバランスを取ります。

各ゲートウェイは、自分が受信したトラフィックからバッチを組み立てます。そのため、小さなペイロードが最初にたまる端末の取り込み地点に近い場所でバッチ化できます。ローカルのバッチは、転送効率を高めるために短時間データを保持します。一方、共有 Valkey によるイベント収集は、後段の処理に向けてイベントをより長く保持する役割を担います。また、あるパーティションのイベントの一部しか各ゲートウェイに届かない場合もあるため、別々のゲートウェイが効率よく作ったバッチを、適切な収集先へ届ける必要があります。

関連するイベントを同じ収集先に集める

ゲートウェイ層は、複数のインスタンスに取り込みを分散しますが、関連するビーコンが別々のゲートウェイへ届くことがあります。アプリケーションが定義したパーティションを処理するコンシューマーには、端末が異なっても、そのパーティションに関連するイベントがまとまっている必要があります。イベントがゲートウェイごとのローカルな収集先に分散したままでは、後段のすべてのコンシューマーが、それらを集める処理を担うことになります。

このアーキテクチャでは、ビーコンの属性からグループ化キーを決定的に導き出し、関連イベントをまとめます。すべてのゲートウェイが同じグループ化ルールを適用します。グループ化に使う属性が同じビーコンからは同じキーが得られ、関連する活動に一貫した論理アドレスを与えます。ゲートウェイは、このアドレスを使ってイベントデータを同じ Valkey シャードへルーティングします。共有の収集先に関連イベントを集約することで、後段で消費できるまとまりのあるデータストリームを作ります。

パーティション S42 に割り当てられたビーコンを、2 台の端末が送る場合を考えます。一方のビーコンはある Valkey Router インスタンスに届き、もう一方は別のインスタンスに届きます。どちらにもパーティション識別子が含まれ、両方のゲートウェイがそこからグループ化キー partition:S42 を導き出します。各ゲートウェイは、この論理アドレスを使って、関連するイベントデータを選択した Valkey シャードへ送ります。端末やゲートウェイが異なっても、そのパーティションのイベントは共有の収集先で合流します。

選択されたシャードは、共有 Valkey の収集基盤の一部であり、キーで区別された複数のグループを保持します。グループ化キーによって、ほかのパーティションのデータと並んでいても、そのパーティションのイベントの関連性を保てます。コンシューマーは、個々のゲートウェイから断片を集めることなく、収集済みのパーティションの活動を処理できます。これにより、ビーコンを受け取るゲートウェイと、関連イベントを集める先を切り離し、後段の分析に必要な関係性を保ちながら、取り込み層に端末のトラフィックを分散できます。

各ゲートウェイは、効率よくバッチ転送するためにイベントをローカルでバッファリングします。同じパーティションキーを使うことで、別々のゲートウェイから来た関連イベントを、同じ Valkey の収集先へ集めます。矢印は、印を付けた 3 件の S42 イベントを追っています。ほかのパーティションやシャードの配置は説明用の例です。

コンシューマーが処理できるまでイベントを待機させる

イベントを整理しても、後段のサービスが処理するより速く到着することがあります。トラフィックが急増すると取り込みはすぐに増えますが、コンシューマーはそれまでと同じペースで処理を続けるかもしれません。流入が一定でも、コンシューマーの処理速度が落ちれば同じ不均衡が生まれます。共有バッファーは、この差を保持する場所を提供します。

Valkey は、コンシューマーが処理するまで、収集したイベントデータを保持します。突発的な増加の間は、取り込みが消費を上回るにつれてバッファーが大きくなります。トラフィックが落ち着いたりコンシューマーの処理能力が増えたりすると、コンシューマーが追いつき、滞留分を減らせます。共有バッファーによって、データを保持できる容量の範囲内で、一時的にレートが釣り合わなくても、ゲートウェイはトラフィックの受信を続けられます。

その容量には限りがあります。待機するデータの量は、流入量と、後段で処理するまでの待ち時間の両方で決まります。ビーコンのペイロードが大きくなったり、トラフィックが増えたりすると、バッファーに入るデータ量が増えます。コンシューマーが遅くなれば待ち時間が長くなります。いずれも必要な容量を増やす可能性があり、同じライブイベント中に両方が起こることもあります。

通常運用からのこうした変化を吸収するのが、容量の余裕です。トラフィックの急増、消費が遅い時間帯、オートスケーリングで容量が増えるまでの間に備えて、保持できる空間を確保します。需要の増加にオートスケーリングが対応するには時間がかかります。応答を待つ間にたまるデータは既存の容量で保持する必要があるため、スケーリングは容量の余裕を補完するものであり、その代わりにはなりません。

このバッファーの役割は、ゲートウェイでのバッチ化とは異なります。ゲートウェイは、小さなビーコンを効率よく転送するために短時間待ちます。Valkey は、後段の処理が追いつくまで、収集済みのイベントを共有で保持します。この役割を区別すると、転送を効率化するだけでは、取り込みと消費の継続的な差を吸収できないことが分かります。

収集したイベントを後段のサービスへ渡す

後段との境界では、内部サービスは収集、グループ化、バッファリングを終えたイベントデータを受け取ります。取り込みアーキテクチャによって端末の接続はすでに処理され、関連イベントが共有の収集先に集まっています。コンシューマーは、そのデータをアプリケーションに必要な処理に使えます。

送信先には、イベント配信の Kafka、分析の ClickHouse、オブジェクトストレージの S3 などがあります。後段での役割は異なりますが、どのサービスも、引き渡し時点で利用できる整理済みのイベントデータから処理を始められます。取り込み境界は、データを生む端末のトラフィックに対応しながら、そのデータを準備する役割を担います。

ライブイベントのトラフィックを扱いやすくする

ゲートウェイと共有 Valkey バッファーは、役割を分担して内部処理を保護します。Valkey Router は端末の接続を処理し、取り込みを制御します。バッチ化は、小さなビーコンの間で転送のオーバーヘッドを分担します。決定的なグループ化キーによって、異なるゲートウェイから来た関連イベントが、まとまりのあるデータストリームへ集まります。共有バッファーは、取り込みと消費の一時的な差が解消するまで、イベントを待機させます。

これらの仕組みを組み合わせることで、境界が予測しにくい端末のトラフィックを処理する間も、内部サービスは整理されたイベントデータを処理できます。その効果を得るには、トラフィックに見合う十分な容量と、待ち時間に応じた保持容量が必要です。このアーキテクチャは、その関係を明確にし、効率的な取り込みと、ライブイベント中のリアルタイム処理を支える容量の余裕を結び付けます。

この境界を設計する際は、想定するビーコンのトラフィック、ペイロードのサイズ、グループ化の要件、後段の処理要件を Momento にご相談ください。お客様のワークロードやトポロジーに Valkey Router と共有 Valkey によるイベント収集をどう組み込めるか、一緒に検討します。

共有 Valkey 層を使えば、その結果を、互換性のあるすべてのワーカーからアクセスできる場所に置けます。Momento の RDMA モジュールと AWS EFA モジュールは、推論用 GPU と Valkey RAM 上の KV ブロックを直接結ぶ経路を提供します。NVMe モジュールはローカルディスクの容量を追加し、オブジェクトストレージコネクターは、低コストの長期ストレージへデータを非同期でフラッシュします。これらの機能により、個々のワーカーの寿命やメモリ容量の制約を超えて、再利用できる状態を保持できます。

運用マニュアルについての質問に答えるアシスタントを考えてみましょう。各プロンプトは同じシステム指示とマニュアルから始まり、その後に異なる質問が続きます。目標は、次の質問をどのワーカーで処理しても、この共通プレフィックスを再利用することです。

再利用できる状態を保持する

KV キャッシュには、過去のトークンに対して計算した attention のキーと値が含まれます。prefill は入力を処理して、この状態を作ります。decode はそれを使って応答を生成し、新しいトークンが加わるにつれて状態を拡張します。これらのテンソルを保持することで、生成中に作り直さずに済みます。

プレフィックスキャッシュは、リクエストをまたいで再利用を行います。後のプロンプトが同じトークン列のプレフィックスと互換性のあるモデル状態を持つ場合、エンジンは計算済みのキャッシュブロックを再利用できます。それでも、新しい質問の処理と回答の生成は必要です。話題が同じというだけでは不十分です。指示を変えたり、プロンプト内でマニュアルを後ろへ移したりすると、再利用できるプレフィックスが変わることがあります。

リモートでの再利用は、prefill と decode の分離とも異なります。分離構成では、この 2 つのフェーズを別々のワーカープールで実行するため、状態の引き渡しが必要です。共有キャッシュはその設計を支援できますが、両フェーズを同じワーカーで処理する場合にも役立ちます。マニュアルの例では、両方を処理するワーカーを使います。

推論とストレージの間に Valkey を配置する

推論ワーカーとは別のストレージノードに Valkey を配置します。GPU メモリは、実行中の推論に必要な状態を保持します。Valkey RAM は、ワーカー群で共有する再利用可能なブロックを保持します。Valkey ノードのローカル NVMe とオブジェクトバケットによって、保持できるワーキングセットを拡張します。

ストレージとコンピュートを分離すると、推論用 GPU を買い足さずにキャッシュ容量を追加できます。新規または置き換え後のワーカーからも、以前に計算したプレフィックスへアクセスできるようになります。Valkey は、モジュールによる拡張機構を備えたオープンソースのストレージ基盤です。Momento のモジュールが、このアーキテクチャに必要な転送機能とストレージ機能を追加します。

以下の参照設計では、下位層のブロックを Valkey RAM に一度読み込んでから転送します。配置、上位層への移動、調整の方法は、この参照設計で選択したアーキテクチャ上の方針です。

GPU への直接転送には Valkey RAM を使います。この参照設計では、下位層のブロックも RAM を経由して戻します。オブジェクトへの書き込みは、即時の再利用とは別に非同期で実行します。

ランタイムとの統合部分は、再利用可能なブロックを識別し、その利用可能性を調整して、テンソルを GPU が使えるキャッシュ状態にする処理を手配します。検索と一括データ転送には、それぞれ異なる役割があります。ブロックが見つかっただけでは、GPU がすぐに使える状態になったとは限りません。

ワーカー A がマニュアルを処理し、再利用の条件を満たす計算済みブロックを外部へ出力したとします。ワーカー B が別の質問を受け取ると、まずローカルキャッシュを確認します。ローカルでミスした場合、統合部分が Valkey に互換性のあるプレフィックスブロックを探します。RAM にヒットすると、Momento の RDMA モジュールまたは EFA モジュールが、そのブロックをワーカー B の GPU メモリへ移動します。その後、ランタイムは一致しなかったプロンプトの末尾部分を処理し、生成を続けます。

使えるブロックがなければ、ワーカー B がプレフィックスを計算します。新たに作られたブロックは、後続のリクエストで使えるよう、共有ストレージへ格納できます。検索が遅くても、回復可能なキャッシュミスが長い待ち時間にならないよう、取得には上限を設けます。まず RAM 上での再利用を機能させ、その後に、RAM だけでは保持しきれない有用なプレフィックスを残す方法へ進みます。

NVMe とオブジェクトストレージでワーキングセットを広げる

各層に明確な役割を与えます。Valkey RAM は、頻繁に使う共有プレフィックスを提供します。Momento の NVMe モジュールは、RAM の外でも保持する価値のあるブロック向けに、ストレージノードの容量を増やします。オブジェクトストレージは、数時間後、別のセッション、またはワーカーの置き換え後に再び使うかもしれないコンテキストを、より大きな保持層に残します。

この参照設計では、要求された NVMe 上のブロックを Valkey RAM に読み込み、同じ高速な転送経路で GPU へ送ります。ディスクは Valkey ノードにローカル接続されているため、推論ワーカーはストレージサービスを通じてアクセスします。すべてのマニュアルを各ワーカーのディスクに複製する必要はありません。

Momento のオブジェクトコネクターは、データを非同期でフラッシュします。RAM にあるブロックは、そのオブジェクトコピーを書き込んでいる間も再利用できます。そのため、即時の再利用をアップロードから切り離せますが、すべてのキャッシュ書き込みがすぐに永続化されるわけではありません。フラッシュが完了する前に、利用できる唯一のコピーが失われた場合、プレフィックスの再計算が必要になることがあります。

オブジェクトにヒットした場合、ここで提案する復帰経路では、保持していたブロックを Valkey RAM に読み込み、それから GPU にロードします。再起動後も互換性のあるオブジェクトを識別できるよう、保持する状態には復元可能な検索用メタデータも必要です。オブジェクトストレージは再利用できる期間を延ばしますが、取得時間はリクエストのレイテンシ予算に収まらなければなりません。必要なアクセス時間に対応できるストレージクラスを選びます。

格納対象の選択と保持のポリシーによって、この階層を有効に使えます。一度しか使わないプロンプトを次々に格納するよりも、再利用される可能性が高いブロックを優先します。コピーを使う転送が終わるまで、そのコピーを利用できる状態に保ちます。削除済みまたは互換性のない状態が利用可能なヒットとして見えないよう、検索用メタデータと下位層で有効期限を調整します。アーキテクチャを定める際は、容量と調整のトレードオフを検討してください。

ワーカーは、引き続き GPU キャッシュにロードした状態を使って attention を計算します。リモートの各層は、利用と利用の間に、再利用可能なブロックを保持します。古いプレフィックスを読み込んで GPU に配置するコストが再計算を上回る場合は、取得を適切なところで打ち切って再計算に切り替える方がよい判断です。この比較によって、ネットワークもキャッシュ設計の一部となります。

ワークロードに合わせてネットワークを選ぶ

推論を提供している負荷条件で、検索、下位層からの読み出し、GPU への配置を含めた実効的なブロック転送帯域幅を測定します。ネットワークの公称速度だけでは、ヒットした場合に prefill より速くなるか判断できません。同時に発生する推論トラフィックやキャッシュへの格納も、帯域幅を取り合います。

RDMA は、通常のソケットのデータ経路を通さずに登録済みのメモリ領域間でデータを移動し、オーバーヘッドを減らします。対応するハードウェアとソフトウェアがあれば、GPU への直接転送によって、推論ホストのメモリを経由したペイロードの受け渡しを避けられます。Momento は、この直接経路の Valkey 側を提供します。

AWS では、対応する GPU とストレージのエンドポイントで Momento の EFA モジュールを使います。プロビジョニングする前に、インスタンスの組み合わせと GPU への直接転送の対応状況を確認してください。EFA デバイスのトラフィックは、同じ Availability Zone と VPC の内部にとどまります。オブジェクトバケットは同じ Region に配置し、通常のオブジェクト API でアクセスします。

推論スタックを接続する

Momento Cache は、リアルタイムのワークロード向けに開発された Redis のオープンソースフォークである Valkey の主要な提供サービスです。Momento Cache と Valkey により、Snap、FOX、Coinbase、Capcom などの世界的な企業を支える、高性能なインフラを利用できます。

Momento は、SGLang、vLLM、LMCache との直接統合を提供します。推論スタックに合う経路を選んでください。マニュアルの例では、すでにワーカーを vLLM で動かしていれば、vLLM との直接統合から始めます。LMCache ですでにオフロードを管理していれば、Momento の LMCache 統合を使います。SGLang のデプロイ環境では、SGLang との直接統合が対応する入口となります。

両方のワーカーで、同じモデルのリビジョンとアダプター、一致するトークン化済みプレフィックス、互換性のあるテンソル表現と並列処理の配置が必要です。新しいモデルやキャッシュ形式には、専用の名前空間を用意します。共有範囲を、認可されたテナントや信頼グループに限定し、プレフィックスの一致とは別にストレージへのアクセスを保護してください。コンテンツハッシュだけでは、認可の境界にはなりません。これらの要件は、統合部分とデプロイ設定で扱い、アプリケーションコードはリクエストの処理に集中できるようにします。

共有キャッシュの効果を測定する

最初の検証構成には、互換性のある推論ワーカー 2 台、RAM と NVMe を備えた独立した Valkey ノード 1 台、オブジェクトバケットが必要です。選択したトポロジーに合う Momento のモジュールとランタイム統合を用意します。ディスクやオブジェクトからの取得を導入する前に、共有 RAM での再利用が機能することを確かめます。

長いマニュアルのプレフィックスをワーカー A に送り、次に同じプレフィックスと別の質問をワーカー B に送ります。比較対象のベースラインでも、ローカルのプレフィックスキャッシュは有効にしておきます。B にローカルコピーがなく、共有ストレージから互換性のあるブロックを取得することを確認します。同じ推論提供条件で、プレフィックスを再計算する場合と最初のトークンが返るまでの時間を比較します。

次に、ワーキングセットを RAM 層の容量より大きくして、NVMe の経路を試します。オブジェクトからの取得は、フラッシュが完了し、対応する制御方法で高速な層のコピーを取り除いたブロックで検証します。推論ワーカーを再起動し、ワーカーが入れ替わっても再利用できることを確認します。リモート層を利用できない場合も試し、取得を上限内で打ち切ってから再計算に切り替わることを確認します。

同時実行数が増えたときのテールレイテンシと転送時間を測定します。層ごとのヒット数と取得バイト数、GPU メモリの逼迫度、オブジェクトへのフラッシュ待ちを追跡します。結果を評価する際は、キャッシュのメモリ、ディスク、オブジェクトへのリクエスト、ネットワークのコストを含めます。取得コストを伴わないヒット率だけを見ると、高価なキャッシュを成功と誤認しかねません。

Valkey と Momento で KV キャッシュを高速化する

繰り返し使うプレフィックスを単一ワーカーのキャッシュより長く保持する必要があり、その状態の読み込みが再計算より速い場合、Valkey は実用的な選択肢です。Momento のモジュールは、共有 RAM 層を推論用 GPU に接続し、ディスクやオブジェクトストレージへも拡張します。導入に向けたアドバイスや検証の支援が必要な場合は、Momento にお問い合わせください。ソリューションエンジニアが、お客様の構成を一緒に検討します。

各ビルドでの進歩を評価するため、再現可能なベンチマークを用意しました。同じベンチマーク、同じツール（sorted-set-benchmark、パイプライン化した ZADD NX、メンバーは m:{i}、スコアは整数）、同じ Graviton4 マシン（r8g.4xlarge）、同じ測定手順です。各バージョンで、実行の間にデータをフラッシュしながら 10 回繰り返し、公式 Docker イメージを --save '' --appendonly no で起動しました。サーバーは一度に一つだけ動かし、同じホスト上の単一のベンチマーククライアントから測定しました。対象は Redis の 6 バージョンと Valkey の 5 バージョンです。

測定結果

メモリの値は、サーバーの used_memory です。ツールの表示どおり、10 進の GB を使っています。どのバージョンでも、10 回の測定値はツールの表示精度である約 10 MB の粒度では同じ値になりました。mem_fragmentation_ratio は一貫して 1.01x で、RSS もこれらの値に近い値を示します。10 回の実行間でスループットのばらつきは小さく、注目する二つの構成の範囲は重なりませんでした（Valkey 9.1：643～652k/s、Redis 8.10：628～639k/s）。

三つの点が目立ちます。第一に、この最適化以前の両エンジンの全バージョンは、このワークロードで同じ 4.83 GB に並びます。ZSET 実装が共通のコードベースに由来することを考えると、予想どおりです。第二に、Redis にも同程度の削減が入りました。メモリ使用量は 4.83 GB から 3.73 GB へ 23% 減り、その境目は正確に 8.6 です（8.4.7 は旧レイアウト、8.6.7 は新レイアウト）。挿入数の中央値も 536k/s から 613k/s に増えています。第三に、今回測定した中で最も省メモリかつ高速な構成は、引き続き Valkey 9.1.2 でした。Redis 8.10.2 よりメモリ使用量が約 10% 少なく、スループットでも小さいながら一貫した優位性があります。

同じアイデアが伝わっていく

特に興味深かったのは、Redis の最新の値が Valkey 8.1 の値から約 1% の範囲に収まったことです。3.73 GB と 3.77 GB で、どちらもメンバーあたり約 75 バイトです。2026 年後半の Redis は、バイト単位で見ると、ほぼ 2025 年 4 月の Valkey に相当します。これは偶然ではありません。公開されているプルリクエストとリリースノートから、その理由を正確にたどれます。

Valkey PR #1427（2025 年 1 月にマージ、同年 4 月の Valkey 8.1 でリリース）では、ソート済みセットの構造を変更し、ハッシュ検索構造がマッピングのコピーを独自に保持する代わりに、スキップリストのノードを直接参照するようにしました。このベンチマークでは、4.83 GB から 3.77 GB への削減に相当します。続く Valkey PR #2508（2025 年 11 月にマージ、9.1 でリリース）では、メンバー文字列をスキップリストのノード自体に埋め込み、要素ごとのポインターと個別のメモリ割り当てを一つずつ取り除きました。これが 3.77 GB から 3.34 GB への削減です。

Redis PR #14701（Valkey の PR から 1 年と 10 日後、2026 年 1 月にマージ）は、この取り組みを Redis に移植しました。PR の説明には、出典がそのまま明記されています。「This is based on: valkey-io/valkey/pull/1427.」（この変更は valkey-io/valkey/pull/1427 に基づきます。）明確に出典を示したエンジニアの姿勢は評価すべきです。誰もがそうするわけではありません。この移植では、Valkey の新しいハッシュテーブルを採用せずに Redis の dict を no_value モードで使い続け、ノードへの埋め込みを組み合わせ、Redis 8.6 でリリースしました。私の測定もリリースノートと一致しており、削減の境目は正確に 8.6 でした。

では、なぜ Redis は依然として 10% 遅れているのでしょうか。後から取り入れる以上、常に後を追うことになるからです。Redis は設計を取り込みましたが、その設計の土台だったハッシュテーブルは採用しませんでした。そして、移植版がリリースされる頃には、Valkey はすでに次の段階へ進んでいました。差の全体像は、採用しなかった設計上の要素と、まだ追いついていないリリースの組み合わせです。作業を担当したエンジニアへの皮肉を込めているわけではありません。Valkey が BSD ライセンスを採用しているのは、まさに Redis を含め誰もがそれを基に開発できるようにするためであり、Redis のユーザーにも確かな恩恵があります。アイデアが逆方向に流れたなら、それも報告します。ただし、私がベンチマークするのは実際にリリースされたものです。その結果は、このデータ構造において、一方のプロジェクトが先行し、もう一方が約 1 年遅れで追いついていることを示しています。

運用者への示唆

注意点はいつもと同じです。これは、スキップリストでエンコードされた一つの大きな ZSET、短いメンバー、整数のスコア、アロケーター単位のメモリ集計、単一のパイプライン化クライアントという条件での測定です。データの形が変われば結果も変わるため、自分たちのワークロードで ツールを実行してください。

Valkey を運用しているなら、結論は明快です。9.1 は、この表の全構成の中でメモリ使用量が最も少なく、挿入速度が最も高い結果でした。アップグレードするだけで、この最適化を利用できます。両プロジェクトがリリースを重ねるたびに、今後もこのベンチマークを続けます。

Redis を運用していて、Valkey の方が効率的なのではないかと気になる場合、選択肢は二つあります。Redis がいずれ Valkey の最新 PR を取り込むのを待つか、Valkey に切り替えるかです。皆さんはどうしますか。

Momento Cache：クラウドで最速の Valkey

Momento のマネージドサービスなら、インフラを自分で管理せずに、常に最新の Valkey を利用できます。Momento は、世界最大級のキャッシュを支えるのと同じ技術で、アップグレード、フェイルオーバー、最適化などを円滑に処理します。Snap、Coinbase、Paramount、Capcom などの企業に続いて、今すぐ Momento Cache をお試しください！

最初の質問：展示会場で見えた、IBC Daily が伝えなかったことは？

「今年の公式な話題は、レイテンシの 3 分の 1 への短縮、あらゆる場所への AI 導入、収益化を待つアーカイブの三つでした。過剰に取り上げられたものは何でしょうか。その代わりに、何を議論すべきだったのでしょうか？」

過剰に取り上げられた話題その 1：「あらゆる場所に AI」

会場を歩いて数えてみると、私が目にした AI の約 90% は、字幕生成、リフレーミング、メタデータ生成、合成の司会者や俳優でした。見事なデモであり、実際に役立つ技術です。しかし、業界を根本から変えるものではありません。

実際のライブイベントで通用するものは、ごくわずかです。大きな金額が動く重要な判断を今も人間が担うワールドカップの試合に持ち込めば、その多くは静かに出番を失います。

過剰に取り上げられた話題その 2：「レイテンシを 3 分の 1 に」

確かに、撮影から視聴までの glass-to-glass の数値は本物です。ただし、それは展示会のデモ環境での話です。

本番環境では、別の問題がその改善効果を打ち消します。広告挿入、コンテンツ保護、ラストマイル、そして、画面にゴールが映るより先にスマートフォンへゴール通知が届く、あの同期の問題です。2026 年には、エンドツーエンドで 1 秒未満の配信を実現できます。しかし、プレミアムなライブ配信の規模で、その費用を負担している事業者はまだいません。ストリーミングが放送のレイテンシ（glass-to-glass で約 5～6 秒）を下回れることは、すでに実証されています。大半のライブコンテンツには、それで十分なのでしょうか。

見落とされたもの：配信を支える基盤

大規模なライブイベントが持ちこたえるか、破綻するかを決めるのは基盤です。この点を十分な声量で語る人はいませんでした。同時接続数の急増、試合開始時のトークン要求の殺到、認証、フェイルオーバー、キャッシュヒット率、オリジンの負荷軽減。リアルタイムの可観測性も欠かせません。ここでいうリアルタイムとは、本当のリアルタイムです。視聴者がすでに SNS で配信停止を訴えているのに、3 分や 5 分前の状況を表示するダッシュボードではありません。

2026 年にこの業界が交わすべきだった議論は、FIFA ワールドカップから心に残った一文に集約されます。104 試合。50 億人の視聴者。失敗の余地はゼロ。

二つ目の質問：2027 年 9 月の同じ会場で、何が時代遅れに聞こえ、何が主役になる？

最も早く色あせる言葉：「AI 搭載」

売り文句としての寿命は、すでに尽きかけています。2027 年には、かつてのクラウドと同じように、AI の利用は前提になるでしょう。もはや誰も「クラウド」自体を売りにはしません。それを使って何を実現するかを売ります。「AI 搭載」も、同じように役目を終えようとしています。

会場の主役になる話題：実は二つあり、互いにつながっている

メディア業界では大規模な統合が進んでいる

プラットフォームは巨大複合企業へと集約されつつあります。2026 年を通して大きなニュースになった Fubo + Disney、WBD + Paramount などの大型合併だけではありません。従来の放送局が配信契約を結び、そのコンテンツが広く普及した同じ大手プラットフォームへ流れ込む動きもあります。IBC では、TF1 の Netflix での配信や、France Télévisions と Prime Video の連携が、フランスのストリーミング市場を持続的にどう変えているかを議論しました。ベンダーにとってもコンテンツ所有者にとっても、結論は明快です。実質的に差別化できる機会は急速に減っています。買い手は減り、一件ごとの賭けは大きくなり、どの案件でも失敗の余地が狭まっています。

そして、トークン消費をどう制御するか？

2027 年には、内製か外部調達かの判断がさらに難しくなります。誰もが AI で製品を作り、縮小する市場で差別化を図るようになるためです。しかし、AI 主導の開発は後戻りしにくい選択です。技術的負債が生まれ、AI が書いたコードベースを保守するだけでも、必要なトークンが増え続けます。人員削減を免れた最後のシニアエンジニアたちに、生成された 100,000 行のコードを渡し、一晩でデバッグするよう頼むことはできません。

この二つを合わせると、2027 年の本当の問いが見えてきます。獲得できる顧客が減り、トークンの請求額が増える中で、何を自分たちで作り、何を他社に任せて大規模に運用してもらうのでしょうか。

来年アムステルダムの IBC で、私はこの議論をしたいと考えています。基盤は、技術スタックの中で最も華やかな部分ではありません。しかし、試合終了の笛が鳴るときまで立っていられるかどうかを決める部分です。

次の大規模ライブイベントに向けて準備していますか？ Momento が大規模なリアルタイムメディアを支える基盤をどう運用しているかをご覧ください。

地域や商品カテゴリーごとに異なる多数の規定を扱う、小売企業の顧客向けサポートアシスタントを考えてみましょう。このアシスタントは、問い合わせのたびに規定を検索し、出典を添えた説明を生成します。その中には、言い回しが少し違うだけで、繰り返し寄せられる質問もあります。

ある顧客が「ヘッドホンはいつまで返品できますか？」と質問します。アシスタントは公式の返品ポリシーを引用し、返品期限が30日間であると説明します。続いて、別の顧客が「ヘッドホンの返品期限は何日ですか？」と尋ねます。同じ説明で両方の質問に答えられるにもかかわらず、アシスタントは再び検索と生成を行い、似た回答を返してしまいます。

セマンティック応答キャッシュは、こうした処理の重複を防ぎます。Valkey に過去の回答と質問に関するメタデータを保存し、Valkey Search モジュールでそのメタデータを使って、似た質問への回答を探します。アプリケーションは回答の候補を取得し、その中から適切なものを返せるようになります。

その結果、推論の呼び出し回数が減り、待ち時間も短くなります。回答を再利用するたびに生成コストを抑えられ、モデルが新たに回答を生成するのを待つ必要もありません。繰り返し寄せられる質問が多いほど、費用と平均応答時間の両方を削減できます。

この用途に Momento Cache の Valkey が適している理由

Momento Cache は、リアルタイムのワークロード向けに開発された Redis のオープンソースフォークである Valkey の主要なプロバイダーです。Momento Cache と Valkey を使えば、Snap、FOX、Coinbase、Capcom などのグローバル企業を支えるものと同じ高性能な基盤を利用できます。

セマンティックキャッシュの各レコードには、元の質問、回答の全文と出典、そして埋め込みを保存します。埋め込みとは、類似検索のために質問を数値ベクトルで表現したものです。地域、言語、商品カテゴリー、条件、ポリシーのバージョンなどの追加フィールドで、その回答を再利用できる範囲を定義します。

Valkey がこれらのレコードを保持し、Search モジュール がベクトルとメタデータのインデックスを作成します。ベクトル検索と構造化フィールドのフィルターを組み合わせることで、セマンティックキャッシュは次の3つを実現できます。

• 回答と検索用データをまとめて保存する。 回答、出典、質問のベクトル、適用範囲を示すフィールドを1つのキーに保存します。一致するレコードには、アプリケーションが回答の適否を判断して返すために必要な情報がすべて含まれています。
• 文脈に合った回答を検索する。 ベクトルの類似度と、地域などの追加フィールドに対するフィルターを組み合わせます。言い換えられた質問への回答を見つけながら、異なるポリシーの適用範囲に属するレコードは除外できます。
• キャッシュした回答をワーカー間で共有する。 あるアプリケーションワーカーが Valkey に保存した回答は、ほかのワーカーからも利用できます。どのインスタンスが処理を担当しても、後続のリクエストで回答を再利用できます。

Valkey は、回答の共有ストアと、フィルターを適用したベクトル検索を提供します。検索に使う埋め込みを定義し、候補の回答を採用するか最終的に判断するのは、アプリケーションです。

セマンティックキャッシュの仕組み

意味が近く、再利用に適した回答が見つかれば、情報の取得と回答の生成を省略できます。

先ほどの2人目の顧客によるヘッドホンの返品に関する質問を例に、実際の処理を見てみましょう。

1. キャッシュを利用できる質問か、どの範囲に該当するかを確認する。 アプリケーションは、ヘッドホンの返品ポリシーに関する一般的な質問であると判断します。アプリケーションのコンテキストから、地域は米国、言語は英語であることと、現在有効なポリシーのバージョンを取得します。

2. 回答の候補を探す。 埋め込みサービスが質問をベクトルに変換します。アプリケーションは FT.SEARCH コマンドで、このベクトルとメタデータのフィルターを Valkey に渡します。検索結果として、回答、ポリシーの出典、メタデータ、ベクトル間の距離を含む回答候補が返されます。

3. 回答が質問に適しているかを確認する。 アプリケーションはベクトル間の距離を確認し、回答に影響する条件が一致しているかを確かめます。これにより、「開封済み」と「未開封」のような小さな表現の違いも見逃さずに判断できます。必要な条件が一致していれば、キャッシュされた説明を返します。

4. キャッシュミス時には回答を生成する。 適切な候補がなければ、アプリケーションは最新のポリシーを取得し、新しい回答を生成します。

5. 再利用できる回答を保存する。 回答を返した後、キャッシュに適した内容であれば、その新しい回答を Valkey に保存します。たとえば、特定の顧客に固有の情報を含む回答は、この共有キャッシュには保存しません。

Valkey に回答を追加するたびに、後続の質問で情報の取得と回答の生成を省略できる機会が増えます。次の顧客が同じ返品ポリシーについて別の言い回しで尋ねたときには、モデルを再度呼び出さずに、より早く説明を返せます。

コストを抑え、回答を速くする

セマンティックキャッシュは、再利用できる回答を返す際に情報の取得と回答の生成を省略し、時間と費用を節約します。ヒット率が25%なら、対象となる質問の4件に1件で処理を短縮できます。

コストの削減。 回答の生成に $1,000 を使う場合、ヒット率が25%なら $250 を削減できる可能性があります。もちろん、キャッシュ基盤にも費用はかかりますが、通常は同じ回答を繰り返し生成する費用よりもはるかに少なく済みます。

応答の高速化。 情報の取得と推論は、呼び出しにかかる時間が特に長い処理で、数秒を要することも珍しくありません。一方、Momento Cache は Valkey のキャッシュにヒットした回答をミリ秒単位で返します。

実際のヒット率は、アプリケーションに寄せられる質問の傾向によって変わります。同じ回答を再利用できる質問が増えるほど、有料のモデル呼び出しを減らし、ユーザーの待ち時間を短縮する機会も増えます。

繰り返される質問に、もっと速く答える

ユーザーが同じ内容を異なる言い回しで尋ねるとき、セマンティックキャッシュを使えば、1つの回答を多くのリクエストに再利用できます。Momento Cache 上の Valkey Search は、回答の共有ストアとフィルター付きのベクトル検索を組み合わせ、アプリケーションが適切な回答を再利用し、生成コストとユーザーの待ち時間を削減できるようにします。

アプリケーションにセマンティックキャッシュを導入してみませんか。Momento Cache を使い始めることで、繰り返し寄せられる質問への回答を再利用できます。

冗談めかして言っていますが、事実でもあります。推論は、速さで知られているわけではありません。強力ではあります。しかし、速いとは言えません。

高速化のために、私たちはさまざまな実験をしてきました。並列取得、ゼロコピー読み取り、メタデータ参照のバッチ化など、取得経路全体が対象です。その中に、大きな利点と引き換えに、大きなトレードオフもありそうな、特に興味深い実験がありました。KV キャッシュをローカルではなくリモートに保存したらどうなるでしょうか。ただし、一つ問題があります。KV キャッシュは巨大です。それをネットワーク越しに運ぶのは、最初から無理な話ではないでしょうか。

一般的な順序はわかっています。GPU メモリが最速で、次にホストの DRAM、同じマシンに搭載された NVMe、そして、どうしても必要ならネットワークの向こう側です。共有が必要なときにリモートを使い、その代償としてレイテンシを支払います。

ただし、これは私だけの新しい発想ではありません。業界全体が今、取り組んでいます。NVIDIA は Dynamo にオフロード階層を用意しています。Mooncake はストアを構築しています。Xinnor は 6 月、クライアント側キャッシュを備えた Lustre ならローカル NVMe に対抗できると論じる記事を公開しました。Khawaja Shams は、プリフィルとデコードを分離すれば、望むかどうかにかかわらず、キャッシュをマシン間で移動させる必要があると述べています。

利点があることは明らかです。しかし、そのトレードオフのコストについては、あまり情報が見当たりませんでした。Valkey のようなシステムに KV キャッシュを保存すると、実際にどれほどレイテンシが増えるのでしょうか。そのコストを払っても、プリフィルを省略する価値はあるのでしょうか。

そこで、自分で測定することにしました。

検証環境

ベンチマークでは 3 台のマシンを使います。vLLM を実行する同一構成の GPU ノード 2 台と、その両方から 10 Gbps のネットワークで 1 ホップ先にある Valkey マシンです。

gpu-a がプリフィルの計算をすべて行います。DRAM 階層と NVMe 階層はその内部にあり、Valkey はネットワークの向こう側です。gpu-b は、プリフィルを行っていないマシンに、キャッシュ済みのリクエストが届くとどうなるかを調べるために使います。

ワークロードは、現実に即して生成した法律・医療文書 30 件で、すべて正確に 10,000 トークンにそろえました。各文書を vLLM に 2 回送ります。1 回目はプリフィルを実行して KV キャッシュを保存します。2 回目は同じプロンプトを送り、最初のトークンが返るまでの時間（TTFT）を測定します。実行ごとに変えるのは、KV キャッシュの保存場所だけです。

すべての環境で vLLM 0.28.0、LMCache 0.5.4、valkey-glide-sync 2.5.1、Valkey 9.1.1 を使い、NVIDIA L4 上で Qwen2.5-7B-Instruct-AWQ を提供します。

正確な結果を得るため、vLLM のプレフィックスキャッシュを無効にしました。これにより、繰り返しリクエストがすべて GPU 上で処理されるのを防ぎます。また、毎回の実行前にディスク階層を消去し、ページキャッシュも破棄する必要がありました。Linux は最近ディスクに書き込んだデータをメモリに保持するためです。そうしなければ、「NVMe」の読み取りが RAM から行われ、実際のディスク速度を検証したことになりません。

目標は、3.1～3.3 秒のコールド TTFT を下回ることでした。別のインスタンスで、1 日間隔を空けてベンチマーク全体を 2 回実行したところ、結果は 2% 以内で再現できました。そのため、この結果には手応えを感じています。ネットワークがどうだったかを見ていきましょう。

すべてを 1 台で処理する

最初のテストでは、gpu-a がすべての作業を担います。KV を計算し、検証対象の階層に保存して、2 回目に読み戻します。Valkey のテストでも、自分のキャッシュを書いて読むのは gpu-a です。ローカルバスの代わりにネットワークを通る点だけが異なります。

見間違いではありません。ネットワークが最速でした。しかも、大きな差をつけています。同じマシンのローカル NVMe に対して 2.7 倍高速でした。ディスクは筐体内にあり、間にスイッチもないのに、ネットワーク越しの方がキャッシュへ速くアクセスできたのです。

（DRAM の行はいったん置いておきます。興味深いことが起きたので、後で説明します。）

最初は、何かを間違えたのだと思いました。「ディスク」階層をインスタンスストアではなく EBS のルートボリュームに置いてしまったのでしょうか。しかし、lsblk では階層が nvme0n1（250 GB のインスタンスストア）上にあることを確認でき、df では実行中に 16 GiB が書き込まれていました。300,000 トークン分の KV として、おおむね妥当な量です。

計算してみると、理由が見えてきました。

各文書の KV キャッシュは、256 トークンのチャンク 39 個で構成されます。1 トークンあたり 57,344 バイトなので、約 572 MB（39 x 256 x 57,344）です。検証用ハーネスの動作を確認する際に、すべてがメモリに収まる文書 2 件で DRAM 階層を試したところ、ヒットは約 82 ms で返りました。DRAM ヒットではほとんど転送が発生しないため、82 ms は基本的にオーバーヘッドと考えられます。それを超える時間は、転送時間と見なせます。

つまり、Valkey の 557 ms のうち、転送は実質約 473 ms です。572 MB を 473 ms で運ぶと 1.2 GB/s になり、10 Gbps の NIC を使い切っていることになります。一方、ディスクは 572 MB の転送に約 1,438 ms かかりました。400 MB/s です。NVMe なら 2 GB/s を超える読み取りができるはずなので、不思議な値です。

したがって、リモート階層はネットワークがボトルネックで、ローカル階層は自分自身のソフトウェアがボトルネックです。LMCache の Valkey コネクターには、今年かなりの改善が加えられたことがわかります。8 個のワーカーが並列に、呼び出し元が所有するバッファーへ直接データを取得します。ローカルディスクの経路には、まだ同じだけの改善が行われていません。NVMe で 400 MB/s という値は、大きな改善余地を示しています。この状態が長く続くとは思いません。

ともあれ、この結果では、KV キャッシュをネットワーク上に置いても、予想したレイテンシの不利はありませんでした。物理的な限界に近い速度で動作していました。仮に来月、ディスクの経路が改善されて 1.5 GB/s に達しても、ネットワークは十分に有力な選択肢です。さらに、Valkey はより高速な NIC を使えば、もっと速くなる余地があります。

ただし、一つ説明できないことがあります。ディスクの 2.18 倍という高速化は中央値ですが、文書別の値には奇妙な傾向がありました。キャッシュ利用時に最初に要求した文書は、約 11 倍速く返ります。2 件目は約 3.5 倍。その後の 28 件は、どれもほぼ 2.1 倍です。不思議なことに、2 回の実行でほぼ同じ結果になりました。

最初の 1～2 リクエストでは何かがウォームな状態で、その後はそうではなくなるようです。原因はわかりませんし、もっともらしい理由を作るつもりもありません。何が起きているにせよ、これは引用している中央値よりディスクをよく見せる現象なので、結論を左右するものではありません。

DRAM について

先ほどの結果表では、DRAM の「高速化倍率」は 0.95x でした。設定を間違えたのでは、と思うかもしれません。しかし、間違いではありません。文書 2 件で確認した際に、ヒットが 82 ms で返ったことを覚えているでしょうか。同じ階層、同じ設定での結果です。TTFT はコールド時が 3122.8 ms、キャッシュ利用時が 82.5 ms で、37.93 倍の高速化でした。

DRAM は遅くありません。スタック全体で、圧倒的に最速です。ただ、容量が足りなくなるのです。

文書 30 件は 300,000 トークン分の KV です。1 トークンあたり 57,344 バイトなので、16 GiB になります。この階層に割り当てたのは 8 GB で、ホスト全体にも 16 GB しかありません。単純にメモリが足りず、2 回目を実行する前にすべて追い出されていました。

それだけではありません。キャッシュから何も提供できなかったすべての階層では、30 件中少なくとも 29 件で、コールド時よりも 3～5% 遅くなりました。ミスする参照にも参照処理は必要であり、追い出しが起きるストアでも書き込みのコストはかかります。このケースでは、小さすぎるキャッシュが負担になっていました。

しかも、文書 30 件など、本番環境のコーパスと比べればごくわずかです。ワーキングセットが文書 2 件なら、DRAM を使えば十分です。30 件以上なら、DRAM より容量の大きいものを選んでください。

2 台に拡張する

ここまでの検証は、1 台のマシンが自分のキャッシュを書いて読み戻すものでした。しかし、本番環境ではリクエストが別のマシンへ送られます。そのときどうなるかが、大きな問いです。そこで、コールド時の処理を gpu-a で、キャッシュ利用時の処理を、プリフィルを行っていない gpu-b で実行しました。

予想どおり、gpu-b には KV がなく、アクセスできるデータもないため、NVMe の再利用はゼロになり、プリフィルに 3.2 秒かかりました。分散環境で使い始めると、NVMe の魅力はかなり薄れます。

一方、Valkey は 5.98 倍から 5.97 倍になっただけでした。KV を計算していないマシンから読み取っても、測定可能な追加コストはありません。最も悪い文書では 5.55 倍から 3.92 倍に下がりましたが、中央値は実質同じです。このキャッシュは、どちらか一方のノードに属しているわけではありません。それこそが目的でした。

検証から得られたこと

ワーキングセットがホストの DRAM に収まるなら、それを使ってください。キャッシュヒットは、プリフィルを再計算するより 37 倍速く返りました。ただし、容量を正確に見積もる必要があります。コーパスをトークン数で測り、モデルのトークンあたりの KV サイズを掛けてください。目分量で判断してはいけません。

収まらなくなると、ローカルディスクは書き込んだマシン上で 2.18 倍の効果を出しますが、他のマシンでは効果がありません。単一ノードでは大きな改善です。しかし、フリート全体では、各エントリが生成元のマシンに閉じ込められ、ヒット率は同じマシンに再度ルーティングされる確率に依存します。

ネットワーク階層への書き込みにもコストはあります。Valkey を使うコールド TTFT は DRAM より約 110～150 ms 遅く、メモリではなくネットワーク越しに保存するコストは 3～4% でした。つまり、キャッシュを埋めるたびに 110～150 ms を払い、その後のヒットごとに約 2.7 秒を取り戻すというトレードオフです。

最も意外だったのは、この環境では共有階層の方がすでに速かったことです。このハードウェア、このモデル、このコーパスサイズでは、キャッシュを別のマシンに置く方が速くなりました。検証前は、レイテンシのコストを払っても共有には価値がある、と論じることになると思っていました。この予想が外れたのは、うれしい結果です。プリフィルの省略には、かかるコスト以上の価値があります。

KV キャッシュはネットワーク上に置くべきです。共有が必要だからという理由だけではありません。今回、そこで最も速く動いたからです。

自分で試す

検証用ハーネス、30 件の文書コーパス、各階層の設定、インフラ用スクリプトは、すべて valkey-kvcache-bench にあります。一つのコマンドで 3 台すべてをプロビジョニングし、全構成を実行し、結果を取得して、すべてを終了します。

cd infra
.\Run-TierBench.ps1 -AwsProfile <profile> -Teardown

コストは 1 時間あたり約 $2.14 で、ベンチマーク全体は 1 時間未満で終わります。

自分で試す場合に、一つ注意点があります。最初に 2 台構成のテストを実行したときは、Valkey を含め、どの階層でも 0/30 になりました。LMCache のデフォルトのキャッシュキーハッシュは Python の hash() であり、プロセスごとに異なるランダムなソルトが使われていたためです。つまり、gpu-a と gpu-b は同じトークンから異なるキーを生成し、ノード間の再利用ができませんでした。LMCache は起動時に Using builtin hash without PYTHONHASHSEED set という警告まで出していたのですが、私は見落としていました。次の設定値で修正できます。

pre_caching_hash_algorithm: sha256_cbor_64bit

共有 KV キャッシュのノード間ヒット率がゼロになったら、おそらくこれが原因です。

ぜひ試してみてください。異なる結果が得られた場合は、比較できるよう、お気軽にご連絡ください。

それでは、よい開発を！

Momento Cache は、インフラの世話に時間を取られず、Valkey の最適な性能を活用したい、スピードを重視するチーム向けに設計されています。Cluster キャパシティと Flex キャパシティにより、このセルフサービス型のインフラプラットフォームで、シングルテナントのフルマネージドリソースを利用できるようになります。

Cluster では、インスタンスタイプ、シャード、レプリカ、アベイラビリティゾーンを直接制御できます。Flex は、指定した範囲内でリソースを自動的に最適化します。どちらも、Momento Cache の Serverless 構成よりも強い分離、細かな制御、高い性能の上限を必要とするワークロードのために設計しました。

運用負担がじわじわ増える罠を避ける

AI 時代には、基本的なインフラをほぼゼロコストで立ち上げることは簡単です。誰もが経験しているでしょう。速く、簡単で、たいていは動きます。まず製品を届けたいときには、正しい選択です。

しかし、成長が始まると状況は変わります。トラフィックの傾向が変化し、メモリの使用量に偏りが生じ、シャードの移動が必要になります。プライマリが停止し、クライアントが一斉に押し寄せ、真夜中にゼロデイ脆弱性のパッチが届きます。気づけば、開発に使うはずだった時間とトークン予算が、増え続ける運用負担に消えています。

機能、製品、サービスを追加するほど、問題は増えていきます。やがて、レイテンシ、コスト、複雑さが右肩上がりに増す中で、チーム全体がインフラとの格闘から抜け出せなくなります。

高速、信頼性、効率。その三つをすべて手にする

Momento のプラットフォームは、Capcom、Coinbase、Paramount、Snap などの企業で、世界中の何百万人ものユーザーが使う重要な機能を支えています。Momento Cache は、本番環境で積み重ねた知見を使いやすいサービスにまとめ、Valkey の性能と柔軟性を余すところなく提供します。

新しい Cluster 構成と Flex 構成では、個々の要件に合わせて Valkey のデプロイを調整できます。Momento は、そのシステムを支えるライフサイクル全体を円滑に運用します。プロビジョニング、正常性の管理、フェイルオーバー、段階的なトポロジー変更、バージョンアップグレード、セキュリティパッチまで対応します。

毎秒 1,000 件でも 100 万件でも、Momento は比類のない性能とリソース利用効率を提供します。成長に合わせて、インフラも拡張します。成熟したプラットフォーム組織を持つ企業では、社内開発者プラットフォームの一部として、Momento Cache を BYOC 構成でデプロイすることもできます。

わかりやすい料金

Momento Cache の料金は、シンプルで予測しやすく、費用対効果が高くなるよう設計しています。us-east-1 の料金は次のとおりです。

• Flex は、Valkey の物理ストレージ 1 GB 月あたり $13 から
• Cluster は、デプロイした各インスタンスの定価に 25% を加算
• データ転送量は、毎月の受信と送信の合計 200 GB まで含まれ、超過分は $0.05/GB

Momento Cache は、指定した容量範囲内での高速な自動スケーリングに対応し、未使用リソースのコストを簡単に削減できます。

大規模な運用を見据えた設計

Momento Cache は、大規模な環境で信頼性と効率を大きく向上させる 2 層構造を採用しています。各 Valkey クラスターの前段にゲートウェイを配置し、ホットキーや接続の集中といった難しいトラフィックの問題を、データ層に届く前に処理します。

ゲートウェイは RESP エンドポイントを公開するため、Momento Cache は標準的な Valkey クライアントと Redis クライアントのすべてに対応します。基盤となるクラスターを隠蔽し、トポロジーが変わっても、一つの安定したエンドポイントを提供します。

block
  app("Redis or Valkey\nclient"):3
  space
  gateway("gateway"):3
  space
  pool("Valkey cluster"):3

  app --> gateway
  gateway --> pool

ゲートウェイは、同時接続数とスループットが高い環境でも、TLS、認証、レート制限などのトラフィック管理をすばやく処理できるよう最適化されています。Valkey クラスターへの確立済み接続のプール上に、クライアントのトラフィックを多重化します。これにより接続レイテンシを減らし、リクエストの集約などの高度な機能を実現します。

こうして、責任を明確に分離した効率的なシステムが生まれます。ゲートウェイがトラフィックの課題を引き受け、Valkey ノードはデータ処理にリソースを集中します。

Momento Cache を使い始める

Momento CLI を使えば、いくつかの短い手順で Momento Cache を試せます。プレビュー期間中は、Web コンソールから利用申請も必要です。

まず、Momento コンソールで API キーを作成し、利用するリージョンのエンドポイントをコピーして、CLI のデフォルトプロファイルを設定します。

# paste the api key and endpoint when prompted
momento configure

次に、Capacity Pool を作成します。利用するリージョンで有効なゾーン ID を指定してください。

momento preview pool create \
  --name example-pool \
  --capacity-gib 32..128 \
  --replicas-per-shard 1..2 \
  --zones use1-az1,use1-az2

momento preview pool describe --name example-pool

Capacity Pool のステータスが active になったら、Database を作成できます。

momento preview database create \
  --name example-db \
  --pool-name example-pool

コンソールに戻り、プールの Databases タブを開いて、リージョンの RESP エンドポイントをコピーします。任意の Valkey クライアントまたは Redis クライアントをスタンドアロンモードにし、TLS を使ってポート 6379 でこのエンドポイントに接続してください。ユーザー名は Database 名、パスワードは Momento の API キーまたはトークンです。ここでは公式の valkey cli を使います。

valkey-cli -h <resp-endpoint> -p 6379 --tls \
  --user example-db --pass <momento-api-key>

> SET example-key "ready"
OK
> GET example-key
"ready"

これで、高性能な Valkey クラスターを利用する準備が整いました。

続いて、ドキュメントで Momento Cache の機能をご確認ください。キャッシュの限界を試したい場合は、Database と同じリージョン、同じゾーンにある c7g.xlarge インスタンスで cachecannon を動かしてみてください。

今後の展開

今回の公開は、Momento Cache の次の章の始まりです。VPC ピアリングや S3 統合など、エンタープライズサービスの機能をさらに Momento Cache へ移していきますので、ご期待ください。

製品を磨き上げるため、厳しい要件の Valkey ワークロードを運用するチームからのフィードバックを求めています。急成長する製品の開発、大規模な Valkey / Redis クラスターの運用、社内キャッシュプラットフォームの設計、チームへの Valkey 導入支援に携わっている方は、次に必要なものや、私たちがお手伝いできることをぜひお聞かせください。

長年の厳しい運用で得た経験を、誰もが今日から使えるサービスに仕上げてくれたエンジニアとパートナーに感謝します。開発を主導した Dylan Abraham と Jason LaPier には、特に感謝を伝えたいと思います。

ただ、インデックスを倍にするのは不安でした。性能への影響がわからなかったからです。超低レイテンシが必要で Valkey を使っているのに、工夫が裏目に出ては困ります。

もちろん、1つから2つなら大問題ではないでしょう。しかしインデックスは増えていくものです。カテゴリで商品を絞るために1つ作り、1か月後に価格を足し、検索チームがベクトルフィールドを欲しがり、決済チーム、配送チームも自分たちのキーに索引を付ける。気づけばリポジトリに12個の FT.CREATE があり、全体の責任者はいません。

直感では、性能は数に反比例しそうです。valkey-search の各インデックスはキープレフィックスを購読します。一致するキーを書くと、そのインデックスの変更キューにエントリが入り、すべて処理されるまでクライアントがブロックされます。これが書き込み後の読み取り整合性を保証します。インデックスが12個なら、エントリも12個で、待ち時間も12倍になるのでしょうか。

そこで、追加インデックスのコストを調べるベンチマークを作りました。すると、私は大きく間違っていたとわかりました。

構成

サーバーは物理8コアの r7i.4xlarge で、Valkey 9.1.1 と valkey-search 1.2.1 を実行しました。valkey-search は書き込みワーカープールを8スレッドに設定します。測定中のバックグラウンド保存の fork がレイテンシを乱さないよう、永続化は無効にしました。負荷は同じプレイスメントグループの別の c7i.8xlarge から、384接続で生成しました。

各書き込みは同じ4.6KBの商品ハッシュで、カテゴリ、価格、SKU、タイトル、説明、1024次元の埋め込みを含みます。負荷生成器は予定に従って送信し、実際に送信できた時刻ではなく、送るはずだった時刻から各リクエストを計測します。これについては後述します。各測定点を25秒ずつ3回実行し、中央値を取ります。

使われていないインデックスにもコストはあるか

先ほどのとおり、インデックスはキープレフィックスを購読します。一致しないキーを追加・更新しても遅くなるのでしょうか。このテストでは、インデックスの存在自体が他の処理を遅くするかを調べます。

product: キーへの同じ書き込みを、2つの構成で実行しました。product: 上のインデックス1つと、それに無関係なプレフィックスのインデックス50個を加えた構成です。

どのレートでも、測定できる差はありませんでした。

プレフィックスの購読がトライ木に格納されているためです。product:88213 を書くと、valkey-search はトライ木をたどり、一致するインデックスだけに通知します。orders: のインデックスには届きません。FT.INFO idx:other0 の mutation_queue_size は実行中ずっと0のままで、この設計どおりの動作を確認できました。

リポジトリ内で増えた雑多なインデックス自体が、書き込みを遅くしているわけではありません。処理経路に入るのは、書くキーとプレフィックスが一致するものだけです。

一致するインデックスの影響

では、一致するインデックスが複数あるとどうなるのでしょうか。同じワークロードで、今度は product: に同一のインデックスを複数追加しました。

一致するインデックスごとに索引付けジョブが作られ、すべて終わるまで書き込みは完了しません。確認するため、Valkey の search_ingest_hash_keys を、同じ時間内に完了した書き込み数で割りました。その値に書き込みレートを掛けて、ジョブ数/秒の列を計算しました。

当然ながら、最も高くつくのは最初に索引付けを有効にする段階です。0から1にすると書き込みレートが58%下がり、2つ目でさらに41%下がりました。2から4へ倍にしても低下は16%だけです。追加するたびに、増分のコストは小さくなりました。

インデックスを増やすと、同じサーバーが処理する索引付けの総量は増えます。1つでは毎秒33,636ジョブ、4つでは67,272です。後から2倍の仕事をこなせたのですから、1〜2個の時点では書き込みプールを飽和させていなかったことが明らかです。

索引付けジョブは物理コア数に合わせたプールへ分散され、クライアントのブロック用ハンドルは、その接続上の1つのブロックに集約されます。書き込みは最も遅い単一ジョブを待つため、4つのインデックスが1つの4倍のコストにはなりません。

ただし、何が制約なのかはわかっていません。ジョブがプールへ届く前にメインスレッドで行う、インデックスごとの管理処理ではないかと推測していますが、測定はしていません。

注：一致するインデックスを増やしても、手遅れになるまでレイテンシの増加に見えない場合があります。毎秒2,000件では、1つと4つの差は1ミリ秒以内でした。消費しているのは容量の余裕なので、正常なシステムの p99 を見ても気づきません。必要になって初めて、余裕がないとわかります。

ベクトルフィールドは影響が違う

ここまでのベンチマークは、通常のフィルター用 TAG と NUMERIC フィールドを使っています。そこで最初のテストに戻り、1インデックスの構成へ1024次元の HNSW ベクトルフィールドを1つ追加しました。再実行すると驚く結果でした。

毎秒32,000件の書き込みが、2,828件になりました。

フィールド1つで、スループットに11倍の差です。概算では、8本の書き込みスレッドに分散したベクトル挿入1回あたりの CPU 時間は2〜3ミリ秒です。さらに性能は急激に崩れます。投入レートを約40%増やすと、破綻しました。

レイテンシは約5ミリ秒から2秒へ悪化します。ほぼ空だったキューは376件になり、それ以上のどのレートでも、その深さにとどまりました。境界より下なら正常、超えればすべてが遅れます。容量計画では、高頻度のプレフィックス上のインデックスにベクトルフィールドがあるかを必ず確認してください。

ベクトルフィールドは他の一致するインデックスにも影響するか

2つのインデックスが必要だった検索機能の話に戻ります。1つで両方をできない理由は、ストップワードです。テキスト処理の設定はインデックス全体に適用され、句読記号で単語を分けてから、ストップワードを削除します。IT-500 は it と 500 に分かれ、it はストップワードなので、500 だけが索引に入ります。NOSTOPWORDS を有効にすると、説明フィールドの the、is、and、it などもすべて索引付けされます。そこで片方だけ有効にするため、2つのインデックスが必要です。

では、最初のインデックスにベクトルがある場合、2つ目にはどれほどコストがかかるのでしょうか。先ほどのテストで、ベクトルがスループットを大きく下げることはわかっています。

差は約3%でした。完全一致用インデックスは、この実行中に141,408個のテキストフィールドを処理しました。両方の変更が同時にプールへ入り、書き込みは遅い方、つまりベクトルを待ちます。すでに HNSW のコストを払っているなら、語句検索用インデックスの追加レイテンシは実質ほぼありません。

得られた教訓

実験開始時の問いが間違っていたとわかりました。インデックス数が多いと性能が極端に落ちると思っていましたが、そうではありません。本当の問いは、書くキーに一致するインデックスの中に、どんなフィールドがあるかです。そう考えると安心できます。

間違った問いに答えようとする間に、ベンチマークについても学びました。

本記事の維持可能な書き込み数は、どれももっと大きく見せることができました。最大レートでは、インデックスなしの構成は毎秒128,000件を完了しましたが、表には80,000件と書いています。そのレートでは、各リクエストがまずキューで1.9秒待っていたからです。使用率100%のサーバーは流入と同じ速度で処理するので、スループットは完璧に見えてもレイテンシを犠牲にします。表には、p99 が妥当な範囲にとどまる最高レートを使いました。

冒頭の4行の表を信じられるまで、3回測定しました。初回は段階ごとに1.4倍ずつ上げたため、2インデックスと4インデックスが同じ16,000の段階に入り、最初は3つ目と4つ目に影響がないと思いました。実際には両方とも段階の間で破綻しており、測定の刻みでは場所を区別できませんでした。そこで1.19倍刻みにすると、明確に分かれました。しかし、その測定は14,000から始まっており、すでに曲線の上方だったため、低負荷時のレイテンシを測れていませんでした。維持可能なレートの基準は低負荷時に対する相対値なので、2回目は甘い基準で評価していたことになります。3回目は2,000から始め、表にはその結果を使いました。レートの段階幅より小さな差は区別できず、急変前の平坦部分を見ていなければ急変点もわかりません。

自分で試す

ベンチマーク、スクリプト、結果は GitHub で公開しています。数値を確認したい方、異論がある方も、ぜひ試して結果を教えてください。

自分の Valkey クラスターで同じテストをするなら、次の3コマンドを実行できます。

FT.INFO <index> # shows mutation_queue_size (write backlog) for the specified index
INFO search # shows search_writer_queue_size for the whole pool
CONFIG SET search.info-developer-visible yes # unlocks per-field-type counters like search_ingest_field_vector

これらの変更は元に戻せるので、既存クラスターでも低コストで実験できます。FT.DROPINDEX は即座に完了し、データ自体はもともとインデックス内にありません。構成を追加し、測定し、不要になったら削除してください。

開発を楽しんでください。

残念ながら、それほど簡単ではありません。記憶は似ているだけでなく、新しくもなければなりません。1年前の記憶にエージェントを左右されたくはないでしょう。結果も重要です。一方の方法が成功し、もう一方が失敗したなら、成功した方を行動の指針にしたいはずです。

エージェントの推論ループ内に Valkey Search を組み込む小さなデモを作る中で、この問題に出会いました。エージェントが終えたタスクをすべて記憶として書き込みます。タスクの文章、有効だった方法、成否、実行時刻、タスクのベクトルを保存します。次に似たタスクが来たときは、最初から見つけ直す代わりに、成功した方法を思い出します。

最初の FT.SEARCH が予想どおり動かなかったため、valkey-search の扱い方を実地で学ぶことになりました。

FT.SEARCH idx:memory "(@outcome:{success} @created_at:[1782900000 +inf])=>[KNN 3 @vector $vec]" PARAMS 2 vec <query-vector> DIALECT 2

=> の左側は、埋め込みと一緒に索引付けした2つのフィールドに対する、タグと数値範囲の通常のブールフィルターです。右側がベクトル検索です。

私は、近いベクトルを見つけてから、タグと時刻のフィルターを適用すると思っていました。しかし、よい意味で違いました。フィルター条件は、実際にはクエリプランナーへの入力です。一致する記憶の数に応じて、Valkey はベクトルインデックスの検索アルゴリズムを変えます。つまりフィルターを追加すると、検索の実行方法そのものが変わります。そのため最初の記憶スキーマを考え直す必要がありました。検索ポリシーは、インデックス設計上の判断でもあったのです。

もはや後処理フィルターではない

Pinecone、Qdrant、Weaviate、Milvus を使っていれば、なじみのある話でしょう。いずれもクエリ時に、フィルターを適用してグラフをたどるか、グラフをやめて一致する部分集合を総当たりするかを決めます。Pinecone は single-stage filtering、Qdrant は query planning、Weaviate は flat search cutoff と呼びます。Milvus には特別な呼び名はなく、そのように動きます。valkey-search も同じ考えで、FT.SEARCH のベクトル経路には後処理のフィルタリングを実装していません。

一方、pgvector では、インデックススキャンの後にフィルターします。初期値の hnsw.ef_search は40なので、候補の約10%を残すフィルターなら、結果は4件だけになるかもしれません。0.8.0で反復インデックススキャンが追加され、多少改善されましたが、初期設定では無効です。

valkey-search はこれをクエリプランナーと呼びます。フィルターに一致するキー数を見積もり、2つの検索アルゴリズムから選びます。

推定数がインデックスに比べて小さければ、事前フィルターを使います。条件を満たすキー集合をたどり、距離を直接計算し、上位 k 件のヒープを保持します。HNSW グラフはたどりません。つまり、小さな集合に対する総当たりスキャンです。

推定数が大きければ、インラインフィルターを使います。述語を isIdAllowed ファンクターとして hnswlib に渡し、最下層を探索する間に評価します。一致しないノードも訪問して展開しますが、結果集合には加えません。

切り替えのしきい値は0.001です。推定一致キー数が、インデックス内のベクトル数の0.1%以下なら総当たりになり、それ以外はインラインフィルターになります。

参考までに、Milvus のしきい値は約7%なので、valkey-search は約70倍厳しい設定です。想像以上にインライン経路が選ばれます。

フィルターの負担をなくす

数百件の記憶を持つデモのインデックスでは、しきい値は1キーを大きく下回ります。そのため1件でも一致すれば、すべてインライン経路になります。この規模では、どちらでも違いに気づきません。

同じスキーマで、本番に1,000,000件の記憶があったらどうなるでしょうか。しきい値は1,000キーです。プランナーはフィルターの選択性を見ます。@outcome:{success} が70%に一致し、@created_at の期間も広ければ、明らかにインライン経路です。その判断は正しいものです。一方、記憶400件の単一テナントに範囲を絞ると、しきい値を下回り、厳密なスキャンになります。距離計算400回は軽いため、完全で高速な検索を得られます。

もう少し難しい場合を考えます。大きなインデックスの1%に一致するフィルターは、しきい値の10倍なのでインライン経路です。HNSW は、残せる候補1件ごとに多くの候補をたどり、想定外のレイテンシが加わります。しかも調整では変えられません。search.prefiltering-threshold-ratio は search.debug-mode が有効でないと変更できず、公開の設定一覧にもありません。

実際にどちらの経路を使っているかは確認できます。valkey-search は search_prefiltering_requests_count と search_inline_filtering_requests_count の両方を数えています。モジュールのフィールドなので、単なる INFO ではなく INFO SEARCH が必要です。同じ検索を100回実行し、どちらが増えるか確認できます。

したがって最善の調整対象は、インデックス自体です。フィルターが名前空間のように働くようにします。インデックス名にハッシュタグを入れ、キーのプレフィックスにも同じタグを付ければ、各テナントの検索は1シャード上の小さなインデックスへ向かい、フィルターの影響はほぼなくなります。Valkey は双方向にこれを強制します。タグ付きのインデックス名では全プレフィックスに同じタグが必要で、タグなしの名前ではどのプレフィックスにもタグを含められません。ただし、ここには FT.ALTER がないため、後で考えを変えても簡単には戻せない点に注意してください。

忘れるコストは高い

HNSW インデックスからベクトルを削除すると、markDelete を呼んで終わります。ノードはグラフから消えず、引き続き訪問され、他の検索の経路にもなります。削除済みの確認に失敗するだけです。search.hnsw-allow-replace-deleted を使えば次の挿入でスロットを再利用できますが、初期値は false で、本番向けというより非本番用のフラグです。本番では、インデックスを削除するまで領域が取り残されます。

幸い、更新は違います。索引付けされたベクトルの変更は、既存ラベルのままその場で更新されます。ノードは同じスロットを保持し、リンクだけが付け直されます。ベクトル以外のハッシュフィールドを書いてもグラフには影響せず、同一バイト列でベクトルを書き直した場合は、その前に処理が終了します。

つまり更新は安く、削除は高くつきます。DEL、追い出し、期限切れも含みます。

これは少し心配です。期限切れこそ、記憶の新しさを保つポリシーだからです。valkey-search は generic、expired、evicted のキースペース通知を購読し、TTL 付きの記憶はキーがなくなるとベクトルインデックスからも確かに消えます。望ましい動作ですが、それがグラフノードを取り残す原因にもなります。

そのため、記憶のキーの付け方を変える必要があります。実行ごとに新しいキーを作るのは安全で合理的な初期設定に思え、私のデモも完了タスクごとに memory:<id> を使っています。しかし、新鮮さを保つ TTL を付けると、失効するキーのたびにノードが残ります。大規模では高価な初期設定です。代わりに、タスクのフィンガープリントから安定したキーを作り、その種類のタスクを学ぶたびに同じ場所で更新します。これなら、試行ごとではなくタスクごとに1ノードで済みます。

新しさを制御する方法は2つあります。@created_at の範囲は、そのクエリで何を信頼するかを決め、何も削除しません。TTL は、どこまで保存費用を払うかを決めます。まず範囲を調整し、TTL はより長い周期の補助手段にするべきです。

データを持つ前に決める

このデモには2度驚かされました。クエリの細部として書いたフィルターが実行アルゴリズムを決め、記憶を新しく保つために追加しかけた TTL が、インデックスの領域を取り残すということです。

少なくとも、すべて調べられます。プランナーのコードは短い関数で、読めば理解できます。フィルターは hnswlib 由来です。削除ノードの動作もソースのコメントにあり、カウンターは INFO SEARCH で見られます。私の説明をそのまま信じなくても、確認できます。

読んでも避けられないのは、判断が必要になる時期です。インデックスの範囲と記憶のキーは、検証に使える記憶が1件もない初日に決めます。開発専用フラグを除けば、削除で取り残された領域を回収するには再構築しかありません。間違えれば、索引を作り直すことになります。

出発点が必要なら、デモを GitHub で公開しています。docker compose up -d で検索モジュール付き Valkey と、自分の記憶を書き込むエージェントを起動できます。いくつかタスクを実行し、INFO SEARCH を見て、クエリが実際にどの経路を使うか確認してください。

開発を楽しんでください。

実現できたと思います。数字もそれを裏付けています。

私たちが望んだ会場

最も誇りに思う数字は、登録124人に対して117人が来場したことです。来場率は94.4%。技術カンファレンスを運営したことがあれば、通常は60%前後だとご存じでしょう。登録しても事情が変わり、半分の名札が受け取られないこともあります。

今回は違いました。そのことが、集まった人々を物語っています。無料の T シャツ、ステッカー、Mo のぬいぐるみ、昔の緑色の Elemental グッズ（Kiran、ありがとう！）を集めるための参加ではありませんでした。欠席7人のうち6人はスポンサー企業の方で、同僚が会場に来ていました。

117人は41の組織を代表し、大手放送局、テクノロジープラットフォーム、動画インフラプロバイダーなど、大規模なメディアワークロードを実際に作り、運用する人々が幅広く集まりました。これほど多くの実務家が1か所に集まると、廊下での会話はセッションと同じくらい、あるいはそれ以上の価値を持ちます。

売り込みは事前審査で除外

私たちが厳しく守ることがあります。BuffConf は営業の場ではありません。提案されたセッションはすべて人が審査し、ベンダーの売り込みに見えるものは差し戻しました。優先したのは利用者と実務家の声、障害が起きて午前3時に本当に呼び出されたことのある人々です。

結果として、17社29人の登壇者による22の技術セッションになりました。特に、登壇者の40%はベンダー以外でした。Paramount、Netflix、FOX、CBS Interactive、Meta、Red Bull Media House などの運用者が、本番での経験を語りました。「当社のロードマップ」ではなく、「何を試し、何が失敗し、最終的に何が耐えられたか」という話です。

マーケティング予算があり、動画の専門家向けカンファレンスをもう1つ支援できるベンダーで日程を埋めるのは簡単です。特に、例年のもっと大きなイベントが、今年はひっそり中止されたように見える状況なら、なおさらです。どのイベントかはおわかりでしょう。しかし、運用者に登壇してもらい、インフラのありのままを話してもらう方が、はるかに難しく、価値も高くなります。そうした話から、会場の誰もが自分の仕事に使える学びを持ち帰れます。

講演で扱ったこと

2日間を通じて3つの主なテーマがあり、それぞれを印象的なセッションが表していました。

大規模な本番ワークフロー。 私は「104試合、50億人の視聴者、失敗の余地なし」で幕を開け、FIFA ワールドカップ2026の数値と、世界規模のライブ配信が実際に要求するものを紹介しました。続いて Paramount の Spencer Shanson が、FAST プラットフォームを数チャンネルから数千へ拡大した経験を語りました。数本のストリームからリニアチャンネルの大きなカタログへ至る道のりは、多くの参加者が日々向き合う運用の現実です。実際に実行した人の話は、どんな構成図より価値があります。そして「大規模」が Netflix の規模を意味するなら、120,000ノードで毎秒10億を超えるリクエストを扱う仕組みを説明するのに、Sunjeet Singh と William Schor ほど適した人はいないでしょう。

実践的な AI と、その限界への率直な認識。 最も新鮮に感じた部分です。AI がすべてを解決すると語る人はいませんでした。まだ道半ばです。基調講演の Manish Rao は、NAB 以降の AWS Elemental Inference の進歩を紹介しました。今の革新の速度では、わずか3か月で世界が変わるほどの差が生まれることに驚きます。CBS Interactive の Edwin Rivera は、CBS Sports が編集者による選定と埋め込みベースの推薦を組み合わせ、実際にエンゲージメントを高める AI の「おすすめ」ページを作った方法を紹介しました。スポーツのコンテンツ発見は、今この業界で最も豊かな課題領域の1つです。NVIDIA の Jeffrey Kember は、アクセラレーテッドコンピューティングがエンコード、品質、リアルタイムのメディアワークフローにもたらす変化を説明しました。メディア向け AI は完成ではなく、まだ始まりなのだと再認識しました。他にも、動画圧縮の概念を直接借りたトークン効率化、自動 QC ループ、エッジでの不正配信対策のシミュレーション基盤がありました。試行錯誤の跡がある実装に、実践的なフレームワーク研修を組み合わせ、チームが持ち帰って開発できる内容でした。

クライアント側の現実。 再生 SDK とデバイス機能の最適化を扱うパネルには、FOX の Jonathan Colwell、Red Bull Media House の Joshua Lamb、Paramount の David Van der Voort（DVD）が参加しました。あらゆるデバイスと利用パターンに対応する日々の混乱を、異なる3つの視点から語りました。再生に携わる人なら誰もが知る断片化の苦労を、3人の運用者が公開で比較する。他では得られないセッションでした。

全体を通じて形式のバランスも保ちました。深い技術講演、十分な交流時間、実際に手を動かすワークショップ。考え、議論し、掘り下げる余地を設けました。

やはり質疑応答が一番

昨年同様、質疑応答には熱気がありました。技術者の参加者が技術的な質問をし、すべての登壇者が応えました。そのやり取りで、準備された講演がさらによいものに変わります。会場の同業者が核心を突くことで、スライドを超え、そこでしか聞けない複雑な詳細へ踏み込めます。

それこそが、対面で開催する理由です。オンラインでは再現できません。

感謝

カンファレンスが実現するのは、形になる前から信じてくれる人々がいるからです。

Paramount、Netflix、CBS Interactive、FOX、Red Bull Media House、NVIDIA、Meta、AWS、Visionular、Bitmovin、そして苦労して得た教訓を共有するために登壇者を送り出してくれたすべての企業の皆さん。宣伝より中身を選んでくださり、ありがとうございます。皆さんがいるから、参加者は飛行機に乗って集まります。

ウルグアイからの JP Saibene と Nicolas Gonzalez、トルコからの Ali Begen、そして遠方からシアトルへ来てくださった皆さん。このコミュニティを形作る好奇心と惜しみなく分かち合う姿勢を持ち寄ってくださり、ありがとうございます。

開催を実現した Momento の仲間、特に Hannah、Mike、Kelsey、Maéline、そして2日間のイベントを自然に進めるために何か月も尽くした皆さん。心から感謝しています。一緒に働けることを幸運に思います。

そして来場してくださった皆さん。このコミュニティそのものがイベントでした。質問、経験、「実は私たちのところでも壊れました」と率直に言える姿勢が、集まる価値を生みます。配信の世界は、特に AI とライブ動画が交わる場所で、急速に動き続けています。私たちは皆、率直な会話を1つずつ重ね、動画の未来を話し合うために集まりました。

また来年お会いしましょう。

これは、もっと不思議に感じてもよいことです。推論といえば、通常は速度が大きなテーマです。最近の記事で目にするのは、最初のトークンまでの時間（TTFT）、テールレイテンシ、人が集中を保てるよう往復時間をミリ秒単位で削る話ばかりです。それなのに私は、特にトークンを多く消費する作業をノート PC から実行し、所要時間をほとんど気にしていませんでした。

Doubleword CEO の Meryem Arik は、最近の講演 Inference for Async Agents in Production で、この感覚を的確に言葉にしていました。「誰が待っているのか」という単純な問いに、私は納得しました。

誰も待っていなければ、推論のコストはまったく違って見えます。

誰も見ていない前提で推論をスケジュールする

チャットのような同期システムでは、人が処理の流れに直接入っています。何の反応もなく待たされると、本当に動いているのかとあちこちクリックし始めます。非同期システムでは、エージェントが作業を分岐させ、30分ほど動き、終わったら通知するかもしれません。画面を見ている人はいません。利用者は別のことをしているので、35分で終わるか45分で終わるかは、あまり問題にならないことも多いのです。

UX の細かな違いのように見えますが、基盤のほぼすべての判断に影響します。

「誰が待っているのか」は、出発点として正しい問いです。より具体的には、どれだけ待たせてよく、その後ろで何が止まっているのか。人が画面を見ていなくても、エージェントのクリティカルパス上の呼び出しには期限があります。非同期ワークフローは、その期限を決める余地を広げてくれるのです。

人を待たせる時間は、システム内で最も高くつく時計です。「人にとって十分速い」という要件が、プロビジョニング、バッチ量、購入するチップ、待機させる余剰容量を決めます。「今すぐ答えがほしい」と言えば、すべてが高価になります。人をループから外すと、その時間制約は緩み、他のすべてに課していた値札も変わります。

バッチ処理を再発明した

対話型のデータベースクエリと夜間の分析ジョブなど、私たちは過去にも同じことをしてきました。午前2時に動くバッチより、利用者が見つめる Web リクエストを優先します。テクノロジー業界は、私が生まれる前から「誰かが待っている」と「誰も待っていない」を分けてきました。

推論は、データベースやジョブキューが何十年も前に学んだことを、よい意味で急速に追体験しています。若い分野の難題がインフラの世界では既知なら、実績のあるパターンをすぐ借りられます。

Meryem は中心的な緊張関係を、レイテンシ、品質、スループットという従来の三角形で説明します。選べるのは2つです。

チャットアプリはレイテンシと品質を選びます。非同期エージェントは品質とスループットを選び、レイテンシを許容します。長時間動くエージェントに主に必要なのは、できるだけ賢いモデルです。サブエージェントを管理し、複数タスクを扱いながら、2時間の作業で一貫性を保つためです。会話の速度でトークンを返しても、利点にはなりません。

バッチ処理の本質はスケジューリング

バッチサイズの計算は複雑です。Meryem の講演の例では、バッチサイズ1で対話性を最大化したモデルは、100万トークンあたり約$4.65でした。同じモデルに十分な同時処理を与え、スループット重視に調整すると、100万トークンあたり約9セントになります。

この例では、重みも品質も同じなのに、コストに50倍の差があります。採算に大きく影響します。

ただし条件があります。大きなバッチが最良の経済性を生むのは、互換性のある待機中の仕事が十分にあり、バッチを埋め続けられる場合だけです。空き枠は、お金を払っているのにトークンを生まない半導体です。需要が突発的で予測困難なまま、バッチを埋め続けることが難題です。

以前、私は別の角度から、GPU はテクノロジー分野で最も高価な資源なのに、うまく使えていないと論じました。バッチサイズも同じ話です。高い使用率が最重要で、その成否はスケジューラーで決まります。

キューこそが製品になる

Meryem の説明で印象的だったのは、ほとんどのプロバイダーがリアルタイムのサーバーレスエンドポイントで赤字になっているという点です。「今すぐ」の追加コストに行き着きます。ばらつくトラフィックに対して人へ高速な応答を約束するには、ピークに合わせて用意し、間の低負荷時の遊休コストを負担しなければなりません。遊休計算資源は、資金を燃やしているのと同じです。

待てる仕事なら、バッチキューは強力な道具になります。負荷の低い時間へ仕事を回し、すでに費用を払っている空き時間を埋められます。中断を許容できる、またはチェックポイントを取れる作業なら、スポットインスタンスで余剰計算資源を使えます。SLA を考慮したルーティングで、緊急リクエストを先に回せます。同じ mixture-of-experts の重みを使うリクエストを連続させ、毎回エキスパートを再読み込みしないよう、キューを並べ替えることもできます。

「今すぐ」を約束しなくなれば、スケジューラー、ルーター、あるいはキューを管理するものがシステムの中心になります。価値はそこへ集まり、全体もその方向へ進んでいます。ハードウェアとモデルがコモディティ化すると、優位性はルーティング、配置、オーケストレーションへ移ります。「次に何を動かすか」を決める者が、経済性を握ります。

待てる時間を分類する

私は習慣で、すべてをリアルタイム扱いしてしまいます。相手の「人間」が、別の6つのことをしているエージェントであっても、息を詰めて待つ人がいるかのように扱います。その結果、不要な仕事にも「今すぐ」の追加コストがかかります。

Doubleword はレイテンシを、リアルタイム、非同期（約1分）、バッチ（24時間）に分類しています。先ほどの50倍のコスト差は、どの区分を選ぶかに帰着します。私を含め、多くの人が反射的に高価な方を選んでいます。

この記事を読んだ直後にできる、地味ですが有用な作業があります。エージェントの呼び出しを1つずつ見て、人が待っているかを確認することです。該当するものの少なさに驚くかもしれません。バックグラウンドでコンテキストを取る呼び出しでは、人は待っていません。11段階中の4段階目を処理するサブエージェントも同じです。夜間の要約ジョブなら、なおさらです。

近い将来、コンテキスト、依存関係、期限からレイテンシ区分を推定する賢いルーターが登場し、手作業で分類しなくて済むようになるでしょう。それを効率よく実現できれば、スケジューラーが各仕事の許容待ち時間に合わせて最適化でき、システムコストは大きく下がります。それまでは、全体を初期設定で「今すぐ」にするのではなく、モデル呼び出しごとに現実的なレイテンシ予算を与えることから始めましょう。

ここで話したことは、インフラの世界では長年使われています。Momento の共有キャッシュも同じ発想です。高価な状態を保存し、すでに費用を払った処理を再利用し、希少な資源を遊ばせず働かせます。推論は、こうした古くからの発想に、非常に大きな新しい金額を付けています。

同じ課題に取り組んでいる方は、ぜひ情報交換しましょう。

開発を楽しんでください。