{
  "format": "agent-article-v0",
  "article_id": "EA-748",
  "canonical_url": "/tools/ea-748-ai-workload-gang-scheduling-topology-aware-placement",
  "page_type": "reference",
  "claim_ids": [],
  "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"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-21",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "EA748-CANDIDATE-20261021-0231JST-C1",
    "SRC-EA-748-URL-1DA6B5BDFE90",
    "SRC-EA-748-URL-7245EBE029F0",
    "SRC-EA-748-URL-DBD91671DFA3",
    "SRC-EA-748-URL-C57DDC8BBE29",
    "BODY-SHA256:e3a4bc4abe3aa5d4f52d37a69e62d675fec7884d7a353e7f5454df51c0557061"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-748-URL-1DA6B5BDFE90",
      "evidence_class": "RESEARCH",
      "title": "Kubernetes SIG Scheduling / Kueue, “Topology-Aware Scheduling”, accessed 2026-10-21:",
      "href": "https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-748-URL-1DA6B5BDFE90"
      ],
      "supporting_locators": [
        "Source / provenance locators",
        "- Kubernetes SIG Scheduling / Kueue, “Topology-Aware Scheduling”, accessed 2026-10-21: https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/"
      ],
      "scope": "Source / provenance locators",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-748-URL-7245EBE029F0",
      "evidence_class": "RESEARCH",
      "title": "Kubernetes SIG Scheduling / Kueue, “All-or-nothing Scheduling”, v0.20 docs, accessed 2026-10-21:",
      "href": "https://kueue.sigs.k8s.io/v0.20/docs/concepts/all_or_nothing/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-748-URL-7245EBE029F0"
      ],
      "supporting_locators": [
        "Source / provenance locators",
        "- 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/"
      ],
      "scope": "Source / provenance locators",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-748-URL-DBD91671DFA3",
      "evidence_class": "RESEARCH",
      "title": "Volcano, “Gang”, v1.15.0, accessed 2026-10-21:",
      "href": "https://volcano.sh/docs/v1.15.0/scheduler/plugins/gang/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-748-URL-DBD91671DFA3"
      ],
      "supporting_locators": [
        "Source / provenance locators",
        "- Volcano, “Gang”, v1.15.0, accessed 2026-10-21: https://volcano.sh/docs/v1.15.0/scheduler/plugins/gang/"
      ],
      "scope": "Source / provenance locators",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-748-URL-C57DDC8BBE29",
      "evidence_class": "RESEARCH",
      "title": "Volcano, “PodGroup”, accessed 2026-10-21:",
      "href": "https://volcano.sh/docs/concepts/podgroup/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-748-URL-C57DDC8BBE29"
      ],
      "supporting_locators": [
        "Source / provenance locators",
        "- Volcano, “PodGroup”, accessed 2026-10-21: https://volcano.sh/docs/concepts/podgroup/"
      ],
      "scope": "Source / provenance locators",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-748-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "EA748-CANDIDATE-20261021-0231JST-C1"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-748&revision_id=EA-748-RESEARCH-20261021-R1&candidate_id=EA748-CANDIDATE-20261021-0231JST-C1",
        "EA-748-RESEARCH-20261021-R1"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-748-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:e3a4bc4abe3aa5d4f52d37a69e62d675fec7884d7a353e7f5454df51c0557061"
      ],
      "supporting_locators": [
        "content/staging/EA-748.md",
        "e3a4bc4abe3aa5d4f52d37a69e62d675fec7884d7a353e7f5454df51c0557061",
        "EA-748-RESEARCH-20261021-R1"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "要点と前提",
      "text": "分散trainingやmulti-node inferenceでは、必要なworker数が揃わないpartial placementと、通信fabricを無視した配置を別々のfailureとして扱う必要があります。EA-748では、gang schedulingを「必要pod群が同時に実行可能な状態を作る admission/scheduling control」、topology-aware placementを「通信・accelerator topologyを踏まえて実行場所を選ぶ placement control」として分離し、両者を組み合わせます。"
    },
    {
      "heading": "主要claim",
      "text": "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です。\n\nKueueの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時に評価することで、この種の「総量はあるが置けない」を減らします。\n\nVolcano v1.15のGang pluginもall-or-nothing schedulingを中核機能として、Jobのminimum runnable podsを満たせる場合にのみgroupを進める設計です。PodGroupの`minMember`/`minResources`は、最低限必要なpod数・resourceを表し、不足時に一部podだけを先行させないために使えます。"
    },
    {
      "heading": "運用上の意味・failure",
      "text": "gang schedulingだけでは「全workerが起動したが、遠いrackへ分散してcollective通信が遅い」問題を防げません。逆にtopology preferenceだけでは、必要workerの一部だけがresourceを保持したまま残りを待つpartial allocationを防げません。したがって、distributed AI workloadではadmission completenessとplacement qualityを別controlとして設計します。\n\n典型的failureは、cluster全体のfree GPU数だけでadmissionすること、GPU SKUだけを揃えてNVLink/NVSwitch/RDMA/rack localityを無視すること、gang sizeを「desired replica数」と固定してelastic trainingのminimum viable sizeを表現しないこと、topology labelが古い・誤っている状態でscheduler判断を信頼することです。\n\nまた、gang schedulingはresource availabilityを作り出しません。大きなgangを無期限に待たせるとqueue head-of-line blockingやfragmentationを増やす可能性があります。priority、preemption、quota borrowing、backfill、elastic/partial admissionの可否をworkload classごとに定義します。"
    },
    {
      "heading": "concrete control / implementation implication",
      "text": "1. workload manifestへ `gang_min_members`、`min_resources`、elastic可否、GPU SKU/profile、network/fabric requirement、topology requirement、priority/queueを明示します。\n2. admission時にaggregate quotaだけでなく、node-level allocatabilityと必要topology domain内のcapacityをreadbackします。\n3. training/inference jobごとに `required` と `preferred` topologyを分離します。通信上絶対必要な同一domain条件を単なるpreferenceへ落としません。\n4. topology sourceをinventory化し、node label/resource topologyと実rack/fabric構成の同期を監査します。labelの存在を物理帯域保証と同一視しません。\n5. gangが長時間pendingの場合、`insufficient total capacity`、`fragmentation`、`topology constraint`、`quota/priority`を区別して観測します。\n6. scheduler変更前後でqueue wait、admission latency、GPU idle reservation、job completion time、collective communication time、cross-rack traffic、preemption/requeueを比較します。\n7. elastic workloadではminimum viable replicasとtarget replicasを分け、partial admissionを許す場合もframework側がそのreplica数で正しく再構成できることを確認します。\n8. multi-tenant環境ではtopology optimizationが一部tenantへ良好なrack/GPUを固定化しないよう、queue fairnessとlocality benefitを同時に測定します。"
    },
    {
      "heading": "適用境界",
      "text": "Kueue TASはKubernetes上のqueue/admissionとtopology-aware schedulingの仕組みであり、NCCLやRDMA fabric自体のhealth、bandwidth、routing correctnessを保証しません。topology labelが正しくても、NIC/GPU faultやoversubscriptionにより通信性能は劣化し得ます。\n\nVolcano Gangはminimum runnable groupを扱えますが、すべてのdistributed frameworkで`minMember`がsemanticに正しいとは限りません。frameworkが固定world sizeを要求する場合は全workerをgangへ含め、elastic frameworkでは実際のminimum viable world sizeを別途検証します。\n\nKueueのmulti-level topology機能にはversionごとのfeature state差があります。運用clusterのKueue version、feature gate、API schemaをlive確認し、documentationの最新例を古いclusterへそのまま適用しません。"
    },
    {
      "heading": "counterevidence / limitations",
      "text": "topology localityを強く要求すると、近接resourceが揃うまでjob開始が遅れ、throughputやqueue fairnessが悪化する場合があります。communication-light workloadでは、厳しいsame-rack制約より早期開始の方がend-to-end completionを改善する可能性があります。\n\ngang schedulingも常に全replica同時開始が最適とは限りません。elastic trainingやfault-tolerant inferenceでは、縮小構成で開始して後からscale outできる場合があります。したがってall-or-nothingはworkload semanticsから導出し、distributed AIという理由だけで一律適用しません。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- workload/modelごとのsame-host / same-rack / same-block requirementの実測break-even。\n- NVLink/NVSwitch/RDMA/EFA等のfabric情報をKubernetes topology modelへどこまで正確に投影できるか。\n- gang待機によるfragmentationとtopology locality benefitの最適trade-off。\n- autoscalerがnode追加中のときのgang admission/topology reservation整合性。\n- elastic workloadのminimum viable replicasとquality/throughput/SLOの関係。\n- topology metadata driftを検出する標準的なreadback方法。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic性、通信特性、queue待機、fragmentationを実測して制約を決める。」"
    },
    {
      "heading": "Source / provenance locators",
      "text": "- Kubernetes SIG Scheduling / Kueue, “Topology-Aware Scheduling”, accessed 2026-10-21: https://kueue.sigs.k8s.io/docs/concepts/topology_aware_scheduling/\n- 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/\n- Volcano, “Gang”, v1.15.0, accessed 2026-10-21: https://volcano.sh/docs/v1.15.0/scheduler/plugins/gang/\n- Volcano, “PodGroup”, accessed 2026-10-21: https://volcano.sh/docs/concepts/podgroup/"
    }
  ],
  "human_url": "/tools/ea-748-ai-workload-gang-scheduling-topology-aware-placement",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-748-ai-workload-gang-scheduling-topology-aware-placement",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-748-ai-workload-gang-scheduling-topology-aware-placement"
}