训练作业拓扑感知的节点放置策略，核心是把GPU、网络交换机和NUMA节点的物理连接关系翻译成调度器能读懂的语言，让每个训练任务都落在通信成本最低的位置上，这是当前大模型训练集群缓解通信瓶颈的通用解法，也直接决定了一个集群能在多大比例上跑出理论算力。
拓扑感知的节点放置策略是什么
从一次慢训练事故说起
一台8卡A100服务器跑分布式训练,数据并行切8卡，按理说卡间走NVLink，通信效率不该差，但实际吞吐只有预期的七成，排查半天，问题出在调度器把8个Pod分到了两台机器上，每台4卡，跨机通信走的是IB网络，单次AllReduce的耗时比纯NVLink通信多了将近一个量级。
这种事故在训练集群里相当普遍,多数训练调度器默认只关心GPU数量够不够，不关心GPU之间的物理距离，可对数据并行和模型并行混合的训练作业来说，通信开销占到迭代总时长的相当一部分，通信路径一旦绕远，训练速度就肉眼可见地掉。
拓扑感知拆开看是三件事
第一件事是建立设备关系映射。 GPU和GPU之间是什么连接方式，是NVLink全互联、NVLink部分互联，还是走PCIe Switch，再到跨机走RDMA网络，每一层链路的带宽和延迟差异很大，把一张8卡服务器的卡间拓扑画出来，通常能看到两颗CPU、四张HCA网卡、多个PCIe Switch之间的完整连接路径。
第二件事是把作业的资源需求翻译成拓扑偏好。 一个训练任务不一定只申请GPU，它还隐含着“哪些GPU要尽量靠在一起”的诉求，张量并行最好全部落在同一张卡间拓扑最优的节点上，数据并行副本之间可以跨机但要走高速网络，流水线并行的不同stage反而不希望全部挤在一起。
第三件事是调度决策时做匹配。 调度器拿到作业的拓扑偏好后，去集群的设备关系图里找满足条件的节点组合，这个匹配过程可以发生在调度器的预选阶段，也可以发生在优选打分阶段，打分标准通常参考通信链路总带宽、跳数、是否跨NUMA等指标，得分最高的组合胜出，进入绑定执行阶段。
这三件事环环相扣,缺了设备关系映射，调度器就是瞎；缺了作业偏好描述，调度器不知道怎么选；缺了匹配算法，前面两件事做了也白做。
为什么训练作业性能会卡在节点放置上
GPU集群里的隐形竞争
训练集群的物理架构大致分三层：服务器内部GPU互联、机柜内服务器互联、机柜间网络互联。
三层带宽逐级递减，延迟逐级递增。 同一个8卡节点内部NVLink带宽在数百GB/s级别，跨机走IB网络降到几十GB/s量级，跨机柜再打折扣。
一个调度器若把训练作业均匀打散到各个机柜,表面上每个节点负载均衡，实际上训练作业内部每次梯度同步都要经过漫长的跨柜路径，多个作业同时跑的时候，跨机柜的流量还会在汇聚交换机上打架，导致延迟抖动进一步放大。
网络长尾是训练的大敌
分布式训练是典型的木桶效应,一个训练step要等所有rank完成局部计算和梯度同步才能继续，某个节点网卡降速或者交换机拥塞一下，整个作业的迭代时间就被拉长，相当一部分AI平台反馈，训练作业的性能不稳定问题最终都指向通信链路上的某几个慢节点。
行业共识认为,节点放置策略对训练性能的影响经常被低估，模型参数越多、并行规模越大，通信开销占比越高，节点放置带来的性能差异越明显。
CPU和GPU也要“住得近”
不少工程师还容易忽略NUMA的影响,GPU显存拷贝数据到CPU内存，或者CPU参与梯度聚合时，跨NUMA访问的带宽损失明显，调度器若不感知NUMA拓扑，把GPU Pod调度到远端CPU对应的PCIe插槽上，数据搬运路径变长，训练吞吐一样受影响。
拓扑感知的节点放置策略不只是处理卡间NVLink的问题,它还要处理CPU-GPU亲和性、PCIe Switch共享冲突、网卡与GPU所在位置的一致性这些细节。
生产环境里如何落地拓扑感知的节点放置策略
先采集集群拓扑这张“地图”
没有地图谈不上导航,实际动手第一步，是把每台GPU服务器的硬件拓扑信息采集上来，形成结构化的标签数据。
- 服务器内执行
nvidia-smi topo -m查看卡间互联矩阵，记录每对GPU的连接类型（NVLink、PCIe、SYS）。 - 用
ibstat和ibnetdiscover获取InfiniBand网络的子网划分和端口连接位置。 - 用
lstopo命令输出CPU、GPU、PCIe Switch、网卡之间的树状连接关系。
把这些信息整理成拓扑标签,挂在Kubernetes节点上，比如一张8卡A100节点可能拥有这样的标签：
gpu-topo.nvidia.com/nvlink-type=fullgpu-topo.nvidia.com/pcie-switch-group=sw0:gpu0,gpu1,gpu2,gpu3rdma.baidu.com/subnet=subnet-1cpu.gpu.affinity=dual-numa
标签粒度不用太细,细到PCIe Switch级别就能覆盖大多数场景，粒度太细标签爆炸，调度器匹配成本反而高。
Kubernetes节点放置策略怎么配置
调度器层面的改造可以分阶段推进。
阶段一，用节点亲和性做粗粒度约束。 在Pod的spec里通过nodeSelector或nodeAffinity限定作业跑在哪些拓扑域的节点上，适合作业类型少、拓扑要求固定的场景。
阶段二，部署自定义调度器插件。 实现一个Scheduler Plugin，在NodeScore和Permit阶段读取Pod的拓扑偏好和节点拓扑标签，计算候选节点组合的通信代价分，例如给跨NUMA的组合扣分，给跨PCIe Switch的组合扣分，给跨机柜的组合重扣，这个方案的弹性远好于静态亲和性，可以细粒度定义打分权重和约束条件。
阶段三，接入外部批调度框架。 集群规模达到数百卡以上时，Kubernetes默认调度器处理大批量Pod排队的能力有限，业界常见的方案是接入支持拓扑感知的批调度器（如Volcano、Kueue结合自定义插件），在作业排队阶段就把多个Pod当作一个整体来分配节点组，而不是一个个分散调度。
三种路线的取舍可以参考下表：
| 方案 | 改造成本 | 调度精度 | 适用规模 |
|---|---|---|---|
| 节点亲和性 | 低 | 粗粒度 | 小于20卡的小集群 |
| 调度器插件 | 中 | 中高粒度 | 数十到数百卡 |
| 外部批调度器 | 高 | 高粒度 | 千卡级集群 |
无论走哪条路线,有一个原则是共通的：训练作业的Pod不是一个独立的个体，而是一个需要同生共死的群组。 调度逻辑必须面向“Pod组”而不是单个Pod来设计。
多机多卡训练节点放置的实用检查单
动手配置时,建议按下面几个步骤逐项核对。
- 看卡间互联类型。 NVLink全互联的节点适合张量并行和模型并行混布的作业；PCIe Switch互联的节点适合数据并行或流水线并行的局部放置。
- 看网络层级。 两层CLOS网络下，优先把作业放在同一个Leaf交换机下；三层架构下，尽量让所有rank落在同一个Spine域内，避免跨Spine通信。
-
映射并行策略到拓扑。
张量并行落在单节点内，节点内卡数不够则优先同机柜补齐；流水线并行跨节点分布，每个stage分配到不同PCIe Switch组或不同机柜，既分散了通信压力也减少了单点故障影响；数据并行副本可以跨机但必须位于同一个高速互联域。 - 验证一下实际效果。 多机多卡训练作业落地后，对比
nvidia-smi topo -m得到的理论拓扑和实际Pod运行的节点列表，然后用通信算子测试（例如NCCL的all_reduce_perf）对比优化前后的带宽达标率，优化合理的集群，AllReduce带宽达标率通常稳定在一个令人满意的水平。
训练作业拓扑感知的节点放置策略常见疑问
拓扑感知调度会让作业排队时间变长吗？
排队时间会略微增加,但多数情况下收益大于代价，它本质是用更精确的资源匹配来换取训练性能，代价是集群被划分成了若干拓扑域，调度器只能在局部范围内寻找满足条件的节点组合，小规模作业或碎片化集群里排队变长的感知较明显，大规模集群里反而因为吞吐提升而抵消了排队影响，生产实践中一般会把拓扑感知逻辑做成可开关的软约束，只在性能敏感的模型训练作业上启用。
只用Kubernetes自带的亲和性配置能替代定制调度器吗？
能覆盖一部分基础场景,但替代不了一个完整的拓扑感知调度策略。nodeAffinity本质上做的是固定分组，它告诉调度器“这个Pod只能去哪儿”，但训练作业的拓扑需求随模型并行方案动态变化，同一套8卡GPU节点，跑数据并行时希望8个Pod尽量分散，跑张量并行时希望8个Pod紧紧聚在一起，静态的标签匹配无法表达这种动态意图，必须由自定义调度逻辑来处理。
如何验证一个训练集群的节点放置是否合理？
有三个快速检查维度,第一，看nvidia-smi topo -m输出的实际节点分配与作业运行位置是否一致，若作业卡跨机柜但并行策略要求机内通信，等于白白浪费本地NVLink带宽，第二，用AllReduce基准测试在同集群不同放置组合下对比耗时，合理放置下8卡全NVLink的AllReduce耗时应该显著低于跨机组合，第三，观察训练日志里的迭代时间波动，正常情况每次迭代时间应该平稳，若频繁出现偶发尖峰，大概率是某个rank所在链路的网络拓扑存在慢路径，需要重新审视节点放置或网络规划。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623173.html
