翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
オブザーバビリティ
モニタリングとオブザーバビリティ
GPU 使用率の高いターゲット
使用率の低い GPUsは、割り当てられた GPU リソースがワークロードによって十分に活用されておらず、コンピューティング容量が浪費されていることを示します。Amazon EKS の AI/ML ワークロードでは、GPU 使用率をモニタリングして、GPU 使用率が高くなるようにし、リソース効率を最適化することをお勧めします。使用率の低い GPUsコンピューティング性能を浪費し、コストが増加しますが、オーバースケジューリングは競合やパフォーマンスの低下につながる可能性があります。
GPU 使用率メトリクスが低い特定のポッド、ノード、またはワークロードを特定するために、Amazon EKS で Cloudwatch Container Insights を設定することをお勧めします。Amazon EKS と簡単に統合できるため、GPU 使用率をモニタリングし、使用率がターゲットレベルを下回った場合にポッドスケジューリングまたはインスタンスタイプを調整できます。または、これが特定の要件 (高度な視覚化など) を満たさない場合は、NVIDIA の DCGM-Exporter を Prometheus および Grafana for Kubernetes ネイティブモニタリングと一緒に使用することを検討してください。どちらのアプローチでも GPU メトリクスに関するインサイトが得られ、使用率がターゲットレベルを下回った場合にポッドスケジューリングまたはインスタンスタイプを調整できます。DCGM-Exporter または CloudWatch を使用してnvidia_smi_utilization_gpu、 (GPU コンピューティングの使用状況) や nvidia_smi_utilization_memory (GPU メモリの使用状況) などの NVIDIA メトリクスを確認します。特定の時間、または特定のジョブで一貫して使用率が低いなどの傾向を探します。
Kubernetes の静的リソース制限 (CPU、メモリ、GPU 数など) は、特に推論などの動的な AI/ML ワークロードに対して、過剰プロビジョニングや使用率の低下につながる可能性があります。使用率の傾向を分析し、ワークロードを少数GPUs に統合して、新しい GPU を割り当てる前に各 GPU が完全に利用されるようにすることをお勧めします。GPUsされていない場合は、スケジューリングと共有を最適化するために次の戦略を検討してください。詳細については、EKS Compute and Autoscaling のベストプラクティスを参照してください。
オブザーバビリティとメトリクス
AI/ML ワークロードのモニタリングおよびオブザーバビリティツールの使用
最新の AI/ML サービスは、インフラストラクチャ、モデリング、アプリケーションロジックの交差点で動作します。プラットフォームエンジニアは、インフラストラクチャ、オブザーバビリティスタックを管理し、メトリクスが収集、保存、視覚化されるようにします。AI/ML エンジニアはモデル固有のメトリクスを定義し、さまざまな負荷と分散におけるパフォーマンスに焦点を当てます。アプリケーション開発者は、API を消費し、リクエストをルーティングし、サービスレベルのメトリクスとユーザーインタラクションを追跡します。成功は、すべての利害関係者にシステムのヘルスとパフォーマンスを可視化する環境全体で統一されたオブザーバビリティプラクティスを確立することに依存します。
AI/ML ワークロード用の Amazon EKS クラスターの最適化には、特に GPU メモリ管理に関する固有のモニタリング課題があります。適切なモニタリングを行わないと、組織は多くの場合、out-of-memory (OOM) エラー、リソースの非効率性、不要なコストに直面します。EKS のお客様にとって、効果的なモニタリングにより、パフォーマンス、レジリエンス、コスト削減が向上します。NVIDIA DCGM Exporter
ツールとフレームワーク
特定のツールやフレームワークは、AI/ML ワークロードをモニタリングするためのネイティブout-of-the-boxメトリクスを提供するため、追加のカスタムセットアップなしで簡単に統合できます。これらは、レイテンシー、スループット、トークン生成などのパフォーマンスの側面に焦点を当てています。これらは、推論の提供とベンチマークに不可欠です。以下に例を示します。
-
vLLM: リクエストのレイテンシーやメモリ使用量などのネイティブメトリクスを提供する、大規模言語モデル (LLMs用の高スループットサービスエンジン。
-
Ray: タスクの実行時間やリソース使用率など、スケーラブルな AI ワークロードのメトリクスを出力する分散コンピューティングフレームワーク。
-
Hugging Face Text Generation Inference (TGI): LLMsデプロイして提供するためのツールキット。推論パフォーマンスのメトリクスが組み込まれています。
-
NVIDIA genai-perf: 生成 AI モデルをベンチマークし、スループット、レイテンシー、特定の時間間隔で完了したリクエストなどの LLM 固有のメトリクスを測定するためのコマンドラインツールです。
オブザーバビリティの方法
次のいずれかの方法で追加のオブザーバビリティメカニズムを実装することをお勧めします。
CloudWatch Container Insights 組織が最小限のセットアップで AWS ネイティブツールを希望する場合は、CloudWatch Container Insights をお勧めします。NVIDIA DCGM Exporter
Container Insights にオンボーディングされると、CloudWatch は環境内の NVIDIA GPUs を自動的に検出し、NVIDIA GPUs の重要なヘルスとパフォーマンスのメトリクスを CloudWatch メトリクスとして収集し、厳選されたout-of-the-box使えるダッシュボードで利用できるようにします。さらに、Ray https://docs.ray.io/en/latest/cluster/vms/user-guides/launching-clusters/aws.html
詳細については、「Amazon EKS and Kubernetes Container Insights metrics」を参照してください。Amazon Amazon CloudWatch Container Insights を使用した NVIDIA GPU ワークロードの運用上のインサイト
Managed Prometheus と Grafana 組織がオープンソースツールとカスタマイズされたダッシュボードに慣れている場合は、NVIDIA DCGM-Exporter
さらに、Ray や vLLM
詳細については、「AWS マネージドオープンソースサービスを使用した Amazon EKS での GPU ワークロードのモニタリング
コアトレーニングとファインチューニングメトリクスのモニタリングを検討する
EKS 上の AI/ML ワークロードのコアトレーニングメトリクスについては、Amazon EKS クラスターとそれで実行されている機械学習ワークロードの状態とパフォーマンスを示すメトリクスの組み合わせを検討してください。詳細な実装については、「Introduction to observing machine learning workloads on Amazon EKS
リソース使用状況メトリクス：
-
CPU、メモリ、GPU、GPU メモリ使用量 — ML ワークロードのこれらのメトリクスをモニタリングすることで、割り当てられたリソースが十分であることを確認し、最適化の機会を特定できます。例えば、 などのメトリクスを追跡すると
gpu_memory_usage_bytes、メモリ消費パターンを識別し、ピーク使用量を検出し、95 パーセンタイル (P95) などのパーセンタイルを計算して、トレーニング中に最も高いメモリ需要を把握できます。これにより、モデルとインフラストラクチャを最適化して OOM エラーを回避し、コストを削減できます。 -
ノードとポッドのリソース使用率 — ノードとポッドレベルでリソースの使用状況を追跡することで、リソースの競合と潜在的なボトルネックを特定できます。たとえば、ポッドのスケジュールに影響する可能性のあるノードが過剰に使用されているかどうかを確認します。
-
リソース使用率とリクエストと制限の比較 — これにより、クラスターが現在のワークロードを処理し、将来のワークロードに対応できるかどうかに関するインサイトが得られます。たとえば、メモリout-of-memoryエラーを避けるために、実際のメモリ使用量と制限を比較します。
-
ML フレームワークの内部メトリクス — 損失曲線、学習率、バッチ処理時間、トレーニングステップ期間など、ML フレームワーク (TensorFlow、PyTorch) の内部トレーニングと収束メトリクスをキャプチャします。多くの場合、TensorBoard などで視覚化されます。
モデルパフォーマンスメトリクス：
-
精度、精度、リコール、F1-score — ML モデルのパフォーマンスを理解するために不可欠です。例えば、トレーニング後、検証セットの F1-scoreを計算してパフォーマンスを評価します。
-
ビジネス固有のメトリクスと KPIs — AI/ML イニシアチブのビジネス価値に直接リンクされたメトリクスを定義して追跡します。たとえば、レコメンデーションシステムでは、ユーザーエンゲージメントの増加を追跡します。
-
これらのメトリクスを経時的に追跡する — これにより、モデルのパフォーマンスの低下を特定できます。たとえば、モデルバージョン間でパフォーマンスメトリクスを比較して、傾向を特定します。
データ品質とドリフトのメトリクス：
-
入力データの統計プロパティ — これらを経時的にモニタリングして、モデルのパフォーマンスに影響を与える可能性のあるデータドリフトや異常を検出します。たとえば、入力機能の平均を追跡してシフトを検出します。
-
データドリフトの検出とアラート — データ品質の問題を自動的に検出して警告するメカニズムを実装します。たとえば、テストを使用して現在のデータとトレーニングデータを比較し、大きなドリフトをアラートします。
レイテンシーとスループットのメトリクス：
-
ML トレーニングパイプラインのEnd-to-Endのレイテンシー — データがトレーニングパイプライン全体を通過するのにかかる時間をモニタリングします。たとえば、データ取り込みからモデル更新までの合計時間を測定します。
-
トレーニングスループットと処理レート — トレーニング中に処理されたデータの量を追跡して、効率を確保します。たとえば、1 秒あたりに処理される正のサンプルと負のサンプルを監視します。
-
チェックポイントの復元レイテンシー – ジョブの再開、障害からの復旧、または初期化時に、保存されたモデルチェックポイントをストレージの場所 (S3、EFS、FSx など) から GPU/CPU メモリにロードするのにかかった時間をモニタリングします。このメトリクスは、ジョブの復旧時間、コールドスタートのパフォーマンス、干渉パイプラインの全体的な効率に直接影響します。自動スケーリング推論サービスでは、チェックポイントのロードが遅いと、コールドスタートの遅延やユーザーエクスペリエンスの低下が発生する可能性があります。これらの関連メトリクスは、チェックポイントのダウンタイムレイテンシー、モデルの逆シリアル化時間、チェックポイントサイズ、チェックポイント復元失敗数など、モデルチェックポイントの改善にも一般的に使用されます。
-
推論リクエストの期間 – 推論リクエストの完了にかかる時間をモニタリングします。これは、最初のリクエストが受信されてからモデルからのレスポンスが完了するまでの時間です。
-
トークンスループット - トークンの処理時間をモニタリングしてモデルのパフォーマンスを測定し、スケーリングの決定を最適化します。処理が遅いと、非効率性やリソースの使用率が低くなり、費用対効果に影響する可能性があります。1 秒あたりのトークン数や 1 秒あたりのトークン数などの追跡メトリクスは、処理時間とともに、パフォーマンスのボトルネック、速度低下、コストドライバーを特定するのに役立ちます。
-
パフォーマンスのボトルネックの特定 — これらのメトリクスを使用して、トレーニングプロセスで最適化すべき領域を特定します。たとえば、データのロードに費やされた時間とモデル計算を分析できます。
エラー率と失敗：
-
ML パイプライン全体のエラーのモニタリング — これには、データの前処理、モデルトレーニング、推論が含まれます。たとえば、問題をすばやく特定するために、前処理でエラーをログに記録します。
-
定期的なエラーの特定と調査 — これにより、高品質のモデルを維持し、一貫したパフォーマンスを確保できます。たとえば、ログを分析して、障害の原因となる特定のデータなどのパターンを見つけます。
Kubernetes および EKS 固有のメトリクス：
-
Kubernetes クラスター状態メトリクス — ポッド、ノード、コントロールプレーンなど、さまざまな Kubernetes オブジェクトのヘルスとステータスをモニタリングします。たとえば、 などのツールを使用してポッドのステータス
kubectlを確認します。 -
成功/失敗したパイプライン実行 — 成功/失敗したパイプライン実行、ジョブ期間、ステップ完了時間、オーケストレーションエラー (Kubeflow/Mlflow/Argo イベントの使用など) を追跡します。
-
AWS サービスメトリクス — EKS インフラストラクチャとそれで実行されているアプリケーションをサポートする他の AWS サービスのメトリクスを追跡します。例えば、Amazon S3 を使用している場合は、バケットサイズをモニタリングしてストレージの使用状況を追跡します。
-
Kubernetes コントロールプレーンメトリクス — API サーバー、スケジューラ、コントローラーマネージャー、および etcd データベースのパフォーマンスの問題や障害をモニタリングします。例えば、応答性のために API サーバーのリクエストレイテンシーを追跡します。
以降のトピックでは、上記のいくつかのメトリクスのデータを収集する方法について説明します。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 メトリクス」を参照してください。
リアルタイムのオンライン推論メトリクスのモニタリングを検討する
リアルタイムシステムでは、ユーザーやその他の依存システムにタイムリーな応答を提供するには、低レイテンシーが不可欠です。レイテンシーが高いと、ユーザーエクスペリエンスが低下したり、パフォーマンス要件に違反する可能性があります。推論レイテンシーに影響するコンポーネントには、モデルのロード時間、前処理時間、実際の予測時間、後処理時間、ネットワーク送信時間などがあります。推論レイテンシーをモニタリングして、サービスレベルアグリーメント (SLAs) を満たす低レイテンシーのレスポンスを確保し、以下のカスタムメトリクスを開発することをお勧めします。予想される負荷下でテストし、ネットワークレイテンシーを含め、同時リクエストを考慮し、さまざまなバッチサイズでテストします。
-
Time to First Token (TTFT) — ユーザーがリクエストを送信してからレスポンスの開始 (最初の単語、トークン、またはチャンク) を受け取るまでの時間。たとえば、チャットボットでは、ユーザーが質問をした後、最初の出力 (トークン) の生成にかかる時間を確認します。
-
End-to-Endのレイテンシー — リクエストが受信されてからレスポンスが返送されるまでの合計時間です。たとえば、リクエストからレスポンスまでの時間を測定します。
-
Output Tokens Per Second (TPS) — モデルが応答を開始した後に新しいトークンを生成する速度を示します。たとえば、チャットボットでは、ベースラインテキストの言語モデルの生成速度を追跡します。
-
エラー率 — 失敗したリクエストを追跡します。これはパフォーマンスの問題を示している可能性があります。たとえば、大きなドキュメントや特定の文字の失敗したリクエストをモニタリングします。
-
スループット — システムが時間単位ごとに処理できるリクエストまたはオペレーションの数を測定します。たとえば、ピーク負荷を処理するために 1 秒あたりのリクエストを追跡します。
K/V (キー/値) キャッシュは、推論レイテンシーの強力な最適化手法であり、特にトランスフォーマーベースのモデルに関連します。K/V キャッシュは、以前のトランスフォーマーレイヤー計算のキーテンソルと値テンソルを保存し、特に大規模言語モデル (LLMs。キャッシュ効率メトリクス (特に K/V またはセッションキャッシュの使用):
-
キャッシュヒット/ミス率 — キャッシュを利用する推論設定 (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
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 ヒストグラムドキュメント
リアルタイムオンライン推論のトークンスループットを追跡する
コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、トークンの処理時間をモニタリングしてモデルのパフォーマンスを測定し、スケーリングの決定を最適化することをお勧めします。次の例は、推論アプリケーションによって公開されたカスタムヒストグラムメトリクス 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 ヒストグラムドキュメント
チェックポイントの復元レイテンシーの測定
コアトレーニングとファインチューニングメトリクスのモニタリングを検討する トピックで説明したように、チェックポイントレイテンシーはモデルライフサイクルの複数のフェーズにおける重要なメトリクスです。次の例は、アプリケーションによって公開されたカスタムヒストグラムメトリクス 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 ヒストグラムドキュメント
