深夜に投げたジョブが、朝には跡形もなく消えていた
共有のKubernetesクラスタでGPUを使ったAIモデルのファインチューニングジョブを流し、翌朝確認したらOOMKilled（メモリ不足による強制終了）で止まっていた——このパターンにハマったことがある運用者は少なくないはずだ。ログには"Killed"の一行だけが残り、数時間分の計算コストが無駄になる。
厄介なのは、CPUやメモリのPodであれば経験則で「requestsを少し盛ればOK」となりがちな対処が、GPUには通用しないことだ。GPUはKubernetesの中でも特殊な扱いを受けるリソースであり、その特殊さを理解しないままリソース設計をすると、同じ事故を繰り返すことになる。
なぜ「requestsを盛る」だけでは解決しない
CPUやメモリのrequests/limitsは、比較的柔軟に設定できる。CPUはスロットリングで緩やかに制限され、メモリも余裕を持たせたrequestsを設定すればある程度の変動を吸収できる。
ところがGPUは事情が違う。Kubernetes公式ドキュメントには、GPUリソースの指定ルールが明記されている。
- GPUの
limitsはrequestsを指定せずに設定でき、その場合Kubernetesはlimitsの値をそのままrequestsとして扱う limitsとrequestsを両方指定する場合、この2つの値は等しくなければならないlimitsを指定せずにrequestsだけを指定することはできない
つまりGPUには、CPUのような「requestsは低めにlimitsは高めに」という緩衝設計が存在しない。1つのPodが要求したGPUは丸ごと占有され、余らせても他のPodには分配されない。だからこそ、requestsの見積もりを一段階誤ると、それがそのままOOMKilledやスケジューリング失敗に直結する。
さらに、Fairwinds のブログは「クラスタ全体のGPU平均使用率は30%を下回ることが多く、直近のデータでは5%程度にまで落ち込むケースもある」と指摘している。多くの現場で、GPUのリソース設計は「デプロイ時に決めたら見直されない」まま放置されているのが実態だ。
VPAに任せられない、という不都合な真実
「オートスケーリングに任せておけばいい」という発想は、GPUワークロードには通用しない。
Kubernetes公式のVertical Pod Autoscalerドキュメントを確認すると、Recommenderが分析対象とするのは一貫して「CPU and memory」であり、GPUへの言及自体が存在しない。Google Cloud の GKE ドキュメントでも「デフォルトでVertical Pod AutoscalingはCPUとメモリの両方に対して推奨値を計算する」とされており、対象範囲は同様だ。ScaleOps のVPA解説記事も、VPAが管理するリソースパラメータをrequests/limitsの文脈で説明する際、一貫してCPUとメモリを前提としている。
つまり、HPAやVPAで運用を自動化してきたチームほど、「GPUも同じように自動最適化されるはず」という思い込みに陥りやすい。しかしGPUリソースの見積もりだけは、依然として人間が実測して設計する領域として残っている。
では何を見積もりの拠り所にするか — 実測ベースの設計手順
自動化に頼れない以上、頼るべきは実測データだ。OneUptime のリソース設計ガイドは、CPU requestsを中央値（P50）、メモリrequestsをP99の実測値に合わせ、メモリlimitsをrequestsの1.5〜2倍に設定するという考え方を紹介している。GPUの場合はrequests=limitsが強制されるため、この「limitsに余裕を持たせる」発想はそのまま使えないが、実測してから数値を決めるという順序そのものは流用できる。
実測基盤としては、Prometheus + Grafanaでノード単位・Pod単位のGPU使用率を継続的に可視化する構成が土台になる。Kubo Cloud はこのPrometheus + Grafana監視をK3sベースの構成に標準搭載しているため、追加の監視基盤を組まずにGPU使用量の実測を始められる。
一段進んだ運用では、リソースの見積もりだけでなく「誰にどれだけGPUを割り当てるか」という配分の課題も出てくる。CNCFがホストするKueueは、バッチ・AI/MLワークロード向けにクォータ管理とジョブキューイングを提供し、アイドル状態のリソースプールから動的に容量を借用する仕組みを持つ。CNCFのブログ(2026年8月)でも、複数チームで同一GPU群を安全に共有する「AIファクトリー」型の運用モデルが解説されており、DRAやKueueといった技術の組み合わせが実装の鍵になると述べられている。GPUをNode/Podに公開する仕組み自体はNVIDIA公式のdevice pluginが担っており、これらのレイヤーを理解した上でrequests/limitsを設計することが、OOMKilledを未然に防ぐ最短ルートだ。
大規模なマルチテナント運用まで見据えるなら、Kubo On-Premise のように、自社インフラ上でGPUリソースを実測・チューニングしながら段階的に拡張できる基盤を検討する価値もある。データを外部に出せない業種でGPUワークロードを扱う場合は特に、実測環境を自社管理下に置けるメリットが大きい。
まとめ
GPUはCPU/メモリと違い、requests=limitsが強制される「融通の利かない」リソースだ。VPAのような自動化は現状GPUには及ばず、見積もりの精度は依然として実測にかかっている。P50/P99といった統計的な考え方を土台にしつつ、Prometheus + Grafanaでの継続的なモニタリング、そしてKueueのようなキュー管理の仕組みを組み合わせることで、「深夜に投げたジョブが朝には消えていた」という事故は避けられる。
AIエージェントやAIワークロードを本番運用する上で、こうした地に足のついたリソース設計を支えるインフラはますます重要になる。Kubo なら、K3sベースの軽量な構成で監視基盤を標準搭載しつつ、GPUワークロードのリソース設計にすぐ着手できる。AI時代のインフラを、思い込みではなく実測で支えていきたい。