# 分散AI workloadのgang scheduling＋topology-aware placement CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-748-ai-workload-gang-scheduling-topology-aware-placement CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-748-URL-1DA6B5BDFE90, EVD-EA-748-URL-7245EBE029F0, EVD-EA-748-URL-DBD91671DFA3, EVD-EA-748-URL-C57DDC8BBE29, EA-748-CURRENT-APPROVAL, EA-748-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-748-UNKNOWN-01 OPS_IDS: none ## Summary 「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic性、通信特性、queue待機、fragmentationを実測して制約を決める。」 ## Current judgment 「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic性、通信特性、queue待機、fragmentationを実測して制約を決める。」 ## Scope 分散AI workloadのgang scheduling＋topology-aware placement ## Confirmed ## UNKNOWN - EA-748-UNKNOWN-01: - workload/modelごとのsame-host / same-rack / same-block requirementの実測break-even。 - NVLink/NVSwitch/RDMA/EFA等のfabric情報をKubernetes topology modelへどこまで正確に投影できるか。 - gang待機によるfragmentationとtopology locality benefitの最適trade-off。 - autoscalerがnode追加中のときのgang admission/topology reservation整合性。 - elastic workloadのminimum viable replicasとquality/throughput/SLOの関係。 - topology metadata driftを検出する標準的なreadback方法。 ## Evidence - EVD-EA-748-URL-1DA6B5BDFE90 (RESEARCH): Kubernetes SIG Scheduling / Kueue, “Topology-Aware Scheduling”, accessed 2026-10-21: — https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/ - EVD-EA-748-URL-7245EBE029F0 (RESEARCH): Kubernetes SIG Scheduling / Kueue, “All-or-nothing Scheduling”, v0.20 docs, accessed 2026-10-21: — https://kueue.sigs.k8s.io/v0.20/docs/concepts/all_or_nothing/ - EVD-EA-748-URL-DBD91671DFA3 (RESEARCH): Volcano, “Gang”, v1.15.0, accessed 2026-10-21: — https://volcano.sh/docs/v1.15.0/scheduler/plugins/gang/ - EVD-EA-748-URL-C57DDC8BBE29 (RESEARCH): Volcano, “PodGroup”, accessed 2026-10-21: — https://volcano.sh/docs/concepts/podgroup/ - EA-748-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-748-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits gang schedulingだけでは「全workerが起動したが、遠いrackへ分散してcollective通信が遅い」問題を防げません。逆にtopology preferenceだけでは、必要workerの一部だけがresourceを保持したまま残りを待つpartial allocationを防げません。したがって、distributed AI workloadではadmission completenessとplacement qualityを別controlとして設計します。 典型的failureは、cluster全体のfree GPU数だけでadmissionすること、GPU SKUだけを揃えてNVLink/NVSwitch/RDMA/rack localityを無視すること、gang sizeを「desired replica数」と固定してelastic trainingのminimum viable sizeを表現しないこと、topology labelが古い・誤っている状態でscheduler判断を信頼することです。 また、gang schedulingはresource availabilityを作り出しません。大きなgangを無期限に待たせるとqueue head-of-line blockingやfragmentationを増やす可能性があります。priority、preemption、quota borrowing、backfill、elastic/partial admissionの可否をworkload classごとに定義します。 ## Failure / limits topology localityを強く要求すると、近接resourceが揃うまでjob開始が遅れ、throughputやqueue fairnessが悪化する場合があります。communication-light workloadでは、厳しいsame-rack制約より早期開始の方がend-to-end completionを改善する可能性があります。 gang schedulingも常に全replica同時開始が最適とは限りません。elastic trainingやfault-tolerant inferenceでは、縮小構成で開始して後からscale outできる場合があります。したがってall-or-nothingはworkload semanticsから導出し、distributed AIという理由だけで一律適用しません。 ## 要点と前提 分散trainingやmulti-node inferenceでは、必要なworker数が揃わないpartial placementと、通信fabricを無視した配置を別々のfailureとして扱う必要があります。EA-748では、gang schedulingを「必要pod群が同時に実行可能な状態を作る admission/scheduling control」、topology-aware placementを「通信・accelerator topologyを踏まえて実行場所を選ぶ placement control」として分離し、両者を組み合わせます。 ## 主要claim Kueueの現行Topology-Aware Scheduling（TAS）は、AI/ML workloadではpod間bandwidthがexecution timeとcostへ直結し、rack/block等のdata-center hierarchyに応じてnode間距離が異なることを前提にしています。TASはnode labelでtopology hierarchyを表し、queue/resource flavorと結び付けてplacementを考慮します。Kueue v0.14以降ではTASはbetaかつdefault enabledです。 KueueのAll-or-nothing Schedulingは、synchronized distributed trainingのように全podが同時に走らないと進まないworkloadでpartial schedulingがresource wasteやdeadlockを生むと説明しています。quota reservationだけではnode fragmentationを捉えられず、たとえばcluster全体に8 GPUが空いていても4+4に分散し、単一8-GPU Podを置けない場合があります。TASはquotaだけでなくtopology placementをadmission時に評価することで、この種の「総量はあるが置けない」を減らします。 Volcano v1.15のGang pluginもall-or-nothing schedulingを中核機能として、Jobのminimum runnable podsを満たせる場合にのみgroupを進める設計です。PodGroupの`minMember`/`minResources`は、最低限必要なpod数・resourceを表し、不足時に一部podだけを先行させないために使えます。 ## 運用上の意味・failure gang schedulingだけでは「全workerが起動したが、遠いrackへ分散してcollective通信が遅い」問題を防げません。逆にtopology preferenceだけでは、必要workerの一部だけがresourceを保持したまま残りを待つpartial allocationを防げません。したがって、distributed AI workloadではadmission completenessとplacement qualityを別controlとして設計します。 典型的failureは、cluster全体のfree GPU数だけでadmissionすること、GPU SKUだけを揃えてNVLink/NVSwitch/RDMA/rack localityを無視すること、gang sizeを「desired replica数」と固定してelastic trainingのminimum viable sizeを表現しないこと、topology labelが古い・誤っている状態でscheduler判断を信頼することです。 また、gang schedulingはresource availabilityを作り出しません。大きなgangを無期限に待たせるとqueue head-of-line blockingやfragmentationを増やす可能性があります。priority、preemption、quota borrowing、backfill、elastic/partial admissionの可否をworkload classごとに定義します。 ## concrete control / implementation implication 1. workload manifestへ `gang_min_members`、`min_resources`、elastic可否、GPU SKU/profile、network/fabric requirement、topology requirement、priority/queueを明示します。 2. admission時にaggregate quotaだけでなく、node-level allocatabilityと必要topology domain内のcapacityをreadbackします。 3. training/inference jobごとに `required` と `preferred` topologyを分離します。通信上絶対必要な同一domain条件を単なるpreferenceへ落としません。 4. topology sourceをinventory化し、node label/resource topologyと実rack/fabric構成の同期を監査します。labelの存在を物理帯域保証と同一視しません。 5. gangが長時間pendingの場合、`insufficient total capacity`、`fragmentation`、`topology constraint`、`quota/priority`を区別して観測します。 6. scheduler変更前後でqueue wait、admission latency、GPU idle reservation、job completion time、collective communication time、cross-rack traffic、preemption/requeueを比較します。 7. elastic workloadではminimum viable replicasとtarget replicasを分け、partial admissionを許す場合もframework側がそのreplica数で正しく再構成できることを確認します。 8. multi-tenant環境ではtopology optimizationが一部tenantへ良好なrack/GPUを固定化しないよう、queue fairnessとlocality benefitを同時に測定します。 ## 適用境界 Kueue TASはKubernetes上のqueue/admissionとtopology-aware schedulingの仕組みであり、NCCLやRDMA fabric自体のhealth、bandwidth、routing correctnessを保証しません。topology labelが正しくても、NIC/GPU faultやoversubscriptionにより通信性能は劣化し得ます。 Volcano Gangはminimum runnable groupを扱えますが、すべてのdistributed frameworkで`minMember`がsemanticに正しいとは限りません。frameworkが固定world sizeを要求する場合は全workerをgangへ含め、elastic frameworkでは実際のminimum viable world sizeを別途検証します。 Kueueのmulti-level topology機能にはversionごとのfeature state差があります。運用clusterのKueue version、feature gate、API schemaをlive確認し、documentationの最新例を古いclusterへそのまま適用しません。 ## counterevidence / limitations topology localityを強く要求すると、近接resourceが揃うまでjob開始が遅れ、throughputやqueue fairnessが悪化する場合があります。communication-light workloadでは、厳しいsame-rack制約より早期開始の方がend-to-end completionを改善する可能性があります。 gang schedulingも常に全replica同時開始が最適とは限りません。elastic trainingやfault-tolerant inferenceでは、縮小構成で開始して後からscale outできる場合があります。したがってall-or-nothingはworkload semanticsから導出し、distributed AIという理由だけで一律適用しません。 ## OPEN_UNKNOWN - workload/modelごとのsame-host / same-rack / same-block requirementの実測break-even。 - NVLink/NVSwitch/RDMA/EFA等のfabric情報をKubernetes topology modelへどこまで正確に投影できるか。 - gang待機によるfragmentationとtopology locality benefitの最適trade-off。 - autoscalerがnode追加中のときのgang admission/topology reservation整合性。 - elastic workloadのminimum viable replicasとquality/throughput/SLOの関係。 - topology metadata driftを検出する標準的なreadback方法。 ## SAFE_WORDING 「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic性、通信特性、queue待機、fragmentationを実測して制約を決める。」 ## Source / provenance locators - Kubernetes SIG Scheduling / Kueue, “Topology-Aware Scheduling”, accessed 2026-10-21: https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/ - Kubernetes SIG Scheduling / Kueue, “All-or-nothing Scheduling”, v0.20 docs, accessed 2026-10-21: https://kueue.sigs.k8s.io/v0.20/docs/concepts/all_or_nothing/ - Volcano, “Gang”, v1.15.0, accessed 2026-10-21: https://volcano.sh/docs/v1.15.0/scheduler/plugins/gang/ - Volcano, “PodGroup”, accessed 2026-10-21: https://volcano.sh/docs/concepts/podgroup/ NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.