[{"data":1,"prerenderedAt":296},["ShallowReactive",2],{"blog-ja-k3s-gpu-oomkilled-vpa-resource-estimation":3,"blog-related-ja-k3s-gpu-oomkilled-vpa-resource-estimation":249,"blog-ja-k3s-gpu-oomkilled-vpa-resource-estimation-alt":236},{"id":4,"title":5,"author":6,"body":7,"date":230,"description":231,"extension":232,"image":233,"locale":234,"meta":235,"navigation":236,"path":237,"seo":238,"stem":239,"tags":240,"__hash__":248},"blog\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation.md","GPUメモリ不足でAIトレーニングジョブがOOMKilled。K3sでVPAが効かない理由とリソース設計","Kubo Team",{"type":8,"value":9,"toc":221},"minimark",[10,15,19,27,31,34,41,52,93,96,105,109,112,118,138,145,149,162,168,177,198,207,210,213],[11,12,14],"h2",{"id":13},"深夜に投げたジョブが朝には跡形もなく消えていた","深夜に投げたジョブが、朝には跡形もなく消えていた",[16,17,18],"p",{},"共有のKubernetesクラスタでGPUを使ったAIモデルのファインチューニングジョブを流し、翌朝確認したらOOMKilled（メモリ不足による強制終了）で止まっていた——このパターンにハマったことがある運用者は少なくないはずだ。ログには\"Killed\"の一行だけが残り、数時間分の計算コストが無駄になる。",[16,20,21,22,26],{},"厄介なのは、CPUやメモリのPodであれば経験則で「requestsを少し盛ればOK」となりがちな対処が、",[23,24,25],"strong",{},"GPUには通用しない","ことだ。GPUはKubernetesの中でも特殊な扱いを受けるリソースであり、その特殊さを理解しないままリソース設計をすると、同じ事故を繰り返すことになる。",[11,28,30],{"id":29},"なぜrequestsを盛るだけでは解決しない","なぜ「requestsを盛る」だけでは解決しない",[16,32,33],{},"CPUやメモリのrequests\u002Flimitsは、比較的柔軟に設定できる。CPUはスロットリングで緩やかに制限され、メモリも余裕を持たせたrequestsを設定すればある程度の変動を吸収できる。",[16,35,36],{},[37,38],"img",{"alt":39,"src":40},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation\u002Fsection01.webp",[16,42,43,44,51],{},"ところがGPUは事情が違う。",[45,46,50],"a",{"href":47,"rel":48},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fmanage-gpus\u002Fscheduling-gpus\u002F",[49],"nofollow","Kubernetes公式ドキュメント","には、GPUリソースの指定ルールが明記されている。",[53,54,55,74,85],"ul",{},[56,57,58,59,63,64,67,68,70,71,73],"li",{},"GPUの",[60,61,62],"code",{},"limits","は",[60,65,66],{},"requests","を指定せずに設定でき、その場合Kubernetesは",[60,69,62],{},"の値をそのまま",[60,72,66],{},"として扱う",[56,75,76,78,79,81,82],{},[60,77,62],{},"と",[60,80,66],{},"を両方指定する場合、",[23,83,84],{},"この2つの値は等しくなければならない",[56,86,87,89,90,92],{},[60,88,62],{},"を指定せずに",[60,91,66],{},"だけを指定することはできない",[16,94,95],{},"つまりGPUには、CPUのような「requestsは低めにlimitsは高めに」という緩衝設計が存在しない。1つのPodが要求したGPUは丸ごと占有され、余らせても他のPodには分配されない。だからこそ、requestsの見積もりを一段階誤ると、それがそのままOOMKilledやスケジューリング失敗に直結する。",[16,97,98,99,104],{},"さらに、",[45,100,103],{"href":101,"rel":102},"https:\u002F\u002Fwww.fairwinds.com\u002Fblog\u002Fhow-do-i-run-ai-workloads-on-kubernetes-without-wasting-gpus",[49],"Fairwinds のブログ","は「クラスタ全体のGPU平均使用率は30%を下回ることが多く、直近のデータでは5%程度にまで落ち込むケースもある」と指摘している。多くの現場で、GPUのリソース設計は「デプロイ時に決めたら見直されない」まま放置されているのが実態だ。",[11,106,108],{"id":107},"vpaに任せられないという不都合な真実","VPAに任せられない、という不都合な真実",[16,110,111],{},"「オートスケーリングに任せておけばいい」という発想は、GPUワークロードには通用しない。",[16,113,114],{},[37,115],{"alt":116,"src":117},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation\u002Fsection02.webp",[16,119,120,125,126,131,132,137],{},[45,121,124],{"href":122,"rel":123},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fvertical-pod-autoscale\u002F",[49],"Kubernetes公式のVertical Pod Autoscalerドキュメント","を確認すると、Recommenderが分析対象とするのは一貫して「CPU and memory」であり、GPUへの言及自体が存在しない。",[45,127,130],{"href":128,"rel":129},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fverticalpodautoscaler",[49],"Google Cloud の GKE ドキュメント","でも「デフォルトでVertical Pod AutoscalingはCPUとメモリの両方に対して推奨値を計算する」とされており、対象範囲は同様だ。",[45,133,136],{"href":134,"rel":135},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fkubernetes-vpa\u002F",[49],"ScaleOps のVPA解説記事","も、VPAが管理するリソースパラメータをrequests\u002Flimitsの文脈で説明する際、一貫してCPUとメモリを前提としている。",[16,139,140,141,144],{},"つまり、HPAやVPAで運用を自動化してきたチームほど、「GPUも同じように自動最適化されるはず」という思い込みに陥りやすい。しかしGPUリソースの見積もりだけは、依然として",[23,142,143],{},"人間が実測して設計する領域","として残っている。",[11,146,148],{"id":147},"では何を見積もりの拠り所にするか-実測ベースの設計手順","では何を見積もりの拠り所にするか — 実測ベースの設計手順",[16,150,151,152,157,158,161],{},"自動化に頼れない以上、頼るべきは実測データだ。",[45,153,156],{"href":154,"rel":155},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-20-kubernetes-resource-requests-limits\u002Fview",[49],"OneUptime のリソース設計ガイド","は、CPU requestsを中央値（P50）、メモリrequestsをP99の実測値に合わせ、メモリlimitsをrequestsの1.5〜2倍に設定するという考え方を紹介している。GPUの場合はrequests=limitsが強制されるため、この「limitsに余裕を持たせる」発想はそのまま使えないが、",[23,159,160],{},"実測してから数値を決める","という順序そのものは流用できる。",[16,163,164],{},[37,165],{"alt":166,"src":167},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation\u002Fsection03.webp",[16,169,170,171,176],{},"実測基盤としては、Prometheus + Grafanaでノード単位・Pod単位のGPU使用率を継続的に可視化する構成が土台になる。",[45,172,175],{"href":173,"rel":174},"https:\u002F\u002Fkubo.hexabase.io\u002F",[49],"Kubo Cloud"," はこのPrometheus + Grafana監視をK3sベースの構成に標準搭載しているため、追加の監視基盤を組まずにGPU使用量の実測を始められる。",[16,178,179,180,185,186,191,192,197],{},"一段進んだ運用では、リソースの見積もりだけでなく「誰にどれだけGPUを割り当てるか」という配分の課題も出てくる。CNCFがホストする",[45,181,184],{"href":182,"rel":183},"https:\u002F\u002Fkueue.sigs.k8s.io\u002F",[49],"Kueue","は、バッチ・AI\u002FMLワークロード向けにクォータ管理とジョブキューイングを提供し、アイドル状態のリソースプールから動的に容量を借用する仕組みを持つ。",[45,187,190],{"href":188,"rel":189},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F08\u002F27\u002Fbuilding-an-ai-factory-on-kubernetes\u002F",[49],"CNCFのブログ","(2026年8月)でも、複数チームで同一GPU群を安全に共有する「AIファクトリー」型の運用モデルが解説されており、DRAやKueueといった技術の組み合わせが実装の鍵になると述べられている。GPUをNode\u002FPodに公開する仕組み自体は",[45,193,196],{"href":194,"rel":195},"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fk8s-device-plugin",[49],"NVIDIA公式のdevice plugin","が担っており、これらのレイヤーを理解した上でrequests\u002Flimitsを設計することが、OOMKilledを未然に防ぐ最短ルートだ。",[16,199,200,201,206],{},"大規模なマルチテナント運用まで見据えるなら、",[45,202,205],{"href":203,"rel":204},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[49],"Kubo On-Premise"," のように、自社インフラ上でGPUリソースを実測・チューニングしながら段階的に拡張できる基盤を検討する価値もある。データを外部に出せない業種でGPUワークロードを扱う場合は特に、実測環境を自社管理下に置けるメリットが大きい。",[11,208,209],{"id":209},"まとめ",[16,211,212],{},"GPUはCPU\u002Fメモリと違い、requests=limitsが強制される「融通の利かない」リソースだ。VPAのような自動化は現状GPUには及ばず、見積もりの精度は依然として実測にかかっている。P50\u002FP99といった統計的な考え方を土台にしつつ、Prometheus + Grafanaでの継続的なモニタリング、そしてKueueのようなキュー管理の仕組みを組み合わせることで、「深夜に投げたジョブが朝には消えていた」という事故は避けられる。",[16,214,215,216,220],{},"AIエージェントやAIワークロードを本番運用する上で、こうした地に足のついたリソース設計を支えるインフラはますます重要になる。",[45,217,219],{"href":173,"rel":218},[49],"Kubo"," なら、K3sベースの軽量な構成で監視基盤を標準搭載しつつ、GPUワークロードのリソース設計にすぐ着手できる。AI時代のインフラを、思い込みではなく実測で支えていきたい。",{"title":222,"searchDepth":223,"depth":223,"links":224},"",2,[225,226,227,228,229],{"id":13,"depth":223,"text":14},{"id":29,"depth":223,"text":30},{"id":107,"depth":223,"text":108},{"id":147,"depth":223,"text":148},{"id":209,"depth":223,"text":209},"2026-09-20","K3s上でAIトレーニングジョブがGPUメモリ不足でOOMKilledされる原因と、Vertical Pod Autoscalerが GPU リソースには効かない理由を解説。requests\u002Flimitsの正しい見積もり方法と実測ベースの設計手順まで、運用者向けに具体的に紹介します。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation",{"title":5,"description":231},"blog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation",[241,242,243,244,245,246,247],"k3s","kubernetes","gpu","oomkilled","vpa","ai-infrastructure","resource-management","4viVTrrqzXsyMgLux7NFehRALBsLdMnqugdUAkc-jxg",[250,258,265,272,280,289],{"path":251,"title":252,"description":253,"date":254,"tags":255},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[241,242,245,256,257],"autoscaling","cgroup",{"path":259,"title":260,"description":261,"date":262,"tags":263},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[241,242,264,245,256],"hpa",{"path":266,"title":267,"description":268,"date":269,"tags":270},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[241,242,264,245,256,271],"metrics-server",{"path":273,"title":274,"description":275,"date":276,"tags":277},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[241,242,247,278,279],"capacity-planning","managed-kubernetes",{"path":281,"title":282,"description":283,"date":284,"tags":285},"\u002Fblog\u002Fja\u002Fkubernetes-mlops-gpu-scheduling-talent-shortage","AIがコードを書ける時代に、なぜインフラエンジニアの給料は上がったのか。企業のAI導入ラッシュが生んだ「MLOps人材不足」の実態","生成AIの普及でコードは誰でも書ける時代になったが、企業のAI導入が進むほどKubernetes上でGPUやモデルサービングを安定運用できるMLOps人材の需要は逆に高まっている。その理由と解決策を解説する。","2026-07-30",[242,241,286,246,287,288],"mlops","gpu-scheduling","devops",{"path":290,"title":291,"description":292,"date":293,"tags":294},"\u002Fblog\u002Fja\u002Fai-manifest-generation-kubernetes-architecture-bottleneck","AIがYAMLを1秒で書いても、クラスタは1秒も速くならない。Kubernetes運用の本当のボトルネックはコードではなくアーキテクチャという話","AIでKubernetesマニフェストを爆速生成しても、本番のKubernetes運用が速くなるとは限らない。CPUスロットリング、HPAとVPAの競合、DB接続不足という3つの本当のボトルネックと、AIと人間の役割分担を解説する。","2026-07-18",[242,241,247,256,295,288],"ai-ops",1792592605567]