資料並行

3 秒看懂

• 定義：資料並行（Data Parallelism, DP）是一種將訓練資料集切分成多份，在多個計算裝置（如GPU）上分別維護一份完整的模型副本，各裝置獨立進行前向傳播與反向傳播算出區域性梯度，再通過全域性通訊將梯度同步、求平均，最終用一致的平均梯度更新模型引數。
• 核心機制：每步迭代等價於增大等效批次規模（effective batch size），梯度同步通常依賴AllReduce（如環狀AllReduce）實現，通訊量約等於模型引數量 × 2（梯度傳一次再歸約一次）。
• 典型應用：現代大型模型訓練的“基本面”並行策略；幾乎總與模型並行（張量並行/流水線並行）及ZeRO最佳化等組合使用，以突破單卡視訊記憶體與算力邊界。
• 優勢與約束：實現相對簡單，但對視訊記憶體要求高——每個裝置必須裝下完整模型（包括最佳化器狀態）。模型過大單卡裝不下時，純資料並行就無法工作，必須引入其他並行策略。

3 分鐘產業解釋

在 AI 基礎設施語境中，資料並行是最基礎也是最先被工程化的分散式訓練手段。產業側習慣將資料並行看作**“橫向擴充套件（Scale‑out）”**：不改變模型的微觀結構，只是讓更多硬體同時跑同一份模型、處理更多樣本，從而縮短牆壁時間。

實際部署時，資料並行逐漸從樸素的“每個GPU算完梯度，送引數伺服器聚合”演進為高效能單指令集/純裝置間聚合的 AllReduce 集合通訊。典型的環形 AllReduce 把梯度同步的頻寬放大係數控制在2倍（雙向環形），讓通訊時間不隨參與者數量線性增長。當 GPU 間互聯從 PCIe 升級為 NVLink、InfiniBand 等高速通路，資料並行可以在數百甚至上千個加速器上維持較高的擴充套件效率。

產業實踐裡，純資料並行幾乎已退化為底層運算元，真正上產的方案往往是資料並行 + 張內並行 + 流水並行 + 解除安裝/重計算的混合體。Megatron‑LM 等架構把資料並行與模型並行的維度統一為並行的“軸”，使用者只需配置張量並行度、流水並行度、資料並行度，系統自動處理跨節點的通訊需求。資料並行對應的通訊原語仍以 AllReduce 為主，但已融進更深度的流水排程中。

需特別釐清的是，資料並行的通訊模式與 MoE 的“All‑to‑All”分派機制有本質不同：資料並行是梯度聚合，全域性約化；MoE 裡 token 到專家的路由則引發 All‑to‑All 分發。二者不能混淆。

用一句話概括產業鏈定位：資料並行負責把批次做大、把訓練加速，模型並行負責把模型拆開、把單卡裝下，兩者互補構成分散式訓練的主幹。

15 分鐘專家深入

1. 同步資料並行的工作流

一次典型迭代（以 PyTorch DDP 為例）：

• 切分資料：全域性 mini‑batch 被均分給每個 DP rank，各 rank 得到獨立的子集（區域性 batch）。
• 前向：各 rank 用相同初值的模型副本對區域性 batch 做前向計算，得到各自損失。
• 反向：各 rank 獨立計算區域性梯度 \nabla \mathcal{L}_k。
• AllReduce 梯度：所有 rank 通過 AllReduce 通訊對區域性梯度求平均（通常是 sum 然後除以 world_size），得到全域性平均梯度 \frac{1}{N}\sum_k \nabla \mathcal{L}_k。
• 最佳化器步進：各 rank 使用完全相同的平均梯度更新引數，從而保證下一步各副本仍然一致。

2. 通訊複雜度與Ring AllReduce

若模型有 $P$ 個引數（以浮點數計），每步梯度同步需傳輸 $2P$ 個元素（演算法層面，先做 ReduceScatter 再 AllGather，合計2倍資料量）。Ring AllReduce 將節點組織成邏輯環，頻寬需求近似為 2P \cdot \frac{N-1}{N} per rank（$N$ 為 rank 數），在 $N$ 較大時每個節點實際傳送量和接收量均約為 $2P$（準確為 2P \cdot \frac{N-1}{N}），有效降低了單點壓力。這解釋了為什麼大型模型訓練極度依賴高速互聯：$P$ 動輒數十億至數千億，$2P$ 當 $N$ 為千卡級別時仍然極其考驗網路背板頻寬。

3. 等效批次與泛化權衡

資料並行 $N$ 路同時工作時，等效全域性 batch size 為區域性 batch size × $N$。增大全域性批次能提高硬體利用率，但過大的 batch 可能破壞收斂性，需配合學習率縮放（如平方根縮放或線性縮放）、LARS/LAMB 等專用最佳化器。業界常通過“梯度累積 + 資料並行”的疊加來解耦物理並行度與邏輯 batch size。

4. 非同步資料並行的退化

早期為降低同步等待，有非同步更新方案（引數伺服器模式），各 worker 將梯度推給 server，不等全體完成就拉取新引數。理論上可以提高硬體利用率，但會引入梯度過期（staleness），收斂行為更難預測。當今大型模型訓練為穩定收斂幾乎清一色採用同步資料並行，非同步主要留存在某些推薦系統或對延遲不敏感的領域。

5. 混合並行中的 DP 定位

在 3D 並行體系（TP‑CP‑DP‑PP 等表述中），資料並行處於最外層：對於流水線並行的每個 micro‑batch 排程，真正的 DP 梯度同步只在所有 micro‑batch 的梯度累積完後執行一次 AllReduce。這樣 DP 的通訊頻率被降低了（比如 Megatron 中梯度累積步數同流水階段數相關），有效掩蓋部分通訊開銷。

技術原理（最深，講機制+關鍵引數）

全部梯度同步的 AllReduce 路徑

假設有 $N$ 個裝置，每個裝置持有區域性梯度向量 \mathbf{g}_k，長度 $P$。目標計算 \overline{\mathbf{g}} = \frac{1}{N} \sum_{k=1}^N \mathbf{g}_k。

樸素 AllReduce：
直接進行全域性求和再廣播。對於頻寬有限的環境，高效實現為Ring AllReduce。將 $P$ 個元素均分成 $N$ 個塊（chunk），裝置編號 $k$ 會接收前驅裝置傳來的塊並累加，再傳遞給後繼。詳細步驟：

階段1: ReduceScatter（每個裝置最終持有一個完全歸約的 chunk）
for i = 0 to N-2:
    send chunk[(k - i) mod N] to (k+1) mod N
    receive chunk[(k - i - 1) mod N] from (k-1) mod N
    將接收到的 chunk 與本地對應 chunk 累加

階段2: AllGather（將歸約後的 chunk 廣播給所有裝置）
for i = 0 to N-2:
    send 本地持有之已歸約 chunk 至下一裝置
    receive 另一 chunk 來自前一裝置並存儲

總通訊量為每裝置傳送 2P \cdot \frac{N-1}{N} 個元素，接收同理，頻寬利用率高，且無須中央匯聚節點。

梯度分批與通訊計算重疊

現代架構（如 PyTorch DDP）將梯度桶（buckets）化：一旦某個桶的反向計算完成，立即啟動該桶的非同步 AllReduce，使得通訊與反向後續層計算重疊。桶大小（bucket size）為可調引數，影響通訊合併的粒度。

關鍵引數

• DP 並行度 $N$：增加時，等效 batch size 年增率例增大，單迭代時間受通訊延遲和網路拓撲約束。
• 區域性 mini‑batch 大小：由單裝置視訊記憶體決定，同時模型必須完整駐留。
• 通訊頻寬 $B$（單向有效頻寬）：AllReduce 時間近似 t_{\text{comm}} \approx \frac{2P}{B}（在理想環形且無延遲假設下）。
• 計算時間 t_{\text{calc}}：正比於區域性 batch 大小與模型計算量。擴充套件效率 E = \frac{t_{\text{calc}}}{t_{\text{calc}} + t_{\text{comm}}}。

與 ZeRO 的耦合

ZeRO‑1 把最佳化器狀態分片到各 DP rank，但梯度仍然需要 AllReduce 來獲得平均梯度；ZeRO‑2 額外分片梯度，在梯度歸約過程中完成 Reduce‑Scatter 即可，各部分僅保留自己負責的梯度分片；ZeRO‑3 進一步分片引數。這意味著資料並行的通訊量從完整的 $2P$ 最佳化為與分片策略相關，但底層依然是集合通訊原語的運用。此時的 DP 概念已從“每個裝置有完整模型”泛化為“資料被切分且各裝置需協作完成全域性更新”。

ASCII 示意（簡化流程）

  Rank0: x0,y0 -> forward -> loss0 -> backward -> g0
  Rank1: x1,y1 -> forward -> loss1 -> backward -> g1
  Rank2: x2,y2 -> forward -> loss2 -> backward -> g2
                      |
                  AllReduce(g0,g1,g2) → g_mean
                      |
               each rank optimizer.step(g_mean)

技術演進史

• 單機多卡時代（2012‑2015）：資料並行最初為多 GPU 在同一臺伺服器內通過 PCIe 通訊實現。架構多為 Caffe、早期的 TensorFlow，基本是引數伺服器架構，梯度彙總採用 CPU 記憶體集中，再分發。
• 多機擴充套件與 AllReduce 引入（2016‑2017）：百度等開源的 AllReduce 實現（如 TensorFlow 的 baidu‑allreduce），將 ring‑based 演算法帶入分散式訓練主流。Horovod（Uber）進一步打包，使得使用者只需幾行程式碼就能把單機訓練拓展為多機多卡資料並行。此時通訊後端以 MPI、NCCL 為主。
• 混合並行崛起（2019‑2021）：模型規模超越單卡視訊記憶體，純資料並行無法繼續；Megatron‑LM 引入張量並行、流水並行，資料並行作為外維並行度與它們結合。Deepspeed 通過 ZeRO 把純資料並行延展到可訓練超大型模型，本質仍是 DP 的演進。
• 跨代互聯與超大規模叢集（2022‑至今）：用上高頻寬域（如 NVSwitch 連線節點內多卡）及 800G 等跨節點互聯，資料並行擴充套件至數千卡甚至萬卡，通訊時間佔比被顯著壓低；同時各種通訊壓縮（梯度量化、稀疏化）也開始與 DP 融合，以減少千卡級網路壓力。MoE 大型模型中，資料並行維度與專家並行維度解耦，通訊模式更復雜。

技術路線對比（量化表）

注：以下為定性比較，具體數值因硬體、拓撲而異，僅作特性示意。

並行策略	模型駐留要求	主要通訊原語	單次通訊量(近似)	擴充套件瓶頸	典型組合架構
資料並行 (DP)	每個裝置完整模型 + 最佳化器狀態	AllReduce	2 \times 引數量	視訊記憶體不足、頻寬/延遲	PyTorch DDP、Horovod
模型並行 (張量並行, TP)	每個裝置僅持模型一部分	AllReduce / ReduceScatter (單層內)	隨並行度變化，部分層約 2 \times 啟用量	通訊細粒度頻繁，需高速內部互聯	Megatron‑LM
流水線並行 (PP)	每個裝置持若干連續層	點對點發送/接收（啟用、梯度）	每 micro‑batch 邊界傳輸啟用，量遠小於 DP	流水氣泡，排程複雜度	GPipe, PipeDream
ZeRO (資料並行+狀態分片)	各裝置部分狀態，計算時收集	ReduceScatter (梯度) + AllGather (引數)	逐階段降低，ZeRO‑3 約 $2P$ 但分片	恢復引數/梯度的通訊量在固定頻寬下仍有限制	DeepSpeed

上下游

• 上游：高效能網路硬體（NIC、交換器、線纜）、集合通訊庫（NCCL、MPI、Gloo）、訓練架構（PyTorch、JAX、TensorFlow）。這些元件直接決定了資料並行的通訊效率和易用性。
• 下游：大型模型訓練平台（如 NeMo Megatron、DeepSpeed 生態）、分散式訓練作業排程器（如 Slurm + Pyxis/Enroot）、雲端廠商的 GPU 叢集服務。資料並行是這些平台對外提供加速服務的核心基礎元件。AI 應用側（自監督預訓練、微調）普遍依賴以資料並行為基礎的分散式方案。

關鍵指標

• 擴充套件效率：E_{\text{scale}} = \frac{\text{單卡吞吐} \times N}{\text{實測N卡吞吐}}。優質分散式訓練追求 E_{\text{scale}} > 0.9。
• 梯度通訊時間佔比：\frac{t_{\text{comm}}}{t_{\text{iter}}}，越低越好，一般希望 <10%。
• 等效 batch size：B_{\text{global}} = B_{\text{local}} \times N，必須與學習率設定共同影響最終精度。
• 每步通訊量：約為 2 \times \text{模型引數量} \times \text{資料位元組寬度}（FP16 時為 $4P$ 位元組）。

這些指標依賴於交換器頻寬、網絡卡數量、拓撲（Fat‑Tree vs Dragonfly）、同號卡 NVLink 域內通訊 vs 跨節點 IB/RoCE 通訊等。具體引數因硬體代際差異巨大，須以實測為準。

供需與市場資料

（由於搜尋不可用，以下僅提供定性趨勢，無精確數字）

• 需求：大型模型研究/生產幾乎為剛需。GPT‑4、Llama 3、Gemini 等訓練均需數百至數千加速器以資料並行為主幹擴充套件。中小規模微調對多卡資料並行的需求同樣旺盛。
• 供給：算力供給來自 NV GPU、AMD GPU、各色 ASIC 叢集，以及雲端租賃。資料並行對網路對稱性要求高，同構、高速互聯的叢集更易保證穩定的擴充套件效率，因此高階算力供不應求。
• 趨勢：向更大規模、更分散的跨地域資料並行邁進（如 Google 的跨 pod 訓練），但也面臨光傳輸成本和延遲挑戰。

代表公司與資本對映

• NVIDIA：提供 GPU 硬體，並通過 NCCL 集合通訊庫、Megatron‑LM 架構深度繫結資料並行實現。資本故事上，其硬體銷售直接受益於分散式訓練規模擴張。
• 微軟（DeepSpeed）：將資料並行與 ZeRO 融合，降低大型模型訓練硬體門檻，形成 Azure AI 服務的底層優勢。
• Meta（PyTorch）：PyTorch Distributed 是當下最多人使用的資料並行架構，間接促進其開源生態和內部研究。
• 雲端平台（AWS、GCP、Azure）：提供託管的分散式訓練叢集，資料並行加速是其訓練服務的核心賣點，驅動算力租賃營收。

投資邏輯

• 資料中心網路升級的受益者：資料並行對頻寬和延遲的高要求，會持續拉動機頂交換器、高速光模組/銅纜、網絡卡等需求。一個萬卡叢集的 AllReduce 通訊是網路裝置價值的關鍵推手。
• 架構與工具鏈壁壘：誰能提供更高效的資料並行通訊庫（如 NCCL）、更優的梯度融合排程，誰就更能繫結使用者。軟硬一體方案（如 NVIDIA GPU + NCCL + Megatron）形成閉環護城河。
• 視訊記憶體瓶頸帶來的混合並行需求：單純資料並行的侷限推動模型並行、視訊記憶體解除安裝等方案的採用，這使能提供“端到端訓練效率”的廠商（如提供完整 SuperPod 級系統的）獲得溢價能力。
• 警惕：若大型模型逐漸轉向低精度訓練、稀疏化、非同步更新等新技術，傳統同步資料並行在通訊上的收益可能被部分替代，但總體而言叢集網路需求仍將高企。

常見誤讀糾偏（≥2）

1. “資料並行就是簡單地把資料切成幾份就夠了。”
   糾偏：資料切分只是第一步。如果不做梯度全域性同步，各模型副本將學到不同資料分佈，最終完全分叉。資料並行的核心是同步後的平均梯度保證了數學上等效於單卡大批次訓練，這才是正確性前提。

2. “All‑to‑All 通訊就是資料並行的核心通訊方式。”
   糾偏：All‑to‑All 主要用於 MoE 的 token 分派（dispatch）和整合（combine），在標準 dense 模型的資料並行中並不出現。資料並行的主導集合通訊是 AllReduce，即便在 ZeRO 中也是 ReduceScatter 等變體。混淆二者會嚴重誤導系統設計與排程。

3. “資料並行和模型並行可以相互替代，哪個好用就用哪個。”
   糾偏：二者不可替代，解決的問題完全不同。資料並行解決樣本吞吐和加速；模型並行解決模型超過單卡視訊記憶體的存放問題。實際訓練必定同時使用多個維度並行。誤以為只靠資料並行就能跑千億引數模型，會直接導致 OOM 失敗。

學習路徑

• 入門閱讀：PyTorch 官方“Getting Started with Distributed Data Parallel”教程，理解 DDP 基礎用法、啟動方式。
• 原理深入：學習 Ring AllReduce 論文“Bringing HPC Techniques to Deep Learning”（Horovod 相關）；閱讀 NCCL 官方文件的 AllReduce 拓撲選擇。
• 工程實踐：在多 GPU 環境中嘗試從單卡調至多卡 DDP，觀察擴充套件效率；然後引入梯度累積、混合精度，理解通訊計算重疊。
• 混合並行：閱讀 Megatron‑LM 論文中的 TP、PP、DP 維度劃分，以及 DeepSpeed ZeRO 的階段分片邏輯，認清資料並行在混合並行中的位置。
• 系統層面：學習 InfiniBand 或 RoCE 網路知識，理解拓撲對 AllReduce 效能的影響，嘗試用 torch.profiler 分析通訊時間佔比。

一句話總結

資料並行是深度學習分散式訓練的**“底盤”技術**——通過同步梯度把多個硬體擰成一臺等效的大型加速器，其擴充套件效率決定著大型模型訓練的天花板，而通訊機制則是這個底盤的傳動軸。

延伸閱讀與來源

• 由於本次檢索全部失敗，以上內容基於公認的分散式訓練教科書級知識、架構文件及行業實踐，未引用特定數字產品規格。部分實現細節（如 NCCL AllReduce 具體演算法選擇）及硬體引數均未註明具體歸屬，以避免無據編造。
• 推薦進一步查閱：Li et al., “Scaling Distributed Machine Learning with the Parameter Server”（OSDI 2014）；Sergeev & Del Balso, “Horovod: fast and easy distributed deep learning in TensorFlow”（arXiv:1802.05799）；Shoeybi et al., “Megatron‑LM: Training Multi‑Billion Parameter Language Models Using Model Parallelism”（arXiv:1909.08053）；Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models”（SC 2020）。