{
  "format": "agent-article-v0",
  "article_id": "EA-746",
  "canonical_url": "/tools/ea-746-gpu-sharing-isolation-decision-mig-vs-time-slicing",
  "page_type": "decision",
  "claim_ids": [],
  "evidence_ids": [
    "EA-746-CURRENT-APPROVAL",
    "EA-746-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-746-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-20",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "EA746-CANDIDATE-20261020-0904JST-C1",
    "BODY-SHA256:201783a0464e53ff2d2ec97b00d30f36e63dc37c773ddaca2c6d373100a18e17"
  ],
  "article_sources": [
    {
      "id": "EA-746-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "EA746-CANDIDATE-20261020-0904JST-C1"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-746&revision_id=EA-746-REV-20261020-0904JST&candidate_id=EA746-CANDIDATE-20261020-0904JST-C1",
        "EA-746-REV-20261020-0904JST"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-746-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-20",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:201783a0464e53ff2d2ec97b00d30f36e63dc37c773ddaca2c6d373100a18e17"
      ],
      "supporting_locators": [
        "content/staging/EA-746.md",
        "201783a0464e53ff2d2ec97b00d30f36e63dc37c773ddaca2c6d373100a18e17",
        "EA-746-REV-20261020-0904JST"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "主要claim",
      "text": "GPU共有方式は「利用率を上げる」という単一目的で選ばず、必要なmemory/fault isolation、性能予測性、GPU機種、workload size、再構成停止許容度を入力にしてMIGとtime-slicingを使い分ける。NVIDIAのMIG User Guideは、MIGが対応GPUを複数のGPU Instanceへ分割し、各instanceへ独立したcompute/memory resourceを割り当て、memory systemの経路・L2 cache・memory controller・DRAM bus等を分離することでpredictable throughput/latencyとfault isolationを提供すると説明している。\n\n一方、NVIDIA GPU Operator/OpenShiftのtime-slicing文書は、CUDA time-slicingで同一GPUを複数replicaとして共有できるが、MIGと異なりreplica間にmemory isolationもfault isolationもないと明記している。したがって、Kubernetes上で`nvidia.com/gpu` replica数が増えたことを、独立した物理GPUやMIG sliceが増えたことと解釈してはならない。\n\n2026年10月時点のGPU Operator 26.3系では、MIG ManagerがMIG-capable GPUのprofileをNVMLから発見してnodeごとのconfigurationを生成できる。MIG geometry変更時にはGPU上でuser workloadが動作していないことが必要で、環境によってはnode rebootも必要になる。MIGは強い分離と予測性を得られる一方、運用上はprofile/geometry管理と再構成コストを持つ。"
    },
    {
      "heading": "運用上の意味・failure",
      "text": "time-slicingは、短いjobやGPUを常時飽和させない同一trust-domain workloadの収容密度を上げる手段として有効である。しかしmemory/fault isolationを提供しないため、強いtenant isolationや性能SLOを必要とするworkloadに「共有GPUだが実質専有」と説明すると設計上の誤りになる。\n\nMIGはGPUをhardware-level resource partitionへ分けるため、他instanceのmemory trafficやcompute contentionの影響を抑え、QoSとfault isolationを取りやすい。ただし利用できるGPU、profile、driver/operator versionには制約があり、profileの固定分割によってworkload sizeとslice geometryが合わない場合はfragmentationが生じる。MIGを有効化しただけでcluster全体の利用率が上がるとは限らない。\n\nまた「MIG vs time-slicing」は常に排他的二択ではない。vGPU等の別レイヤーではMIG-backed time-sliced構成も存在するため、比較時にはKubernetes device-plugin time-slicing、MIG bare-metal/container、vGPUを混同しない。"
    },
    {
      "heading": "具体的control / implementation implication",
      "text": "1. GPU poolごとに `sharing_mode=exclusive|mig|time_slicing`、GPU model、driver、GPU Operator/device-plugin version、MIG capability、MIG profile、replica countをinventory化する。\n2. workload classに `isolation_required`, `memory_guarantee`, `latency_slo`, `throughput_slo`, `gpu_memory_request`, `trusted_co_tenant`, `preemption_tolerance` を持たせ、scheduler policyへ入力する。\n3. tenant境界またはfault containmentが必要なら、Kubernetes time-slicingだけを分離controlとして扱わない。MIGまたは別のVM/vGPU/physical isolationを評価する。\n4. time-slicing poolでは、replica数をcapacity multiplierとして表示する場合でも「物理memory容量がreplica数倍になった」とcapacity accountingしない。OOM、latency tail、context-switch/contentionをload testする。\n5. MIG poolでは、profileごとのSM/memory capacityと実workload分布を照合し、未使用sliceと「大きなjobが入らない」fragmentationを別指標で監視する。\n6. MIG geometry変更は通常request pathから分離し、node drain/cordon、GPU client停止、必要時reboot、configuration state readbackを含むmaintenance operationとして扱う。\n7. rollout前に同一workload mixでexclusive / MIG / time-slicingを比較し、GPU utilizationだけでなくp50/p95/p99 latency、throughput、OOM/fault propagation、queue wait、reconfiguration downtimeを記録する。"
    },
    {
      "heading": "適用境界",
      "text": "MIGの分離保証は対応GPUと対応構成に依存する。NVIDIAはAmpere以降の対応GPUを対象としており、すべてのGPUが同じprofileや機能を持つわけではない。GPU Operatorの具体的profile生成やMIG Manager挙動もversion/driverで変わるため、clusterのlive versionとhardwareを確認する。\n\ntime-slicingの性質も実装面で区別する。GPU Operator/device-pluginによるKubernetes time-slicingとNVIDIA vGPUのtime-sliced schedulerは同じ「時間共有」の概念を持つが、管理境界・virtualization・isolation contractは同一ではない。本記事のcontrolは共有方式の選択原則であり、vGPU licensingやhypervisor-specific保証まで一括して断定しない。"
    },
    {
      "heading": "counterevidence / limitations",
      "text": "MIGは強い分離を提供するが、固定partitionが小規模・変動workloadに対して常に効率的とは限らない。time-slicingは分離が弱い一方、MIG非対応GPUでも利用でき、細粒度jobの収容率を上げられる場合がある。したがって「MIGが常に上位互換」という結論は不適切である。\n\nMIGでは通信機能にも制約があり、NVIDIA CUDA-X Deployment documentationはMIG利用時のCUDA IPCやNVLink/NVSwitchに関する制約を示している。distributed/HPC workloadでは、単一GPU内の分離だけでなくinter-GPU communication requirementを先に確認する必要がある。\n\n性能はmodel、batch size、kernel shape、memory bandwidth、concurrency、driver/runtimeに依存するため、一般的なMIG/time-slicing比較値を自環境のSLOへそのまま移植しない。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- 現行clusterで利用しているGPU SKUごとのMIG profileとdriver/operator compatibility。\n- workload mix別のMIG fragmentationとtime-slicing contentionの実測break-even。\n- GPU fault種別ごとのMIG instance境界でのcontainment範囲。\n- distributed inference/trainingでMIG通信制約がend-to-end throughputへ与える影響。\n- MIG-backed vGPU等を含めたvirtualization layerとの最終isolation contract。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「MIGは対応GPUをhardware-levelのGPU instanceへ分割し、compute/memory resourceの分離と予測性を得る方式である。KubernetesのCUDA time-slicingは同一GPUを時間共有して収容密度を上げるが、replica間のmemory/fault isolationを提供しない。選択は利用率だけでなく、tenant/fault isolation、性能SLO、workload size、対応GPU、MIG再構成コストを含めて決め、実workloadで検証する。」"
    },
    {
      "heading": "Source / provenance locators",
      "text": "- NVIDIA Multi-Instance GPU User Guide, Introduction / latest, accessed 2026-10-20.\n- NVIDIA GPU Operator 26.3, “GPU Operator with MIG”, including MIG Manager/profile generation and reconfiguration prerequisites, accessed 2026-10-20.\n- NVIDIA GPU Operator on Red Hat OpenShift, “Time-slicing NVIDIA GPUs in OpenShift”, accessed 2026-10-20.\n- NVIDIA CUDA-X Deployment Documentation, “Multi-Instance GPU (MIG)”, communication/isolation limitations, accessed 2026-10-20.\n- NVIDIA Virtual GPU Software Documentation 19.0, MIG-backed and time-sliced vGPU architecture, accessed 2026-10-20."
    }
  ],
  "human_url": "/tools/ea-746-gpu-sharing-isolation-decision-mig-vs-time-slicing",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-746-gpu-sharing-isolation-decision-mig-vs-time-slicing",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-746-gpu-sharing-isolation-decision-mig-vs-time-slicing"
}