翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # オブザーバビリティ **ヒント** Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。 ## モニタリングとオブザーバビリティ ### 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](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)」を参照してください。 ## オブザーバビリティとメトリクス ### AI/ML ワークロードのモニタリングおよびオブザーバビリティツールの使用 最新の AI/ML サービスでは、インフラストラクチャ、モデリング、アプリケーションロジック間の調整が必要です。プラットフォームエンジニアは、インフラストラクチャとオブザーバビリティスタックを管理します。メトリクスを収集、保存、視覚化します。AI/ML エンジニアは、モデル固有のメトリクスを定義し、さまざまな負荷とデータ分散の下でパフォーマンスをモニタリングします。アプリケーション開発者APIs を消費し、リクエストをルーティングし、サービスレベルのメトリクスとユーザーインタラクションを追跡します。統一されたオブザーバビリティプラクティスがない場合、これらのチームはサイロで作業し、システムのヘルスとパフォーマンスに関する重要なシグナルを見逃します。環境間で共有可視性を確立することで、すべてのステークホルダーが問題を早期に検出し、信頼性の高いサービスを維持できます。 AI/ML ワークロード用の Amazon EKS クラスターの最適化には、特に GPU メモリ管理に関する固有のモニタリング課題があります。適切なモニタリングを行わないと、組織はout-of-memory (OOM) エラー、リソースの非効率性、不要なコストに直面します。効果的なモニタリングにより、EKS 顧客のパフォーマンス、耐障害性、コスト削減が向上します。3 つのモニタリングレイヤーを組み合わせた包括的なアプローチを使用します。まず、[NVIDIA DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) を使用して詳細な GPU メトリクスをモニタリングし、GPU 電力使用量、GPU 温度、SM アクティビティ、SM 占有率、XID エラーを追跡します。次に、[Ray](https://docs.ray.io/en/latest/serve/monitoring.html) や [vLLM](https://docs.vllm.ai/en/v0.8.5/design/v1/metrics.html) などの推論サービスフレームワークをモニタリングして、ネイティブメトリクスを通じて分散ワークロードのインサイトを取得します。3 つ目は、アプリケーションレベルのインサイトを収集して、ワークロードに固有のカスタムメトリクスを追跡することです。このレイヤードアプローチにより、アプリケーションのパフォーマンスを通じてハードウェア使用率を可視化できます。 #### ツールとフレームワーク いくつかのツールとフレームワークは、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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) をお勧めします。NVIDIA [DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) と統合して GPU メトリクスを収集し、インサイトをすばやく得るための構築済みのダッシュボードを提供します。クラスターに [CloudWatch Observability アドオン](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html)をインストールすることで、Container Insights は [NVIDIA DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html) のライフサイクルをデプロイおよび管理し、Nvidia のドライバーから GPU メトリクスを収集して CloudWatch に公開します。 Container Insights をインストールすると、CloudWatch は環境内の NVIDIA GPUs を自動的に検出し、重要なヘルスとパフォーマンスのメトリクスを収集します。これらのメトリクスは、厳選されたout-of-the-boxダッシュボードに表示されます。Unified CloudWatch エージェントを使用して [Ray](https://docs.ray.io/en/latest/cluster/vms/user-guides/launching-clusters/aws.html) と [vLLM](https://docs.vllm.ai/en/latest/) を CloudWatch と統合し、ネイティブメトリクスを送信することもできます。 [ CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/UseCloudWatchUnifiedAgent.html) この統一されたアプローチにより、EKS 環境でのオブザーバビリティが簡素化され、チームはモニタリングインフラストラクチャを構築するのではなく、パフォーマンスの調整とコストの最適化に集中できます。 使用可能なメトリクスの完全なリストについては、[「Amazon EKS および Kubernetes Container Insights メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html#Container-Insights-metrics-EKS-GPU)」を参照してください。GPU モニタリングの実装に関するstep-by-stepガイダンスについては、[Amazon CloudWatch Container Insights を使用した NVIDIA GPU ワークロードの運用上のインサイト](https://aws.amazon.com/blogs/mt/gain-operational-insights-for-nvidia-gpu-workloads-using-amazon-cloudwatch-container-insights/)の取得」を参照してください。推論レイテンシーを最適化する実用的な例については、[「AI 応答性の最適化: Amazon Bedrock レイテンシー最適化推論の実用的なガイド](https://aws.amazon.com/blogs/machine-learning/optimizing-ai-responsiveness-a-practical-guide-to-amazon-bedrock-latency-optimized-inference/)」を参照してください。 **Managed Prometheus と Grafana** カスタマイズされたダッシュボードと高度な可視化機能が必要な場合は、[NVIDIA DCGM-Exporter](https://catalog.ngc.nvidia.com/orgs/nvidia/teams/k8s/containers/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](https://awslabs.github.io/ai-on-eks/docs/blueprints/inference/GPUs/vLLM-rayserve)てネイティブメトリクスを Prometheus にエクスポートすることで、このモニタリングスタックを拡張できます。[Grafana を AWS X-Ray データソースに接続](https://docs.aws.amazon.com/grafana/latest/userguide/x-ray-data-source.html)して分散トレースを視覚化し、推論パイプライン全体のパフォーマンスのボトルネックを特定することもできます。この組み合わせにより、アプリケーションレベルのリクエストフローを通じて GPU レベルのメトリクスからend-to-endの可視性が得られます。 このモニタリングスタックのデプロイに関するstep-by-stepガイダンスについては、[「AWS マネージドオープンソースサービスを使用した Amazon EKS での GPU ワークロードのモニタリング](https://aws.amazon.com/blogs/mt/monitoring-gpu-workloads-on-amazon-eks-using-aws-managed-open-source-services/)」を参照してください。 ### コアトレーニングとファインチューニングメトリクスのモニタリングを検討する コアトレーニングメトリクスをモニタリングして、Amazon EKS クラスターとそのクラスターで実行されている機械学習ワークロードの状態とパフォーマンスを追跡します。トレーニングワークロードは、長期間実行され、リソースの消費が異なり、モデルの収束とデータパイプラインの効率を可視化する必要があるため、推論ワークロードとは異なるモニタリング要件があります。以下のメトリクスは、ボトルネックを特定し、リソース割り当てを最適化し、トレーニングジョブを正常に完了させるのに役立ちます。このモニタリングアプローチを実装するためのstep-by-stepガイダンスについては、[「Amazon EKS での機械学習ワークロードのモニタリングの概要](https://aws.amazon.com/blogs/containers/part-1-introduction-to-observing-machine-learning-workloads-on-amazon-eks/)」を参照してください。 **リソース使用状況メトリクス** リソース使用状況メトリクスをモニタリングして、リソースが適切に消費されていることを確認します。これらのメトリクスは、ボトルネックと根本原因のパフォーマンス問題を特定するのに役立ちます。 + **CPU、メモリ、ネットワーク、GPU パワー、GPU 温度** - これらのメトリクスをモニタリングして、割り当てられたリソースがワークロードの需要を満たし、最適化の機会を特定します。gpu\$1memory\$1usage\$1bytes などのメトリクスを追跡してメモリ消費パターンを特定し、ピーク使用量を検出します。95 パーセンタイル (P95) などのパーセンタイルを計算して、トレーニング中の最も高いメモリ需要を把握します。この分析は、モデルとインフラストラクチャを最適化して OOM エラーを回避し、コストを削減するのに役立ちます。 + **SM 占有率、SM アクティビティ、FPxx アクティビティ** - これらのメトリクスをモニタリングして、GPU の基盤となるリソースがどのように使用されているかを理解します。[経験則](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html#metrics)としての SM アクティビティのターゲット 0.8。 + **ノードとポッドのリソース使用率** - ノードとポッドレベルでリソースの使用状況を追跡して、リソースの競合と潜在的なボトルネックを特定します。ノードが容量制限に近づいているかどうかをモニタリングします。これにより、ポッドスケジューリングが遅延し、トレーニングジョブが遅くなる可能性があります。 + **リソース使用率とリクエストと制限の比較** — 実際のリソース使用率と設定されたリクエストと制限を比較して、クラスターが現在のワークロードを処理し、将来のワークロードに対応できるかどうかを判断します。この比較により、OOM エラーやリソースの無駄を避けるためにリソース割り当てを調整する必要があるかどうかがわかります。 + **ML フレームワークの内部メトリクス** - TensorFlow や PyTorch などの ML フレームワークから内部トレーニングと収束メトリクスを取得します。これらのメトリクスには、損失曲線、学習率、バッチ処理時間、トレーニングステップ期間が含まれます。TensorBoard または同様のツールを使用してこれらのメトリクスを視覚化し、モデルの収束を追跡し、トレーニングの非効率性を特定します。 **モデルパフォーマンスメトリクス** モデルパフォーマンスメトリクスをモニタリングして、トレーニングプロセスが精度とビジネス要件を満たすモデルを生成することを確認します。これらのメトリクスは、トレーニングを停止するタイミングの決定、モデルバージョンの比較、パフォーマンスの低下の特定に役立ちます。 + **精度、精度、リコール、F1-score** — これらのメトリクスを追跡して、モデルが検証データに対してどの程度うまく機能するかを理解します。各トレーニングエポックの後に検証セットの F1-scoreを計算して、モデルが改善しているかどうか、および許容可能なパフォーマンスレベルに達したタイミングを評価します。 + **ビジネス固有のメトリクスと KPIs** — AI/ML イニシアチブのビジネス価値を直接測定するメトリクスを定義して追跡します。レコメンデーションシステムでは、クリックスルー率や変換率などのメトリクスを追跡して、モデルが意図したビジネス成果を促進するようにします。 + **経時的なパフォーマンス** — モデルバージョンとトレーニング実行のパフォーマンスメトリクスを比較して、傾向を特定し、低下を検出します。新しいモデルバージョンが、ベースラインモデルと比較してパフォーマンスを維持または改善するかどうかを追跡します。この履歴比較は、新しいモデルをデプロイするか、トレーニングの問題を調査するかを決定するのに役立ちます。 **データ品質とドリフトのメトリクス** データ品質とドリフトメトリクスをモニタリングして、トレーニングデータの一貫性と代表性を維持します。データドリフトにより、時間の経過とともにモデルのパフォーマンスが低下する可能性がありますが、データ品質の問題により、モデルが収束したり、信頼できない結果を生成したりする可能性があります。 + **入力データの統計プロパティ** — 平均、標準偏差、入力特徴の分布などの統計プロパティを経時的に追跡して、データドリフトや異常を検出します。特徴分布がベースライントレーニングデータから大幅にシフトするかどうかをモニタリングします。例えば、重要な機能の平均が 2 標準偏差以上変化した場合、データパイプラインが変更されたかどうか、または基盤となるデータソースがシフトしたかどうかを調査します。 + **データドリフトの検出とアラート** — トレーニングに影響を与える前に、データ品質の問題を検出して警告する自動メカニズムを実装します。Kolmogorov-Smirnov テストやカイ二乗テストなどの統計テストを使用して、現在のデータ分布を元のトレーニングデータと比較します。テストが重大なドリフトを検出したときにアラートを設定して、更新されたデータでモデルを再トレーニングしたり、データパイプラインの問題を調査したりできるようにします。 **レイテンシーとスループットのメトリクス** レイテンシーとスループットのメトリクスをモニタリングして、トレーニングパイプラインのボトルネックを特定し、リソース使用率を最適化します。これらのメトリクスは、トレーニング中に費やす時間と最適化作業の焦点を理解するのに役立ちます。 + **ML トレーニングパイプラインのEnd-to-Endのレイテンシー** — データ取り込みからモデル更新まで、トレーニングパイプライン全体でデータが流れる合計時間を測定します。このメトリクスをトレーニング実行全体で追跡して、パイプラインの変更によってパフォーマンスが向上するか低下するかを特定します。レイテンシーが高い場合は、多くの場合、データのロード、前処理、ノード間のネットワーク通信のボトルネックを示します。 + **トレーニングスループットと処理レート** — トレーニングパイプラインが時間単位ごとに処理するデータの量を追跡して、効率的なリソース使用率を確保します。1 秒あたりに処理されたサンプルや 1 分あたりに完了したバッチなどのメトリクスをモニタリングします。ハードウェア容量に対するスループットが低い場合は、GPU サイクルを浪費するデータロード、前処理、またはモデル計算の非効率性が示されます。 + **チェックポイントの保存と復元のレイテンシー** – モデルチェックポイントをストレージ (S3、EFS、FSx) に保存し、ジョブを再開したり、障害から回復したりするときに GPU または CPU メモリに復元するために必要な時間をモニタリングします。チェックポイント操作が遅いと、ジョブの復旧時間が長くなり、コストが増加します。チェックポイントのサイズ、保存期間、復元期間、障害数を追跡して、圧縮やストレージ階層の高速化などの最適化の機会を特定します。 + **データのロードと前処理時間** - ストレージからのデータのロードと前処理変換の適用にかかった時間を測定します。この時間をモデル計算時間と比較して、トレーニングがデータバインドかコンピューティングバインドかを判断します。データロードが合計トレーニング時間の 20% 以上を消費する場合は、キャッシュ、プリフェッチ、または高速ストレージを使用してデータパイプラインを最適化することを検討してください。 **エラー率と失敗** トレーニングパイプライン全体でエラー率と障害をモニタリングして、信頼性を維持し、無駄なコンピューティングリソースを防止します。検出されないエラーにより、トレーニングジョブがサイレントに失敗したり、無効なモデルを生成したり、問題に気付くまでに GPU 時間を浪費したりする可能性があります。 + **パイプラインエラーモニタリング** — データの前処理、モデルトレーニング、チェックポイントオペレーションなど、ML パイプラインのすべてのステージでエラーを追跡します。エラータイプ、頻度、影響を受けるコンポーネントをログに記録して、問題をすばやく特定します。一般的なエラーには、データ形式の不一致、前処理中のout-of-memory障害、ストレージ制限によるチェックポイント保存障害などがあります。エラー率がベースラインしきい値を超えたときにアラートを設定して、エラーがカスケードされる前に調査できるようにします。 + **定期的なエラー分析 — **定期的なエラーのパターンを特定して調査し、将来の障害を防ぎ、パイプラインの信頼性を向上させます。ログを分析して、特定のデータサンプル、バッチサイズ、またはトレーニング設定が一貫して障害を引き起こすかどうかを確認します。たとえば、特定の入力データ型が前処理エラーをトリガーする場合は、パイプラインの早い段階で検証チェックを追加するか、データクリーニングロジックを更新します。平均障害間隔 (MTBF) を追跡して、パイプラインの信頼性が時間の経過とともに向上するかどうかを測定します。 **Kubernetes および EKS 固有のメトリクス** Kubernetes および EKS メトリクスをモニタリングして、クラスターインフラストラクチャが正常であり、トレーニングワークロードをサポートできることを確認します。これらのメトリクスは、トレーニングジョブの障害やパフォーマンスの低下を引き起こす前に、インフラストラクチャの問題を検出するのに役立ちます。 + **Kubernetes クラスター状態メトリクス** — ポッド、ノード、デプロイ、サービスなどの Kubernetes オブジェクトのヘルスとステータスをモニタリングします。ポッドのステータスを追跡して、保留中、失敗、またはクラッシュループ状態でスタックしているポッドを特定します。ノードの状態をモニタリングして、ディスク負荷、メモリ負荷、ネットワーク利用不能などの問題を検出します。kubectl またはモニタリングツールを使用してこれらのメトリクスを継続的にチェックし、ポッドの起動に失敗したり、ノードがスケジュールできなくなったりした場合にアラートを設定します。 + **Training Pipeline Execution Metrics** — パイプラインの実行の成功と失敗、ジョブ期間、ステップ完了時間、オーケストレーションエラーを追跡します。トレーニングジョブが予想される時間枠内に完了したかどうか、および失敗率が時間の経過とともに増加するかどうかをモニタリングします。ジョブの成功率、平均ジョブ期間、失敗までの時間などのメトリクスを追跡します。これらのメトリクスは、インフラストラクチャの問題、設定の問題、またはデータ品質の問題がトレーニングの失敗を引き起こすかどうかを特定するのに役立ちます。 + **AWS サービスメトリクス** — EKS インフラストラクチャとトレーニングワークロードをサポートする AWS サービスのメトリクスを追跡します。リクエストのレイテンシー、エラー率、スループットなどの S3 メトリクスをモニタリングして、データのロードパフォーマンスが一貫していることを確認します。IOPS、スループット、キューの長さなどの EBS ボリュームメトリクスを追跡して、ストレージのボトルネックを検出します。VPC フローログとネットワークメトリクスをモニタリングして、ノード間または外部サービスへの接続の問題を特定します。 + **Kubernetes コントロールプレーンメトリクス** — API サーバー、スケジューラ、コントローラーマネージャー、および etcd データベースをモニタリングして、クラスターオペレーションに影響するパフォーマンスの問題や障害を検出します。API サーバーのリクエストレイテンシー、リクエストレート、エラーレートを追跡して、コントロールプレーンがリクエストのスケジュールに迅速に応答できるようにします。etcd データベースのサイズ、コミット期間、リーダーの変更をモニタリングして、安定性の問題を検出します。API サーバーのレイテンシーが高い、または頻繁に etcd リーダーを変更すると、ポッドのスケジュールが遅延し、トレーニングジョブの起動時間が長くなる可能性があります。 **アプリケーションログとインスタンスログ** アプリケーションログとインスタンスログを収集して分析し、メトリクスだけでは説明できない問題を診断します。ログは、エラー、状態変更、システムイベントに関する詳細なコンテキストを提供し、トレーニングジョブが失敗したり、パフォーマンスが低下したりする理由を理解するのに役立ちます。ログをメトリクスと関連付けることで、根本原因をより迅速に特定できます。 + **アプリケーションログ** - トレーニングジョブ、データパイプライン、ML フレームワークからアプリケーションログを収集して、ボトルネックを特定し、障害を診断します。これらのログには、データのロードエラー、モデル初期化の失敗、チェックポイントの保存エラー、フレームワーク固有の警告など、ジョブの実行に関する詳細情報が記録されます。ログタイムスタンプをメトリクスのスパイクと関連付けて、パフォーマンスの低下や障害の原因を理解します。例えば、GPU 使用率が突然低下した場合、アプリケーションログにデータパイプラインの停止や前処理の失敗を示すエラーがないか確認します。CloudWatch Logs や Fluent Bit などの一元化されたログ記録ツールを使用して、すべてのポッドからログを集約し、検索できるようにします。 + **インスタンスログ** - システムジャーナルログやメッセージ出力などのインスタンスレベルのログを収集して、ハードウェアの問題やカーネルレベルの問題を検出します。これらのログには、GPU ドライバーのエラー、メモリ割り当ての失敗、ディスク I/O エラー、アプリケーションログに表示されない可能性のあるネットワークインターフェイスの問題が表示されます。インスタンスログをアプリケーションログとメトリクスと関連付けて、トレーニングの失敗がハードウェアの問題またはアプリケーションの問題に起因するかどうかを判断します。例えば、トレーニングジョブがout-of-memoryエラーで失敗した場合、システムがメモリ不足になったか、アプリケーションがコンテナ制限を超えたかどうかを示すカーネル OOM キラーメッセージの dmesg ログを確認します。GPU XID エラーやディスク障害などの重大なハードウェアエラーのアラートを設定して、障害が発生したインスタンスを、トレーニングが広範囲に中断される前に置き換えることができます。 以下のセクションでは、[CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) と Amazon Managed [Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html) を使用した [Amazon Managed](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html) Prometheus の 2 つの AWS 推奨アプローチを使用して、上記のメトリクスを収集する方法を示します。最小限のセットアップと事前構築されたダッシュボードで AWS ネイティブツールを使用する場合は、CloudWatch Container Insights を選択します。カスタマイズされたダッシュボード、高度な視覚化機能が必要な場合、または既存の Prometheus ベースのモニタリングインフラストラクチャと統合する場合は、Amazon Managed Grafana で Amazon Managed Prometheus を選択します。使用可能な Container Insights メトリクスの完全なリストについては、[「Amazon EKS および Kubernetes Container Insights メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-enhanced-EKS.html)」を参照してください。 ### リアルタイムオンライン推論メトリクスのモニタリングを検討する リアルタイムシステムでは、ユーザーやその他の依存システムにタイムリーな応答を提供するには、低レイテンシーが不可欠です。レイテンシーが高いと、ユーザーエクスペリエンスが低下したり、パフォーマンス要件に違反する可能性があります。推論レイテンシーに影響するコンポーネントには、モデルのロード時間、前処理時間、実際の予測時間、後処理時間、ネットワーク送信時間などがあります。推論レイテンシーをモニタリングして、サービスレベルアグリーメント (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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) と Amazon [Managed Grafana を使用したオープンソースの Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html) です。 [https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html](https://docs.aws.amazon.com/grafana/latest/userguide/getting-started-with-AMG.html)全体的なオブザーバビリティのニーズに基づいて、これらのソリューションのいずれかを選択します。Container [Insights メトリクスの完全なリストについては、「Amazon EKS および Kubernetes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-enhanced-EKS.html) Container Insights メトリクス」を参照してください。 ### GPU メモリ使用状況の追跡 [コアトレーニングとファインチューニングメトリクスのモニタリングを検討する](#aiml-consider-monitor-fine-tuning-metrics) トピックで説明したように、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)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html) 形式で構造化ログを出力するように設定する必要があります。CloudWatch ログは EMF を解析し、メトリクスを公開します。トレーニングアプリケーションで [aws\$1embedded\$1metrics](https://github.com/awslabs/aws-embedded-metrics-python) を使用して、構造化ログを 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() ``` ### リアルタイムオンライン推論の推論リクエスト期間を追跡する [コアトレーニングとファインチューニングメトリクスのモニタリングを検討する](#aiml-consider-monitor-fine-tuning-metrics) トピックで説明したように、ユーザーやその他の依存システムにタイムリーな応答を提供するには、低レイテンシーが不可欠です。次の例は、推論アプリケーションによって公開されたカスタムヒストグラムメトリクス `inference_request_duration_seconds`を追跡する方法を示しています。95 パーセンタイル (P95) レイテンシーを計算してワーストケースのシナリオに焦点を当て、ステージング環境で合成推論リクエスト (Locust 経由など) でテストし、アラートしきい値 (>500ms など) を設定して SLA 違反を検出します。 **AWS ネイティブ CloudWatch Container Insights の例** このサンプルでは、AWS CloudWatch Embedded Metric Format を使用して、推論アプリケーションで inference\$1request\$1duration\$1seconds のカスタムヒストグラムメトリクスを作成する方法を示します。 ``` 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\$1request\$1duration\$1seconds のカスタムヒストグラムメトリクスを作成する方法を示しています。 ``` 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 ヒストグラムドキュメント](https://prometheus.io/docs/practices/histograms/)」および[「Prometheus クライアントドキュメント](https://github.com/prometheus/client_python)」を参照してください。 ### リアルタイムオンライン推論のトークンスループットを追跡する [コアトレーニングとファインチューニングメトリクスのモニタリングを検討する](#aiml-consider-monitor-fine-tuning-metrics) トピックで説明したように、トークンの処理時間をモニタリングしてモデルのパフォーマンスを測定し、スケーリングの決定を最適化することをお勧めします。次の例は、推論アプリケーションによって公開されたカスタムヒストグラムメトリクス `token_processing_duration_seconds`を追跡する方法を示しています。95 パーセンタイル (P95) の期間を計算して処理効率を分析し、非本番稼働用クラスターでシミュレートされたリクエストロード (100～1000 リクエスト/秒など) でテストし、KEDA トリガーを調整してスケーリングを最適化します。 **AWS ネイティブ CloudWatch Container Insights の例** このサンプルでは、AWS CloudWatch Embedded Metric Format を使用して token\$1processing\$1duration\$1seconds の推論アプリケーションでカスタムヒストグラムメトリクスを作成する方法を示します。ディメンション (「set\$1dimension`) 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\$1processing\$1duration\$1seconds の推論アプリケーションでカスタムヒストグラムメトリクスを作成する方法を示しています。 ``` 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 ヒストグラムドキュメント](https://github.com/prometheus/client_python)」および[「Prometheus クライアントドキュメント](https://github.com/prometheus/client_python)」を参照してください。 **チェックポイントの復元レイテンシーの測定** [コアトレーニングとファインチューニングメトリクスのモニタリングを検討する](#aiml-consider-monitor-fine-tuning-metrics) トピックで説明したように、チェックポイントレイテンシーはモデルライフサイクルの複数のフェーズにおける重要なメトリクスです。次の例は、アプリケーションによって公開されたカスタムヒストグラムメトリクス `checkpoint_restore_duration_seconds``を追跡する方法を示しています。95 パーセンタイル (P95) の期間を計算して復元パフォーマンスをモニタリングし、非本番クラスターでスポット中断をテストし、アラートしきい値 (<30 秒など) を設定して遅延を検出します。 **AWS ネイティブ CloudWatch Container Insights の例** このサンプルは、CloudWatch Insights を使用して checkpoint\$1restore\$1duration\$1seconds をヒストグラムとして公開するようにバッチアプリケーションを計測する方法を示しています。 ``` 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 ヒストグラムドキュメント](https://prometheus.io/docs/practices/histograms/)」および[「Prometheus クライアントドキュメント](https://github.com/prometheus/client_python)」を参照してください。