AI向けのGPUは足りないのに、使われ方は驚くほど悪い。Cast AIのレポートは、その矛盾を数字で突きつけています。
この記事では、Kubernetes環境でGPUやCPU、メモリがどれだけ無駄になっているのかを整理し、何を見れば改善できるのかを実務目線でまとめます。
- 2026年のKubernetes最適化レポートが示した最新の利用率
- どこでコストが膨らみやすいのか
- まず確認すべき指標と改善の進め方
https://cast.ai/press-release/new-kubernetes-cost-benchmark-report-reveals-persistent-cloud-waste
レポートが示した現実
Cast AIの2025年版Kubernetes Cost Benchmark Reportは、AWS、Azure、GCPにまたがる2,100以上の組織を分析し、Kubernetesの資源利用が依然として低いと示しました。平均CPU利用率は10%、メモリ利用率は23%です。GPUの話になるとさらに厳しく、2026年版のState of Kubernetes Optimization Reportでは平均GPU利用率が5%という数字が出ています。AI基盤に高価なGPUを積み増しても、実際の稼働が追いついていない状況です。
この数字の意味は単純です。需要があるから増やす、ではなく、今あるリソースの使い切り方が甘いまま追加調達している現場が多いということです。特にKubernetesでは、将来の負荷に備えてCPUやメモリを厚めに申請しやすく、そのまま過剰確保が常態化します。結果として、ノードは空いているのに請求だけが膨らみます。
無駄が発生する場所
Kubernetesの無駄は、単に「未使用インスタンスがある」という話ではありません。よくある原因は3つです。
- requestsが実使用量より大きい
- node選定が固定化されている
- GPUを特定リージョンに縛り、割高な在庫を買っている
Google Cloudのドキュメントでも、Cost OptimizationタブではCPUのUsed、Requested、Allocatableを並べて確認でき、メモリも同様に比較できると説明されています。つまり、見るべきなのは稼働量そのものではなく、実使用量と要求量の差です。この差が大きいほど、請求に直結する無駄が増えます。
何を見ればよいか
改善の起点は、利用率の平均値を眺めることではありません。まず、クラスタ単位とワークロード単位で次の差分を確認します。
- CPU Used と Requested の差
- メモリ Used と Requested の差
- GPUの実利用時間と割当時間の差
- リージョン別の単価差
この4点を見れば、どこが構造的に過剰なのかが見えます。平均CPU利用率が10%でも、すべてのワークロードが均一に悪いわけではありません。特定のサービスだけが過大申請していることも多いです。そこを外すと、オートスケールを入れても効果が薄くなります。
Spotと自動最適化が効く理由
Cast AIのレポートでは、Spot Instancesを部分的に使うと平均59%のコスト削減、全面的に使うと77%の削減が示されています。さらに、GPUの配置をより安い地域へ移せる場合、平均Spot価格比で2倍から7倍、オンデマンド価格比で3倍から10倍の差が出るとしています。
ここで重要なのは、Spotを使うこと自体ではなく、負荷を自動で移せるかどうかです。人手でリージョンをまたぐ運用を続けると、実務では切り替えが遅れます。自動化は、安い場所を探すだけでなく、そこに安全に寄せる仕組みまで含めて考える必要があります。
実務での始め方
すぐにやるべきことは大きくありません。まずは現状把握です。
- KubernetesのCost Optimization画面で、UsageとRequestの差を確認する
- GPUを使うワークロードだけを抜き出し、稼働率を別管理する
- リージョン固定の前提を見直し、価格差を比較する
- Spotを入れるなら、障害時の退避先を先に決める
この順番にすると、いきなり大きな構成変更をせずに改善余地を見つけられます。逆に、いきなり自動化製品を入れても、前提の無駄が見えていないと効果の説明ができません。
まとめ
Kubernetesのコスト問題は、クラスタを増やせば解決する種類の話ではありません。利用率の低さ、とくにGPUの5%という数字は、AI基盤の投資がそのまま価値になっていない現実を示しています。
まず見るべきなのは、リソースの請求額ではなく、RequestedとUsedの差です。そこを詰めたうえで、Spotやリージョン分散、自動最適化を組み合わせると、削減幅は一段大きくなります。