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

オブザーバビリティ

モニタリングとオブザーバビリティ

GPU メトリクスの説明

GPU 使用率メトリクスは、GPU がサンプルウィンドウ中に何らかの作業を実行したかどうかを示します。このメトリクスは、GPU が少なくとも 1 つの命令を実行した時間の割合をキャプチャしますが、GPU がハードウェアをどれだけ効率的に使用したかはわかりません。GPU には、命令を実行する並列処理ユニットである複数のストリーミングマルチプロセッサ (SMs) が含まれています。使用率が 100% の読み取りは、GPU がすべての SMs で大量の並列ワークロードを実行したことを意味するか、1 つの小さな命令がサンプル期間中に GPU をアクティブ化したことを意味する可能性があります。実際の使用率を理解するには、複数のレベルのハードウェアアーキテクチャで GPU メトリクスを調べる必要があります。各ストリーミングマルチプロセッサは異なるコアタイプから構築され、各レイヤーは異なるパフォーマンス特性を公開します。最上位メトリクス (GPU 使用率、メモリ使用率、GPU Power、GPU 温度、nvidia-smi を介して表示) は、デバイスがアクティブかどうかを示します。より深いメトリクス (SM 使用率、SM アクティビティ、テンソルコア使用率) により、GPU がリソースをどの程度効率的に使用するかがわかります。

GPU の高電力使用量をターゲットにする

使用率の低い GPUs、ワークロードがすべての GPU コンポーネントを同時にエンゲージできないため、コンピューティング容量を浪費し、コストが増加します。Amazon EKS の AI/ML ワークロードの場合、実際の GPU アクティビティを識別するためのプロキシとして GPU の電力使用量を追跡します。GPU 使用率は、GPU がカーネルを実行する時間の割合を報告しますが、ストリーミングマルチプロセッサ、メモリコントローラー、テンソルコアがすべて同時にアクティブであるかどうかは明らかにしません。電力使用量は、完全にエンゲージされたハードウェアが、軽量カーネルを実行しているハードウェアやタスク間でアイドル状態になっているハードウェアよりも大幅に多くの電力を消費するため、このギャップを公開します。GPU の熱設計能力 (TDP) と消費電力を比較して使用率の低さを特定し、ワークロードが CPU 前処理、ネットワーク I/O、非効率的なバッチサイズによってボトルネックになっているかどうかを調査します。

Amazon EKS で CloudWatch Container Insights を設定して、GPU の電力消費量が低いポッド、ノード、またはワークロードを特定します。このツールは Amazon EKS と直接統合されており、GPU の電力消費量をモニタリングし、電力使用量がターゲットレベルを下回ったときにポッドスケジューリングまたはインスタンスタイプを調整できます。高度な視覚化またはカスタムダッシュボードが必要な場合は、NVIDIA の DCGM-Exporter with Prometheus と Grafana for Kubernetes ネイティブモニタリングを使用します。どちらのアプローチもnvidia_smi_power_draw、 (GPU の電力消費量) や nvidia_smi_temperature_gpu (GPU 温度) などの主要な NVIDIA メトリクスを表しています。メトリクスのリストについては、https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.htm を参照してください。特定の時間、または特定のジョブで一貫して低い電力使用量などのパターンを探します。これらの傾向は、ワークロードを統合する場所やリソース割り当てを調整する場所を特定するのに役立ちます。

Kubernetes の静的リソース制限 (CPU、メモリ、GPU 数など) は、特に需要が変動する推論などの動的な AI/ML ワークロードでは、過剰プロビジョニングや使用率の低下につながることがよくあります。使用率の傾向を分析し、ワークロードをより少ない GPUs に統合します。追加の GPU を割り当てる前に、各 GPU がフル使用率に達していることを確認します。このアプローチにより、無駄が減り、コストが削減されます。スケジューリングと共有戦略の最適化に関する詳細なガイダンスについては、「EKS Compute and Autoscaling best practices」を参照してください。

オブザーバビリティとメトリクス

AI/ML ワークロードのモニタリングおよびオブザーバビリティツールの使用

最新の AI/ML サービスでは、インフラストラクチャ、モデリング、アプリケーションロジック間の調整が必要です。プラットフォームエンジニアは、インフラストラクチャとオブザーバビリティスタックを管理します。メトリクスを収集、保存、視覚化します。AI/ML エンジニアは、モデル固有のメトリクスを定義し、さまざまな負荷とデータ分散の下でパフォーマンスをモニタリングします。アプリケーション開発者APIs を消費し、リクエストをルーティングし、サービスレベルのメトリクスとユーザーインタラクションを追跡します。統一されたオブザーバビリティプラクティスがない場合、これらのチームはサイロで作業し、システムのヘルスとパフォーマンスに関する重要なシグナルを見逃します。環境間で共有可視性を確立することで、すべてのステークホルダーが問題を早期に検出し、信頼性の高いサービスを維持できます。

AI/ML ワークロード用の Amazon EKS クラスターの最適化には、特に GPU メモリ管理に関する固有のモニタリング課題があります。適切なモニタリングを行わないと、組織はout-of-memory (OOM) エラー、リソースの非効率性、不要なコストに直面します。効果的なモニタリングにより、EKS 顧客のパフォーマンス、耐障害性、コスト削減が向上します。3 つのモニタリングレイヤーを組み合わせた包括的なアプローチを使用します。まず、NVIDIA DCGM Exporter を使用して詳細な GPU メトリクスをモニタリングし、GPU 電力使用量、GPU 温度、SM アクティビティ、SM 占有率、XID エラーを追跡します。次に、Ray や vLLM などの推論サービスフレームワークをモニタリングして、ネイティブメトリクスを通じて分散ワークロードのインサイトを取得します。3 つ目は、アプリケーションレベルのインサイトを収集して、ワークロードに固有のカスタムメトリクスを追跡することです。このレイヤードアプローチにより、アプリケーションのパフォーマンスを通じてハードウェア使用率を可視化できます。

ツールとフレームワーク

いくつかのツールとフレームワークは、AI/ML ワークロードをモニタリングするためのネイティブout-of-the-boxメトリクスを提供します。これらの組み込みメトリクスにより、カスタム計測が不要になり、セットアップ時間が短縮されます。メトリクスは、レイテンシー、スループット、トークン生成などのパフォーマンスの側面に焦点を当てており、推論の提供とベンチマークに不可欠です。ネイティブメトリクスを使用すると、カスタムコレクションパイプラインを構築せずに、すぐにモニタリングを開始できます。

オブザーバビリティメソッド

次のいずれかの方法で追加のオブザーバビリティメカニズムを実装することをお勧めします。

CloudWatch Container Insights 組織が最小限のセットアップで AWS ネイティブツールを希望する場合は、CloudWatch Container Insights をお勧めします。NVIDIA DCGM Exporter と統合して GPU メトリクスを収集し、インサイトをすばやく得るための構築済みのダッシュボードを提供します。クラスターに CloudWatch Observability アドオンをインストールすることで、Container Insights は NVIDIA DCGM Exporter のライフサイクルをデプロイおよび管理し、Nvidia のドライバーから GPU メトリクスを収集して CloudWatch に公開します。

Container Insights をインストールすると、CloudWatch は環境内の NVIDIA GPUs を自動的に検出し、重要なヘルスとパフォーマンスのメトリクスを収集します。これらのメトリクスは、厳選されたout-of-the-boxダッシュボードに表示されます。Unified CloudWatch エージェントを使用して Ray と vLLM を CloudWatch と統合し、ネイティブメトリクスを送信することもできます。 CloudWatch この統一されたアプローチにより、EKS 環境でのオブザーバビリティが簡素化され、チームはモニタリングインフラストラクチャを構築するのではなく、パフォーマンスの調整とコストの最適化に集中できます。

使用可能なメトリクスの完全なリストについては、「Amazon EKS および Kubernetes Container Insights メトリクス」を参照してください。GPU モニタリングの実装に関するstep-by-stepガイダンスについては、Amazon CloudWatch Container Insights を使用した NVIDIA GPU ワークロードの運用上のインサイトの取得」を参照してください。推論レイテンシーを最適化する実用的な例については、「AI 応答性の最適化: Amazon Bedrock レイテンシー最適化推論の実用的なガイド」を参照してください。

Managed Prometheus と Grafana カスタマイズされたダッシュボードと高度な可視化機能が必要な場合は、NVIDIA DCGM-Exporter と Grafana for Kubernetes ネイティブモニタリングを使用して Prometheus をデプロイします。Prometheus は DCGM-Exporter から GPU メトリクスをスクレイピングして保存し、Grafana は柔軟な視覚化とアラート機能を提供します。このアプローチにより、CloudWatch Container Insights と比較して、ダッシュボードの設計とメトリクスの保持をより細かく制御できます。

Ray、vLLM Ray、vLLM などのオープンソースフレームワークを統合しhttps://awslabs.github.io/ai-on-eks/docs/blueprints/inference/GPUs/vLLM-rayserveてネイティブメトリクスを Prometheus にエクスポートすることで、このモニタリングスタックを拡張できます。Grafana を AWS X-Ray データソースに接続して分散トレースを視覚化し、推論パイプライン全体のパフォーマンスのボトルネックを特定することもできます。この組み合わせにより、アプリケーションレベルのリクエストフローを通じて GPU レベルのメトリクスからend-to-endの可視性が得られます。

このモニタリングスタックのデプロイに関するstep-by-stepガイダンスについては、「AWS マネージドオープンソースサービスを使用した Amazon EKS での GPU ワークロードのモニタリング」を参照してください。

コアトレーニングとファインチューニングメトリクスのモニタリングを検討する

コアトレーニングメトリクスをモニタリングして、Amazon EKS クラスターとそのクラスターで実行されている機械学習ワークロードの状態とパフォーマンスを追跡します。トレーニングワークロードは、長期間実行され、リソースの消費が異なり、モデルの収束とデータパイプラインの効率を可視化する必要があるため、推論ワークロードとは異なるモニタリング要件があります。以下のメトリクスは、ボトルネックを特定し、リソース割り当てを最適化し、トレーニングジョブを正常に完了させるのに役立ちます。このモニタリングアプローチを実装するためのstep-by-stepガイダンスについては、「Amazon EKS での機械学習ワークロードのモニタリングの概要」を参照してください。

リソース使用状況メトリクス

リソース使用状況メトリクスをモニタリングして、リソースが適切に消費されていることを確認します。これらのメトリクスは、ボトルネックと根本原因のパフォーマンス問題を特定するのに役立ちます。

モデルパフォーマンスメトリクス

モデルパフォーマンスメトリクスをモニタリングして、トレーニングプロセスが精度とビジネス要件を満たすモデルを生成することを確認します。これらのメトリクスは、トレーニングを停止するタイミングの決定、モデルバージョンの比較、パフォーマンスの低下の特定に役立ちます。

データ品質とドリフトのメトリクス

データ品質とドリフトメトリクスをモニタリングして、トレーニングデータの一貫性と代表性を維持します。データドリフトにより、時間の経過とともにモデルのパフォーマンスが低下する可能性がありますが、データ品質の問題により、モデルが収束したり、信頼できない結果を生成したりする可能性があります。

レイテンシーとスループットのメトリクス

レイテンシーとスループットのメトリクスをモニタリングして、トレーニングパイプラインのボトルネックを特定し、リソース使用率を最適化します。これらのメトリクスは、トレーニング中に費やす時間と最適化作業の焦点を理解するのに役立ちます。

エラー率と失敗

トレーニングパイプライン全体でエラー率と障害をモニタリングして、信頼性を維持し、無駄なコンピューティングリソースを防止します。検出されないエラーにより、トレーニングジョブがサイレントに失敗したり、無効なモデルを生成したり、問題に気付くまでに GPU 時間を浪費したりする可能性があります。

Kubernetes および EKS 固有のメトリクス

Kubernetes および EKS メトリクスをモニタリングして、クラスターインフラストラクチャが正常であり、トレーニングワークロードをサポートできることを確認します。これらのメトリクスは、トレーニングジョブの障害やパフォーマンスの低下を引き起こす前に、インフラストラクチャの問題を検出するのに役立ちます。

アプリケーションログとインスタンスログ

アプリケーションログとインスタンスログを収集して分析し、メトリクスだけでは説明できない問題を診断します。ログは、エラー、状態変更、システムイベントに関する詳細なコンテキストを提供し、トレーニングジョブが失敗したり、パフォーマンスが低下したりする理由を理解するのに役立ちます。ログをメトリクスと関連付けることで、根本原因をより迅速に特定できます。

以下のセクションでは、CloudWatch Container Insights と Amazon Managed Grafana を使用した Amazon Managed Prometheus の 2 つの AWS 推奨アプローチを使用して、上記のメトリクスを収集する方法を示します。最小限のセットアップと事前構築されたダッシュボードで AWS ネイティブツールを使用する場合は、CloudWatch Container Insights を選択します。カスタマイズされたダッシュボード、高度な視覚化機能が必要な場合、または既存の Prometheus ベースのモニタリングインフラストラクチャと統合する場合は、Amazon Managed Grafana で Amazon Managed Prometheus を選択します。使用可能な Container Insights メトリクスの完全なリストについては、「Amazon EKS および Kubernetes Container Insights メトリクス」を参照してください。

リアルタイムオンライン推論メトリクスのモニタリングを検討する

リアルタイムシステムでは、ユーザーやその他の依存システムにタイムリーな応答を提供するには、低レイテンシーが不可欠です。レイテンシーが高いと、ユーザーエクスペリエンスが低下したり、パフォーマンス要件に違反する可能性があります。推論レイテンシーに影響するコンポーネントには、モデルのロード時間、前処理時間、実際の予測時間、後処理時間、ネットワーク送信時間などがあります。推論レイテンシーをモニタリングして、サービスレベルアグリーメント (SLAs) を満たす低レイテンシーのレスポンスを確保し、以下のカスタムメトリクスを開発することをお勧めします。予想される負荷でテストし、ネットワークレイテンシーを含め、同時リクエストを考慮し、さまざまなバッチサイズでテストします。

K/V (キー/値) キャッシュは、推論レイテンシーの強力な最適化手法であり、特にトランスフォーマーベースのモデルに関連します。K/V キャッシュは、以前のトランスフォーマーレイヤー計算のキーテンソルと値テンソルを保存し、特に大規模言語モデル (LLMs。キャッシュ効率メトリクス (特に K/V またはセッションキャッシュの使用):

以降のトピックでは、上記のメトリクスのデータを収集する方法について説明します。AWS が推奨する 2 つのアプローチの例を示します。AWS ネイティブの CloudWatch Container Insights と Amazon Managed Grafana を使用したオープンソースの Amazon Managed Prometheus です。 https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html全体的なオブザーバビリティのニーズに基づいて、これらのソリューションのいずれかを選択します。Container Insights メトリクスの完全なリストについては、「Amazon EKS および Kubernetes Container Insights メトリクス」を参照してください。

GPU メモリ使用状況の追跡

コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、GPU メモリの使用量は、out-of-memory (OOM) エラーを防ぎ、効率的なリソース使用率を確保するために不可欠です。次の例は、トレーニングアプリケーションを計測してカスタムヒストグラムメトリクス を公開しgpu_memory_usage_bytes、P95 メモリ使用量を計算してピーク消費量を特定する方法を示しています。ステージング環境でサンプルトレーニングジョブ (トランスフォーマーモデルの微調整など) を使用してテストしてください。

AWS ネイティブ CloudWatch Container Insights の例

このサンプルでは、AWS ネイティブアプローチを使用してトレーニングアプリケーションを計測してヒストグラムgpu_memory_usage_bytesとして公開する方法を示します。AI/ML コンテナは、CloudWatch Embedded Metrics Format (EMF) 形式で構造化ログを出力するように設定する必要があります。CloudWatch ログは EMF を解析し、メトリクスを公開します。トレーニングアプリケーションで aws_embedded_metrics を使用して、構造化ログを EMF 形式で CloudWatch Logs に送信し、GPU メトリクスを抽出します。

from aws_embedded_metrics import metric_scope
import torch
import numpy as np

memory_usage = []

@metric_scope
def log_gpu_memory(metrics):
    # Record current GPU memory usage
    mem = torch.cuda.memory_allocated()
    memory_usage.append(mem)

    # Log as histogram metric
    metrics.set_namespace("MLTraining/GPUMemory")
    metrics.put_metric("gpu_memory_usage_bytes", mem, "Bytes", "Histogram")

    # Calculate and log P95 if we have enough data points
    if len(memory_usage) >= 10:
        p95 = np.percentile(memory_usage, 95)
        metrics.put_metric("gpu_memory_p95_bytes", p95, "Bytes")
        print(f"Current memory: {mem} bytes, P95: {p95} bytes")

# Example usage in training loop
for epoch in range(20):
    # Your model training code would go here
    log_gpu_memory()

Prometheus と Grafana の例

このサンプルでは、Python の Prometheus クライアントライブラリを使用して、トレーニングアプリケーションを計測してヒストグラムgpu_memory_usage_bytes`として公開する方法を示します。

from prometheus_client import Histogram
from prometheus_client import start_http_server
import pynvml

start_http_server(8080)
memory_usage = Histogram(
    'gpu_memory_usage_bytes',
    'GPU memory usage during training',
    ['gpu_index'],
    buckets=[1e9, 2e9, 4e9, 8e9, 16e9, 32e9]
)

# Function to get GPU memory usage
def get_gpu_memory_usage():
    if torch.cuda.is_available():
        # Get the current GPU device
        device = torch.cuda.current_device()

        # Get memory usage in bytes
        memory_allocated = torch.cuda.memory_allocated(device)
        memory_reserved = torch.cuda.memory_reserved(device)

        # Total memory usage (allocated + reserved)
        total_memory = memory_allocated + memory_reserved

        return device, total_memory
    else:
        return None, 0

# Get GPU memory usage
gpu_index, memory_used = get_gpu_memory_usage()

リアルタイムオンライン推論の推論リクエスト期間を追跡する

コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、ユーザーやその他の依存システムにタイムリーな応答を提供するには、低レイテンシーが不可欠です。次の例は、推論アプリケーションによって公開されたカスタムヒストグラムメトリクス inference_request_duration_secondsを追跡する方法を示しています。95 パーセンタイル (P95) レイテンシーを計算してワーストケースのシナリオに焦点を当て、ステージング環境で合成推論リクエスト (Locust 経由など) でテストし、アラートしきい値 (>500ms など) を設定して SLA 違反を検出します。

AWS ネイティブ CloudWatch Container Insights の例

このサンプルでは、AWS CloudWatch Embedded Metric Format を使用して、推論アプリケーションで inference_request_duration_seconds のカスタムヒストグラムメトリクスを作成する方法を示します。

import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger

cloudwatch = boto3.client('cloudwatch')

@metric_scope
def log_inference_duration(metrics: MetricsLogger, duration: float):
    metrics.set_namespace("ML/Inference")
    metrics.put_metric("inference_request_duration_seconds", duration, "Seconds", "Histogram")
    metrics.set_property("Buckets", [0.1, 0.5, 1, 2, 5])

@metric_scope
def process_inference_request(metrics: MetricsLogger):
    start_time = time.time()

    # Your inference processing code here
    # For example:
    # result = model.predict(input_data)

    duration = time.time() - start_time
    log_inference_duration(metrics, duration)

    print(f"Inference request processed in {duration} seconds")

# Example usage
process_inference_request()

Prometheus と Grafana の例

このサンプルは、Python の Prometheus クライアントライブラリを使用して、推論アプリケーションで inference_request_duration_seconds のカスタムヒストグラムメトリクスを作成する方法を示しています。

from prometheus_client import Histogram
from prometheus_client import start_http_server
import time

start_http_server(8080)
request_duration = Histogram(
    'inference_request_duration_seconds',
    'Inference request latency',
    buckets=[0.1, 0.5, 1, 2, 5]
)
start_time = time.time()
# Process inference request
request_duration.observe(time.time() - start_time)

Grafana で、クエリを使用して P95 レイテンシーの傾向histogram_quantile(0.95, sum(rate(inference_request_duration_seconds_bucket[5m])) by (le, pod))を視覚化します。詳細については、「Prometheus ヒストグラムドキュメント」および「Prometheus クライアントドキュメント」を参照してください。

リアルタイムオンライン推論のトークンスループットを追跡する

コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、トークンの処理時間をモニタリングしてモデルのパフォーマンスを測定し、スケーリングの決定を最適化することをお勧めします。次の例は、推論アプリケーションによって公開されたカスタムヒストグラムメトリクス token_processing_duration_secondsを追跡する方法を示しています。95 パーセンタイル (P95) の期間を計算して処理効率を分析し、非本番稼働用クラスターでシミュレートされたリクエストロード (100～1000 リクエスト/秒など) でテストし、KEDA トリガーを調整してスケーリングを最適化します。

AWS ネイティブ CloudWatch Container Insights の例

このサンプルでは、AWS CloudWatch Embedded Metric Format を使用して token_processing_duration_seconds の推論アプリケーションでカスタムヒストグラムメトリクスを作成する方法を示します。ディメンション (「set_dimension) with a custom `get_duration_bucket 関数」を使用して、期間をバケット (「⇐0.01」、「>1」など) に分類します。

import boto3
import time
from aws_embedded_metrics import metric_scope, MetricsLogger

cloudwatch = boto3.client('cloudwatch')

@metric_scope
def log_token_processing(metrics: MetricsLogger, duration: float, token_count: int):
    metrics.set_namespace("ML/TokenProcessing")
    metrics.put_metric("token_processing_duration_seconds", duration, "Seconds")
    metrics.set_dimension("ProcessingBucket", get_duration_bucket(duration))
    metrics.set_property("TokenCount", token_count)

def get_duration_bucket(duration):
    buckets = [0.01, 0.05, 0.1, 0.5, 1]
    for bucket in buckets:
        if duration <= bucket:
            return f"<={bucket}"
    return f">{buckets[-1]}"

@metric_scope
def process_tokens(input_text: str, model, tokenizer, metrics: MetricsLogger):
    tokens = tokenizer.encode(input_text)
    token_count = len(tokens)

    start_time = time.time()
    # Process tokens (replace with your actual processing logic)
    output = model(tokens)
    duration = time.time() - start_time

    log_token_processing(metrics, duration, token_count)
    print(f"Processed {token_count} tokens in {duration} seconds")
    return output

Prometheus と Grafana の例

このサンプルは、Python の Prometheus クライアントライブラリを使用して token_processing_duration_seconds の推論アプリケーションでカスタムヒストグラムメトリクスを作成する方法を示しています。

from prometheus_client import Histogram
from prometheus_client import start_http_server
import time

start_http_server(8080)
token_duration = Histogram(
    'token_processing_duration_seconds',
    'Token processing time per request',
    buckets=[0.01, 0.05, 0.1, 0.5, 1]
)
start_time = time.time()
# Process tokens
token_duration.observe(time.time() - start_time)

Grafana で、 クエリを使用して P95 処理時間の傾向histogram_quantile(0.95, sum(rate(token_processing_duration_seconds_bucket[5m])) by (le, pod))`を視覚化します。詳細については、「Prometheus ヒストグラムドキュメント」および「Prometheus クライアントドキュメント」を参照してください。

チェックポイントの復元レイテンシーの測定

コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、チェックポイントレイテンシーはモデルライフサイクルの複数のフェーズにおける重要なメトリクスです。次の例は、アプリケーションによって公開されたカスタムヒストグラムメトリクス checkpoint_restore_duration_seconds`を追跡する方法を示しています。95 パーセンタイル (P95) の期間を計算して復元パフォーマンスをモニタリングし、非本番クラスターでスポット中断をテストし、アラートしきい値 (<30 秒など) を設定して遅延を検出します。

AWS ネイティブ CloudWatch Container Insights の例

このサンプルは、CloudWatch Insights を使用して checkpoint_restore_duration_seconds をヒストグラムとして公開するようにバッチアプリケーションを計測する方法を示しています。

import boto3
import time
import torch
from aws_embedded_metrics import metric_scope, MetricsLogger

@metric_scope
def log_checkpoint_restore(metrics: MetricsLogger, duration: float):
    metrics.set_namespace("ML/ModelOperations")
    metrics.put_metric("checkpoint_restore_duration_seconds", duration, "Seconds", "Histogram")
    metrics.set_property("Buckets", [1, 5, 10, 30, 60])
    metrics.set_property("CheckpointSource", "s3://my-bucket/checkpoint.pt")

@metric_scope
def load_checkpoint(model, checkpoint_path: str, metrics: MetricsLogger):
    start_time = time.time()

    # Load model checkpoint
    model.load_state_dict(torch.load(checkpoint_path))

    duration = time.time() - start_time
    log_checkpoint_restore(metrics, duration)

    print(f"Checkpoint restored in {duration} seconds")

Prometheus と Grafana の例

このサンプルは、Python の Prometheus クライアントライブラリを使用して、バッチアプリケーションを計測してヒストグラムcheckpoint_restore_duration_secondsとして公開する方法を示しています。

from prometheus_client import Histogram
from prometheus_client import start_http_server
import torch

start_http_server(8080)
restore_duration = Histogram(
    'checkpoint_restore_duration_seconds',
    'Time to restore checkpoint',
    buckets=[1, 5, 10, 30, 60]
)
with restore_duration.time():
    model.load_state_dict(torch.load("s3://my-bucket/checkpoint.pt"))

Grafana で、 クエリを使用して P95 復元レイテンシーの傾向histogram_quantile(0.95, sum(rate(checkpoint_restore_duration_seconds_bucket[5m]) by (le))を視覚化します。詳細については、「Prometheus ヒストグラムドキュメント」および「Prometheus クライアントドキュメント」を参照してください。