拓扑感知调度

Brief

GPU 和 LPU 不再是彼此独立的设备，而是构成紧密耦合的加速器网络，其整体性能高度依赖于作业放置位置和底层拓扑结构。在类似 NVIDIA NVL72 这样的机架级系统中，72 张 GPU 共享超过 13 TB 显存，对上层表现为一个单一加速器——直到工作负载跨越交换机“岛屿”，把原本高效的集体通信操作变成瓶颈。类似地，Groq 采用编译期、软件调度的架构，预设了确定性的数据流动；随机调度会打破这些假设和可预测性。即使在同一个数据中心内部，不同 GPU 之间的性能也可能存在显著差异，这推动了一类新的需求：在调度作业时，调度器必须感知硬件拓扑和性能波动，做出拓扑感知的放置决策。

那些忽略 NVLink、PCIe 或 NIC（网卡）拓扑的朴素调度器，往往会把多 GPU 工作负载任意打散，从而导致训练 step time 变长、整体效率下降。训练工作负载通常是同步、带宽受限的，更偏好部署在同一 NVLink“岛屿”的连续 GPU 上，并要求在 all-reduce 和流水线阶段维持统一的高带宽通信路径。这类作业的调度应基于网络织物带宽进行协同分配，避免跨交换机跳数，并将链路、交换机和节点边界视作故障域来处理。与之相对，推理工作负载则更受延迟和 SLO 约束，通常需要在跨故障域的多副本高可用与分片之间取得平衡，以在最短路径上保持 MoE（Mixture of Experts）和 KV-cache 的局部性。进一步针对 prefill 与 decode 阶段分别优化算力放置策略，配合微批处理和租户隔离，可以继续提升整体效率。

随着加速器性能越来越依赖网络和数据中心拓扑，我们认为拓扑感知调度将演变为必需能力。团队已经在评估 Kueue 及相关项目，以提升作业放置精度、性能表现，并在大规模扩展场景中保持可预测的伸缩能力，为客户提供更可靠的算力服务。

来源：技术雷达

Details

背景与现状：为什么需要拓扑感知调度

从“单卡性能”到“机架级加速器性能”

在大模型训练和高并发推理场景下，性能瓶颈正从单卡 FLOPS 转移到集群内通信与数据路径。典型变化包括：

• 机架级系统（如 NVL72 类形态）把几十张 GPU 绑定为一个大加速器，统一暴露显存和算力。
• 专用推理加速器（如采用编译期调度架构的设备）假设数据流是高度确定的，依赖稳定的网络和放置。
• 同一数据中心内，不同机柜、不同交换域之间带宽与延迟差异显著，对同步训练尤为敏感。

在这种背景下，调度器如果仍然只把 GPU 当作“同质资源池中的 N 个 slot”，就会系统性浪费硬件能力。

典型适用场景

拓扑感知调度主要针对以下场景产生价值：

• 大规模分布式训练：多机多卡、需要频繁 all-reduce / all-to-all 通信。
• 大模型推理服务：同时承载高并发在线请求与大 batch 批处理，使用 MoE、KV cache 等结构。
• 共享 GPU 平台：多团队、多租户共享集群，希望在不干预应用的前提下提升整体利用率和稳定性。

问题与风险：朴素调度的结构性矛盾

朴素调度忽略了“物理世界”

传统集群调度器往往只看到以下维度：

• $$\text{GPU_count}$$、$$\text{GPU_memory}$$、节点 CPU / 内存；
• 简单的 label（例如 “has-gpu=true”）。

在这种模型下，多 GPU 任务有较大概率被“打散”到：

• 不同 NVLink 岛之间；
• 需跨多级交换机才能互联的节点上；
• 带宽抖动明显或共享严重拥塞上行链路的机柜中。

结果是：

• 训练任务的 step time 明显变长，吞吐量下降；
• 同一模型不同 run 之间的性能不稳定，难以容量规划；
• 对于依赖确定性调度的推理硬件，可能直接破坏延迟 SLO。

性能与可靠性的隐性风险

在多租户场景中，缺乏拓扑感知还可能带来：

• 噪声邻居效应：一个高带宽训练任务影响同 fabric 上所有推理服务的 P99 延迟。
• 故障域耦合：将高可用副本集集中在同一交换机或机柜，一旦网络故障即整体失效。
• 性能回归难以归因：即便应用容器镜像、模型版本都未改变，仅调度放置位置不同就会引起 20%+ 性能波动。

模式与原理：拓扑感知调度在做什么

核心思路：把“拓扑”引入调度决策

拓扑感知调度的本质，是在调度决策中显式引入以下信息：

• 物理与逻辑拓扑：
  • NVLink 拓扑（岛内 vs 岛间）。
  • PCIe 关系（同根复杂度、跨 CPU socket）。
  • 网络拓扑（机箱内 / 机柜内 / 机柜间、交换层级）。
• 链路特性与健康状况：
  • 有效带宽、延迟、抖动。
  • 当前利用率和历史拥塞情况。
• 故障域边界：
  • 链路、交换机、机柜、供电和机房区域。

调度器基于这些信息，为不同类型的工作负载应用不同策略，而不是一刀切地按“能跑就行”来分配资源。

针对训练与推理的不同策略

1. 训练任务（同步、带宽受限） 目标：最大化通信效率、稳定 step time。 典型策略：

• 优先将同一作业中的 GPU 放在同一 NVLink 岛内，保证 all-reduce 的高带宽路径。
• 尽可能减少跨交换机跳数，避免跨机柜长路径。
• 将链路、交换机、节点视为不同层级的故障域：同一数据并行组尽量不跨“小概率共故障”的边界。

2. 推理任务（延迟 & SLO 约束） 目标：在高可用与局部性之间平衡。 典型策略：

• 通过副本跨故障域分布，提升高可用能力。
• 对 MoE、KV-cache 这种强调局部性的结构，尽量把相关 shard 放在最短网络路径上。
• 区分 prefill 与 decode 阶段：prefill 可适度批处理、追求吞吐；decode 更敏感于尾延迟，调度策略应不同。

对比与演进：从“资源视角”到“拓扑视角”

旧模式：资源是“可互换的”

传统 GPU 调度的假设：

• 只要满足 $$\text{N_GPU}$$、显存、简单 label，就认为机器是等价的。
• 性能回归多被归咎于模型或代码变化，较少怀疑“放置”。

这种模式在以下情况下还能凑合：

• 小规模训练（单机或少量节点）。
• 模型规模较小，对跨节点带宽不敏感。
• 推理 QPS 较低，对尾延迟要求宽松。

新模式：资源有“位置”和“关系”

拓扑感知调度的变化包括：

• 作业描述不再只有“要 8 张卡”，而是附带“需要单一 NVLink 岛”“允许最多 1 次跨交换跳”等约束。
• 调度决策不再是单步贪心，而是需要全局考虑同一 fabric 上多个作业的带宽竞争。
• 调度策略与底层硬件演进更加耦合：新架构（如 NVL、定制加速器）推出时，需要更新对应的拓扑模型和约束策略。

这意味着调度系统从“通用资源分配器”演进为“面向加速器的性能协调器”。

系统性影响：对平台与工程实践的改变

对整体架构与平台的影响

• 控制面复杂度上升 调度器需要：
• 与底层网络与 GPU 管理系统集成，获取实时或准实时拓扑信息。
• 保持拓扑模型与实际布线和变更同步（机柜搬迁、链路增减等）。
• 观测与调优需求增强 平台通常需要：
• 对 step time、集体通信耗时、网络利用率做统一观测。
• 建立“放置变化 → 性能变化”的可追踪性，方便调优与回溯。

对工程效率与协作方式的影响

• 开发与平台之间需要明确“需求表达接口”：
  • 例如通过作业 spec 中声明训练并行策略、容忍的网络拓扑级别。
  • 推理服务可能需在部署配置中指定对延迟和高可用的优先级取舍。
• 模型工程与 MLOps 团队需要理解：
  • 为什么同一个模型在不同集群拓扑下表现不同。
  • 何时应该通过调整并行策略、batch 策略而非简单加卡。

落地建议：如何在团队中实践拓扑感知调度

适用边界与前置条件

更适合考虑拓扑感知调度的场景：

• 单次训练需使用多机多卡，训练时间以天计，任一步长的提升都能带来可观收益。
• 集群内存在明显的网络分层结构（机架级 NVLink、分层交换网络），且已经观察到不同节点组合的性能差异。
• 多租户 GPU 平台中，训练与推理混部，经常出现性能互相干扰。

不建议优先投入的情况：

• 主要是小规模单机训练或轻量推理，对尾延迟不敏感。
• GPU 资源规模较小、网络拓扑比较“扁平”，实际收益有限。
• 缺乏基本的观测能力（不能方便地看到网络带宽、step time、P99 延迟等）。

渐进式引入路径

一个相对稳妥的推进路径可以是：

1. 观测先行

• 给现有训练与推理任务补全：step time、all-reduce 耗时、网络利用率、延迟分布的观测。
• 对比“不同节点组合”的性能差异，用数据证明拓扑确实是问题来源之一。

2. 离线分析与手工约束

• 在现有调度器上先引入简单的 soft constraint：
  • 如“同一训练作业的 GPU 优先同机柜”“同一 DP group 保持在同一 NVLink 岛”。
• 对比应用约束前后的性能变化和资源碎片率。

3. 集成拓扑信息与调度策略

• 引入支持队列与拓扑感知调度的组件（如正在被评估的 Kueue 等），将拓扑、带宽和故障域纳入调度决策。
• 根据训练 / 推理不同类型，定义并实现差异化调度策略（如不同优先级队列或 profile）。

4. 规模化与治理

• 当策略稳定后，将拓扑感知调度作为平台“默认能力”，并通过文档和模板向应用团队暴露少量可调参数，而非让每个团队自己写复杂约束。
• 建立变更流程：新增机架、扩容网络时，同步更新拓扑模型和调度策略。

典型风险与防范思路

• 风险：资源碎片化和队列等待时间上升
  • 防范：策略上区分“强约束作业”（大模型训练）与“弹性作业”（小规模训练或离线推理），对后者放宽拓扑要求，平衡整体利用率。
• 风险：调度逻辑过度复杂，难以维护
  • 防范：
    • 将拓扑模型与策略模块化，避免把所有规则硬编码在核心调度器中。
    • 保持清晰的可视化与调试工具，能直观看到一次调度决策为何如此产生。
• 风险：对平台与网络团队的协作要求陡增
  • 防范：
    • 从少量关键集群、关键模型开始试点，沉淀跨团队的协作模式与责任边界。
    • 把“拓扑变更影响评估”纳入变更流程，避免网络调整后调度行为失控。

整体而言，拓扑感知调度不是单一功能点，而是一条演进路径：随着训练规模增大、推理延迟要求收紧、硬件拓扑更加复杂，它逐渐从“高级优化”变成“基础能力”。对承担大模型训练和推理基础设施的团队而言，尽早在观测、建模和调度策略上预留演进空间，会减少未来被迫重构的成本。