Amazon SageMaker HyperPodとCurvineによる大規模LLM向け階層型KVキャッシュ

大規模な大規模言語モデル（LLM）推論をスケールさせる場合、通常、KVキャッシュのトレードオフが生じます。つまり、増大するKVキャッシュに対応するために過剰に大きなGPUインスタンスのコストを支払うか、同一のプロンプトがリクエストごとに再計算されることで、最初のトークンまでの応答時間（TTFT）の遅延を受け入れるかの選択です。Qwen、Llama、DeepSeekなどの一般公開済み基盤モデル（FM）の幅広いカタログを、ビジネスラインごとのエンドポイント、検索拡張生成（RAG）パイプライン、またはマルチターン対話アプリケーションに展開しているチームにとって、このトレードオフはそのままインフラストラクチャコストの上昇とユーザーエクスペリエンスの低下につながります。根本的な原因は、生成中にvLLMがすべてのトークンのアテンションキーと値をKVキャッシュに保存し、プレフィックスキャッシュが共通の先頭トークンを持つリクエスト間でそのキャッシュを再利用することです。ml.g6e.4xlarge（GPUあたり48 GB）のようなコスト効率の高いインスタンスでは、プレフィックスキャッシュ用に残されるメモリが限られており、長いプロンプトではキャッシュヒット率が低下し、同一のシステムプロンプトがリクエストごとに再プリフィルされ、水平スケールされたvLLMレプリカはそれぞれが分離されたキャッシュを維持します。このソリューションは、3層のキャッシュ階層を構築します。L0（GPUプレフィックスキャッシュ）、L1（CPUメモリオフロード）、L2（Curvine経由の共有分散NVMeプール）です。L0はvLLMのネイティブなページドアテンション層で、L1はLMCacheを使用して退避されたGPUブロックをホストのDRAMにオフロードし、L2はローカルのNVMeドライブをCurvine経由で共有名前空間にプールし、ReadWriteMany PVCとして各推論Podにマウントします。HyperPodのインテリジェントルーティングは、プレフィックス認識、KV認識、ラウンドロビンなどの戦略を使用して、関連するKVブロックを持つ可能性が最も高いレプリカにリクエストをルーティングします。最終的な効果は、完全なミスの場合のみシステムがゼロから再プリフィルすることになり、中程度から高いプロンプト重複を持つワークロードのTTFTを大幅に削減します。テスト展開では、ポッド間キャッシュヒット率が最大100%向上し、TTFTが最大2.7倍改善され、約1,900トークンのプロンプトに対するノード間L2読み取りレイテンシは約56ミリ秒でした。このアーキテクチャにより、以前はP5インスタンスを必要としていたワークロードを、より低コストのG6eインスタンスで実行でき、エンドポイントあたりのコストを削減できます。この実装には、Tiered Storageを有効にしたSageMaker HyperPod、EKSクラスター、およびInference OperatorとCurvineのインストールが必要です。この投稿では、Tiered Storageの有効化、Inference Operatorと依存関係のインストール、Curvineのインストール、ファイルシステムバックアップL2のためのInference Operatorのパッチ適用、ベンチマークの5つの段階を説明します。