KubernetesにおけるGPUの分割利用

By シュバム・ライ

Published: July 6, 2026

Built for Speed: ~10ms Latency, Even Under Load

Blazingly fast way to build, track and deploy your models!

Handles 350+ RPS on just 1 vCPU — no tuning needed
Production-ready with full enterprise support

Get Started with Truefoundry Now Talk to the Expert

概要

GenAI革命により、業界全体でGPUの需要が急増しています。企業は大量のLLMをトレーニング、ファインチューニング、デプロイしたいと考えています。これにより、最新のGPUの入手性が低下し、価格が高騰しました。パブリッククラウドでワークロードを実行している企業は、GPUの可用性を巡る高価格と不確実性の増大に苦しんでいます。

このような新たな状況において、利用可能なGPUを最大限に活用できることは極めて重要です。単一のGPUを複数のプロセス間で分割または共有することが、この問題の解決に役立ちます。これをKubernetes上で実装することで、オートスケーリングと高度なスケジューラを活用し、GPU利用率を最適化できるという、非常に優れた組み合わせが実現します。

GPUを共有するためのオプション

Kubernetesで単一のGPUを複数のワークロードと共有するには、以下のオプションがあります。

MIG

Multi-Instance GPU (MIG) は、NVIDIA AmpereアーキテクチャベースのGPU（NVIDIA A100など）を、CUDAアプリケーション向けに個別のGPUインスタンスに安全に分割することを可能にします。各パーティションはメモリと計算が完全に分離されており、予測可能なスループットとレイテンシを提供できます。

単一のNVIDIA A100 GPUは、最大7つの独立したGPUインスタンスに分割できます。各パーティションは、分割されたノードで実行されているソフトウェアからは個別のGPUとして認識されます。その他のMIG対応GPUとサポートされるパーティション数は、以下に記載されていますこちら。
詳細情報こちら

メリット

予測可能なレイテンシとスループットをサポートできる、完全な計算およびメモリ分離
nvidia-device-pluginKubernetes向けnvidia-device-pluginはMIGをネイティブでサポートしています

デメリット

A100、H100、A30などの最新GPUのみがサポートされています。そのため、利用可能な選択肢が制限されます。
ほとんどのアーキテクチャでは、パーティション数は7という厳格な制限があります。メモリと計算要件が限られた小規模なワークロードを実行している場合、これはかなり少ない数です。

タイムスライシング

タイムスライシングにより、複数のワークロードを同じGPU上でスケジュールできます。複数のプロセス間で計算時間が共有され、プロセスは時間的にインターリーブされます。クラスター管理者は、クラスターまたはノードを設定して特定のレプリカ数/GPUをアドバタイズさせ、それに応じてノードを再構成できます。

利点

単一のGPUを共有できるポッドの数に上限がない
古いバージョンのNVIDIA GPUでも動作可能

欠点

メモリまたは障害の分離がない。ワークロードが割り当てられたメモリをオーバーランしないようにするための組み込みの方法はありません。
タイムスライシングは、実行中のすべてのプロセスに均等な時間を提供します。複数のプロセスを実行しているポッドは、意図したよりもはるかにCPUを占有する可能性があります。

GPU共有にはMPSやvGPUのような他の選択肢もありますが、それらは`nvidia-device-plugin`でネイティブサポートされていないため、ここでは説明しません。

タイムスライシングのデモ

Azure Kubernetes Serviceでタイムシェアリングをどのように利用できるかについて、簡単なウォークスルーを見ていきましょう。既存のKubernetesクラスターから始めます。

1. クラスターにGPU対応ノードプールを追加する

 
$ az aks nodepool add \
    --name <nodepool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --node-vm-size Standard_NC4as_T4_v3 \
		--node-count 1

‍‍これにより、単一のNVIDIA T4 GPUを持つ既存のAKSクラスターに、単一ノードの新しいノードプールが追加されます。これは、以下を実行することで確認できます。

 
$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'

2. GPUオペレーターをインストールする


$ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
	&& helm repo update
$ helm install gpu-operator nvidia/gpu-operator \
-n gpu-operator --create-namespace \
--set driver.enabled=false \
--set toolkit.enabled=false \
--set operator.runtimeClass=nvidia-container-runtime

3. オペレーターがインストールされたら、タイムスライシング構成を作成し、クラスター全体を設定して、利用可能なGPUリソースをスライスするようにします。‍‍


$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 10
EOF

# Reconfigure gpu operator to pick up the config map
$ kubectl patch clusterpolicy/cluster-policy \
-n gpu-operator --type merge \
-p '{"spec": {"devicePlugin": {"config": {"name": "time-slicing-config", "default": "any"}}}}'

4. 既存のノードが正常に再構成されたことを確認します。‍


$ kubectl get nodes <gpu-node-name> -o 'jsonpath={.status.allocatable.nvidia\.com\/gpu}'
10

5. 4つのレプリカを持ち、それぞれが2つのnvidia.com/gpuリソースを要求するデプロイメントを作成することで、設定を確認できます。


$ kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: time-slicing-verification
  labels:
    app: time-slicing-verification
spec:
  replicas: 4
  selector:
    matchLabels:
      app: time-slicing-verification
  template:
    metadata:
      labels:
        app: time-slicing-verification
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      hostPID: true
      containers:
        - name: cuda-sample-vector-add
          image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubuntu20.04"
          command: ["/bin/bash", "-c", "--"]
          args:
            - while true; do /cuda-samples/vectorAdd; done
          resources:
           limits:
             nvidia.com/gpu: 1
EOF

このデプロイメントのすべてのPodが、既に作成された同じノード上で起動し、それらを収容できたことを確認します。

結論

GenAI革命はGPU要件の状況を一変させ、リソース利用に対する責任がこれまで以上に重要になっています。ここで概説した両方のアプローチには欠点がありますが、現在の状況ではGPUコストに責任を持つことからは逃れられません。

TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

Built for Speed: ~10ms Latency, Even Under Load

Schedule your Demo Now