KubernetesでのGPU稼働では、測定・課金システムをゼロから構築する必要がある

CPUとメモリの監視ツールは、Kubernetes上のGPU（Graphics Processing Unit）へ同じように簡単には移行できない。プラットフォームは通常、コンテナまたはPodレベルの使用量メトリクスを提供するが、GPUを共有する場合、プラットフォームチームはデータ収集から各チームのコスト負担割合の決定まで、可視化と割り当てに関するほとんどの層を自ら構築する必要がある。

この問題が重要なのは、GPUが通常、インフラ請求額の中で最も高価な項目だからだ。分析によると、運用コストはノードの価格だけにとどまらず、測定上のギャップを補い、数値の正確性を検証し、ワークロードがKubernetesによって割り当てられた範囲を超えないようにするためのエンジニアリング時間も含む。

なぜ通常のメトリクスでは不十分なのか

多くの運用担当者が利用を始めるNVIDIA DCGM exporterは、デフォルトでは物理デバイスレベルのデータを提供する。PodがGPUを1基丸ごと所有している場合はこれで十分なこともあるが、time-slicingやMPSを使ってデバイスを共有する場合は状況が異なる。この場合、1基のGPUを使用する各Podに同じ値が表示され、実際には存在しない1基のGPUを3つのワークロードが300%消費したように見えることがある。

問題は、グラフが正常に見えても、基礎となるデータが割り当てに適していない可能性があることだ。そのためチームは、消費者を実際には区別していない数値に基づいて、レポートやダッシュボードをすべて構築してしまう可能性がある。

プラットフォームチームにとって実務上何が変わるのか

GPUは、リソース割り当てモデルの点でもCPUとは異なる。Kubernetesでは通常、GPUはnvidia.com/gpu: 1のような整数リソースとして表示され、スケジューラーはCPUの場合のように小数単位を扱えない。実際の共有は、time-slicing、MPS、MIGによってスケジューラーの下位レベルで行われるため、ワークロードが要求した量と使用した量を比較することがより複雑になる。

チームは、Kubernetesが割り当て済みとして記録した内容と、アプリケーションが実際にアクセスできる内容が一致することを確認するため、独立した制御も必要とする。適切な設定で上書きされなければ、環境変数NVIDIA_VISIBLE_DEVICESによって、スケジューラーが1基だけ割り当てた場合でも、コンテナからノード上のすべてのGPUが見えてしまう可能性がある。

また、「GPU使用率80%」という表現も、必ずしも一つの意味を持つわけではない。それはサンプル期間の一部でカーネルが実行されていたことだけを測定している可能性があり、演算能力やメモリ帯域幅の消費量を示しているとは限らない。vLLMなど一部のフレームワークでは、起動時にGPUメモリの大部分が予約されることがあるため、一般的な使用率の数値よりも、メモリや帯域幅のほうが重要な指標になる場合がある。

課金：メモリは演算よりも割り当てやすい

NVIDIA NVMLライブラリを使えば、各プロセスが保持しているメモリ量を表示し、そのプロセスを対応するPodや担当チームに関連付けることができる。ただし、ドライバーが自身のために保持する領域があるため、値の合計はカードのメモリ全体とは一致しない。

一方、並列実行されるワークロード間で演算時間を割り当てる場合、精度には限界がある。2つのワークロードがそれぞれ90%アクティブであるように見えても、どちらが能力の70%を消費し、どちらが30%を消費したのかをメトリクスが示さないことがある。そのため分析では、GPUメモリの使用量を社内課金の実用的な基準として使用し、演算の測定は正確な課金基準ではなく運用指標として扱うことを提案している。

共有モデルの選択が計算を変える

GPUの共有には単一のモデルしかないわけではない。time-slicingは分離を行わずにデバイスを交代で使用し、MPSは異なるプロセスのカーネルを同時に実行できるようにする。一方、MIGはハードウェアを固定された区画に分割する。それでも、クラウドサービスが一部しか使用していない場合でも物理GPU全体に対して課金することがあり、記事によると、A100およびH100クラスのカードは最大7つのインスタンスに分割できる。

Dynamic Resource Allocation（DRA）は、リソース管理の将来的な経路になるとみられているが、まだ成熟段階にあり、Karpenterなどのスケーリングツールを含む周辺ツールもこの発展に追随している。

なぜこのニュースが重要なのか

AWSでは、MIGに対応するA100クラスで最も安価なGPUの価格は1時間あたり約22ドル、スポット料金を利用すると約14ドルであるのに対し、CPUのみを使用する比較対象のインスタンスは記事によると1時間あたり約5ドルである。そのため使用量の割り当てを誤ることは、小さな会計上の問題ではなく、キャパシティ、コスト、チーム間の負担の公平性に関する判断へ直接影響する可能性がある。

編集上の結論は、Kubernetes上でGPUを稼働させるには、CPUやメモリとは異なる運用モデルが依然として必要だということだ。プラットフォームチームは、何を正確に測定できるのかを特定し、コスト配分の明確なルールを策定し、実際の消費量を表していない一般的なGPU使用率の指標に基づいて会計上の判断を下すことを避ける必要がある。一方、情報源は、DRAの成熟とハードウェア分割によってこのギャップが徐々に縮小する可能性を示しているが、その時期と現在のツールの限界は依然として未解決の問題である。