AWS、SageMaker HyperPodと分散キャッシュ「Curvine」による階層型KVキャッシュ構成を公開──LLM推論のTTFTを最大2.7倍改善
要点
-
Amazon Web Services(AWS)が、Amazon SageMaker HyperPodと分散キャッシュ「Curvine」を組み合わせた大規模言語モデル(LLM)向けの階層型KVキャッシュアーキテクチャを公開した。
-
GPUメモリ(L0)とCPUメモリ(L1)に加え、共有NVMeストレージ(L2)を活用する3層構造により、複数の推論レプリカ間でKVキャッシュの共有を実現する。
-
検証環境において、Pod間でのキャッシュヒット率最大100%、最初のトークン出力までの時間(TTFT)で最大2.7倍の高速化を達成した。
-
従来は上位のP5インスタンスが必要だった推論ワークロードを、低コストなG6eインスタンスへ移行可能にし、運用コストの削減につながるとしている。
-
Amazon Web Services(AWS)は現地時間2026年8月12日、機械学習向けクラスタ管理サービス「Amazon SageMaker HyperPod」において、軽量な分散キャッシュファイルシステム「Curvine」を活用した階層型KVキャッシュ構成の構築手法を公式ブログで発表しました。
-
大規模言語モデル(LLM)の推論処理において課題となっていたメモリ容量の制約とプロンプト再計算のオーバーヘッドを解消し、応答性能の向上とインフラコストの削減を両立するアプローチとしています。
LLM推論におけるGPUメモリとキャッシュのトレードオフ
LLMのテキスト生成処理では、計算済みのトークン情報を再利用して計算量を抑えるため、注目機構(アテンション)のKeyとValueのデータを「KVキャッシュ」としてメモリ上に保持します。さらに、共通のシステムプロンプトなどを使い回す「プレフィックスキャッシング」を利用することで、リクエストごとの重複処理(プレフィル)を省き、処理開始までの待ち時間を大幅に短縮できます。
しかし、QwenやLlama、DeepSeekといった公開基盤モデルを検索拡張生成(RAG)や複数ターンの対話アプリケーションなどで大規模に運用する際、メモリ容量が大きな壁となっていました。例えば、GPUメモリが48GBの「ml.g6e.4xlarge」のようなコスト効率に優れたインスタンスでは、モデルのパラメータ(重み)を展開した後に残るメモリ容量が限られます。モデルの大規模化や同時リクエスト数の増加に伴ってKVキャッシュ用の領域が不足し、長いプロンプトでキャッシュヒット率が低下して同一のプロンプトを都度再計算せざるを得ない状況が発生していました。
加えて、推論エンジンの「vLLM」を水平スケールさせて複数レプリカで運用する場合、従来の構成ではレプリカごとにキャッシュが独立して管理されていました。そのため、以前処理したプロンプトと同じ内容であっても別のレプリカにリクエストが振り分けられると実質的なコールドスタートとなり、最初のトークンが出力されるまでの時間(TTFT:Time-to-First-Token)が悪化するという構造的な課題を抱えていました。
GPU・CPU・共有NVMeを束ねる3層キャッシュの設計
今回AWSが提示したソリューションは、単一のPod(コンテナ単位)内に閉じていたキャッシュの階層をクラスタ全体へ拡張するものです。SageMaker HyperPodが提供する「Managed Tiered KV Cache and Intelligent Routing(マネージド階層型KVキャッシュおよびインテリジェントルーティング機能)」を土台に、軽量分散キャッシュファイルシステムの「Curvine」を組み合わせています。
具体的には、以下の3つの階層(Tier)でキャッシュを管理します。
- L0(GPUメモリ/HBM): 最もアクセスレイテンシが低いvLLMネイティブのページアテンション層。モデル重みをロードした後の空き領域を最もアクセス頻度の高いホットなデータに割り当てる。
- L1(ホストCPUメモリ): GPUから溢れたデータをノード内のメインメモリへ退避させるローカル層。
- L2(Curvineによる共有NVMeプール): 各ノードのローカルNVMeストレージをネットワーク経由で束ねた分散共有キャッシュ層。
この3層構造にキャッシュの状態を考慮したリクエストルーティング(Intelligent Routing)を組み合わせることで、異なる推論レプリカ間であっても、ローカルディスクに近い高速なアクセス性能で過去のKVキャッシュを共有・再利用できるようにしています。
実装手順とコンポーネントの役割
記事では、この階層型アーキテクチャを構築するためのエンドツーエンドの実装手順も解説されています。
主な流れとしては、まずSageMaker HyperPodの階層型ストレージ機能を有効化し、各コンピュートノードが備えるローカルNVMe上にCurvineのワーカーをデプロイします。その上で、ファイルシステムをバックエンドとするL2キャッシュに対応させるため、推論オペレーター(Inference Operator)にパッチを適用して設定を完了させます。これにより、複雑な専用インフラを個別に構築することなく、クラスタ内のストレージリソースを効率的にキャッシュ領域として統合できるとしています。
最大2.7倍のTTFT改善と高価なインスタンスからの移行
テスト環境でのベンチマーク検証において、この階層型KVキャッシュアーキテクチャは高い性能改善効果を示しました。
検証結果によると、複数のPodにまたがるリクエストであっても最大100%のキャッシュヒット率を達成したほか、TTFT(最初のトークン出力時間)が最大で2.7倍向上しました。また、約1,900トークンのプロンプトを用いた測定では、ノード間をまたぐL2キャッシュの読み取りレイテンシを約56ミリ秒に抑えられたと報告されています。
AWSは、この仕組みを導入することで、これまで大きなKVキャッシュ領域を確保するために高価な「P5」インスタンスを必要としていたワークロードを、より安価な「G6e」インスタンスへと移行できる可能性があると説明しています。これにより、モデルのエンドポイントごとに発生するインフラ費用を削減できる道が開かれます。なお、具体的なコスト削減効果は、運用するモデルのサイズやトラフィックの特性によって変動するとしています。