Kubernetes クラスター全体での GPU 使用状況をリアルタイムで可視化する方法
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
NVIDIA Developer Blog
NVIDIA が、Kubernetes クラスター全体にわたる GPU の使用状況をリアルタイムで監視・可視化する機能を提供するツールを発表しました。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
AI インフラストラクチャの価値を最大化するには、GPU の利用率に対する深い可視性が求められます。しかし、Kubernetes 上で AI ワークロードを実行している多くのプラットフォームチームは、自社の GPU がどのように使用されているかについて限られた可視性しか持っていないのが実情です。誰が消費しているのか、どの程度のメモリが使用中なのか、そして Kubernetes のポッドが待機状態にあるのか、あるいは静かにアイドル化しているのかを知らないケースがほとんどです。シグナルがないため、GPU フリートは日常的に非効率に利用され、ユーザーがエスカレーションするまでスケジューリングのボトルネックが表面化しないという遅れが生じます。
NVIDIA Data Center GPU Manager (DCGM) Exporter を基盤として構築された GPU Usage Monitor は、単一の Helm チャートデプロイメントを通じて、Kubernetes クラスター全体における GPU の割り当て状況、計算利用率、メモリ消費量、およびポッドステータスに対するリアルタイムな可視性を可能にします。
GPU アクセラレーションされた Kubernetes クラスターにおける観測性のギャップ
GPU アクセラレーションされた Kubernetes クラスターを管理するサイト信頼性エンジニア (SRE) やプラットフォームチームにとって、2 つの失敗モードが一般的であり、かつ高コストです。
- 過剰プロビジョニング: エンジニアは競合を避けるために GPU を丸ごと要求しますが、モデルは利用可能なメモリと計算リソースの 30〜50% しか使用しないことが頻繁にあります。消費状況に対する可視性がないため、これらの割り当てを適切なサイズに調整するシグナルがありません。その結果、名目上の需要は高いものの有効な利用率が低いクラスターとなり、アイドル状態にあるハードウェアに対して支払いを行うことになります。
- Pod の飢餓状態とスケジューリングの盲点：GPU リクエストが積み重なり、Pod が Pending 状態でキューに並び、モデル学習ジョブや推論エンドポイントが起動前に停止することがあります。Pending 中の GPU Pod と実行中の GPU Pod をクラスター全体で把握する視点がなければ、これらのスケジューリングボトルネックは通常、ユーザーから障害報告があった時点でしか発見されず、監視アラートを通じて早期に検知されることはありません。
標準的な Kubernetes メトリクススタック（kube-state-metrics や node-exporter など）では、GPU に特化したシグナルが表面化しません。DCGM Exporter は個別 GPU のハードウェアメトリクスを公開しますが、これを Prometheus と Grafana へ接続し、本番環境品質のダッシュボードを実現するには、相当な手動設定作業が必要です。その結果、チームは不整合のあるオンデマンド型の監視セットアップに陥るか、GPU モニタリング自体を行わないことになります。
GPU Usage Monitor とは何か？
GPU Usage Monitor は、Kubernetes 向けに完全に統合された GPU 可観測性スタックをデプロイするオープンソースプロジェクトです。SRE やプラットフォームチームが個別コンポーネントを組み立てて設定する必要はなく、GPU Usage Monitor は DCGM Exporter、kube-state-metrics、Prometheus、Grafana を単一のデプロイに統合し、GPU アクセラレーションワークロードのために特別に設計された事前構築済みダッシュボードを備えています。
設計の原則は運用上の簡素さです。単一の Helm インストールコマンドを実行するだけで、カスタムダッシュボードの作成やスクレイプ設定を必要とせず、数分以内に実行可能な GPU 可視性が得られます。
GPU Usage Monitor のアーキテクチャ
このツールは 4 つの主要コンポーネントで構成されています:
- DCGM Exporter: NVIDIA GPU メトリクスを公開します（外部コンポーネント – GPU Operator を経由してデプロイ）
- kube-state-metrics: Kubernetes ポッドおよびリソースメトリクスを公開します
- Prometheus: DCGM および kube-state-metrics からのメトリクスを収集・保存します
- Grafana: GPU Usage Monitor ダッシュボードを通じて可視化を提供します
DCGM はハードウェア層を扱い、kube-state-metrics は Kubernetes レイヤーを担当します。Prometheus と Grafana がこれらを統合された観測性プレーンに結びつけます。各コンポーネントはプラットフォームチームによって個別によく理解されていますが、このチャートの価値はその統合にあります。
GPU Usage Monitor の始め方
GPU Usage Monitor は Apache 2.0 ライセンスの下でオープンソースとして提供されており、現在 GitHub で入手可能です。
事前要件インストール前に以下の条件を確認してください:
- Kubernetes 1.19 以降
- Helm 3.0 以降
- GPU ノード上で実行中の DCGM Exporter
インストール
フル監視スタックのデプロイには 3 つのコマンドが必要です。
Update chart dependencies
helm dependency update
Install into a dedicated namespace
helm install gpu-usage-monitor . \
--namespace gpu-usage-monitor \
--create-namespace
Forward Grafana to localhost
kubectl port-forward \
-n gpu-usage-monitor \
svc/gpu-usage-monitor-grafana 3000:80
Navigate to http://localhost:3000 and log in with the default credentials (admin / admin). For any environment beyond a local development cluster, update credentials through values.yaml before exposing the dashboard to wider teams.
What the dashboards surface
Once deployed, the pre-built Grafana dashboards give operators an immediate read on the state of GPU resources across the cluster.
Key insights you can get from the dashboard:
- GPU allocation trends. Track which namespaces and workloads hold GPU allocations over time. Spot allocations that were made but never actively used are a direct signal for reclaiming idle capacity.
- Compute utilization with thresholds. Per-GPU utilization percentages displayed against configurable thresholds. Set warning and critical bounds to get ahead of saturation before it degrades inference latency or training throughput.
- ワークロードごとのメモリ使用量。ポッド別に内訳されたリアルタイムの GPU メモリ消費状況。これはリソース要求の適切なサイズ設定（right-sizing）のための基盤となる指標です：もしあるワークロードが 80 GB の NVIDIA GPU で一貫して 12 GB を消費しているなら、フルな GPU 割り当ては必要ありません。
- 実行中および待機中のポッド数。GPU 対応 Kubernetes ポッドが実際に稼働している数と、Pending（待機）状態で止まっている数の、単一のビューからの確認。待機中の数が増加することは、ユーザーが何か問題に気づく前に、スケジューリング圧力の早期警告となります。
- GPU タイプによるフィルタリング。NVIDIA GPU プラットフォーム（Hopper, Blackwell, Blackwell Ultra など）別にすべてのメトリクスをフィルタリングできます。GPU タイプによって適切なワークロードや期待される利用率が異なるような、多様な GPU を持つファームウェアにおいて有用です。
設定
この Helm チャートは既存のインフラストラクチャを置き換えるのではなく、そこに適合するように設計されています。values.yaml 内の主要な設定オプションは、3 つの領域に分類されます。
- 外部 Prometheus インテグレーション：組織が管理型またはセルフホスト型の Prometheus インスタンスを運用している場合、このチャートは既存のスタックへ GPU メトリクスを送信するように構成でき、同時に新しい Prometheus をデプロイする必要はありません。これにより、メトリクスの保持期間、アラートルール、データライフサイクル管理を一元化できます。
- カスタムリソース割り当て：すべてのチャートコンポーネントに対する CPU およびメモリの要求（requests）と制限（limits）は設定可能です。特に長期にわたるメトリクス保持が必要な場合など、クラスターのリソース予算に合わせてこれらの値を調整してください。
- クレデンシャル管理：より広範な展開前に、デフォルトの Grafana 認証情報を上書きしてください。このチャートは標準的な Helm 値を通じてこれらの設定を公開しており、既存のシークレット管理ワークフローを通じて容易に管理できます。
単一の ML チーム向けの小規模 GPU クラスターを管理する場合でも、数百ものワークロードを提供する大規模プラットフォームを実行する場合でも、効率的にインフラストラクチャを運用するためには、完全な GPU 観測性が必須条件です。GPU Usage Monitor は、その観測性を数分で利用可能にします。
さらに詳しく知る
Kubernetes クラスター内の GPU リソースを監視するための包括的な Helm chart にアクセスしてください。
著者について
原文を表示
Maximizing the value of AI infrastructure demands deep visibility into GPU utilization. Yet many platform teams running AI workloads on Kubernetes operate with limited visibility into how their GPUs are used. Most don’t know who’s consuming them, how much memory is in use, and whether Kubernetes pods are pending or silently idle. Without a signal, GPU fleets are routinely underutilized and slow to surface scheduling bottlenecks until users escalate.
The GPU Usage Monitor, built on the NVIDIA Data Center GPU Manager (DCGM) Exporter, enables real-time visibility into GPU allocation, compute utilization, memory consumption, and pod status across an entire Kubernetes cluster and through a single Helm chart deployment.
The observability gap in GPU-Accelerated Kubernetes clusters
For site reliability engineers (SREs) and platform teams managing GPU-accelerated Kubernetes clusters, two failure modes are common and costly.
- Over-provisioning: Engineers request entire GPUs to avoid contention, but models frequently use 30-50% of available memory and compute. Without visibility into consumption, there’s no signal to right-size these allocations. The result is a cluster with high nominal demand but low effective utilization – paying for hardware that sits idle.
- Pod starvation and scheduling blind spots: GPU requests can stack up, leaving pods queued in a Pending state and causing model training jobs or inference endpoints to stall before they start. Without a cluster-wide view of pending versus running GPU pods, these scheduling bottlenecks are often discovered too late – typically when a user reports a failure, rather than through a monitoring alert.
The standard Kubernetes metrics stack – including kube-state-metrics and node-exporter – doesn’t surface GPU-specific signals. DCGM Exporter exposes per-GPU hardware metrics, but wiring it into Prometheus and Grafana with production-quality dashboards requires significant manual configuration effort. Teams end up with inconsistent, one-off monitoring setups, or no GPU monitoring at all.
What is the GPU Usage Monitor?
The GPU Usage Monitor is an open-source project that deploys a fully integrated GPU observability stack for Kubernetes. Rather than requiring SRE and platform teams to assemble and configure individual components, the GPU Usage Monitor uses DCGM Exporter, kube-state-metrics, Prometheus, and Grafana into a single deployment, complete with pre-built dashboards designed specifically for GPU-accelerated workloads.
The design principle is operational simplicity. A single helm install command results in actionable GPU visibility within minutes, with no custom dashboard authoring or scrape configuration required.
GPU Usage Monitor architecture
The tool consists of four main components:
- DCGM Exporter: Exposes NVIDIA GPU metrics (external – deployed via GPU Operator)
- kube-state-metrics: Exposes Kubernetes pod and resource metrics
- Prometheus: Collects and stores metrics from DCGM and kube-state-metrics
- Grafana: Provides visualization through the GPU Usage Monitor Dashboard
DCGM handles the hardware layer, and kube-state-metrics handles the Kubernetes layer. Prometheus and Grafana tie them together into a unified observability plane. Each component is well-understood independently by platform teams; the value of the chart is the integration.
How to get started with the GPU Usage Monitor
The GPU Usage Monitor is open source under the Apache 2.0 license and available now on GitHub.
Prerequisites**Before installing, verify the following:
- Kubernetes 1.19 or later
- Helm 3.0 or later
- DCGM Exporter running on GPU nodes
Installation**
Deploying the full monitoring stack takes three commands.
# Update chart dependencies
helm dependency update
# Install into a dedicated namespace
helm install gpu-usage-monitor . \
--namespace gpu-usage-monitor \
--create-namespace
# Forward Grafana to localhost
kubectl port-forward \
-n gpu-usage-monitor \
svc/gpu-usage-monitor-grafana 3000:80
Navigate to http://localhost:3000 and log in with the default credentials (admin / admin). For any environment beyond a local development cluster, update credentials through values.yaml before exposing the dashboard to wider teams.
What the dashboards surface
Once deployed, the pre-built Grafana dashboards give operators an immediate read on the state of GPU resources across the cluster.
Key insights you can get from the dashboard:
- GPU allocation trends. Track which namespaces and workloads hold GPU allocations over time. Spot allocations that were made but never actively used are a direct signal for reclaiming idle capacity.
- Compute utilization with thresholds. Per-GPU utilization percentages displayed against configurable thresholds. Set warning and critical bounds to get ahead of saturation before it degrades inference latency or training throughput.
- Memory usage per workload. Real-time GPU memory consumption broken down by pod. This is the foundational signal for right-sizing resource requests: if a workload consistently consumes 12 GB on an 80 GB NVIDIA GPU, it doesn’t need a full GPU allocation.
- Running and pending pod counts. A single-pane view of how many GPU-enabled Kubernetes pods are actively running versus stuck in Pending. A growing pending count is an early warning of scheduling pressure – visible before users notice anything is wrong.
- GPU type filtering. Filter all metrics by NVIDIA GPU platform (Hopper, Blackwell, Blackwell Ultra, and others). Useful for heterogeneous fleets where GPU type affects what workloads are appropriate and what utilization numbers are expected.
Configuration
The Helm chart is designed to fit into existing infrastructure rather than replace it. Key configuration options in values.yaml fall into three areas.
- External Prometheus integration: If an organization operates a managed or self-hosted Prometheus instance, the chart can be configured to ship GPU metrics to the existing stack instead of deploying a new Prometheus alongside it. This keeps metric retention, alerting rules, and data lifecycle management centralized.
- Custom resource allocation: CPU and memory requests and limits for all chart components are configurable. Tune these values to fit the cluster’s resource budget, especially for the Prometheus instance if long-term metric retention is required.
- Credential management: Override default Grafana credentials before any broader rollout. The chart exposes these through standard Helm values, making them straightforward to manage via existing secret management workflows.
Whether managing a small GPU cluster for a single ML team or running a large-scale platform serving hundreds of workloads, complete GPU observability is a prerequisite for operating that infrastructure efficiently. The GPU Usage Monitor makes that observability accessible in minutes.
Learn more
Access the comprehensive Helm chart for monitoring GPU resources in Kubernetes clusters.
About the Authors
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み