数据并行？这玩意算是分布式训练里的老伙计了。但你以为把数据切碎喂给每张卡就完事了？天真。上个月我们A100集群跑GPT-2微调，800张卡同步拉满，梯度同步那一下……整个机柜的交换机指示灯瞬间全绿——不是健康，是过载。CLOSE_WAIT积压到系统日志都打不开了。
后来复盘，问题出在通信。今天不扯虚的，纯聊这块的算法底裤和那些要命的坑。
不止是切数据——Ring AllReduce的拓扑魔术
数据并行并不是简单分数据，关键是梯度同步算法。传统参数服务器模式中央节点压力大，容易成瓶颈。更优雅的做法是Ring AllReduce，把GPU连成环，每个卡只与邻居通信。先用Scatter-Reduce把梯度散开并累加，再用AllGather把完整梯度收集回来。这个过程通信量是2(N-1)/N，几乎最优。就像十个朋友围成一圈传纸条，每个人把知道的部分加上自己的，转几圈后大家都拿到了全部信息。
对比PS模式，实测下，4节点32卡V100，PS模式通信时间占总step的38%，Ring AllReduce降到12%。带宽利用率从71%飙到96%。工程师的浪漫，就是把O(n)的带宽成本压到O(1)。再说NCCL，利用GPU Direct RDMA，绕过CPU内存，直接走PCIe或NVLink。简直粗暴。但配置错了也白搭——有一次环境里忘了装nvidia-fabricmanager，稳定性一塌糊涂。
通信风暴：当梯度同步变成了DDoS
大模型梯度量巨大，同步时瞬时流量冲垮交换机。就像早高峰地铁。有个场景：模型参数量10亿，FP32梯度就是4GB，100张卡同步时，网络要吞下400GB数据？不是这样算的，Ring是渐进的，但突发流量依然可怕。我们实际压测，在40Gbps网卡下，超过64卡时，同步延迟抖动剧烈，从50ms跳到800ms！原因？交换机buffer满，丢包，TCP重传。那次在线服务直接降级，惨。
解决？方法一，梯度累加，减少同步频率，但收敛可能变慢。方法二，梯度压缩，比如PowerSGD，把梯度矩阵分解为低秩，通信量减少到5%，代价是计算开销。方法三，也是最推荐，上硬件：Mellanox的SHARP（Scalable Hierarchical Aggregation and Reduction Protocol），在交换机里做聚合，把流量模型从多对多改为树形归并。我们启用后，64卡以上同步延迟降低70%。还有，TCP/IP协议栈开销也不能忽视，改RoCE或者IB是正道。
收敛困境：大力出奇迹的反噬
数据并行常伴随大batch size，因为每张卡要分数据。总batch size = per-gpu batch * world_size。比如per-gpu=32，64卡就2048。batch一大，训练不稳定，验证精度下降。传统药方是学习率线性缩放：lr = base_lr * total_batch/256。但光缩放不够，初始阶段梯度方向乱跳。需要warmup：前几个epoch学习率从小线性增长。我们实验用Cosine warmup+线性缩放，成功把2048 batch的精度恢复到小batch水平。
但是，当batch超大（比如32k）时，即使warmup也会掉点。这就得用LARS或LAMB优化器，自适应调整每层学习率。实践上，用DeepSpeed的LAMB，32k batch训练BERT只损失0.2%精度。还有一个坑：梯度噪声。大batch梯度方差小，容易陷入sharp minima，泛化差。可以加标签平滑、MixUp等正则化。总之，别以为数据并行就是免费午餐。
异步的罂粟：快但有毒
为了加速，有人用异步SGD，worker独立更新，不等其他人。这样快，但模型参数可能从不同时间点拉取，梯度过期。我们试过一次，训练初期快30%，但后期loss震荡，最终收敛点比同步差1.5个BLEU。更别说调试时候梯度值莫名其妙。建议除非万不得已，坚守同步；真要异步，加个staleness bound限制最大延迟步数，再用TK或DC-ASGD补偿。但工程复杂度陡增。
搞数据并行，看起来简单，实际是通信、数值、系统的三体问题。想驾驭它，得先敬畏那个悄悄老去的交换机。最后说一句——千万别在周五下午改AllReduce的chunk size，否则周末就泡汤了。
