拓扑感知调度的目标是让通信紧密的进程尽量落在合适的 GPU、CPU、网卡和网络故障域内，减少跨 NUMA、跨交换层级或跨拥塞域的绕行。它不是简单添加节点标签，而是把真实硬件拓扑、作业并行策略和容量约束转换为调度器能执行的规则。
适用条件与判断边界
适用于多 GPU、多网卡、多机并行且节点或网络并非完全同构的集群。作业需要能够表达副本数、GPU 数量、通信组和容错要求；平台侧需要可靠采集 GPU-NIC-CPU 亲和性、机架或 Pod、交换域与维护状态。小型单机任务可能无需复杂规则，但也要避免落到降级节点。
实施与选型方法
先用系统工具和资产数据生成节点拓扑事实，按 NUMA、GPU 互连、网卡亲和、机架和网络平面建立稳定标签。再根据数据并行、张量并行或流水并行的通信强度定义优先与禁止条件。调度策略应同时考虑资源碎片，不能为了局部最优让大作业长期无法排队。每次调度后将实际放置与 NCCL 路径、接口流量和作业表现关联。
主要风险与控制方式
风险包括标签过期、人工修改造成事实漂移、约束过严导致资源闲置、约束过松让通信跨域，以及把故障域集中误认为性能优化。拓扑规则还可能与抢占、弹性伸缩和维护冲突。不能仅凭调度成功判断放置正确，应检查任务实际绑定和数据路径。
如何核验结果
- 抽取不同节点核对标签与 PCIe、NUMA、GPU、网卡及机架事实，发现漂移立即隔离。
- 比较拓扑感知前后的实际放置、接口流量、作业完成时间和资源碎片，而非只看平均利用率。
- 模拟节点或网络故障域不可用，验证任务重排不会违反隔离和容量保护规则。
下一步行动
先选择通信密集且结果稳定的作业建立拓扑策略试点，将标签生成自动化并设置过期检查。策略上线后持续观察排队时间与资源碎片，按业务证据调整软硬约束。
核对具体版本与功能边界时，可查看Kubernetes 节点分配文档、NVIDIA NCCL 故障排查，并以目标版本页面为准。
WeChat
Profile