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

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

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

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

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

注記

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

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

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

呼び出しメトリクス

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

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

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

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

  • model_latency_milliseconds - ミリ秒単位のモデル呼び出しレイテンシー

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

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

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

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

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

  • クラスター ID:

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

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

  • リソース ID:

    • 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/v1alpha1 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/v1alpha1 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/v1alpha1 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 ワークスペースの詳細が表示されます。

この 1 つのアクションは、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. 09:30 から高レイテンシーアラートがアクティブ

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

    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 は、InferenceEndpointConfig 仕様内の WorkerConfig.ModelInvocationPort.ContainerPort です)。

  • パス: お客様が設定 (デフォルトの /metrics)

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

カスタムオブザーバビリティ統合では、以下の責任があります。

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

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

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

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

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

ダッシュボードにデータが表示されない

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

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

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

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

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

  2. HyperPod Observabilty が有効になっていることを確認します。

    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

その他の一般的な問題

問題 ソリューション アクション

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

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

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

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

モデル設定を更新する

モデル仕様metrics: {enabled: true}への の追加

AMP ワークスペースが設定されていません

データソース接続の修正

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

ネットワーク接続

セキュリティグループ/NACLs

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