Amazon SageMaker HyperPod にモデルをデプロイする - Amazon SageMaker AI

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon SageMaker HyperPod にモデルをデプロイする

Amazon SageMaker HyperPod は、トレーニングを超えて、Kubernetes の柔軟性と AWS マネージドサービスの運用上の優秀性を組み合わせた包括的な推論プラットフォームを提供するようになりました。モデルライフサイクル全体で同じ HyperPod コンピューティングを使用して、エンタープライズグレードの信頼性で機械学習モデルをデプロイ、スケーリング、最適化できます。

Amazon SageMaker HyperPod は、kubectl、Python SDK、Amazon SageMaker Studio UI、HyperPod CLI など、複数の方法でモデルをデプロイできる柔軟なデプロイインターフェイスを提供します。このサービスは、需要に基づいて自動的に調整する動的リソース割り当てを備えた高度なオートスケーリング機能を提供します。さらに、パフォーマンスを最適化するために time-to-first-token、GPU 使用率などの重要なメトリクスを追跡する包括的なオブザーバビリティとモニタリング機能を提供しています。

注記

GPU 対応インスタンスにデプロイする場合、マルチインスタンス GPU (MIG) テクノロジーを使用した GPU パーティショニングを使用して、1 つの GPU で複数の推論ワークロードを実行できます。これにより、GPU の使用率とコストの最適化が向上します。GPU パーティショニングの設定の詳細については、「」を参照してくださいAmazon SageMaker HyperPod での GPU パーティションの使用 HyperPod

トレーニングと推論の統合インフラストラクチャ

トレーニングワークロードと推論ワークロードの間でコンピューティングリソースをシームレスに移行することで、GPU 使用率を最大化します。これにより、運用の継続性を維持しながら総所有コストを削減できます。

エンタープライズ対応デプロイオプション

Amazon SageMaker JumpStart のオープンウェイトモデルやゲートモデル、Amazon S3 および Amazon FSx のカスタムモデルなど、複数のソースからモデルをデプロイできます。単一ノードとマルチノードの両方の推論アーキテクチャをサポートします。

マネージド階層型キーバリュー (KV) キャッシュとインテリジェントルーティング

KV キャッシュは、以前のトークンを処理した後、事前に計算されたキーと値のベクトルを保存します。次のトークンが処理されると、ベクトルを再計算する必要はありません。2 層キャッシュアーキテクチャにより、低レイテンシーのローカル再利用に CPU メモリを使用する L1 キャッシュと、Redis を活用してスケーラブルなノードレベルのキャッシュ共有を可能にする L2 キャッシュを設定できます。

インテリジェントルーティングは受信リクエストを分析し、関連するキャッシュされたキーと値のペアを持つ可能性が最も高い推論インスタンスに転送します。システムはリクエストを調べ、次のいずれかのルーティング戦略に基づいてルーティングします。

  1. prefixaware — 同じプロンプトプレフィックスを持つ後続のリクエストは、同じインスタンスにルーティングされます。

  2. kvaware — 受信リクエストは、KV キャッシュヒット率が最も高いインスタンスにルーティングされます。

  3. session — 同じユーザーセッションからのリクエストは、同じインスタンスにルーティングされます。

  4. roundrobin — KV キャッシュの状態を考慮せずにリクエストを均等に分散します。

この機能を有効にする方法の詳細については、「」を参照してくださいパフォーマンスを向上させるために KV キャッシュとインテリジェントルーティングを設定する

KV キャッシュの組み込み L2 キャッシュ階層型ストレージのサポート

既存の KV キャッシュインフラストラクチャに基づいて、HyperPod は Redis と共に追加の L2 バックエンドオプションとして階層型ストレージを統合するようになりました。組み込みの SageMaker マネージド階層型ストレージを使用すると、パフォーマンスが向上します。この機能強化により、キャッシュオフロードのよりスケーラブルで効率的なオプションが提供され、特に高スループットの LLM 推論ワークロードに役立ちます。この統合は、既存の vLLM モデルサーバーおよびルーティング機能との互換性を維持しながら、パフォーマンスを向上させます。

注記

データ暗号化: KV キャッシュデータ (注意キーと値) は、推論レイテンシーを最適化し、パフォーマンスを向上させるために、保管時に暗号化されずに保存されます。encryption-at-rest要件が厳しいワークロードの場合は、プロンプトとレスポンスのアプリケーションレイヤー暗号化を検討するか、キャッシュを無効にします。

データ分離: マネージド階層型ストレージを L2 キャッシュバックエンドとして使用する場合、クラスター内の複数の推論デプロイは、分離なしでキャッシュストレージを共有します。異なるデプロイからの L2 KV キャッシュデータ (注意キーと値) は分離されません。データ分離を必要とするワークロード (マルチテナントシナリオ、さまざまなデータ分類レベル) の場合は、個別のクラスターにデプロイするか、専用の Redis インスタンスを使用します。

自動フェイルオーバーによるマルチインスタンスタイプのデプロイ

HyperPod Inference は、マルチインスタンスタイプのデプロイをサポートし、デプロイの信頼性とリソース使用率を向上させます。デプロイ設定でインスタンスタイプの優先リストを指定すると、希望するインスタンスタイプに容量がない場合、システムは使用可能な代替方法から自動的に選択します。Kubernetes スケジューラはpreferredDuringSchedulingIgnoredDuringExecutionノードアフィニティを使用してインスタンスタイプを優先度順に評価し、ワークロードを優先度の高い使用可能なインスタンスタイプに配置しながら、優先リソースが利用できない場合でもデプロイを確保します。この機能は、コストとパフォーマンスの設定を維持しながら、容量の制約によるデプロイの失敗を防ぎ、クラスター容量の変動中でも継続的なサービスの可用性を確保します。

きめ細かなスケジューリング制御のためのカスタムノードアフィニティ

HyperPod Inference は、カスタムノードアフィニティをサポートし、インスタンスタイプの選択以外のワークロードの配置を制御します。アベイラビリティーゾーンの分散、キャパシティータイプのフィルタリング (オンデマンドとスポット)、カスタムノードラベルなどのノード選択基準を nodeAffinityフィールドで指定します。このシステムは、 を使用した必須の配置制約requiredDuringSchedulingIgnoredDuringExecutionと、 を使用したオプションの設定をサポートしておりpreferredDuringSchedulingIgnoredDuringExecution、デプロイの柔軟性を維持しながら、ポッドスケジューリングの決定を完全に制御できます。

注記

重要なサービスの可用性を提供するために、特定の日常的な運用メトリクスを収集します。これらのメトリクスの作成は完全に自動化されており、基盤となるモデル推論ワークロードの人間によるレビューは含まれません。これらのメトリクスは、デプロイオペレーション、リソース管理、エンドポイント登録に関連しています。