Volcano网络拓扑感知调度案例

在大规模GPU集群中部署大模型推理服务时，网络拓扑对性能的影响至关重要。本文通过 PD（Prefill-Decode）分离部署 的实战场景案例，详细演示如何使用Volcano的网络拓扑感知调度功能，在IB（InfiniBand）网络环境下优化节点选择，实现：

🎯 延迟优化：将跨交换机通信延迟从5-10μs降低到2-5μs，性能提升2-5倍
🎯 带宽优化：保持200Gbps高带宽，避免50%的带宽损失，吞吐量提升30-50%
🎯 资源优化：Prefill使用NVIDIA-H100高性能GPU，Decode使用NVIDIA-GeForce-RTX-4090性价比GPU，降低整体成本

本文将从场景背景、技术方案分析、HyperNode拓扑设计到具体实施，提供完整的实践案例。

场景背景

基础设施环境

硬件拓扑：

集群规模：GPU服务器若干
IB网络组网：
- 7个交换机，其中3个IB交换机，4个以太网交换机，每个叶子交换机上最多有64台GPU服务器
- IB网络提供高带宽（200Gbps）、低延迟（<2μs）的RDMA通信
- 跨IB网络域通信需要经过以太网，延迟显著增加（>10μs）
GPU配置：
- 每台服务器配置8张GPU卡
- 每个交换机下有各种卡型号服务器，以NVIDIA-A100/NVIDIA-H100和RTX 4090/RTX 5090为主。

大致的网络拓扑如下：

                                    eth switch6
                      /                                    \
                  ib switch4                           eth switch5
              /                \                    /               \
      ib switch0           ib switch1         eth switch2      eth switch3
      /    |    \          /    |    \        /    |    \      /    |    \ 
  node0   ...  node63   node64 ... node127  ...   ...   ...  ...   ...   ...

网络性能对比：

通信类型	带宽	延迟	带宽损失	适用场景
`IB`交换机内（同交换机节点）	`200Gbps`	`<2μs`	`0%`	高性能分布式推理
`IB`交换机间（跨`IB`交换机）	`200Gbps`	`2-5μs`	`0%`	分布式推理
`IB`到以太网（跨交换机类型）	`100Gbps`	`5-10μs`	`~50%`	一般分布式任务
以太网交换机间	`10-100Gbps`	`>10μs`	`50-95%`	非性能敏感任务

PD分离推理场景介绍

什么是PD分离？

PD分离（Prefill-Decode分离）是大模型推理优化的一种架构模式：

Prefill阶段：处理输入prompt，生成初始KV Cache
- 计算密集型，需要高算力
- 输入长度可变，计算量大
- 适合部署在高性能数据中心GPU上（如NVIDIA-H100、NVIDIA-A100）
Decode阶段：逐个生成输出token
- 访存密集型，对带宽要求高
- 计算量相对较小，但需要频繁访问KV Cache
- 可以使用性价比更高的消费级GPU（如NVIDIA-GeForce-RTX-4090、NVIDIA-GeForce-RTX-5090）

PD分离的优势：

✅ 资源利用率提升：不同阶段使用最适合的GPU型号
✅ 吞吐量提升：Prefill和Decode可以并行处理不同请求
✅ 成本优化：根据计算特点选择性价比最优的硬件

业务需求

分布式PD推理架构：

在我们的场景中，需要部署分布式PD分离推理服务：

Prefill服务：
- 需要12个Pod，每个Pod使用1张GPU（NVIDIA-H100）
- 要求在同一IB网络域内，以实现高效的KV Cache传输
Decode服务：
- 需要12个Pod，每个Pod使用1张GPU（NVIDIA-GeForce-RTX-4090）
- 要求在同一IB网络域内，以实现高效的KV Cache访问

核心需求：

✅ 同域部署：Prefill和Decode集群必须部署在同一IB网络域内，避免跨域通信延迟
✅ 域内优化：在IB网络域内，优化节点选择，减少跨交换机通信
✅ 资源利用：充分利用同一域内不同节点的GPU型号优势（NVIDIA-H100用于Prefill，NVIDIA-GeForce-RTX-4090用于Decode）

技术方案分析

简单亲和性调度的局限性

场景分析：

在大规模混合网络集群中（7个交换机，其中3个IB交换机、4个以太网交换机，最多384台服务器），如果仅使用节点亲和性或Pod亲和性：

# 仅使用节点亲和性的配置示例
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: nvidia.com/gpu.product
              operator: In
              values:
                - NVIDIA-H100  # 只能保证选择NVIDIA-H100节点

存在的问题：

无法感知网络拓扑：
- ❌ 调度器不知道节点之间的网络距离和交换机类型
- ❌ 12个Prefill Pod可能分散在IB和以太网交换机下
- ❌ 12个Decode Pod也可能分散在不同类型的交换机下
- ❌ Prefill和Decode之间的KV Cache传输可能需要跨交换机类型
网络性能不可控：
- ❌ 延迟问题：
  - 同一IB交换机内通信延迟<2μs
  - 跨IB交换机通信延迟2-5μs
  - 跨交换机类型（IB到以太网）延迟5-10μs
  - 延迟差异可能导致5倍的性能差距
- ❌ 带宽损失问题：
  - IB交换机间保持200Gbps带宽
  - 跨交换机类型带宽降至100Gbps（损失~50%）
  - 以太网交换机间带宽仅10-100Gbps（损失50-95%）
  - 带宽损失严重影响KV Cache传输效率
资源利用率低：
- ❌ 无法优先选择网络距离近且交换机类型匹配的节点
- ❌ 可能导致高性能IB交换机下的节点空闲，而低性能以太网交换机下的节点过载

实际影响：

对于PD分离推理服务：

Prefill生成的KV Cache需要频繁传输给Decode
如果12个Prefill Pod和12个Decode Pod分散在不同类型的交换机下：
- 延迟影响：跨交换机类型通信延迟从<2μs增加到5-10μs，增加5倍
- 带宽影响：跨交换机类型带宽从200Gbps降至100Gbps，损失50%
- 吞吐量影响：KV Cache传输效率降低，Decode阶段等待时间增加，整体吞吐量可能下降30-50%

网络拓扑感知调度的优势

核心价值：

网络拓扑感知调度能够理解集群的网络拓扑结构，在调度时优先选择网络距离近的节点：

拓扑感知：
- ✅ 调度器知道每个节点所属的交换机层级和交换机类型（IB或以太网）
- ✅ 能够计算节点之间的网络距离（通过LCA最低公共祖先）
- ✅ 优先选择同一交换机下的节点，避免跨交换机类型通信
性能优化：
- ✅ 延迟优化：
  - 12个Prefill Pod尽量集中在IB交换机下（ib switch0、ib switch1）
  - 12个Decode Pod也尽量集中在IB交换机下（ib switch0、ib switch1）
  - 两组Pod尽量在同一IB交换机下（ib switch0、ib switch1），延迟保持在2-5μs
- ✅ 带宽优化：
  - 避免跨交换机类型通信，保持200Gbps带宽
  - 避免带宽损失（50-95%），确保KV Cache传输效率
灵活性：
- ✅ 支持Hard模式（严格限制）和Soft模式（尽力而为）
- ✅ 可以通过highestTierAllowed控制允许的最大网络距离
- ✅ 在满足拓扑约束的前提下，仍然支持其他调度策略

使用方案

组合方案：节点亲和性 + 网络拓扑感知调度

节点亲和性：硬约束，确保选择正确的GPU型号（NVIDIA-H100或NVIDIA-GeForce-RTX-4090）
网络拓扑感知调度：软约束，在满足GPU型号要求的前提下，优化网络拓扑

方案优势：

✅ 精确控制：通过节点亲和性确保GPU型号正确
✅ 性能优化：通过网络拓扑感知在域内选择网络距离近的节点
✅ 适应性强：适合大规模、复杂网络拓扑的集群

HyperNode拓扑设计

拓扑结构设计

提示

我们这里以交换机（switch）为单位来描述网络拓扑层级，真实使用的业务场景中，我们可以构造一个虚拟的层级关系（比如按照一定的标签规则，label1为1级、label2为2级...以此类推），不一定要按照真实的交换机为单位来划分。

根据我们的网络拓扑情况，设计如下HyperNode拓扑层级：

tier3                                            eth switch6
                                  /                                    \
tier2                         ib switch4                           eth switch5
                          /                \                    /              \
tier1             ib switch0           ib switch1         eth switch2      eth switch3
                  /    |    \          /    |    \        /    |    \      /    |    \ 
             node0    ...   node63  node64 ... node127  ...   ...   ...   ...  ...   ...

层级说明：

Tier 1：叶子交换机层，每个叶子交换机下最多64台服务器
- ib switch0、ib switch1：IB交换机，提供高带宽低延迟通信
- eth switch2、eth switch3：以太网交换机，用于非性能敏感任务
Tier 2：汇聚交换机层
- ib switch4：IB汇聚交换机，连接ib switch0和ib switch1
- eth switch5：以太网汇聚交换机，连接eth switch2和eth switch3
Tier 3：核心交换机（eth switch6），整个集群的根节点，连接不同类型的汇聚交换机

网络拓扑特点：

同一IB交换机内：延迟<2μs，带宽200Gbps，性能最优
跨IB交换机：延迟2-5μs，带宽200Gbps，保持高性能
IB到以太网：延迟5-10μs，带宽降至100Gbps（损失~50%），性能显著下降
以太网交换机间：延迟>10μs，带宽10-100Gbps（损失50-95%），不适合高性能任务

PD分离部署说明：

Prefill服务：12个Pod，需要选择NVIDIA-H100节点，必须部署在IB交换机下（ib switch0或ib switch1）
Decode服务：12个Pod，需要选择NVIDIA-GeForce-RTX-4090节点，必须部署在IB交换机下（ib switch0或ib switch1）
两个服务的所有节点应尽量在同一IB汇聚交换机（ib switch4）下，以：
- 保持200Gbps带宽，避免带宽损失
- 保持2-5μs延迟，避免跨交换机类型通信
- 确保KV Cache传输效率最优

HyperNode配置

为了支持网络拓扑感知调度，我们需要创建HyperNode资源来描述集群的网络拓扑（这里使用手动维护HyperNode的方式）。

提示

如果不基于以太网节点之间的网络拓扑实现感知调度，可以不创建以太网的HyperNode以简化维护成本。本示例为保证完整性，为所有交换机创建了HyperNode配置。

# Tier 1: IB叶子交换机 ib-switch0
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: ib-switch0
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            topology.kubernetes.io/switch: ib-switch0
            topology.kubernetes.io/switch-type: ib  # IB交换机标识

---
# Tier 1: IB叶子交换机 ib-switch1
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: ib-switch1
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            topology.kubernetes.io/switch: ib-switch1
            topology.kubernetes.io/switch-type: ib

---
# Tier 1: 以太网叶子交换机 eth-switch2
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: eth-switch2
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            topology.kubernetes.io/switch: eth-switch2
            topology.kubernetes.io/switch-type: ethernet  # 以太网交换机标识

---
# Tier 1: 以太网叶子交换机 eth-switch3
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: eth-switch3
spec:
  tier: 1
  members:
    - type: Node
      selector:
        labelMatch:
          matchLabels:
            topology.kubernetes.io/switch: eth-switch3
            topology.kubernetes.io/switch-type: ethernet

---
# Tier 2: IB汇聚交换机 ib-switch4（连接 ib-switch0 和 ib-switch1）
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: ib-switch4
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: ib-switch0
    - type: HyperNode
      selector:
        exactMatch:
          name: ib-switch1

---
# Tier 2: 以太网汇聚交换机 eth-switch5（连接 eth-switch2 和 eth-switch3）
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: eth-switch5
spec:
  tier: 2
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: eth-switch2
    - type: HyperNode
      selector:
        exactMatch:
          name: eth-switch3

---
# Tier 3: 核心交换机 eth-switch6（集群根节点）
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: eth-switch6
spec:
  tier: 3
  members:
    - type: HyperNode
      selector:
        exactMatch:
          name: ib-switch4
    - type: HyperNode
      selector:
        exactMatch:
          name: eth-switch5

配置说明：

IB交换机（ib-switch0、ib-switch1）：通过标签选择器关联IB交换机下的节点，用于高性能任务
以太网交换机（eth-switch2、eth-switch3）：通过标签选择器关联以太网交换机下的节点，用于非性能敏感任务
IB汇聚交换机（ib-switch4）：连接两个IB叶子交换机，保持200Gbps带宽
以太网汇聚交换机（eth-switch5）：连接两个以太网叶子交换机
核心交换机（eth-switch6）：连接不同类型的汇聚交换机，形成完整的拓扑树

重要提示：

PD分离服务应部署在IB交换机下的节点，通过节点标签topology.kubernetes.io/switch-type: ib进行筛选
避免将高性能任务调度到以太网交换机下的节点，以免带宽损失和延迟增加

方案实施

为节点打标签

提示

以下脚本仅做示例，主要阐述在使用网络拓扑感知调度之前，节点打标也是很重要一个环节。

# 为 IB switch0 下的节点打标签（假设 node0-node63）
for i in {0..63}; do
  kubectl label node node$i topology.kubernetes.io/switch=ib-switch0
  kubectl label node node$i topology.kubernetes.io/switch-type=ib
done

# 为 IB switch1 下的节点打标签（假设 node64-node127）
for i in {64..127}; do
  kubectl label node node$i topology.kubernetes.io/switch=ib-switch1
  kubectl label node node$i topology.kubernetes.io/switch-type=ib
done

# 为以太网 switch2 下的节点打标签（假设 node128-node191）
for i in {128..191}; do
  kubectl label node node$i topology.kubernetes.io/switch=eth-switch2
  kubectl label node node$i topology.kubernetes.io/switch-type=ethernet
done

# 为以太网 switch3 下的节点打标签（假设 node192-node255）
for i in {192..255}; do
  kubectl label node node$i topology.kubernetes.io/switch=eth-switch3
  kubectl label node node$i topology.kubernetes.io/switch-type=ethernet
done

# 验证标签
kubectl get nodes -L topology.kubernetes.io/switch,topology.kubernetes.io/switch-type

标签说明：

topology.kubernetes.io/switch：标识节点所属的叶子交换机（ib-switch0、ib-switch1、eth-switch2、eth-switch3）
topology.kubernetes.io/switch-type：标识交换机类型（ib或ethernet）

重要提示：

PD分离服务的节点必须在IB交换机下（topology.kubernetes.io/switch-type=ib）
以太网交换机下的节点不适合高性能推理任务，应用于非性能敏感任务

Prefill服务配置

需求：部署Prefill服务，12个Pod，选择NVIDIA-H100节点，尽量集中在少数交换机下。

提示

这里使用Volcano Job来演示Prefill服务的部署，若使用Deployment部署，相关配置一致。

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: pd-prefill-service
spec:
  minAvailable: 12  # Gang调度：12个Pod必须同时满足
  schedulerName: volcano
  queue: default
  
  # 网络拓扑感知调度：优化节点选择，尽量集中在少数交换机下
  networkTopology:
    mode: hard  # 硬约束，必须按照highestTierAllowed选择网络距离近的节点
    highestTierAllowed: 2  # 允许在Tier 2（汇聚交换机）内调度
  
  tasks:
    - replicas: 12
      name: prefill-worker
      template:
        spec:
          # 节点亲和性：必须选择IB交换机下的H100节点（硬约束）
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: nvidia.com/gpu.product
                        operator: In
                        values:
                          - NVIDIA-H100  # 必须在H100节点
                      - key: topology.kubernetes.io/switch-type
                        operator: In
                        values:
                          - ib  # 必须在IB交换机下
            
            # Pod反亲和性：尽量将Pod分散到不同节点（软约束）
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
                - weight: 100
                  podAffinityTerm:
                    labelSelector:
                      matchExpressions:
                        - key: volcano.sh/job-name
                          operator: In
                          values:
                            - pd-prefill-service
                    topologyKey: kubernetes.io/hostname
          
          containers:
            - name: prefill-service
              image: vllm/vllm:latest
              command: ["python", "-m", "vllm.entrypoints.api_server"]
              args:
                - "--model=/models/llama-70b"
                - "--tensor-parallel-size=1"
                - "--pipeline-parallel-size=1"
                - "--enable-prefix-caching"
              env:
                - name: NCCL_IB_DISABLE
                  value: "0"    # 启用IB网络
                - name: NCCL_SOCKET_IFNAME
                  value: "ib0"  # 指定IB网络接口
                - name: NCCL_IB_HCA
                  value: "mlx5" # 指定IB设备
              resources:
                limits:
                  nvidia.com/gpu: "1"
                requests:
                  nvidia.com/gpu: "1"
          restartPolicy: OnFailure

关键配置说明：

minAvailable: 12：Gang调度，确保12个Pod同时满足才开始调度
nodeAffinity：硬约束，确保所有Prefill Pod调度到IB交换机下的NVIDIA-H100节点
- nvidia.com/gpu.product: NVIDIA-H100：选择NVIDIA-H100节点
- topology.kubernetes.io/switch-type: ib：必须在IB交换机下
networkTopology.mode: hard：硬约束，必须按照highestTierAllowed选择网络距离近的节点
networkTopology.highestTierAllowed: 2：允许在Tier 2（IB汇聚交换机）内调度
podAntiAffinity：软约束，尽量将Pod分散到不同节点
NCCL_IB_DISABLE=0：启用IB网络

调度效果（网络拓扑感知的优势）：

如果不使用网络拓扑感知调度或未限制交换机类型：

❌ 12个Pod可能分散在IB和以太网交换机下
❌ 延迟问题：跨交换机类型通信延迟可能达到5-10μs
❌ 带宽损失：跨交换机类型带宽降至100Gbps，损失50%
❌ KV Cache传输效率严重下降，吞吐量可能下降30-50%

使用网络拓扑感知调度 + IB交换机约束后：

✅ 12个Prefill Pod全部部署在IB交换机下（ib-switch0和ib-switch1）
✅ 大部分Pod在同一叶子交换机下，通信延迟<2μs，带宽200Gbps
✅ 少数跨叶子交换机的通信也在同一IB汇聚交换机（ib-switch4）下，延迟2-5μs，带宽200Gbps
✅ 避免跨交换机类型通信，无带宽损失，网络性能最优

Decode服务配置

需求：部署Decode服务，12个Pod，选择NVIDIA-GeForce-RTX-4090节点，尽量集中在少数交换机下，并与Prefill服务在同一汇聚交换机下。

提示

这里使用Volcano Job来演示Decode服务的部署，若使用Deployment部署，相关配置一致。

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: pd-decode-service
spec:
  minAvailable: 12  # Gang调度：12个Pod必须同时满足
  schedulerName: volcano
  queue: default
  
  # 网络拓扑感知调度：优化节点选择，尽量集中在少数交换机下
  networkTopology:
    mode: hard  # 硬约束，必须按照highestTierAllowed选择网络距离近的节点
    highestTierAllowed: 2  # 允许在Tier 2（汇聚交换机）内调度
  
  tasks:
    - replicas: 12
      name: decode-worker
      template:
        spec:
          # 节点亲和性：必须选择IB交换机下的RTX 4090节点（硬约束）
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: nvidia.com/gpu.product
                        operator: In
                        values:
                          - NVIDIA-GeForce-RTX-4090  # 必须在RTX 4090节点
                      - key: topology.kubernetes.io/switch-type
                        operator: In
                        values:
                          - ib  # 必须在IB交换机下
            
            # Pod反亲和性：尽量将Pod分散到不同节点（软约束）
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
                - weight: 100
                  podAffinityTerm:
                    labelSelector:
                      matchExpressions:
                        - key: volcano.sh/job-name
                          operator: In
                          values:
                            - pd-decode-service
                    topologyKey: kubernetes.io/hostname
          
          containers:
            - name: decode-service
              image: vllm/vllm:latest
              command: ["python", "-m", "vllm.entrypoints.api_server"]
              args:
                - "--model=/models/llama-70b"
                - "--tensor-parallel-size=1"
                - "--pipeline-parallel-size=1"
                - "--enable-prefix-caching"
              env:
                - name: NCCL_IB_DISABLE
                  value: "0"    # 启用IB网络
                - name: NCCL_SOCKET_IFNAME
                  value: "ib0"  # 指定IB网络接口
                - name: NCCL_IB_HCA
                  value: "mlx5" # 指定IB设备
              resources:
                limits:
                  nvidia.com/gpu: "1"
                requests:
                  nvidia.com/gpu: "1"
          restartPolicy: OnFailure

关键配置说明：

minAvailable: 12：Gang调度，确保12个Pod同时满足才开始调度
nodeAffinity：硬约束，确保所有Decode Pod调度到IB交换机下的NVIDIA-GeForce-RTX-4090节点
- nvidia.com/gpu.product: NVIDIA-GeForce-RTX-4090：选择NVIDIA-GeForce-RTX-4090节点
- topology.kubernetes.io/switch-type: ib：必须在IB交换机下
networkTopology.mode: hard：硬约束，必须按照highestTierAllowed选择网络距离近的节点
networkTopology.highestTierAllowed: 2：允许在Tier 2（IB汇聚交换机）内调度
podAntiAffinity：软约束，尽量将Pod分散到不同节点

调度效果（PD分离的完整优化）：

使用网络拓扑感知调度 + IB交换机约束后：

✅ 12个Decode Pod也全部部署在IB交换机下（ib-switch0和ib-switch1）
✅ Prefill和Decode之间的KV Cache传输主要在同一IB交换机（ib-switch0和ib-switch1），或者汇聚交换机（ib-switch4）下，延迟2-5μs，带宽200Gbps
✅ 避免跨交换机类型的KV Cache传输，无带宽损失
✅ 整体推理性能最优，吞吐量最高

与简单亲和性调度的对比：

对比项	简单亲和性调度	网络拓扑感知 + IB约束
`Prefill Pod`分布	可能分散在`IB`和以太网交换机	集中在`IB`交换机（`ib-switch0/1`）
`Decode Pod`分布	可能分散在`IB`和以太网交换机	集中在`IB`交换机（`ib-switch0/1`）
`Prefill`内部通信延迟	`2-10μs`（可能跨交换机类型）	`<5μs`（`IB`交换机内）
`Prefill`内部通信带宽	`100-200Gbps`（可能损失`50%`）	`200Gbps`（无损失）
`Decode`内部通信延迟	`2-10μs`（可能跨交换机类型）	`<5μs`（`IB`交换机内）
`Decode`内部通信带宽	`100-200Gbps`（可能损失`50%`）	`200Gbps`（无损失）
`Prefill-Decode`通信延迟	`5-10μs`（可能跨交换机类型）	`2-5μs`（同一`IB`汇聚交换机）
`Prefill-Decode`通信带宽	`100Gbps`（损失`50%`）	`200Gbps`（无损失）
整体吞吐量	下降`30-50%`	最优，无损失

总结

网络拓扑感知调度在大规模集群中的核心价值：

拓扑感知的性能优化：
- ✅ 在大规模混合网络集群（7个交换机，其中3个IB交换机、4个以太网交换机，最多384台服务器）中，网络拓扑感知调度能够显著优化节点选择
- ✅ 通过IB交换机类型约束，确保所有高性能任务部署在IB交换机下
- ✅ 12个Prefill Pod和12个Decode Pod集中在IB交换机下，避免跨交换机类型通信
- ✅ 通过highestTierAllowed: 2限制，确保所有Pod在同一IB汇聚交换机（Tier 2）下
- ✅ 延迟优化：从可能的5-10μs降低到2-5μs，性能提升2-5倍
- ✅ 带宽优化：保持200Gbps带宽，避免50%的带宽损失，吞吐量提升30-50%
解决简单亲和性调度的局限性：
- ✅ 简单的节点亲和性只能保证GPU型号正确，无法感知网络拓扑和交换机类型
- ✅ 网络拓扑感知调度能够理解节点之间的网络距离和交换机类型，优先选择网络距离近且交换机类型匹配的节点
- ✅ 在满足GPU型号要求的前提下，进一步优化网络性能，避免跨交换机类型的带宽损失
资源精细化利用：
- ✅ Prefill服务使用高性能NVIDIA-H100 GPU，满足计算密集型需求
- ✅ Decode服务使用性价比高的NVIDIA-GeForce-RTX-4090 GPU，满足访存密集型需求
- ✅ 充分发挥不同GPU型号的优势，降低整体成本
适应混合网络拓扑：
- ✅ 支持IB和以太网混合的多层级网络拓扑（叶子交换机、汇聚交换机、核心交换机）
- ✅ 通过HyperNode灵活定义网络拓扑结构，支持不同交换机类型的标识
- ✅ 适合大规模、复杂混合网络拓扑的集群环境
- ✅ 能够根据任务特性选择合适的交换机类型（高性能任务选择IB，非性能敏感任务选择以太网）
灵活扩展：
- ✅ 支持多个PD分离服务实例
- ✅ 可以根据负载动态调整Prefill和Decode服务规模
- ✅ 易于水平扩展，适应业务增长

场景背景​

基础设施环境​

PD分离推理场景介绍​

业务需求​

技术方案分析​

简单亲和性调度的局限性​

网络拓扑感知调度的优势​

使用方案​

HyperNode拓扑设计​

拓扑结构设计​

HyperNode配置​

方案实施​

为节点打标签​

Prefill服务配置​

Decode服务配置​

总结​

参考资料​