なぜGPUは「共有」を前提に設計しなければならないのか
Kubernetesクラスタに乗るワークロードの中で、GPUほど「1人に独占させてはいけない」リソースはありません。CPUやメモリなら足りなければノードを増やせば済みますが、GPUは価格も供給も別次元です。AWSは2026年1月にH200インスタンスのオンデマンド価格を15%引き上げており、これは約2年ぶりのGPU値上げだと報じられています（cast.ai の分析）。H100クラスの単価は依然としてAWS/Azureで1時間あたり12〜13ドル前後という水準です。
それだけ高価なリソースにもかかわらず、実態はさらに深刻です。23,000を超えるKubernetesクラスタを対象にした調査では、GPUの平均利用率はわずか5%程度にとどまり、実効コストは公開されている時間単価の20倍近くに達しているという報告があります（winbuzzer の報道）。1つのチームがGPUノードを専有して眠らせている間、隣のチームは順番待ちでGPUが確保できない——この状況こそが、KubernetesにおけるGPUのマルチテナント設計を「あったら便利」ではなく「なければ回らない」要件に変えています。
だからこそ、複数チーム・複数ワークロードで1つのクラスタのGPUを分け合うマルチテナント設計が、AI基盤運用の出発点になります。ここで最初に直面する問いが、「namespaceで論理的に分けるか、ノードごと物理的に分けるか」という選択です。K3sベースの軽量KubernetesであるKuboであれば、こうしたGPUノードプールもクラウド事業者のマネージドK8sより低コストで構築できます。
namespace分離という選択 — 論理的な壁とその限界
最も手軽なマルチテナント戦略は、チームごとにnamespaceを分け、ResourceQuotaでGPU数を制限する方法です。Kubernetesは v1.10 以降、GPUのような拡張リソースもResourceQuotaの対象にでき、requests.nvidia.com/gpu: "4" のような設定でnamespace単位の上限を設定できます（Kubernetes公式ドキュメント: Resource Quotas）。GPU自体の割り当ては、Podマニフェストの limits セクションでのみ指定でき、NVIDIAなどベンダー提供のデバイスプラグインが nvidia.com/gpu という拡張リソースをkubeletに登録する仕組みが土台になっています（Kubernetes公式ドキュメント: Schedule GPUs）。
さらに、1枚のGPUを複数ワークロードで時分割共有する「time-slicing」も選択肢に入ります。NVIDIA GPU Operatorのtime-slicing機能を使えば、1つの物理GPUに対して複数のレプリカを定義し、それぞれ独立してPodに割り当てられます（NVIDIA公式ドキュメント: Time-Slicing GPUs in Kubernetes）。
ただし、namespace分離には無視できない限界があります。KubernetesのnamespaceはあくまでAPIオブジェクトのスコープを分けるものであり、GPUメモリ（VRAM）そのものを分離する仕組みではありません。あるテナントのモデルの重みがGPUメモリ上に残存したまま次のテナントに引き渡される、といったリスクが指摘されています（vcluster のGPUマルチテナンシー解説）。AWSのEKSベストプラクティスガイドでも、namespace・RBAC・NetworkPolicyによる「ソフトなマルチテナンシー」は信頼できる社内チーム向けの手法であり、外部顧客や強い規制要件がある場合は、より強固な分離が必要になると整理されています（AWS EKS Best Practices: Multi-tenancy）。
つまりnamespace分離は「コストは低いが、分離の壁は薄い」という選択です。
専用ノードという選択 — 強固な壁と重くなるコスト
もう一方の極が、GPUノードそのものをチームやワークロードに専有させる方法です。KubernetesのtaintとtolerationはPodのスケジューリングを制御する仕組みで、特定のtaintを持つノードには、対応するtolerationを持つPodしかスケジュールされません（phoenixnap の解説: Kubernetes Taints and Tolerations）。GPUノードは通常のCPUノードよりはるかに高額なため、NoSchedule effectのtaintを設定して汎用ワークロードの侵入を防ぎ、GPUを本当に必要とするPodだけを通す、という運用が一般的です。
この方式のメリットは分離の強さです。同じノード上で他チームのプロセスが動くことがないため、セキュリティ境界も、リソース競合（ノイジーネイバー問題)も明確に排除できます。一方でデメリットは明白で、専用ノードは常にそのチーム・ワークロード専用として確保され続けるため、利用が波打つワークロードでは遊休時間がそのままコストとして積み上がります。前述の「GPU平均利用率5%」問題の一因は、まさにこの「念のため専有しておく」設計判断の積み重ねにあります。
専用ノードは「分離は強いが、コストの天井が高い」という選択です。
namespace分離と専用ノードを組み合わせたハイブリッドなマルチテナント設計
namespace分離と専用ノード、どちらか一方に振り切る必要はありません。実務での現実解は、ワークロードの性質に応じて両者を組み合わせるハイブリッド設計です。
具体的には、機密性が高い、あるいはSLAが厳しい本番推論ワークロードは専用ノード＋taintで強く分離し、それ以外の実験的なワークロードや研究開発用途はnamespace分離＋ResourceQuotaで共有ノードに同居させる、という切り分けです。Mirantisのマルチテナンシー解説でも、AIワークロードにおいてはnamespace単位のGPUクォータだけでは不十分で、Priority ClassやMIG(Multi-Instance GPU)によるパーティショニングを組み合わせることが推奨されています（Mirantis: Kubernetes Multi-Tenancy Best Practices）。GPUを最大7つの独立インスタンスに分割できるMIGを、専用ノードの内部でさらに細かく配分する、という2段構えの設計も現実的な選択肢です。
このハイブリッド設計の本質は、「単一クラスタ内でコストと分離レベルのバランスを取る」という考え方そのものにあります。マルチテナントGPU基盤に唯一の正解は存在せず、ワークロードごとのリスク許容度とコスト許容度を天秤にかけて、その都度アーキテクチャを選び直す必要があるのです。
Kuboで実践するGPUマルチテナント基盤の構築
ここまで見てきたnamespace分離・専用ノード・ハイブリッドという3つの設計は、いずれもYAMLレベルでは決して複雑なものではありませんが、「どのワークロードをどちらに振り分けるか」の判断と、ResourceQuota・taint・tolerationの整合性を保守し続ける運用負荷は小さくありません。
Kubo はK3sベースの軽量Kubernetesディストリビューションでありながら、GPUノードプールを含むフルスペックのKubernetesクラスタを構築できます。AI-Driven Deploymentの仕組みにより、「本番推論用のGPUノードを専有にして、開発用ワークロードはnamespace分離で共有させたい」といった要件を自然言語で伝えるだけで、taint/tolerationとResourceQuotaの組み合わせをAIが自動生成できるのが特徴です。マルチテナントGPU基盤特有の複雑な設定管理を、No Opsの発想で解消できます。
コスト面でも、KuboはEKS/AKSと比較して同等スペックのクラスタを約半額程度で運用できる料金体系を持っています。GPUのように単価が高いリソースほど、ベースとなるクラスタ運用コストの差が総コストに効いてきます。GPUの利用率を上げる工夫(namespace分離やtime-slicing)と、クラスタ運用そのもののコストを下げる工夫(Kuboの採用)は、両輪で取り組む価値があります。
まとめ
GPUなどのAIアクセラレーターをKubernetesクラスタで複数チームに配分する際、namespace分離は低コストだが分離が弱く、専用ノードは分離が強いがコストが高いという構造的なトレードオフがあります。実務での現実解は、ワークロードの重要度・機密性に応じて両者を組み合わせるハイブリッド設計であり、「唯一の正解」を探すのではなく、自社のワークロード特性に合わせて都度アーキテクチャを選び直す姿勢こそが、マルチテナントGPU基盤運用の本質です。
自社のAIワークロードにどのGPUマルチテナント設計が適しているか判断に迷う場合は、Kubo のお問い合わせから、アーキテクチャ相談を受け付けています。AIエージェント基盤まで見据えるなら、Kuboの上で動くCaptain.AIとの組み合わせも検討する価値があります。