powered by TechFeed
表示モード
ハウツー

SageMakerの推論エンドポイントで「P99が急騰」したとき何が原因かを数分で切り分けられる — AWSが100種類以上のLLM監視メトリクスをCloudWatchに自動出力

6月19日、AWSが「Monitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatch」と題した記事を公開した。LLMを本番運用しているチームにとって、推論エンドポイントのP99レイテンシが急騰したとき、原因がGPUメモリ圧迫なのか、KVキャッシュの枯渇なのか、アベイラビリティゾーン(AZ)間のトラフィック偏在なのか、あるいはオートスケーリングポリシーの未発動なのかを数分以内に切り分けることは、かなりの難題だ。

6月19日、AWSが「Monitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatch」と題した記事を公開した。LLMを本番運用しているチームにとって、推論エンドポイントのP99レイテンシが急騰したとき、原因がGPUメモリ圧迫なのか、KVキャッシュの枯渇なのか、アベイラビリティゾーン(AZ)間のトラフィック偏在なのか、あるいはオートスケーリングポリシーの未発動なのかを数分以内に切り分けることは、かなりの難題だ。

AWSはこの課題に対し、100種類以上の詳細推論メトリクスをSageMakerエンドポイントから自動出力し、CloudWatchのSageMaker Insightsダッシュボードで一元可視化する仕組みを提供している。Grafanaの独自構築やPrometheusの設定が不要になる点が実用上の大きなメリットだ。


対象となる2つのエンドポイント構成

記事では、生成AIワークロードに関連する2つのエンドポイントアーキテクチャを対象としている。

  • シングルモデルエンドポイント(SME):1エンドポイントに1モデル。シンプルだが、モデルごとにGPUフリートが必要。
  • 推論コンポーネント(IC)エンドポイント:複数モデルが同一インスタンス群を共有。モデルごとの独立スケーリング、AZをまたいだコピー分散による高可用性(HA)をサポート。元記事では、生成AIワークロードにおける推奨アーキテクチャとして紹介されている。

詳細メトリクスの有効化

新規エンドポイント:デフォルトでON

新規作成するエンドポイント設定では、EnableDetailedObservabilityパラメータがデフォルトでtrueになっている。追加コードは不要だ。

import boto3

sm = boto3.client("sagemaker")

# 詳細メトリクスはデフォルトで有効
response = sm.create_endpoint_config(
    EndpointConfigName="my-llm-config",
    ProductionVariants=[{
        "VariantName": "primary",
        "InstanceType": "ml.g6.4xlarge",
        "InitialInstanceCount": 2,
        "ManagedInstanceScaling": {
            "Status": "ENABLED",
            "MinInstanceCount": 2,
            "MaxInstanceCount": 8
        }
    }],
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)

sm.create_endpoint(
    EndpointName="my-llm-endpoint",
    EndpointConfigName="my-llm-config"
)

エンドポイントがInService状態になってから2分以内に、OpenTelemetry形式のメトリクスがCloudWatchへ流れ始める。メトリクスの発行頻度はデフォルト60秒だが、MetricsPublishFrequencyInSecondsで短縮できる。

既存エンドポイント:明示的なオプトイン

既存エンドポイントに詳細メトリクスを有効化するには、MetricsConfigフラグを含む新しいエンドポイント設定を作成し、エンドポイントを更新する必要がある。元記事のコード例に基づくと、MetricsConfigcreate_endpoint_configの引数として渡す形になっている。

# 新しい設定を作成
sm.create_endpoint_config(
    EndpointConfigName="my-existing-config-v2",
    ProductionVariants=[{
        "VariantName": "primary",
        "ModelName": "my-existing-model",
        "InstanceType": "ml.g6.4xlarge",
        "InitialInstanceCount": 2
    }],
    MetricsConfig={"EnableDetailedObservability": True},
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)

# エンドポイントを更新
sm.update_endpoint(
    EndpointName="my-existing-endpoint",
    EndpointConfigName="my-existing-config-v2"
)

なお、既存のCloudWatchクラシックメトリクス(InvocationsModelLatencyなど)をInsightsダッシュボードやPromQLで参照するには、CloudWatchコンソールの設定画面でOTelメトリクスエンリッチメントを有効化する必要がある。これはアカウントとリージョン単位の一回限りの設定だ。


Insightsダッシュボードの3タブ構成

ダッシュボードはCloudWatchコンソールの「Infrastructure Monitoring → SageMaker Insights」から、またはSageMakerコンソールの各エンドポイントページから直接アクセスできる。フィルタが自動で適用されるため、空のダッシュボードから目的のリソースを探す手間がない。

Performanceタブ:レイテンシ起因の切り分けに特化

実運用で最も使うタブだ。色付きの六角形(ヘキサゴン)でフリート内の全リソースを可視化し、緑(正常)・白(アラームなし)・赤(アラーム発報中)で状態を一覧できる。ホバーするとTTFT(Time to First Token)、出力TPS、並行リクエスト数、KVキャッシュ利用率、CloudWatchアラームのステータスが表示される。

TTFTとITL(Inter-Token Latency、トークン間レイテンシ)はP50/P99を切り替えながら時系列で確認できる。TTFTのスパイクを検出したら、Latency breakdownパネルでモデルレイテンシとオーバーヘッドレイテンシに分解して原因を絞り込む。両者が正常にもかかわらずTTFTが高止まりする場合は、モデルの推論エンジンが内部キューでKVキャッシュスロット待ちをしている可能性がある。そのときはEngine and request pressureパネルでKVキャッシュ使用率を確認する。

KVキャッシュ(Key-Valueキャッシュ)とは、LLMのアテンション計算の中間結果を保持するGPUメモリ領域。これが枯渇するとリクエストがキュー待ちになり、TTFTが急増する。

ビジネスアワーにKVキャッシュ使用率が40〜50%を繰り返し超えるようなら、顧客に影響が出る前にオートスケーリングのトリガー閾値を引き下げる対処が有効だ。

vLLMおよびSGLangコンテナフレームワークを使用しているエンドポイントでのみ、TTFT・ITL・出力TPS・KVキャッシュのトークンレベルメトリクスが利用可能な点に注意が必要だ。

Capacityタブ:リソース配置の判断に使う

「追加でモデルを載せられるか?」を判断するためのタブだ。GPU、GPUメモリ、CPU、CPUメモリ、Diskの利用率をホバーカードで確認できる。GPUメモリが89%に達していれば、追加モデルの重みを載せるVRAMの余裕はほぼない。

時系列パネルでは以下のシグナルに注目する:

  • GPUメモリが数日かけて右肩上がり→ 容量限界が近い。先手でインスタンス追加を検討する
  • GPUメモリが突然低下→ モデルのクラッシュまたはアンロードを疑う
  • Diskが定期的にスパイク→ コールドスタート時のモデルダウンロードと相関している可能性が高い

Reliabilityタブ:高可用性とコールドスタートの診断

AZごとのインスタンスおよびICコピー数をバーチャートで確認できる。分布のリスク評価は以下のとおりだ。

分布状況 リスク 対処
3AZ以上に均等分散 対処不要
1〜2AZに集中 再バランス
いずれかのAZにインスタンスゼロ 単一AZ障害で全断

インスタンスは均等分散していても、ICコピーが特定マシンに偏っているケースがある。インスタンスとICコピーをトグルで切り替えて両方を確認する必要がある。


GrafanaやDatadogとの接続

SageMaker InsightsダッシュボードはCloudWatchネイティブだが、メトリクスはPromQL互換エンドポイント経由でもクエリ可能だ。CloudWatchはPrometheus互換のリモートリードエンドポイントを提供しており、GrafanaのデータソースとしてCloudWatch managed Prometheusスクレイピングを設定することで、既存のGrafanaダッシュボードから同じメトリクスを参照できる。DatadogなどPromQL対応のオブザーバビリティ基盤にも同様に接続できるため、既存の監視スタックを維持しながらSageMakerの詳細メトリクスを取り込む構成が可能だ。独自ダッシュボードを構築したいチームにとっても、メトリクス収集基盤として活用しやすい。


詳細はMonitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatchを参照していただきたい。