分散AI workloadのgang scheduling＋topology-aware placement

分散trainingやmulti-node inferenceでは、必要なworker数が揃わないpartial placementと、通信fabricを無視した配置を別々のfailureとして扱う必要があります。EA-748では、gang schedulingを「必要pod群が同時に実行可能な状態を作る admission/scheduling control」、topology-aware placementを「通信・accelerator topologyを踏まえて実行場所を選ぶ placement control」として分離し、両者を組み合わせます。

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だけを先行させないために使えます。

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ごとに定義します。

• workload manifestへ gang_min_members、min_resources、elastic可否、GPU SKU/profile、network/fabric requirement、topology requirement、priority/queueを明示します。
• admission時にaggregate quotaだけでなく、node-level allocatabilityと必要topology domain内のcapacityをreadbackします。
• training/inference jobごとに required と preferred topologyを分離します。通信上絶対必要な同一domain条件を単なるpreferenceへ落としません。
• topology sourceをinventory化し、node label/resource topologyと実rack/fabric構成の同期を監査します。labelの存在を物理帯域保証と同一視しません。
• gangが長時間pendingの場合、insufficient total capacity、fragmentation、topology constraint、quota/priorityを区別して観測します。
• scheduler変更前後でqueue wait、admission latency、GPU idle reservation、job completion time、collective communication time、cross-rack traffic、preemption/requeueを比較します。
• elastic workloadではminimum viable replicasとtarget replicasを分け、partial admissionを許す場合もframework側がそのreplica数で正しく再構成できることを確認します。
• 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へそのまま適用しません。

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という理由だけで一律適用しません。

• 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方法。

「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic性、通信特性、queue待機、fragmentationを実測して制約を決める。」

• 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/