万卡规模的训练集群里，网络拥塞几乎不可避免。集合通信会在同一时刻让成百上千张卡向同一个方向发包，交换机缓存瞬间被填满，丢包和重传随之而来。拥塞控制算法的作用，就是让发送端感知网络状态、及时降速，避免拥塞崩溃。不同的算法在信号来源、收敛速度和硬件要求上差别很大，选型不能只看名气。

先看最常见的 DCQCN。它是数据中心量化拥塞通知的改进版，依赖交换机在队列超过阈值时标记数据包，接收端再把拥塞信号回传给发送端降速。优点是部署成熟，主流网卡和交换机都支持，调参资料丰富。缺点是信号依赖队列堆积，反应偏慢，在突发流量下容易先丢包再降速。对中小规模集群和流量模式相对平稳的训练任务，DCQCN 是稳妥的起点。

TIMELY 走的是另一条路。它用往返时延作为拥塞信号，时延一变大就降速，时延恢复就提速。因为时延变化早于队列溢出，它的反应比 DCQCN 更快。代价是对时延测量精度要求高，虚拟化环境或链路抖动大的场景容易误判。TIMELY 更适合时延稳定、链路质量好的自建集群，且需要网卡支持高精度时间戳。

HPCC 则把精确链路负载信息直接写进数据包，发送端能算出每条链路的利用率并精确调整速率。它的收敛最快、队列最浅，理论上最接近理想的拥塞控制。但 HPCC 要求交换机支持 INT 遥测，硬件门槛最高，部署成本也最大。对超大规模集群或对集合通信尾延迟极其敏感的任务，这笔投入才划算。

选型时可以按三个维度打分。第一是集群规模和流量突发程度，规模越大、突发越强，越值得用反应快的算法。第二是现有硬件支持情况，网卡和交换机支不支持相应的标记或遥测，往往直接决定了可选范围。第三是运维能力，参数调不好时，再好的算法也会表现平平，上线前必须在与生产一致的流量模型下做压测。

没有一种算法能在所有场景下最优。常见的做法是先用成熟的 DCQCN 跑通基线，再针对关键集合通信链路做专项压测，确认瓶颈确实来自拥塞控制而非拓扑或负载均衡后，再评估是否升级到 TIMELY 或 HPCC。把拥塞控制当作可度量的工程选项，而不是玄学调参，集群的训练效率才有持续改进的依据。