k8s で GPU を扱う標準的手法
LLM 等の AI ワークロードで GPU を k8s 上で動かす需要が急増しました。本記事では編集部の視点で、実務での運用を公開情報をもとに整理します。GPU インフラ運用 もご参考に。
セットアップ
(1) NVIDIA Device Plugin：DaemonSet 形式。(2) GPU Operator：自動セットアップ。(3) nvidia-container-toolkit。(4) resources.limits.nvidia.com/gpu。(5) node label：GPU タイプ識別。
GPU 割当パターン
(1) 1 GPU / 1 Pod：シンプル。(2) 複数 GPU / 1 Pod：分散学習。(3) MIG (Multi-Instance GPU)：物理分割。(4) Time-slicing：複数 Pod が時間共有。(5) MPS (Multi-Process Service)：CUDA レベル共有。
MIG の活用
(1) A100/H100で対応。(2) 1g.10gb / 2g.20gb 等のスライス。(3) 独立メモリ：分離が強固。(4) マルチテナントに最適。(5) 推論ワークロードで威力。推論コスト最大半減も(公開情報をもとに)。
スケジューリング
(1) node selector：GPU タイプで。(2) Pod 優先度：重要処理を優先。(3) Volcano：バッチスケジューラ。(4) KubeFlow：ML パイプライン。(5) Run:AI / Volcano：GPU 専用。
分散学習
(1) PyTorch DDP/FSDP。(2) StatefulSet + Headless Service。(3) NCCL 通信：高速ネット要。(4) RDMA/InfiniBand：レイテンシ最小。(5) マルチノード対応。PyTorch 実践 もご参考に。
コスト管理
(1) 稼働率監視：50% 以下は要見直し。(2) auto-scaling：需要連動。(3) Spot/Preemptible：学習に活用。(4) MIG で共有：推論コスト削減。(5) idle 検知：自動シャットダウン。k8s コスト最適化 も合わせて。
失敗しがちなパターン
(1) GPU の専有放置：稼働率低い。(2) NCCL チューニング不足：通信ボトルネック。(3) VRAM OOM：バッチサイズ過大。(4) イメージ巨大：CUDA + cuDNN で数GB。(5) 監視なし：故障に気付かず。対策は、(1)MIG/Time-slicing、(2)RDMA、(3)gradient checkpointing、(4)multi-stage build、(5)DCGM Exporter、です。