Kubernetes で GPU 推論基盤を運用する前に確認すべき5項目

社内向けのレコメンド機能やチャットボットで、GPU（画像処理用に開発された並列計算チップ）を使った推論サービスを Kubernetes 上に構築する案件が増えています。既存の業務システム基盤を Kubernetes（コンテナ化されたアプリケーションの配置・運用を自動化する基盤ソフトウェア）で運用してきたチームが、次に AI ワークロードを載せる際にどこで詰まりやすいかを整理しました。GPU をどう Kubernetes に認識させ、どう配置し、どう増減させるか。基幹システムの安定運用を担ってきたエンジニアが、AI 案件に着手する前の判断材料になれば幸いです。

何が変わるのか：CPU/メモリ管理との違い

従来の業務アプリケーションは CPU とメモリを基準にスケジューリング（Pod をどのノードに配置するか決める処理）されてきました。

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

この設定であれば、空きリソースのあるノードに Pod を置けば済みます。ところが GPU を使うワークロードは、これに加えて nvidia.com/gpu: 1 のような専用リソースを要求します。

GPU は台数が限られ、単価も CPU コアより高い部品です。ノードに GPU を認識させる仕組みは、デバイスプラグイン（GPU などの専用ハードウェアを Kubernetes に登録する拡張機構）と呼ばれる方式で提供されます。基幹系のバッチ処理やWebアプリのスケーリングとは、前提となるリソースの性質そのものが違う点をまず押さえておく必要があります。

GPUの種類差とワークロードの相性

クラスタ内に複数世代の GPU が混在する場合を考えます。あるノードには旧世代の T4、別のノードには A100 や H100 といった高性能モデルが載っているイメージです。

ここに「軽量な埋め込みモデルの推論」「大規模言語モデルの推論」「分散学習ジョブ」という3種類のワークロードが来ると、どのGPUにどれを載せるかで効率が大きく変わります。埋め込みモデルに最高性能のGPUを使うのは費用対効果が悪く、逆に大規模モデルを非力なGPUに置くとメモリ不足でエラーになります。

判断に使う軸は次のようなものです。

GPUの種類とメモリ容量
ワークロードのサイズ（モデルパラメータ数やバッチサイズ)
ノード間のネットワーク構成（トポロジー）
コストと優先度

Kubernetes v1.36では、こうした複数Podを一体として扱うためのPodGroupsや、トポロジーを考慮したスケジューリング、ワークロードを意識したプリエンプション（優先度の高い処理のために低優先度の処理を退避させる機能）、Dynamic Resource Allocation（GPUなど特殊デバイスをより柔軟に割り当てる仕組み）との連携が強化されています。これらは密結合なAI/MLジョブやバッチ処理を意識した機能です。バージョンを確認する際は kubectl version --short でクラスタのサーバーバージョンをまず見ておくと良いでしょう。

なぜ「Pod単位」の発想では足りないのか

従来のKubernetesスケジューラは基本的にPod単位で配置を決めます。しかし分散学習のように4台のワーカーが揃わないと処理を開始できないジョブでは、2台だけ配置されて残り2台が待機状態のままでは意味がありません。

この「必要な数が揃うまで待ってから一括で配置する」考え方をギャングスケジューリング（gang scheduling）と呼びます。判断の流れを単純化すると次のようになります。

必要な台数分のリソースが空いているか？
  Yes → ワークロードをまとめてスケジュール
  No  → 空きが出るまで待機

さらにワーカー間で大量のデータ転送が発生する分散学習では、物理的に離れたノードに配置してしまうとネットワーク遅延がボトルネックになります。トポロジーを意識したスケジューリングは、単一Podの空き容量だけでなく、ジョブ全体の配置文脈を見て判断する点が従来型と異なります。

業務システム側の視点で見る影響範囲

ここまでの仕組みを、既存の基幹システムやマイクロサービス（機能単位で分割された小さなサービス群）を運用してきた立場で読み替えると、確認すべきポイントが見えてきます。

1点目は、既存クラスタにGPUノードを混在させる場合、Taint/Toleration（特定のノードに特定のPodしか置けないよう制限する仕組み）の設定漏れがないかです。GPUノードに一般業務のPodが誤って配置されると、高コストなリソースが業務システムのために占有されてしまいます。

2点目は、リソースクォータ（namespace単位でのリソース使用上限）にGPU用の項目を追加しているかどうかです。従来のCPU/メモリのクォータ設定だけでは、GPU利用量の統制が抜けたままになります。

3点目は、オートスケーリング設定がGPUワークロードの起動時間を考慮しているかです。モデルのロードには数十秒〜数分かかるケースがあり、CPUアプリと同じスケールアウトの閾値では応答が遅れます。

クラスタのバージョンとGPUスケジューリング関連機能の対応状況（kubectl versionで確認）
GPUノードへのTaint設定と、対応するTolerationがワークロード側にあるか
ResourceQuotaにnvidia.com/gpuなどのカスタムリソースが含まれているか
分散ジョブがギャングスケジューリングを前提にしているか、単純なPod単位配置のままか
モデルサービング用のPodのReadinessProbe（起動完了を判定する仕組み）が、モデルロード時間に見合っているか

これらは既存の運用ノウハウが使い回せる部分と、GPU特有の考慮が必要な部分が混在しています。既存のマイクロサービス運用チームがそのままAI基盤を引き継ぐ場合、上記のチェックリストを移行判断のたたき台にするとよさそうです。

まとめ

GPUをKubernetesで扱う際は、CPU/メモリ管理の延長線ではなく、専用リソースとして別枠で設計する必要があります。

デバイスプラグインによるGPU認識、GPU種類ごとの向き不向き、ギャングスケジューリングやトポロジー考慮といった要素は、既存の業務システム基盤の知識だけでは判断がつきにくい領域です。

まず着手できるのは、現行クラスタのバージョン確認とTaint/Toleration・ResourceQuotaの設定点検です。ここから始めて、モデルサービング特有の起動時間を踏まえたヘルスチェック設計へと広げていくのが、無理のない移行の順番だと考えられます。