HyperPod クラスターでの推論オブザーバビリティの実装 - Amazon SageMaker AI

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

HyperPod クラスターでの推論オブザーバビリティの実装

Amazon SageMaker HyperPod は、データサイエンティストと機械学習エンジニアがデプロイされたモデルをモニタリングして最適化できるようにする包括的な推論オブザーバビリティ機能を提供します。このソリューションは SageMaker HyperPod Observability を介して実現し、推論ワークロードのパフォーマンスメトリクスを自動的に収集して、統合された PrometheusGrafana ダッシュボードで本番環境に対応するモニタリングを提供します。

メトリクスをデフォルトで有効にすると、プラットフォームは呼び出し遅延、同時リクエスト数、エラー率、トークンレベルのメトリクスなどの重要なモデルパフォーマンスデータをキャプチャし、カスタムオブザーバビリティソリューションの実装を希望するお客様に標準の Prometheus エンドポイントを提供します。

注記

このトピックでは、HyperPod クラスターでの推論オブザーバビリティの実装について詳しく説明します。一般的なリファレンスについては、「クラスターとタスクのオブザーバビリティ」を参照してください。

このガイドでは、HyperPod クラスターで推論のオブザーバビリティを実装して使用するためのステップバイステップの手順を説明します。デプロイ YAML ファイルでメトリクスを設定して、ロール (管理者、データサイエンティスト、または機械学習エンジニア) に基づいてモニタリングダッシュボードにアクセスし、Prometheus エンドポイントを使用してカスタムオブザーバビリティソリューションと統合して、一般的なモニタリングの問題をトラブルシューティングする方法について説明します。

サポートされている推論メトリクス

呼び出しメトリクス

これらのメトリクスは、モデル推論のリクエストとレスポンスデータをキャプチャし、モデルタイプやサービングフレームワークを問わず、普遍的な可視性を提供します。推論メトリクスを有効にすると、これらのメトリクスは呼び出し時に計算され、モニタリングインフラストラクチャにエクスポートされます。

  • model_invocations_total - モデルへの呼び出しリクエストの合計数

  • model_errors_total - モデル呼び出し中のエラーの合計数

  • model_concurrent_requests - アクティブな同時モデルリクエスト数

  • model_latency_milliseconds - ミリ秒単位のモデル呼び出し遅延

  • model_ttfb_milliseconds - モデルの最初のバイトまでのレイテンシーのミリ秒単位の時間

モデルコンテナのメトリクス

これらのメトリクスは、トークン処理、キュー管理、フレームワーク固有のパフォーマンス指標など、モデルコンテナの内部オペレーションに関するインサイトを提供します。使用可能なメトリクスは、モデルのフレームワークによって異なります。

メトリクスのディメンション

すべての推論メトリクスには、デプロイ全体にわたる詳細なフィルタリングと分析を可能にする包括的なラベルが含まれています。

  • クラスターのアイデンティティ:

    • cluster_id - HyperPod クラスターの一意の ID

    • cluster_name - HyperPod クラスターの名前

  • リソースのアイデンティティ:

    • resource_name - デプロイ名 (「jumpstart-model-deployment」など)

    • resource_type - デプロイのタイプ (jumpstart、inference-endpoint)

    • namespace - マルチテナンシー用の Kubernetes 名前空間

  • モデルの特性:

    • model_name - 特定のモデル識別子 (「llama-2-7b-chat」など)

    • model_version - A/B テストとロールバック用のモデルのバージョン

    • model_container_type - サービス提供フレームワーク (TGI、LMI、-)

  • インフラストラクチャのコンテキスト:

    • pod_name - デバッグ用の個々のポッド識別子

    • node_name - リソース相関用の Kubernetes ノード

    • instance_type - コスト分析用の EC2 インスタンスタイプ

  • 運用のコンテキスト:

    • metric_source - 収集ポイント (リバースプロキシ、モデルコンテナ)

    • task_type - ワークロード分類 (推論)

デプロイ YAML でメトリクスを設定する

Amazon SageMaker HyperPod を使用すると、すべてのモデルデプロイでデフォルトで推論メトリクスを有効にして、追加の設定なしですぐにオブザーバビリティを取得できます。デプロイ YAML 設定を変更し、特定の要件に基づいてメトリクス収集を有効または無効にすることで、メトリクスの動作をカスタマイズできます。

JumpStart からモデルをデプロイする

次の YAML 設定を使用して、メトリクスを有効にした JuJumpStartmpStart モデルをデプロイします。

apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: JumpStartModel metadata: name:mistral-model namespace: ns-team-a spec: model: modelId: "huggingface-llm-mistral-7b-instruct" modelVersion: "3.19.0" metrics: enabled:true # Default: true (can be set to false to disable) replicas: 2 sageMakerEndpoint: name: "mistral-model-sm-endpoint" server: instanceType: "ml.g5.12xlarge" executionRole: "arn:aws:iam::123456789:role/SagemakerRole" tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/mistral-model/certs/

Amazon S3 または Amazon FSx からカスタムモデルとファインチューニングされたモデルをデプロイする

次の YAML を使用して、詳細なメトリクス設定でカスタム推論エンドポイントを設定します。

apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: JumpStartModel metadata: name:mistral-model namespace: ns-team-a spec: model: modelId: "huggingface-llm-mistral-7b-instruct" modelVersion: "3.19.0" metrics: enabled:true # Default: true (can be set to false to disable) replicas: 2 sageMakerEndpoint: name: "mistral-model-sm-endpoint" server: instanceType: "ml.g5.12xlarge" executionRole: "arn:aws:iam::123456789:role/SagemakerRole" tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/mistral-model/certs/ Deploy a custom inference endpoint Configure custom inference endpoints with detailed metrics settings using the following YAML: apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: inferenceendpoint-deepseeks namespace: ns-team-a spec: modelName: deepseeks modelVersion: 1.0.1 metrics: enabled: true # Default: true (can be set to false to disable) metricsScrapeIntervalSeconds: 30 # Optional: if overriding the default 15s modelMetricsConfig: port: 8000 # Optional: if overriding, it defaults to the WorkerConfig.ModelInvocationPort.ContainerPort within the InferenceEndpointConfig spec 8080 path: "/custom-metrics" # Optional: if overriding the default "/metrics" endpointName: deepseek-sm-endpoint instanceType: ml.g5.12xlarge modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: model-weights region: us-west-2 modelLocation: deepseek prefetchEnabled: true invocationEndpoint: invocations worker: resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 cpu: 25600m memory: 102Gi image: 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.32.0-lmi14.0.0-cu124 modelInvocationPort: containerPort: 8080 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model environmentVariables: ... tlsConfig: tlsCertificateOutputS3Uri: s3://hyperpod/inferenceendpoint-deepseeks4/certs/
注記

特定のデプロイのメトリクスを無効にするには、YAML 設定で metrics.enabled: false と指定します。

ロール別の推論ワークロードのモニタリングとトラブルシューティング

Amazon SageMaker HyperPod は、初期クラスターのセットアップから高度なパフォーマンスのトラブルシューティングまで、さまざまなユーザーワークフローをサポートする包括的なオブザーバビリティ機能を提供します。ロールとモニタリング要件に基づいて、次のガイダンスを使用します。

HyperPod 管理者

責任範囲: オブザーバビリティインフラストラクチャを有効にして、クラスター全体にわたってシステムヘルスを確保します。

注意事項:

  • クラスター全体のオブザーバビリティは、すべてのワークロードのインフラストラクチャメトリクスを提供します。

  • ワンクリックセットアップは、事前設定されたダッシュボードを使用してモニタリングスタックをデプロイします。

  • インフラストラクチャメトリクスはモデル固有の推論メトリクスとは別です。

必須事項:

  1. HyperPod コンソールに移動します。

  2. クラスターを選択します。

  3. 先ほど作成した HyperPod クラスターの詳細ページに移動します。HyperPod オブザーバビリティアドオンをインストールする新しいオプションが表示されます。

  4. [クイックインストール] オプションをクリックします。1~2 分後、すべてのステップが完了し、Grafana ダッシュボードと Prometheus ワークスペースの詳細が表示されます。

このように、単一のアクションで、EKS アドオンを自動的にデプロイし、オブザーバビリティ演算子を設定して、Grafana で構築済みのダッシュボードをプロビジョンできます。

データサイエンティスト

責任範囲: モデルを効率的にデプロイし、基本的なパフォーマンスをモニタリングします。

注意事項:

  • メトリクスは、モデルのデプロイ時に自動的に有効になります。

  • Grafana ダッシュボードは、モデルのパフォーマンスを直ちに可視化します。

  • ダッシュボードをフィルタリングすると、特定のデプロイに集中できます。

必須事項:

  1. モデルは、任意の方法を使用してデプロイできます。

    1. Amazon SageMaker Studio UI

    2. HyperPod CLI コマンド

    3. ノートブックの Python SDK

    4. YAML 設定を使用した kubectl

  2. モデルメトリクスへのアクセス:

    1. Amazon SageMaker Studio を開きます。

    2. HyperPod クラスターに移動し、Grafana ダッシュボードを開きます。

    3. 推論ダッシュボードを選択します。

    4. フィルターを適用して、特定のモデルデプロイを表示します。

  3. 重要なパフォーマンス指標のモニタリング:

    1. モデルのレイテンシーとスループットを追跡します。

    2. エラー率と可用性をモニタリングします。

    3. リソース使用率の傾向を確認します。

これが完了すると、追加の設定なしでモデルのパフォーマンスをすぐに可視化できるため、デプロイの問題やパフォーマンスの変化を迅速に特定できます。

機械学習エンジニア (MLE)

責任範囲: 本番稼働用モデルのパフォーマンスを維持し、複雑なパフォーマンスの問題を解決します。

注意事項:

  • 高度なメトリクスには、キューの深さやトークンメトリクスなどのモデルコンテナの詳細などがあります。

  • 複数のメトリクスタイプにわたる相関分析により根本原因が明らかになります。

  • オートスケーリング設定は、トラフィックのスパイク時にパフォーマンスに直接影響を及ぼします。

架空のシナリオ: 顧客のチャットモデルで断続的に応答が遅くなります。約 5~10 秒の遅延についての苦情がユーザーから寄せられています。MLE は、推論オブザーバビリティを活用して、体系的なパフォーマンス調査を行うことができます。

必須事項:

  1. Grafana ダッシュボードを調べて、パフォーマンスの問題の範囲と重大度を把握します。

    1. 午前 9 時 30 分から高レイテンシーアラートがアクティブです。

    2. P99 レイテンシー: 8.2 秒 (通常: 2.1 秒)

    3. 影響を受けた時間枠: 09:30~10:15 (45 分)

  2. 複数のメトリクスを関連付けて、インシデント中のシステム動作を把握します。

    1. 同時リクエスト数: 最高 45 までのスパイク (通常: 15~20)

    2. ポッドスケーリング: インシデント中に KEDA が 2 から 5 にポッドをスケーリング

    3. GPU 使用率: 正常のまま (85~90%)

    4. メモリ使用量: 通常 (24 GB/32 GB)

  3. インフラストラクチャメトリクスは正常と思われるため、分散システムの動作を調べます。

    1. ノードレベルビュー: 同じノードに集中しているすべてのポッド (分散不良)

    2. モデルコンテナメトリクス: TGI キューの深さは 127 件のリクエストを示す (通常: 5~10)

    Available in Grafana dashboard under "Model Container Metrics" panel Metric: tgi_queue_size{resource_name="customer-chat-llama"} Current value: 127 requests queued (indicates backlog)
  4. 相互接続された設定の問題を特定する:

    1. KEDA スケーリングポリシー: 遅すぎる (30 秒のポーリング間隔)

    2. スケーリングタイムライン: トラフィックの急増から 45 秒以上遅延したスケーリングレスポンス

  5. 分析に基づいて、ターゲットを絞った修正を実装します。

    1. 更新された KEDA ポーリング間隔: 30 秒 → 15 秒

    2. スケーリング設定での maxReplicas の増加

    3. スケーリングしきい値を調整して早期にスケーリング (同時リクエスト 15 件と 20 件の比較)

包括的なメトリクスを使用して複雑なパフォーマンス問題を体系的に診断し、的を絞った修正を実装することで、一貫した本番稼働用モデルのパフォーマンスを維持するための予防策を確立できます。

独自のオブザーバビリティ統合を実装する

Amazon SageMaker HyperPod は、業界標準の Prometheus エンドポイントを介して推論メトリクスを公開するため、既存のオブザーバビリティインフラストラクチャと統合できます。組み込みの Grafana および Prometheus スタックを使用する代わりに、カスタムモニタリングソリューションを実装したり、サードパーティーのオブザーバビリティプラットフォームと統合したりする場合は、このアプローチを使用します。

推論メトリクスエンドポイントにアクセスする

注意事項:

  • 推論メトリクスは標準化された Prometheus エンドポイントに自動的に公開されます

  • メトリクスは、モデルタイプやサービングフレームワークを問わず使用できます。

  • データ収集には、標準 Prometheus スクレイピング方法が適用されます。

推論メトリクスのエンドポイント設定:

  • ポート: 9113

  • パス: /metrics

  • 完全なエンドポイント: http://pod-ip:9113/metrics

利用可能な推論メトリクス:

  • model_invocations_total - モデルへの呼び出しリクエストの合計数

  • model_errors_total - モデル呼び出し中のエラーの合計数

  • model_concurrent_requests - モデルあたりのアクティブな同時リクエスト数

  • model_latency_milliseconds - ミリ秒単位のモデル呼び出し遅延

  • model_ttfb_milliseconds - モデルの最初のバイトまでのレイテンシーのミリ秒単位の時間

モデルコンテナのメトリクスへのアクセス

注意事項:

  • モデルコンテナは、使用するフレームワークに固有の追加のメトリクスを公開します。

  • これらのメトリクスは、トークン処理やキューの深さなどの内部コンテナについてのインサイトを提供します。

  • エンドポイント設定はモデルコンテナタイプによって異なります。

Text Generation Inference (TGI) コンテナを使用した JumpStart モデルデプロイの場合:

Large Model Inference (LMI) コンテナを使用した JumpStart モデルデプロイの場合:

カスタム推論エンドポイント (BYOD) の場合:

  • ポート: お客様の設定 (デフォルトは 8080 WorkerConfig.ModelInvocationPort.ContainerPort within the InferenceEndpointConfig spec のデフォルト)

  • パス: お客様の設定 (default /metrics)

カスタムオブザーバビリティ統合を実装する

カスタムオブザーバビリティ統合でお客様が担う責任は、以下のとおりです。

  1. メトリクススクレイピング: 上記のエンドポイントから Prometheus 互換のスクレイピングを実装する

  2. データエクスポート: 選択したオブザーバビリティプラットフォームへのエクスポートを設定する

  3. アラート: 運用要件に基づいてアラートルールを設定する

  4. ダッシュボード: モニタリングニーズに合わせて可視化ダッシュボードを作成する

推論オブザーバビリティの問題のトラブルシューティング

ダッシュボードにデータが表示されません

Grafana ダッシュボードが空で、すべてのパネルに「データなし」と表示されている場合は、次の手順を実行して調査します。

  1. 推論オブザーバビリティがインストールされていることを管理者に確認します。

    1. HyperPod コンソールに移動してクラスターを選択し、「オブザーバビリティ」ステータスが「有効」と表示されているかを確認します。

    2. Grafana ワークスペースリンクがクラスターの概要からアクセス可能であることを確認します。

    3. Amazon Managed Prometheus ワークスペースが設定され、データを受信しているこを確認します。

  2. HyperPod オブザーバビリティが有効になっていることを確認します。

    hyp observability view
  3. 次のとおり、モデルメトリクスが有効になっていることを検証します。

    kubectl get jumpstartmodel -n <namespace> customer-chat-llama -o jsonpath='{.status.metricsStatus}' # Expected: enabled: true, state:Enabled
    kubectl get jumpstartmodel -n <namespace> customer-chat-llama -o jsonpath='{.status.metricsStatus}' # Expected: enabled: true, state:Enabled
  4. メトリクスエンドポイントを確認します。

    kubectl port-forward pod/customer-chat-llama-xxx 9113:9113 curl localhost:9113/metrics | grep model_invocations_total# Expected: model_invocations_total{...} metrics
  5. ログを確認します。

    # Model Container kubectl logs customer-chat-llama-xxx -c customer-chat-llama# Look for: OOM errors, CUDA errors, model loading failures # Proxy/SideCar kubectl logs customer-chat-llama-xxx -c sidecar-reverse-proxy# Look for: DNS resolution issues, upstream connection failures # Metrics Exporter Sidecar kubectl logs customer-chat-llama-xxx -c otel-collector# Look for: Metrics collection issues, export failures

その他の一般的な問題

問題 ソリューション Action

推論オブザーバビリティがインストールされていない

コンソールを使用して推論オブザーバビリティをインストールする

HyperPod コンソールで「オブザーバビリティを有効にする」

モデルでメトリクスが無効になっている

モデルの設定を更新する

モデル仕様に metrics: {enabled: true} を追加する

AMP ワークスペースが設定されていない

データソース接続を修正する

Grafana データソースで AMP ワークスペース ID を検証する

ネットワーク接続

セキュリティグループ/NACL を確認する

ポッドが AMP エンドポイントに到達できることを確認する