AI 的分散式訓練：為什麼要幾千張 GPU 一起跑
把一個大型訓練任務拆給多張 GPU，並不是只有一種拆法。常見的策略可以分成資料平行、張量平行、流水線平行，以及以混合專家為代表的稀疏化方法。每一種方法解決不同的瓶頸，也帶來不同的通訊成本。理解它們的差異，是理解「為什麼需要幾千張卡」的關鍵。
2.1 資料平行：最直覺，也最常見
資料平行（Data Parallelism）是最直覺的做法：每一張 GPU 都持有一份完整的模型副本，但各自處理不同批次的訓練資料。每張卡獨立完成前向傳播與反向傳播，算出各自的梯度，接著把所有卡的梯度做一次「全歸約」（AllReduce），得到平均梯度，再用來更新模型。因為每張卡的模型完全相同，更新後的權重也仍然相同，訓練邏輯得以保持一致。
資料平行的優點是實作相對簡單，幾乎所有主流框架都支援。它可以把全球批次大小（global batch size）放大到單卡無法達到的規模，進而改善訓練穩定性與吞吐量。然而它有兩個明顯限制：第一，模型必須能放進單張 GPU，這對大型模型通常不成立；第二，梯度同步的通訊量與模型大小成正比，模型越大，通訊越重。
為了解決「模型放不進單卡」的問題，後續出現了 ZeRO 與 FSDP 等技術。它們把優化器狀態、梯度甚至參數切分到不同的資料平行進程上，讓每張卡只保留一部分，需要時再透過通訊收集。這本質上是「資料平行加上狀態切分」，大幅降低了單卡記憶體壓力，也讓資料平行得以延伸到更大的模型。
2.2 張量平行：把一層矩陣拆開來算
張量平行（Tensor Parallelism）解決的是「單層太大」的問題。以 Transformer 為例，一個線性層的權重矩陣可能非常巨大。張量平行會把矩陣乘法沿著特定維度切分，讓多張 GPU 各自計算一部分，再將結果合併。這樣一來，單卡只需要儲存部分權重，記憶體壓力隨之下降。
但張量平行的代價是通訊非常頻繁。因為幾乎每一層的前向與反向傳播都需要同步部分結果，通訊延遲會直接卡在計算路徑上。這種策略通常被限制在節點內部，依靠 NVLink 或 NVSwitch 這種高頻寬、低延遲的互連來完成。一旦跨節點，網路頻寬往往差了一個數量級，張量平行的效率就會急速下降。
實務上，張量平行通常以 2、4、8 卡為一個單位，對應單一節點內的 GPU 數量。這也是為什麼現代 GPU 伺服器多半設計成 8 卡一組，並用高速交換器把它們串成一個高頻寬域。
2.3 流水線平行：把模型切成好幾段
流水線平行（Pipeline Parallelism）換了一個角度：既然一層一層的模型太深，那就把不同層分配給不同 GPU。例如前 20 層放在第一組 GPU，中間 20 層放在第二組，最後 20 層放在第三組。資料像生產線一樣，從第一段流到最後一段。
這種做法的好處是通訊量相對小，因為只有段落與段落之間需要傳遞激活值，而不是每一層都同步。它適合跨節點擴展，因為對頻寬的要求比張量平行低得多。然而流水線平行會產生「氣泡」（bubble）：當第一段在算第一批資料時，後面的段落在等；等到最後一段開始算時，前面的段落又閒置了。為了減少氣泡，系統會把一個大批次切成多個微批次（micro-batch），並採用 1F1B 等調度策略，讓各段盡量保持忙碌。
流水線的效率取決於微批次數量與流水線深度的比例。流水線越深、微批次越少，氣泡佔比就越高。這也是為什麼在設計 3D 平行時，工程師必須仔細調整流水線段數與批次大小，否則新增的 GPU 可能只是在製造更多等待。
2.4 混合專家與稀疏化：用「不全部啟動」換取規模
混合專家模型（Mixture of Experts, MoE）提供了另一條路。它在模型中加入多個「專家」子網路，並透過門控網路決定每個 token 要交給哪些專家處理。由於每個 token 只會啟動少數專家，模型的總參數可以非常大，但單次計算量卻不會等比例增加。這讓模型容量與計算成本之間出現了新的槓桿。
MoE 的分散式訓練通常涉及「專家平行」：不同的專家放在不同的 GPU 上，token 需要透過 all-to-all 通訊被送到對應的專家，計算完再送回來。這種通訊模式對網路拓樸相當敏感，也容易出現負載不均的問題。如果某些專家被太多 token 選中，就會成為熱點，拖慢整體訓練。因此，MoE 系統需要仔細設計負載平衡損失與路由策略。
三、從 2D 到 3D 平行：為什麼幾千張卡要一起跑
單一平行策略都有明顯的上限：資料平行受限於單卡記憶體，張量平行受限於節點內頻寬，流水線平行受限於氣泡與深度。於是，現代大型訓練幾乎都採用多維度組合，也就是所謂的 3D 平行：同時使用資料平行、張量平行與流水線平行，必要時再加上專家平行或序列平行。
3.1 3D 平行的組合邏輯
可以把 3D 平行想像成一個三維座標系。張量平行負責把單層切開，通常放在節點內；流水線平行負責把層與層之間切開，通常跨節點；資料平行則在最外層複製多份模型，處理不同資料。假設一個叢集有 512 張 GPU，你可能會設定張量平行為 8、流水線平行為 8、資料平行為 8，三者相乘正好是 512。
這種組合的設計原則是「把通訊最密集的維度放在頻寬最高的地方」。張量平行每層都要同步，因此必須放在 NVLink 域內；流水線平行只在段落邊界傳遞激活值，可以跨節點；資料平行則在每一步更新時做梯度同步，雖然量大，但可以透過梯度累積與通訊重疊來緩解。這種分層設計，讓數千張 GPU 能夠各司其職，而不是全部擠在同一條通訊瓶頸上。
3.2 實務案例：從數百卡到上萬卡
近年幾個公開的大型訓練案例，可以幫助我們理解規模的演進。微軟與 NVIDIA 合作的 Megatron-Turing NLG 530B 模型，使用了超過兩千張 A100 GPU；Meta 的 OPT-175B 使用了近千張 A100；Llama 3 的 405B 模型則公開說明使用了超過一萬六千張 H100 GPU 進行訓練。這些數字背後，並不是單純「卡越多越好」，而是模型大小、序列長度、批次大小與可用預算共同推導出來的結果。
以 Llama 3 405B 為例，模型權重本身就需要數百 GB 的儲存空間，優化器狀態更是數 TB。訓練時還需要容納長序列帶來的巨量激活值。在這種情況下，單純的資料平行完全不可行，必須結合張量平行、流水線平行與資料平行，並搭配 ZeRO 式的狀態切分，才能把記憶體需求分散到上萬張 GPU 上。同時，訓練還需要處理數百次硬體故障與網路抖動，這些都是書本上不會寫、卻在真實叢集裡天天發生的問題。
3.3 邊際效益：為什麼不是「越多越好」
新增 GPU 並不會等比例帶來速度提升。根據 Amdahl 定律，系統中無法平行的部分會限制整體加速比。在分散式訓練裡，這些「無法平行」的部分包括梯度同步、檢查點寫入、資料載入、故障恢復與排程等待。當 GPU 數量增加到某個程度，通訊與協調成本可能吃掉大部分新增算力，形成邊際效益遞減。
此外，大規模平行會改變訓練動力學。全球批次變大後，學習率、 warmup 步數與優化器設定都需要重新調整；批次太大也可能導致泛化能力下降。因此，實務上並不是無腦地把叢集擴到最大，而是根據模型規模、資料量與時間預算，找到一個「單位成本效益」最高的平行配置。幾千張 GPU 之所以存在，是因為某些模型的訓練需求已經大到只有這個量級才能在合理時間內完成，而不是因為這個數字聽起來比較厲害。
四、通訊才是真正的戰場：AllReduce、NVLink 與 InfiniBand
如果說 GPU 是分散式訓練的肌肉，那麼通訊網路就是神經系統。很多時候，限制訓練速度的不是 GPU 算得不夠快，而是 GPU 在等資料。理解通訊成本，才能真正理解為什麼幾千張 GPU 的系統設計如此複雜。
4.1 梯度同步與 AllReduce 的成本
在資料平行中，每一步訓練結束後，所有 GPU 都必須同步梯度。最常見的作法是環形 AllReduce：每張 GPU 把梯度切成若干塊，沿著環形拓樸傳遞並累加，最後每張卡都得到完整的平均梯度。環形 AllReduce 的總通訊量約為「2 × 梯度大小 × (N-1)」，其中 N 是參與的 GPU 數量。分攤到每張卡，大約是梯度大小的兩倍。
聽起來不多，但實際數字很驚人。假設模型有 1000 億參數，梯度以 16 位元儲存，大小約 200GB。每一步都要傳輸數百 GB，即使使用 400Gb/s 的 InfiniBand，也需要數秒鐘。若模型有數千億參數，通訊時間甚至可能超過計算時間。這就是為什麼大規模訓練必須使用梯度累積：先在本地累積多個微批次的梯度，再進行一次同步，以降低通訊頻率。
4.2 節點內與節點間：差一個數量級的頻寬
GPU 之間的連線可以分成兩個層級。節點內部通常使用 NVLink 與 NVSwitch，提供每秒數百 GB 甚至接近 TB 級的雙向頻寬。以 NVIDIA 的世代演進為例，A100 的 NVLink 頻寬約為 600GB/s，H100 則提升到約 900GB/s。這種頻寬讓張量平行可以在節點內高效運行。
節點之間則依賴 InfiniBand 或高速乙太網路。常見的 NDR InfiniBand 單埠頻寬為 400Gb/s，換算下來約 50GB/s，與 NVLink 相差一個數量級以上。這個差距決定了平行策略的擺放位置：需要頻繁同步的張量平行放在節點內，通訊較稀疏的流水線平行與資料平行則跨節點。這不是隨便的設計選擇，而是被物理頻寬逼出來的架構。
4.3 拓樸設計與 rail-optimized 網路
大型 GPU 叢集的網路拓樸是一門專門學問。常見的設計包括 fat-tree、spine-leaf，以及針對 GPU 流量特性最佳化的 rail-optimized 架構。rail-optimized 的概念是讓同一位置編號的 GPU 連到同一組交換器，形成多條平行的「軌道」，讓 AllReduce 與 all-to-all 流量能夠分散，避免熱點。
拓樸設計的目標是降低「最慢那條路徑」的影響。分散式訓練是同步的，整體速度取決於最慢的參與者。如果網路中有某條鏈路壅塞，所有 GPU 都得等它。因此，現代叢集不只看總頻寬，更看頻寬是否均勻、延遲是否穩定、是否有足夠的備援路徑。這些工程細節，往往比 GPU 本身的規格更能決定訓練效率。
4.4 通訊壓縮與計算重疊
除了硬體，軟體層也有許多降低通訊成本的手段。通訊壓縮可以把梯度量化成較低位元，或使用誤差補償與稀疏化來減少傳輸量；通訊重疊則是把梯度同步與反向傳播的計算排在一起，讓網路傳輸隱藏在計算背後。現代的分散式訓練框架通常會把梯度切成多個桶子（bucket），每算完一個桶子就開始非同步傳輸，進一步提高重疊率。
這些技術的重點不是「完全消除通訊」，而是「讓通訊不要成為關鍵路徑」。當通訊能夠被計算掩蓋，系統才能接近線性擴展。但這需要框架、編譯器與網路共同配合，也是為什麼大規模訓練往往需要高度客製化的軟體堆疊，而不是直接把開源腳本拿來跑。
五、大規模訓練的工程現實：故障、檢查點與彈性
數千張 GPU 一起跑，聽起來很壯觀，但真正跑起來之後，工程團隊面對的往往是無止境的故障處理。硬體會壞、網路會抖、程式會當、儲存會慢。分散式訓練系統的目標，不是假設這些問題不會發生，而是假設它們一定會發生，並且讓訓練能夠繼續。
5.1 千卡叢集的故障率
在一個擁有數千張 GPU 的叢集裡，每天發生數次硬體或軟體異常並不罕見。GPU 過熱、記憶體錯誤、NVLink 降速、網路交換器重啟、儲存節點延遲，任何一個小問題都可能讓同步訓練停擺。Meta 在 Llama 3 的技術報告中就提到，405B 模型在約 54 天的訓練期間發生了數百次意外中斷，其中部分需要人工介入處理。這個數字提醒我們，大規模訓練不只是演算法問題，更是可靠性工程問題。
故障率會隨著規模上升。當你使用一萬張 GPU，而不是一百張，硬體故障的期望次數會等比例增加。這也是為什麼大型實驗室需要專職的叢集維運團隊、自動化的健康檢查，以及能夠快速隔離故障節點的管理系統。
5.2 檢查點：把「重跑」的成本降到最低
檢查點（checkpoint）是分散式訓練的保險。系統會定期把模型權重、優化器狀態、學習率排程與資料載入器的進度寫入儲存系統。一旦訓練中斷，就可以從最近的檢查點恢復，而不必從頭開始。問題是，大型模型的檢查點可能高達數 TB，寫入一次需要可觀的時間與頻寬。
為了解決這個問題，現代系統採用非同步檢查點：先把狀態寫到本地或高速暫存，再由背景程序慢慢寫到長期儲存，讓訓練不必停下來等。有些系統還會採用分層儲存與差量檢查點，只儲存有變化的部分。這些技術的核心目標只有一個：讓檢查點的頻率足夠高，以降低故障時的重工成本，同時不讓檢查點本身成為新的瓶頸。
5.3 彈性訓練與排程
彈性訓練（elastic training）讓叢集在節點增減時仍能繼續訓練。當有 GPU 故障被移除，系統會重新組態平行策略，調整資料平行的世界大小，並從檢查點恢復。這聽起來簡單，實際上涉及通訊群組重建、批次大小調整與學習率重算。PyTorch 的 elastic 工具鏈與各種排程器外掛，就是為了處理這些問題而存在。
在資源管理層面，大型訓練通常需要 gang scheduling：要嘛一次拿到所有需要的 GPU，要嘛全部等待，避免部分資源被占用卻無法開始訓練。Kubernetes、Slurm 與各家自研排程器都在這個領域投入大量工程。對於一個需要數千張 GPU 的任務，排程效率可能直接影響數週的等待時間。
六、成本、能耗與效益：幾千張 GPU 值得嗎？
談到幾千張 GPU，就不能不談錢。大型訓練是一項資本密集的工程，涉及硬體採購、資料中心建設、電力、冷卻與人力。理解成本結構，才能判斷什麼時候該用大叢集，什麼時候該用更聰明的方法。
6.1 訓練成本結構
成本可以粗分為硬體折舊、雲端租用、電力與冷卻、網路與儲存，以及人力。若以雲端租用估算，一張高階 GPU 每小時的價格可能落在數美元區間。數千張 GPU 跑上數十天，帳單很容易達到數百萬甚至上千萬美元。自建叢集雖然單位成本較低，但需要前期資本支出與長期維運能力。
成本項目
主要影響因素
最佳化方向
GPU 硬體
型號、數量、使用年限
提高利用率、混合新舊世代
電力與冷卻
功耗、PUE、電價
液冷、綠電、提高環境溫度容忍度
網路與儲存
InfiniBand 埠數、儲存頻寬
rail-optimized 拓樸、分層儲存
人力與維運
叢集規模、自動化程度
自動化監控、故障預測、標準化流程
值得注意的是，GPU 利用率往往比帳面價格更關鍵。一個利用率只有四成的叢集，實際單位算力成本會比帳面高出許多。因此，大型團隊會投入大量資源在排程、資料管線與故障恢復上，目標是讓昂貴的 GPU 盡可能保持忙碌。
6.2 能源與散熱
數千張 GPU 的功耗可達數兆瓦。以每張卡數百瓦到上千瓦估算，加上 CPU、網路與冷卻，整體資料中心的用電量相當於一座小型城鎮。這讓散熱技術成為關鍵：傳統氣冷在高密度機櫃中逐漸吃力，液冷與直接晶片冷卻開始成為大型 AI 資料中心的選項。
能源成本也推動了選址策略。電力便宜、氣候涼爽、再生能源充足的地點，往往更適合建設大型訓練叢集。部分業者甚至會把訓練任務安排在電力過剩或電價較低的時段，以降低邊際成本。這些看似與 AI 無關的基礎設施決策，實際上深深影響了模型訓練的可行性。
6.3 什麼時候不該用大叢集
並非所有任務都需要幾千張 GPU。對多數企業與研究團隊而言，微調既有模型、使用參數高效微調（如 LoRA）、知識蒸餾、量化與檢索增強，往往能用遠低於預訓練的成本達到可接受的效果。資料品質、領域知識與產品設計，也常常比模型規模更能決定最終價值。
此外，訓練與推論的成本結構不同。一個模型訓練完成後，推論成本會隨著使用者數量持續累積。有時候，選擇較小的模型、更好的檢索策略或更聰明的系統架構，比追求最大參數量更符合商業現實。幾千張 GPU 的訓練是少數頂尖實驗室的遊戲，但分散式訓練的許多技術，最終會下放到較小規模的叢集，讓更多人受益。
七、未來趨勢：從集中式叢集到跨資料中心
當單一資料中心的電力與空間逐漸吃緊，分散式訓練的下一個前沿，是把多個資料中心串起來。這聽起來像是把「幾千張 GPU」擴展到「幾萬張 GPU」，但實際上，跨資料中心的延遲與頻寬限制，會讓問題變得完全不同。
7.1 跨資料中心訓練
同一資料中心內的 GPU 可以透過高速網路緊密耦合，但跨資料中心的距離可能數百甚至數千公里，延遲從毫秒級上升到數十毫秒。對於需要頻繁同步的張量平行與資料平行來說，這是致命的。因此，跨資料中心訓練通常需要更寬鬆的同步策略，例如增加本地計算比例、使用非同步更新，或把平行維度限制在延遲可接受的範圍內。
另一種思路是「模型分割加管線」：把不同層放在不同資料中心，只有段落邊界需要傳輸激活值。這種做法對延遲的容忍度較高，但仍需要解決頻寬、可靠性與資料隱私問題。Google 曾公開討論以多個 TPU 叢集進行大規模訓練的經驗，這類嘗試預示了未來「算力網路」的可能性。
7.2 低精度、異質算力與軟硬體協同
降低通訊與計算成本最直接的方法之一，是使用更低精度。BF16 已成為訓練主流，FP8 與更低位元格式正在快速成熟。低精度不僅減少記憶體占用，也直接降低通訊量。與此同時，異質算力排程讓不同世代的 GPU 甚至不同類型的加速器共同參與訓練，雖然增加了負載平衡與數值穩定性的挑戰，但能提高既有資源的利用率。
軟硬體協同設計也是重要方向。新一代 GPU 擴大 NVLink 域、推出更高速的互連，網路廠商則推進光互連與共同封裝光學。編譯器與通訊庫則針對特定拓樸自動選擇最佳策略。這些進展共同決定未來分散式訓練的性價比曲線。
7.3 演算法與系統的共同演化
最後，分散式訓練不會只是系統工程師的課題。演算法層面的創新，例如稀疏化、混合專家、分散式優化器與聯邦式訓練，都會改變通訊與計算的比例。未來的模型架構可能會更考慮硬體特性，而硬體也會更針對 AI 訓練的瓶頸進行設計。這種共同演化，將決定「幾千張 GPU」是否會成為常態，還是被更高效的架構取代。
八、常見問題 FAQ
Q1：為什麼不直接把模型切小一點，非要用幾千張 GPU？
模型大小與能力之間存在規模定律的關係。對某些任務而言，較小的模型無法達到所需的推理能力與泛化表現。幾千張 GPU 是為了在合理時間內訓練出這種規模的模型，而不是單純追求數字。若能透過資料品質、架構創新或微調達到目標，確實不需要動用大叢集。
Q2：資料平行和模型平行可以同時用嗎？
可以，這正是 3D 平行的核心。資料平行負責擴充吞吐量，張量平行與流水線平行負責降低單卡記憶體需求。實務上會根據模型大小、節點頻寬與批次大小，決定各維度的比例。
Q3：為什麼不直接用非同步訓練，讓每張卡自己跑？
非同步訓練可以降低同步等待，但會引入梯度陳舊（stale gradient）問題，影響收斂穩定性。對大型模型而言，訓練穩定性往往比短暫的速度提升更重要。因此，多數大型訓練仍以同步或半同步為主，並透過梯度累積與通訊重疊來降低同步成本。
Q4：幾千張 GPU 的訓練，一般企業玩得起嗎？
少數頂尖實驗室與大型雲端業者才有能力進行這種規模的預訓練。多數企業更適合使用開源模型微調、檢索增強或較小規模的分散式訓練。雲端租用與算力市場的成熟，也讓中等規模的實驗變得可行，但關鍵仍在於明確的應用場景與成本效益評估。
Q5：分散式訓練最大的瓶頸是 GPU 算力還是網路？
取決於平行策略與模型規模。在小規模或通訊量低的任務中，算力可能是瓶頸；但在數千張 GPU 的同步訓練中，網路頻寬、延遲與可靠性往往是決定整體效率的關鍵。許多大規模訓練的優化工作，實際上是在處理通訊與協調問題。
九、結語：規模背後的工程智慧
回到最初的問題：為什麼要幾千張 GPU 一起跑？答案並不是「因為可以」，而是因為大型模型的記憶體、算力與時間需求，已經超過任何單一加速器所能承擔的範圍。分散式訓練透過資料平行、張量平行、流水線平行與各種稀疏化技術，把一個巨大的訓練任務拆解成數千個可協作的小任務，再用高速網路與精密排程把它們綁在一起。
但真正讓這件事成立的，不只是硬體數量，而是對通訊、故障、成本與演算法的深刻理解。一個千卡叢集如果網路拓樸設計不良、檢查點策略不當、排程效率低落，實際算力可能遠低於帳面規格。相反地，一個設計良好的系統，能讓昂貴的 GPU 保持忙碌，把數十年的計算壓縮成數週的訓練。
對多數讀者而言，未必會親自操作上千張 GPU 的叢集，但理解分散式訓練的原理，有助於判斷 AI 產業的技術走向、成本結構與競爭門檻。當下一次看到「萬卡訓練」的新聞時，你看到的將不再只是一個誇張的數字，而是一整套關於記憶體、頻寬、可靠性與工程權衡的複雜系統。這，正是雅寶社區 · 頂客論壇希望帶給讀者的深度視角。