顺德韭菜星1. 先聊清楚：DDP 到底解决了我什么问题
我最早接触分布式训练，纯属被逼的。模型从几千万参数涨到上亿之后，单卡训练一个 epoch 要跑大半天，调一次学习率就要等一宿，心态直接崩掉。后来把训练脚本从 DataParallel 切到 DDP（Distributed Data Parallel，分布式数据并行），同样的 batch size，四张卡跑出来的速度差不多是原来的 2.8 到 3.4 倍，那一刻我才意识到：DDP 不是锦上添花，而是大模型训练的刚需。
先给没接触过分布式训练的朋友一个直观类比：单卡训练就像一个人搬砖，你的 GPU 显存就是双手能捧的砖数。DDP 做的事情不是让这个人搬得更快，而是叫来一群人，每人分一块区域的砖，搬完互相打个招呼“我这边搬完了”，然后汇总结果。人多了，搬砖总量自然上去了，但这中间的“打招呼”方式如果设计得不好，就会变成一群人挤在同一个门口进进出出，效率反而更低。DDP 厉害的地方，就在于它把这套“打招呼”机制做得非常优雅，让多卡协作的开销降到最低。
DDP 的全称是 Distributed Data Parallel，PyTorch 官方推荐的分布式训练方案。它解决的问题很朴素：如何在多张 GPU（甚至多台机器）上，以最小的改动、最少的内存冗余、最快的通信效率，把一个 batch 的数据拆成多份并行计算，同时保证训练效果和单卡一致。它适合谁？适合所有已经用 PyTorch 写出单卡训练脚本、模型显存超了或者训练时间过长的人。哪怕你只有一台双卡机器，DDP 也能直接提速；如果你有八卡甚至多机多卡，DDP 几乎是绕不开的必修课。
但注意，DDP 不是银弹。如果你的模型特别大，单张卡连一个 batch 都塞不下，那你需要的是模型并行、流水线并行或者 ZeRO 这类显存优化手段。DDP 的默认设定是“每张卡都能装下一整个模型副本”，它解决的是“数据太多、算不过来”的问题，不是“模型太大、装不下”的问题。这一点在选型之前必须搞清楚，否则你会在 DDP 里浪费大量时间去调参数，最后发现方向就错了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. DDP 的核心设计思路：从 DataParallel 到 DDP，变化在哪
2.1 DataParallel 的坑，我替你踩过了
在 DDP 普及之前，很多人用的是 PyTorch 自带的 torch.nn.DataParallel（简称 DP）。DP 的思路是：一个进程里放一个模型，然后把每个 batch 的数据切分到多张卡上，每张卡前向计算得到梯度，最后汇总到主卡（通常就是 GPU 0）上更新参数。听起来好像没啥问题，但实际用起来，坑一个接一个。
首先，DP 的通信方式是“卡 0 集中式”。每轮迭代，所有卡的梯度都要传输到卡 0，卡 0 更新完参数再把新参数广播回去。这意味着卡 0 的通信负载和显存占用都远高于其他卡，GPU 利用率天然不均衡。更麻烦的是，多卡之间的梯度同步用的锁机制比较粗暴，很容易导致多卡并行时算力浪费。另一个经典问题是，DP 不支持模型并行，你在 forward 里写的任何张量都不能跨卡，只能在单卡内部跑完整个模型。
我自己的亲身体验是，DP 在四卡以内的提速效果尚可，一旦超过四卡，收益会明显下降，因为通信开销的增长超过了算力投入。而且 DP 的 batch size 设置很别扭——你设的 batch size 是“每卡的 batch size”，实际总 batch 等于单卡 batch 乘以卡数。这导致调参时脑子要不停换算，非常容易出错。更致命的是，DP 在分布式训练生态里几乎被抛弃了，很多新特性（比如 torch.compile、混合精度插件、梯度裁剪钩子）对 DP 的支持都是半吊子。所以新项目我从不建议用 DP，直接 DDP 起步。
2.2 DDP 的两大设计支柱：单进程多线程 + 梯度全局 AllReduce
理解了 DP 的痛点，DDP 的设计思路就很好理解了。DDP 采用“单进程控制多个子进程”的并行模式：每个 GPU 对应一个独立的 Python 子进程，各自拥有一份完整的模型副本、优化器状态和数据采样器。进程之间通过进程组（ProcessGroup）进行通信，后端默认是 NCCL（NVIDIA 专为多卡通信设计的库）。
DDP 的关键创新在于梯度同步阶段。它不再把梯度集中到某一张卡上，而是采用 AllReduce 算法：所有卡在反向传播计算出各自的梯度后，把梯度数据发送给所有其他卡，每张卡都拿到全部卡梯度之和（或平均值），然后各自用这个统一梯度去更新自己本地的模型副本。这样，每个副本的更新方向完全一致，训练效果等同于“使用全部数据训练出的模型”，但每一张卡只计算了自己那一份数据的前向和反向，计算量实现了线性扩展。
这里有个非常重要的细节：DDP 的 AllReduce 是在梯度计算过程中“边算边通信”的，不是等所有层梯度算完再一次性通信。PyTorch 把梯度张量按模型参数的注册顺序分桶（bucket），每个桶的梯度算完后立刻开始异步通信。这种做法的好处是，通信和计算可以重叠，GPU 在等通信结果时还能继续算下一层的梯度，从而把通信延迟“藏”在计算时间里。实测下来，这个设计至少能提升 20% 到 30% 的效率，是 DDP 能跑出接近线性加速比的关键。
2.3 为什么要用独立进程而不是线程
你可能会想：DP 就是多线程，DDP 是多进程，为什么进程比线程好？原因