一、先按模型规模定主策略
1.1 参数量决定要不要切到张量并行
当单卡显存装不下整份参数与优化器状态时，张量并行把权重沿隐藏维切开，是多卡协同的前提。参数量没到那个量级，硬上张量并行只会增加通信次数。先算清单卡能否容纳，再决定是否引入这一层切分。这一步想清楚，后面通信量能少一大截。先想透这层，落地才不会被通信拖后腿。
1.2 层数多优先看流水并行
模型层数很深时，流水并行把网络按层分段铺到不同设备，让各段交替工作。它缓解了单卡显存放不下整模型的问题，也降低了对单卡算力的绝对要求。层越多，流水并行的收益越明显，是深网训练常走的路线。分段得当，设备空闲时间会被明显压下来。
二、通信开销是隐藏的分水岭
2.1 卡间互联能力决定并行上限
再好的切分，也受卡间互联带宽制约。带宽不足时，设备间频繁交换激活值与梯度，通信时间盖过计算时间，并行效率骤降。选型阶段就要把互联能力算进上限，否则策略只是纸面可行。互联这关过不去，再好的切分也跑不出预期。互联能力这条线，选型时务必单独核。
2.2 用重叠把通信藏进计算里
把通信与计算在时间上重叠，是压低开销的务实办法：前一批在传，后一批在算。重叠做得好，通信几乎不额外占时间，整体效率明显抬升。这要求调度与内核配合，是落地时最该打磨的一环。重叠率提上去，有效算力才不被白白耗在等待上。
三、策略要随硬件与框架调
3.1 显存上限倒逼切分粒度
硬件显存越小，切分越细，通信链条越长。显存上限直接决定能选哪种并行组合，而非反过来。做方案时，先以显存为硬约束倒推切分粒度，再谈效率优化，顺序不能乱。约束摆在前，方案才不会一落地就撞墙。硬约束先行，后面调优空间才留得足。
3.2 框架原生支持度影响落地成本
同一套策略，不同框架的实现成本差很多。优先选对目标并行有原生支持的框架，能省下大量自研与调试时间。框架不支持的组合，即便理论上更优，落地代价也可能抵消收益。原生支持度，是评估方案可行性的硬指标之一。
结尾
分布式并行没有万能解，核心是先按规模定主策略、再被通信与显存约束收拢、最后贴合硬件与框架落地。把这三层想透，策略才不是堆名词，而是真正让训练跑得快又稳的抓手。定期回看效率数据，组合也能随业务持续调优。落地后盯住效率曲线，哪层切分拖了后腿，数据会直接告诉你。定期回看效率数据，策略才不会停在一年前的旧经验里。
