新闻中心

InfiniBand Congestion Control 与 Adaptive Routing 怎么配合:别把两者当成替代项 NEWS DETAIL

资讯分类 · NVIDIA 网络互连 作者 · 中科新远技术编辑部 审核人 · 中科新远 发布时间 · 2026-08-10 更新时间 · 2026-08-10 来源 · NVIDIA 官方文档
InfiniBand Congestion Control 与 Adaptive Routing 怎么配合:别把两者当成替代项
场景示意图,不对应具体设备型号、端口布局或技术拓扑。

结论先行:两者不是替代关系

InfiniBand Congestion Control 与 Adaptive Routing 应被看作两层互补机制:前者通过拥塞反馈和速率调节抑制持续排队,后者在可用路径之间分散流量,降低热点形成概率。路径改变不能替代端到端拥塞反馈,反之亦然。只开 Adaptive Routing,遇到接收端、注入端或下游端口长期过载时,流量仍可能在新路径上继续排队;只依赖拥塞控制,在拓扑存在多条等价或近似等价路径时,又可能错过更均衡的路径利用。

能力边界怎么划分

Congestion Control 关注“已经或正在发生的拥塞如何被端到端感知并收敛”,典型目标是减少热点扩散、降低丢包风险和长尾延迟。Adaptive Routing 关注“同一目的地是否可以选择更合适的下一跳”,典型目标是避开局部拥塞端口,提高 fabric 内链路利用均衡度。NVIDIA UFM Enterprise 的能力、对象和操作入口应以对应版本手册为准,部署前应核对 NVIDIA UFM Enterprise User Manual 中关于 InfiniBand fabric 管理、监控和配置项的说明。

决策对照

问题场景优先关注配置判断
少数端口出现持续队列和拥塞标记拥塞控制先确认反馈、阈值和端到端响应是否生效,再评估是否需要路径分散
多条上行链路利用率差异明显Adaptive Routing检查拓扑、路由引擎和可用路径条件,避免把所有压力压到固定链路
接收端处理能力不足拥塞反馈与业务限速换路只能转移中间链路压力,不能提升终端消费能力
作业流量突发且目的地集中两者协同用路径选择摊开瞬时热点,用拥塞控制约束持续过载
需要变更生产网络验证与回退先灰度、记录基线、保留原路由和原参数

适用条件要先复核

是否能启用、如何启用、哪些交换机或固件版本支持,不能凭经验推断。InfiniBand 子网管理器、交换机固件、网卡固件、UFM 版本、拓扑形态和业务通信模式都会影响效果。NVIDIA 的网络文档入口 NVIDIA Networking Documentation 可用于复核产品文档、版本说明和管理工具行为。对混合代际设备、分阶段扩容 fabric、非标准拓扑或已有厂商建议参数的现场,应先做兼容性和变更窗口评估。

常见失败边界

第一类失败是把 Adaptive Routing 当成拥塞控制。路径选择可以绕开某个拥塞端口,但如果热点来自许多节点同时写入同一存储、同一 GPU 组或同一服务端,瓶颈终点没有改变,网络只是在不同路径上排队。第二类失败是把 Congestion Control 当成路径优化。拥塞反馈能让发送端降速,但不会自动创造更短或更空闲的物理路径;如果路由长期把大流量压在同一组链路上,反馈只能缓解症状。第三类失败是只看平均吞吐,忽略尾延迟、端口拥塞事件和作业完成时间抖动,最后得到看似可用但不可预测的网络。

推荐配置顺序

  1. 建立基线:记录拓扑、路由模式、关键端口利用率、错误计数、拥塞事件、作业运行时间和 P99 延迟。
  2. 确认拥塞控制能力:按官方文档核对设备、固件、子网管理器和管理平台版本,避免在不支持或行为不明的组合上直接变更。
  3. 小范围启用或调整:优先选择可回滚的分区、机架或业务窗口,避免一次覆盖全 fabric。
  4. 再评估 Adaptive Routing:在存在多路径且流量分布不均时启用或调整,并观察路径利用是否更均衡。
  5. 固化参数:只有当吞吐、尾延迟、拥塞事件和作业稳定性同时改善,才把参数推广到更大范围。

验证指标不能只看一项

网络级验证至少应覆盖四类指标:端口层面的带宽利用率、拥塞或等待相关计数、错误和重传相关计数;作业层面的完成时间、吞吐和尾延迟;路径层面的链路利用均衡度和热点迁移情况;变更层面的告警数量、故障域和回滚时间。对于 HPC、AI 训练或存储流量,平均带宽提升但 P99 延迟变差,仍可能意味着配置不适合该业务。验证周期也要覆盖业务峰值,而不只是空闲时段的合成压测。

实施中的观察方法

变更后应比较同一批节点、同一作业、同一数据规模下的前后差异。若拥塞事件减少但链路利用更偏斜,说明路径策略可能仍需调整;若链路更均衡但端到端延迟未改善,要检查接收端、应用同步点或存储后端。若出现局部端口错误、链路 flap 或管理面告警,应先排除物理层和固件问题,避免把硬件或链路质量问题误判为路由策略问题。

回退路径要预先准备

生产环境中,回退不是事后补救,而是配置前提。应保存变更前的子网管理器配置、UFM 相关策略、路由模式、拥塞控制参数和设备清单;明确哪些参数可以在线恢复,哪些需要维护窗口或重启相关服务。若变更后出现作业大面积超时、尾延迟显著恶化、拥塞从单点扩散为多点,或监控显示未知错误上升,应先回退到已验证配置,再分离测试拥塞控制和 Adaptive Routing 的单项影响。

相关栏目与方案