网络拓扑感知调度（汇总分享）

注意

本文还在完善中，后续会持续更新内容和示例，完善后再删除该提示。

背景：从单机到多机的通信挑战

随着AI大模型规模的持续扩大，单台机器（即使配备多张高端GPU）已难以满足训练和推理的需求，分布式多机多卡成为常态。然而，当计算从单机扩展到多机时，通信架构面临根本性的变化——节点间的网络性能成为制约整体效率的关键瓶颈。

理解网络拓扑感知调度，需要先从单机场景的GPU Direct技术说起，再延伸到多机场景下的RDMA技术，最终引出网络拓扑感知调度的核心价值。

GPU Direct：单机场景的通信加速

什么是GPU Direct？

GPU Direct是NVIDIA开发的一系列高性能通信技术，旨在实现GPU与其他设备（网络接口卡NIC、存储设备、其他GPU）之间的直接数据传输，绕过CPU和主机内存，消除传统数据传输路径中的性能瓶颈。

在传统架构中，GPU与外部设备之间的数据传输必须经过CPU和主机内存，存在多次内存拷贝、CPU参与数据搬运等问题，导致延迟高、带宽受限。GPU Direct通过直接内存访问（DMA）技术，让设备绕过CPU直接与GPU显存通信。

GPU Direct核心子技术

技术	场景	核心功能
`GPU Direct Storage`	`GPU ↔ 存储`	`GPU`直接访问`NVMe/SSD`，绕过`CPU`加载数据
`GPU Direct P2P`	`GPU ↔ GPU`（同节点`PCIe`）	同服务器内`GPU`间点对点通信，绕过`CPU`
`GPU Direct RDMA`	`GPU ↔ 网络`	`GPU`直接与网卡通信，实现远程直接内存访问

GPU Direct P2P与NVLink

GPU Direct P2P允许同一物理服务器上共享PCIe总线的GPU之间直接访问彼此显存，消除了经过CPU的两次拷贝，延迟降低约50%。但P2P受限于PCIe带宽（PCIe 4.0仅约128 GB/s双向），且受拓扑约束只适用于同一PCIe交换机下的GPU。

为突破PCIe带宽瓶颈，NVIDIA推出了NVLink高速点对点互联技术。以第四代NVLink（Hopper架构）为例，单GPU总带宽可达900 GB/s，是PCIe 5.0的7倍。进一步地，NVSwitch交换芯片实现了单机8张GPU的全互联，任意两GPU间均有直达路径，彻底解决了单机多卡通信瓶颈。

架构	全互联	典型总带宽	延迟
`PCIe P2P`	否	`~128 GB/s`	高
`NVLink`（点对点）	否	`~900 GB/s`	低
`NVLink + NVSwitch`	是	`900 GB/s`	极低

单机的局限：无法解决多机问题

NVLink和NVSwitch解决了单机内部的高速互联，但仅限于同一物理服务器内部。当训练规模扩展到多台服务器时，节点间的通信必须借助网络实现。此时，普通以太网（TCP/IP传统协议栈）因大量内存拷贝、CPU参与、内核协议处理等原因，成为明显的性能瓶颈，这正是RDMA技术的用武之地。

RDMA：多机场景的高性能通信基石

什么是RDMA？

RDMA（Remote Direct Memory Access，远程直接内存访问）是一种绕过远程主机操作系统内核、直接访问其内存数据的技术。与传统TCP/IP通信相比，RDMA具有三大核心特性：

CPU Offload：无需CPU干预，数据传输不消耗远程主机的CPU资源
Kernel Bypass：应用程序通过专有Verbs接口直接在用户态执行数据传输，无需内核态与用户态之间的上下文切换
Zero Copy：数据直接从发送端缓冲区传输到接收端缓冲区，无需经过网络软件协议栈

传统TCP/IP通信需要经过「用户空间→内核Socket Buffer→NIC Buffer→网络→NIC Buffer→内核Socket Buffer→用户空间」等多次内存拷贝，而RDMA将这一过程压缩为直接内存到内存的传输，大幅降低延迟、提升带宽利用率。

RDMA三种实现方案对比

目前市场上主流的RDMA实现方案有三种，均使用相同的Verbs API，但物理层和链路层有所不同：

维度	`InfiniBand（IB）`	`RoCE（RoCE v2）`	`iWARP`
基础协议	专有`IB`协议栈	以太网承载`IB`传输层	`TCP/IP`承载`RDMA`
网卡要求	专用`IB HCA`网卡	支持`RoCE`的网卡	支持`iWARP`的网卡
交换机要求	专用`IB`交换机	标准以太网交换机（需支持无损以太网）	标准以太网交换机
典型带宽	`NDR 400Gbps`	`100~400Gbps`	`10~100Gbps`
端到端延迟	`<1μs`（最低）	`1~3μs`	`5~10μs`（受`TCP`影响）
无损网络	原生支持（基于信用流控）	需配置`PFC/ECN`	`TCP`重传机制
成本	高（网卡+交换机均昂贵）	中（仅网卡需支持`RoCE`）	低（标准以太网即可）
扩展性	强（支持数万`GPU`卡集群）	中（支持数千`GPU`卡集群）	弱
运维复杂度	高（需子网管理器`SM`）	中（需精细化流控配置）	低
典型应用	大规模`HPC`、超算、顶级`AI`集群	数据中心`AI`训练集群	存储网络

InfiniBand

InfiniBand是性能最强的RDMA实现，采用集中式子网管理架构：子网管理器（SM）负责发现拓扑、分配本地ID（LID）、配置交换机转发表。凭借原生的基于信用的流量控制（Credit-Based Flow Control），IB网络本质上是无损的，无需额外配置即可避免丢包。同时支持自适应路由，每个数据包均可动态选择最优路径，在大规模部署下性能稳定。

NVIDIA（收购Mellanox后）占据IB市场70%以上份额，最新的NDR技术已实现单端口400Gbps速率。其代价是部署成本高——既需要专用IB HCA网卡，又需要专用IB交换机。

RoCE v2

RoCE（RDMA over Converged Ethernet）在以太网上承载IB的传输层协议，性能与IB相当，但可以复用现有以太网基础设施，仅要求服务器侧安装支持RoCE的网卡。RoCE v2基于UDP/IP，支持三层路由，已成为数据中心AI集群的主流选择。

RoCE的关键挑战在于：以太网本身不是无损网络，丢包会导致大量重传，严重影响RDMA性能。因此部署时需要在交换机上精细配置PFC（优先级流量控制）和ECN（显式拥塞通知），运维复杂度相对较高。

iWARP

iWARP基于TCP/IP，对网络基础设施要求最低，标准以太网即可使用。但由于受TCP协议的影响（序列号、确认、重传等机制），延迟比IB和RoCE高出数倍，通常用于存储网络而非大规模AI训练集群。

RDMA在AI大模型训练推理中的价值

在AI大模型训练场景下，多机多卡分布式训练中的梯度同步（AllReduce）、参数更新、KV Cache传输等操作均涉及大量跨节点数据交换。以LLM训练为例：

梯度同步：数十亿参数的梯度需要在每个训练步骤内完成多机同步
模型并行：不同节点负责不同的模型层，中间激活值频繁跨节点传递
PD分离推理：Prefill节点产生的KV Cache需要实时传输给Decode节点

若使用传统以太网（TCP/IP），仅CPU开销和内存拷贝就会消耗大量资源，成为训练效率的天花板。RDMA技术通过CPU Offload和Zero Copy，将跨节点通信开销降至接近本地内存访问的水平，使GPU算力得到充分释放。

网络拓扑感知调度：多机场景的调度优化

多机网络环境的痛点

有了RDMA硬件之后，是否就万事大吉了？答案是否定的。在真实的数据中心环境中，RDMA设备的组网拓扑本身极为复杂，不同节点之间的实际网络性能差异显著。若调度系统对此毫无感知，盲目地将任务分配到任意节点上，将带来以下痛点：

跨交换机通信延迟

现代数据中心通常采用多层交换机架构（Spine-Leaf、Fat-Tree等）。同一接入层交换机下的节点通信路径最短，延迟最低；跨越的交换机层级越多，延迟越高，带宽竞争越激烈：

通信场景	延迟	带宽	说明
同一接入层`IB`交换机内	`<2μs`	`200Gbps`	路径最短，性能最优
跨`IB`接入层（同`IB`汇聚层）	`2~5μs`	`200Gbps`	经过一级汇聚交换机
跨`IB`到以太网	`5~10μs`	`~100Gbps`（损失约`50%`）	跨越不同类型网络
以太网交换机间	`>10μs`	`10~100Gbps`（损失`50~95%`）	无`RDMA`加速

对于时延敏感的大模型训练，延迟从2μs增加到10μs意味着5倍的通信性能差距，直接影响训练吞吐量。

跨RDMA与非RDMA网络的性能悬崖

RDMA设备（IB网卡、RoCE网卡）通常只覆盖集群中的部分节点，并非全量部署。若调度器不了解网络类型，可能将RDMA任务的一部分Pod调度到非RDMA节点上：

那些Pod只能通过普通TCP/IP通信
由于RDMA集合通信（如AllReduce）要求所有参与节点均使用相同通信路径，任何一个节点回落到TCP/IP都会拖累整体性能
极端情况下，整个任务的通信性能会降级至普通以太网水平，RDMA加速形同虚设

网络带宽争用与资源碎片

在没有拓扑感知的调度下，多个大型分布式任务可能各自占用跨越不同网络域的节点，导致上行链路（汇聚层、核心层交换机）的带宽被严重争用。高层链路带宽通常是接入层的瓶颈，多任务竞争会造成「同一链路被多个任务争用」的网络代码（Hot Spot）问题，最终所有任务都受到影响。

网络代码（Hot Spot）问题

当大量通信流量汇聚在少数几条跨层链路上时，这些链路成为热点（Hot Spot）。热点链路上的数据包排队延迟急剧上升，严重时触发PFC（优先级流量控制）暂停，甚至引发死锁，导致整个RDMA网络性能大幅下降。

网络拓扑感知调度的核心价值

网络拓扑感知调度的核心思想是：调度器在分配计算节点时，感知集群的网络拓扑结构，优先将同一任务的多个Pod调度到网络距离近（即在同一交换机域内）的节点上，从而最大化利用高速网络，降低跨层通信开销。

主要收益包括：

降低通信延迟：将同一任务的Pod集中在同一接入层或汇聚层交换机下，避免不必要的跨层路由
保障带宽：减少跨层链路的流量，避免带宽竞争和热点问题
充分利用高速网络：确保RDMA任务的所有Pod都调度在RDMA网络覆盖的节点上
提升训练效率：实践数据显示，大规模模型训练中网络拓扑优化可将训练时间缩短40~60%，GPU利用率提升20~30%

Volcano网络拓扑感知调度实现

Volcano是一款面向AI和HPC场景的Kubernetes批量调度系统，其network-topology-aware插件提供了完整的网络拓扑感知调度能力。

版本说明

以下内容基于Volcano v1.13.0版本，网络拓扑插件后续版本可能有所更新。

设计原理

Volcano的网络拓扑感知调度基于三个核心设计：

统一的网络拓扑API：通过HyperNode CRD标准化描述集群网络拓扑
拓扑感知调度策略：基于HyperNode层级信息进行智能调度打分
灵活的约束模式：支持Hard（硬约束）和Soft（软约束）两种调度模式

HyperNode CRD

HyperNode是Volcano定义的自定义资源，用于表示一个性能域（Performance Domain），即一组具有相同网络带宽和延迟特性的节点或子性能域，通常映射到一个物理交换机或机架顶部交换机（ToR）。

HyperNode通过Tier（层级）字段区分不同性能域：Tier值越小，节点间网络带宽越高、延迟越低；Tier值越大，代表越高层级的汇聚或核心交换机。

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1          # Tier层级，越小网络性能越好
  members:
    - type: Node   # 成员类型：Node（真实节点）或HyperNode（子性能域）
      selector:
        exactMatch:
          name: node0   # 精确匹配节点名
    - type: Node
      selector:
        exactMatch:
          name: node1

HyperNode的members字段支持三种选择器：

选择器类型	说明	适用范围
`exactMatch`	精确匹配节点名称	叶子及非叶子`HyperNode`
`regexMatch`	正则表达式匹配节点名称	仅叶子`HyperNode`
`labelMatch`	基于节点标签匹配	仅叶子`HyperNode`

多个HyperNode通过层级连接，形成一棵网络拓扑树：

tier3                                     s6
                          /                                \
tier2                   s4                                  s5
                /               \                    /               \
tier1         s0                s1                  s2               s3
           /      \          /      \            /      \         /      \
        node0    node1    node2    node3      node4    node5    node6    node7

在这棵树中，node0和node1同属s0（tier1），通信效率最高；node0和node4需经过s0→s4→s5→s2，通信效率最低。

调度模式：Hard与Soft

Volcano Job和PodGroup通过networkTopology字段设置拓扑约束：

spec:
  networkTopology:
    mode: hard          # 调度模式：hard（硬约束）或 soft（软约束）
    highestTierAllowed: 2  # 允许的最高Tier层级

参数	类型	说明
`mode`	`string`	`hard`：所有任务必须调度在指定`Tier`内的同一`HyperNode`中；`soft`：尽力而为，允许降级调度
`highestTierAllowed`	`int`	允许的最高`Tier`层级，值越小网络性能要求越高

Hard模式：作业的所有任务必须被调度到Tier ≤ highestTierAllowed的同一个HyperNode内。若不满足条件，作业保持Pending状态。适用于对网络延迟极其敏感的大规模分布式训练。

Soft模式：调度器尽最大努力将任务集中调度在同一HyperNode内，若资源不足则允许跨HyperNode调度。保证作业能够尽快启动，适用于希望优化网络性能但可接受一定调度灵活性的场景。

调度打分逻辑

network-topology-aware插件采用以下打分策略选择最优HyperNode：

基于Tier的打分（Tier越低得分越高）：

tierScore = (maxTier - currentTier) / (maxTier - minTier) * 100

基于任务分布的打分（已调度的同作业Pod越多得分越高）：

taskNumScore = (hyperNodeTaskNum / totalTaskNum) * 100

综合得分：首次调度时各候选HyperNode得分为0，后续调度计算候选HyperNode与已分配节点的最低公共祖先（LCA）的Tier的得分，再叠加任务分布得分，优先将同一任务的Pod集中调度到同一HyperNode。

配置方式

启用Volcano调度插件

修改Volcano调度器的ConfigMap，启用network-topology-aware插件：

volcano-scheduler.conf
actions: "enqueue, allocate, backfill"
tiers:
- plugins:
  - name: priority
  - name: gang
  - name: conformance
- plugins:
  - name: predicates
  - name: proportion
  - name: network-topology-aware   # 启用网络拓扑感知插件
    arguments:
      weight: 10    # 插件权重，决定该插件在总分中的占比
  - name: nodeorder
  - name: binpack

手动配置HyperNode

以下展示与上述网络拓扑树对应的完整HyperNode配置：

# Tier1：叶子HyperNode，包含真实节点
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1
  members:
    - type: Node
      selector:
        exactMatch:
          name: node0
    - type: Node
      selector:
        exactMatch:
          name: node1
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s1
spec:
  tier: 1
  members:
    - type: Node
      selector:
        exactMatch:
          name: node2
    - type: Node
      selector:
        exactMatch:
          name: node3
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s2
spec:
  tier: 1
  members:
    - type: Node
      selector:
        exactMatch:
          name: node4
    - type: Node
      selector:
        exactMatch:
          name: node5
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s3
spec:
  tier: 1
  members:
    - type: Node
      selector:
        exactMatch:
          name: node6
    - type: Node
      selector:
        exactMatch:
          name: node7
---
# Tier2：汇聚层HyperNode，组合Tier1的HyperNode
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s4
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s0
    - type: HyperNode
      selector:
        exactMatch:
          name: s1
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s5
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s2
    - type: HyperNode
      selector:
        exactMatch:
          name: s3
---
# Tier3：根HyperNode
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s6
spec:
  tier: 3
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s4
    - type: HyperNode
      selector:
        exactMatch:
          name: s5

自动发现HyperNode（推荐）

对于InfiniBand网络，Volcano支持通过UFM（Unified Fabric Manager）自动发现网络拓扑并管理HyperNode。修改volcano controller的配置（支持热更新，无需重启）：

volcano-controller.conf
networkTopologyDiscovery:
  # UFM发现源（适用于InfiniBand网络）
  - source: ufm
    enabled: true
    interval: 10m
    credentials:
      secretRef:
        name: ufm-credentials
        namespace: volcano-system
    config:
      endpoint: https://ufm-server:8080
      insecureSkipVerify: true

  # 基于节点标签的发现源（通用方案）
  - source: label
    enabled: true
    config:
      networkTopologyTypes:
        topologyA2:
          - nodeLabel: "volcano.sh/tor"      # 接入层交换机标签
          - nodeLabel: "kubernetes.io/hostname"
        topologyA3:
          - nodeLabel: "volcano.sh/hypercluster"
          - nodeLabel: "volcano.sh/hypernode"
          - nodeLabel: "kubernetes.io/hostname"

使用示例：分布式训练场景

以下通过一个分布式训练场景，结合前文已定义的网络拓扑树，展示如何使用Volcano网络拓扑感知调度将训练任务集中调度到同一网络域内。

场景背景

现有一个集群，拥有8个工作节点，网络拓扑结构如下：

tier3                                     s6
                          /                                \
tier2                   s4                                  s5
                /               \                    /               \
tier1         s0                s1                  s2               s3
           /      \          /      \            /      \         /      \
        node0    node1    node2    node3      node4    node5    node6    node7

s0~s3（tier1）：接入层交换机，每个交换机下有2个节点，同交换机内延迟最低
s4、s5（tier2）：汇聚层交换机，分别管理2个tier1 HyperNode
s6（tier3）：核心层交换机，管理所有tier2 HyperNode

现需要提交一个4个worker的PyTorch分布式训练任务，要求所有worker必须调度在同一tier2 HyperNode内（即s4或s5下），以确保AllReduce梯度同步的通信延迟不超过跨汇聚层水平。

节点标签配置

首先为节点打上交换机归属标签，以便HyperNode通过labelMatch自动关联节点：

kubectl label node node0 switch=s0
kubectl label node node1 switch=s0
kubectl label node node2 switch=s1
kubectl label node node3 switch=s1
kubectl label node node4 switch=s2
kubectl label node node5 switch=s2
kubectl label node node6 switch=s3
kubectl label node node7 switch=s3

HyperNode配置

# Tier1：叶子HyperNode，通过labelMatch关联节点
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            switch: s0
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s1
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            switch: s1
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s2
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            switch: s2
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s3
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            switch: s3
---
# Tier2：汇聚层HyperNode
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s4
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s0
    - type: HyperNode
      selector:
        exactMatch:
          name: s1
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s5
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s2
    - type: HyperNode
      selector:
        exactMatch:
          name: s3
---
# Tier3：核心层HyperNode
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s6
spec:
  tier: 3
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: s4
    - type: HyperNode
      selector:
        exactMatch:
          name: s5

分布式训练任务配置

使用Hard模式，将4个worker强制约束在同一tier2 HyperNode内：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: pytorch-distributed-training
spec:
  minAvailable: 4
  schedulerName: volcano
  queue: default

  # 网络拓扑约束：硬约束，所有worker必须在同一个tier2 HyperNode内
  networkTopology:
    mode: hard
    highestTierAllowed: 2

  tasks:
    - replicas: 4
      name: worker
      template:
        metadata:
          labels:
            app: pytorch-training
        spec:
          containers:
            - name: pytorch-worker
              image: pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime
              command:
                - "sh"
                - "-c"
                - |
                  torchrun \
                    --nproc_per_node=1 \
                    --nnodes=$WORLD_SIZE \
                    --node_rank=$RANK \
                    --master_addr=$MASTER_ADDR \
                    --master_port=23456 \
                    /workspace/train.py
              resources:
                requests:
                  cpu: "4"
                  memory: "16Gi"
                  nvidia.com/gpu: "1"
                limits:
                  cpu: "4"
                  memory: "16Gi"
                  nvidia.com/gpu: "1"
          restartPolicy: OnFailure

调度效果说明

提交上述训练任务后，Volcano调度器的处理逻辑如下：

过滤阶段：插件检查highestTierAllowed: 2，筛选出能容纳4个worker的tier2 HyperNode候选（s4或s5），跨越tier2的调度方案被直接排除
打分阶段：根据Tier打分和已分配Pod数量打分，优先将后续worker调度到与已分配节点同一HyperNode下
最终结果：4个worker全部落在s4（node0~node3）或s5（node4~node7）下，不会跨越核心层交换机s6

在Hard模式下，若s4和s5均无法容纳4个worker（例如节点资源不足），任务将保持Pending状态直到资源就绪，而不会将worker分散到s4和s5两侧——这保证了训练任务始终运行在低延迟的网络域内。

若希望在资源紧张时允许跨tier2调度（牺牲部分网络性能以换取更快的任务启动），可将mode改为soft：

networkTopology:
  mode: soft
  highestTierAllowed: 2

注意事项

必须设置资源请求和限制：网络拓扑感知调度依赖任务的资源请求信息。若任务为BestEffort类型（未设置requests/limits），即使启用了插件，该任务也不会触发网络拓扑调度。

resources:
  requests:
    cpu: "4"
    memory: "16Gi"
    nvidia.com/gpu: "1"
  limits:
    cpu: "4"
    memory: "16Gi"
    nvidia.com/gpu: "1"

集群中不存在HyperNode时：若任务指定了网络拓扑调度配置，但集群中不存在任何HyperNode资源，调度器按默认逻辑进行调度，不会受到拓扑约束影响。

背景：从单机到多机的通信挑战​

GPU Direct：单机场景的通信加速​

什么是GPU Direct？​

GPU Direct核心子技术​

GPU Direct P2P与NVLink​

单机的局限：无法解决多机问题​

RDMA：多机场景的高性能通信基石​

什么是RDMA？​

RDMA三种实现方案对比​

InfiniBand​

RoCE v2​

iWARP​

RDMA在AI大模型训练推理中的价值​

网络拓扑感知调度：多机场景的调度优化​

多机网络环境的痛点​

跨交换机通信延迟​

跨RDMA与非RDMA网络的性能悬崖​

网络带宽争用与资源碎片​

网络代码（Hot Spot）问题​

网络拓扑感知调度的核心价值​

Volcano网络拓扑感知调度实现​

设计原理​

HyperNode CRD​

调度模式：Hard与Soft​

调度打分逻辑​

配置方式​

启用Volcano调度插件​

手动配置HyperNode​

自动发现HyperNode（推荐）​

使用示例：分布式训练场景​

场景背景​

节点标签配置​

HyperNode配置​

分布式训练任务配置​

调度效果说明​

注意事项​

参考资料​