Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 一枚を複数で使う二つの方法
time-slicing — 時間を分ける
MIG — ハードウェアを分ける
隔離水準の差が生む結果
何をいつ選ぶか
おわりに — 共有は資源の問題ではなく信頼の問題
試してみる
シリーズ
参考資料

はじめに — 一枚を複数で使う二つの方法

前回は、GPUが拡張リソースとして整数でしか要求されず、ハードウェアに隔離の仕組みが無いためそのまま分け合えないという話をしました。ところが実務では分けたい理由が次々に出てきます。ノートPC規模の推論モデルを何個か一枚に載せたいし、開発者八人に一枚ずつ配る予算は無いのです。

NVIDIAが用意した答えは二つで、両者は名前が似ているだけで性質が異なります。一方は時間を分け、他方はハードウェアを分けます。選ぶ基準は性能ではなく隔離です。

メトリクス名と設定は2026-08-12に公式ドキュメント・リポジトリで確認しました。バージョンによって異なる場合があるため、使用中のバージョンで再確認してください。

time-slicing — 時間を分ける

time-slicingは、デバイスプラグインに物理GPU一枚を複数のレプリカとして広告させる設定です。ハードウェアは一切変わりません。スケジューラが見る数だけが増えます。

公式ドキュメントが示すConfigMap構造はこうです。

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: 4

重要なフィールドは三つです。replicasは一枚を何個として広告するかを決めます。renameByDefaultはそのレプリカを元の名前で広告するか共有専用の名前で広告するかを選びます。真にすると広告されるリソースがnvidia.com/gpu.sharedに変わり、偽なら名前はnvidia.com/gpuのままです。failRequestsGreaterThanOneは一つのコンテナがレプリカを二つ以上要求したときに失敗させるかを決めます。

実務で最も危険なスイッチがrenameByDefaultです。偽のままだと、既存のマニフェストが誰も触っていないのにある日から共有GPUを受け取り始めます。真にすると名前が変わるので共有を望むPodはマニフェストを直す必要が生じますが、その代わり事故が静かに起きません。

適用はClusterPolicy経由で行います。

kubectl create -n gpu-operator -f time-slicing-config.yaml

kubectl patch clusterpolicies.nvidia.com/cluster-policy \
  -n gpu-operator --type merge \
  -p '{"spec": {"devicePlugin": {"config": {"name": "time-slicing-config-all", "default": "any"}}}}'

ノードごとに別設定を与えたい場合は、ノードにnvidia.com/device-plugin.configラベルを付けてConfigMapのどのキーを使うかを指定します。複製倍数はnvidia.com/gpu.replicasラベルで確認できます。

そしてドキュメントが強調する一文があります。MIGと違い、レプリカ間にはメモリ隔離も障害隔離も無いということです。この一文の実務的な意味は後で改めて扱います。

MIG — ハードウェアを分ける

MIGはGPUをハードウェア水準で複数のインスタンスに分割します。インスタンスごとにメモリスライスと演算資源が物理的に分離されるため、ドキュメントの表現どおりCUDAアプリケーションに分離された安全なGPUインスタンスを提供します。ただし条件があります。Ampere以降のアーキテクチャに基づくGPUでのみ動作します。 A100が代表例としてドキュメントに挙がっています。

GPU OperatorではMIGをノードラベルで操作します。

# ノードがMIGに対応しているか確認
kubectl get nodes -L nvidia.com/mig.capable,nvidia.com/mig.strategy

# プロファイルを適用
kubectl label nodes <node-name> nvidia.com/mig.config=all-1g.5gb --overwrite

# 適用状態を追跡 (pending / rebooting / success / failed)
kubectl get node <node-name> -o jsonpath='{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}'

nvidia.com/mig.config.stateが状態機械の役目を果たします。ラベルを付けた直後にpendingへ移り、必要ならrebootingを経てsuccessかfailedで終わります。このラベルを見ずに待って時間を無駄にする例が実務では多くあります。

リソースがどう広告されるかは戦略で分かれます。single戦略はノードの全GPUでMIGが有効かつプロファイルが統一されている場合を、mixed戦略はそうでない場合を扱います。mixedではプロファイルごとにリソースが分かれ、リポジトリのドキュメント基準でA100 40GBではnvidia.com/mig-1g.5gb、nvidia.com/mig-2g.10gb、nvidia.com/mig-3g.20gb、nvidia.com/mig-7g.40gbが、A100 80GBではnvidia.com/mig-1g.10gb、nvidia.com/mig-2g.20gb、nvidia.com/mig-3g.40gb、nvidia.com/mig-7g.80gbが現れます。プロファイル別の個数はnvidia.com/mig-1g.10gb.countのようなラベルでも露出します。

Helmチャートの既定戦略はmig.strategy: singleです。MIG Managerにカスタム設定を渡すには、ConfigMapにconfig.yamlというキーが必ず必要だとチャートのコメントが明示しています。

隔離水準の差が生む結果

両方式の違いを表にするとこうなります。

項目	time-slicing	MIG
分ける対象	時間	ハードウェア
メモリ隔離	無し	有り
障害隔離	無し	有り
対応ハードウェア	事実上制限なし	Ampere以降
適用方法	ConfigMapとClusterPolicy	ノードラベルとMIG Manager
ノード再起動	不要	プロファイル変更時に必要な場合あり
広告リソース	元の名前または共有専用の名前	プロファイル別に分かれた名前

最も重要なのは隔離の二行です。time-slicingではレプリカ一つがVRAMを食い尽くすと、同じカードの別レプリカがメモリ確保に失敗します。スケジューラから見れば両方のPodが正常にリソースを受け取っているのに、実際には片方がもう片方を飢えさせている状態です。さらに悪いのは障害隔離が無いほうで、あるワークロードがGPUを異常状態にすると同じカードの全レプリカが一緒に倒れます。

そこから判断基準が出ます。レプリカ同士が互いを信頼できるか。 同じチームの同じサービスを複数立てるのなら信頼できます。別々のチーム、別々の顧客、あるいは利用者がコードを持ち込むノートブック環境なら信頼できません。

何をいつ選ぶか

まとめると選択はおおむねこう分かれます。

time-slicingが合うのは開発と実験の環境、対話的なノートブック、そしてGPUをごく短時間しか使わないバッチ処理です。共通点は、隔離が破れたときの損害がリトライで済むことです。信頼境界の内側で、人が見ていて、失敗しても回し直せます。

MIGが合うのは本番の推論サービング、マルチテナント、そして遅延を約束しなければならないサービスです。特にSLOを掲げるサービスなら選択肢は事実上一つです。隣のインスタンスの負荷が自分の遅延に影響する状態では、どんな約束も守れません。

どちらでもない場合も珍しくありません。大きなモデルをサービングしていてVRAMが既にぎりぎりなら、分けるものがありません。このとき必要なのは共有ではなくバッチサイズとKVキャッシュ設定の調整であり、その判断には観測データが要ります。次の二回がそのデータの出どころを扱います。

おわりに — 共有は資源の問題ではなく信頼の問題

GPU共有を資源活用率の問題としてだけ見ると、ほぼ必ずtime-slicingに落ち着きます。設定が簡単でハードウェアを選ばず即座に効果が見えるからです。そしてある日、一つのPodが別のPodを殺し、原因究明に丸一日かかります。

共有方式は活用率ではなく信頼境界で選ぶのが正解です。 同じ境界の内側なら時間を分け、境界を越えるならハードウェアを分けます。ハードウェアが対応しないなら分けません。この順序を守れば、後から説明しづらい障害が大きく減ります。

次回は、こう構成したGPUが実際にどう使われているかを見る方法、つまりDCGM Exporterを扱います。

試してみる

K8s 実習ラボ — ConfigMapとノードラベルを扱う流れを自分でたどってください。
LLM GPUメモリ(VRAM)計算機 — 一枚に何個載るかをまず計算してみてください。
Kubestronautクイズ — ラベルとセレクタの理解を問題で点検してください。

シリーズ

前の記事: デバイスプラグインとGPUスケジューリング
次の記事: DCGM Exporter — GPUメトリクスは実際に何を測っているのか

参考資料

GPU Operator time-slicingドキュメント: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
GPU Operator MIGドキュメント: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html
NVIDIA k8s-device-pluginリポジトリ: https://github.com/NVIDIA/k8s-device-plugin
gpu-operatorリポジトリ values.yaml: https://github.com/NVIDIA/gpu-operator/blob/main/deployments/gpu-operator/values.yaml