AI 的模型平行：為什麼大模型要切開跑
從單機到分散式的必然
回顧深度學習的發展，早期模型只有幾百萬參數，單卡訓練綽綽有餘，資料平行（把不同批次的資料分給不同 GPU）就足以應付。但當模型本身大到單卡裝不下時，資料平行就失效了——你不可能在每張卡上都放一份完整的模型。於是人們開始思考：能不能把「模型本身」也切開？這就是模型平行的起點。
值得注意的是，模型平行並不是單一技術，而是一整個家族的策略統稱。不同的切法，對應不同的通訊模式、不同的硬體需求、不同的效率瓶頸。接下來我們就來拆解這些路線。
二、模型平行的四大主流路線
在分散式訓練的語境裡，「平行」基本上可以沿著兩個維度展開：切資料與切模型。切模型又細分為切層內（張量）、切層間（流水線）、切專家（MoE）等。實務上，大型訓練幾乎都是多種策略的組合，也就是所謂的「3D 平行」甚至「4D 平行」。以下逐一說明。
資料平行（Data Parallelism）：最直覺的起手式
雖然資料平行嚴格來說不算「模型平行」，但它是理解整個體系不可或缺的基礎。做法很簡單：每張 GPU 都持有一份完整的模型副本，但餵給它們不同的資料批次。每張卡各自計算梯度，然後透過 All-Reduce 通訊把所有卡的梯度平均起來，最後每張卡用相同的平均梯度更新參數，確保模型副本始終保持一致。
資料平行的優點是實作簡單、擴展性好，幾乎所有框架都支援。但缺點也很明顯：每張卡都必須能容納完整模型。當模型大到單卡放不下時，資料平行就走到盡頭。此外，隨著 GPU 數量增加，梯度同步的通訊量也會線性成長，最終成為瓶頸。這也解釋了為什麼後來會出現 ZeRO、FSDP 這類「資料平行 + 參數分片」的改良方案——它們本質上是在資料平行的框架裡，偷偷引入了模型平行的思維。
張量平行（Tensor Parallelism）：把一層拆成好幾塊
張量平行是真正意義上的「把模型切開」。它的核心概念是：把單一層的權重矩陣，沿著某個維度切成多塊，分給不同的 GPU 計算。以一個線性層 Y = XW 為例，你可以把權重矩陣 W 按列切分成 W1、W2，分別放在兩張卡上，得到 Y1 = XW1、Y2 = XW2，再把結果拼接起來。這就是所謂的「列平行」（Column Parallelism）。另一種是「行平行」（Row Parallelism），把 W 按行切分，輸入 X 也跟著切，最後把兩邊的部分和相加。
Transformer 架構裡的注意力層與前饋層，都可以用這套方式拆解。著名的 Megatron-LM 就是張量平行的代表作。它的優勢在於單層的計算被攤到多張卡上，記憶體與算力都獲得緩解；但代價是每層計算完都要進行一次 All-Reduce 或 All-Gather 通訊，對 GPU 之間的頻寬要求極高。因此張量平行通常被限制在「同一台機器內」或「同一個高速互連域（如 NVLink）內」使用，跨機房做張量平行往往得不償失。
流水線平行（Pipeline Parallelism）：按層分工，像工廠輸送帶
如果說張量平行是「把一層切碎」，那流水線平行就是「把不同層丟給不同的卡」。假設模型有 24 層，你把它分成 4 段，每段 6 層，放在 4 張 GPU 上。第 1 張卡算完前 6 層，把中間結果傳給第 2 張卡，依此類推，像工廠的輸送帶一樣。
這個做法聽起來很直觀，卻有一個致命問題：「氣泡」（Pipeline Bubble）。在傳統的流水線中，當第 1 張卡在算時，第 2、3、4 張卡其實是閒置的；等到資料流到最後一張卡，前面幾張又空了。為了解決這個問題，研究人員引入了「微批次」（Micro-batch）的概念：把一個大批次切成許多小批次，讓它們像流水線上的零件一樣連續灌入，使各張卡盡量保持忙碌。GPipe、PipeDream 等系統就是這方面的經典工作。
流水線平行的好處是通訊量相對小（只需在相鄰階段間傳遞激活值），因此適合跨機器擴展；缺點則是排程複雜、氣泡難以完全消除，而且對記憶體的需求會因為要快取多個微批次的激活值而上升。
專家平行（Expert Parallelism）與 MoE 架構
近年最受矚目的路線，當屬混合專家模型（Mixture of Experts, MoE）。在 MoE 架構中，模型的前饋層被替換成多個「專家」網路，每次前向傳播時，由一個路由器（Router）決定每個 token 要交給哪幾個專家處理。於是「專家」天然就可以被分佈到不同的 GPU 上，這就是專家平行。
專家平行的魅力在於：它讓模型總參數量可以極大，但每個 token 實際參與計算的參數卻相對少。換句話說，你可以在不大幅增加計算成本的前提下，把模型容量撐大。Mixtral、DeepSeek-MoE、以及許多雲端大廠的旗艦模型，都採用了這類設計。不過，專家平行也有自己的難題：路由容易負載不均（某些專家被塞爆、某些閒置），而且 token 需要在不同 GPU 之間來回搬運，通訊模式比張量平行更不規則。
3D 平行：不是選一個，而是全部疊起來
實務上，訓練一個千億級模型，幾乎不會只用一種平行策略。常見的做法是「3D 平行」：資料平行 × 張量平行 × 流水線平行。例如，把 512 張 GPU 分成 8 個流水線階段，每個階段內再做 8 路張量平行，剩下的再做 8 路資料平行。這樣的組合可以在記憶體、算力、通訊三者之間取得平衡，也是 Megatron-DeepSpeed 等框架的標準配置。
近年還出現了「4D 平行」的說法，把專家平行也納入維度，甚至再加上序列平行（Sequence Parallelism，專門處理長上下文）。這說明了一件事：模型平行已經不是單一技巧，而是一門「資源配置的藝術」——你要根據模型結構、硬體拓撲、頻寬預算，找出最適合的切法組合。
三、模型平行怎麼運作？拆解切分與通訊機制
理解了有哪些路線之後，我們需要再往下一層，看看這些策略在技術上是如何實現的。模型平行的本質，是一連串「切分—計算—通訊—合併」的循環。其中，通訊原語與切分邏輯是兩個最關鍵的環節。
All-Reduce、All-Gather、Reduce-Scatter：分散式訓練的三大通訊原語
如果你只記住三個名詞，記這三個就夠了。它們是集合通訊（Collective Communication）的核心操作，幾乎所有平行策略都建立在它們之上。
這三者之間的關係可以用一個經典等式描述：All-Reduce = Reduce-Scatter + All-Gather。理解這個等式，你就理解了為什麼通訊優化往往圍繞著「如何減少這兩個步驟的資料量」打轉。像是 Ring All-Reduce、Tree All-Reduce 等演算法，都是在頻寬與延遲之間做取捨。
張量平行中的列切分與行切分
讓我們更具體地看張量平行如何運作。考慮一個 Transformer 的前饋層，它有兩個線性變換：Y = GeLU(XA)、Z = YB。在 Megatron 的設計中，第一層採用列切分：把 A 按列切成 A1、A2，兩張卡各自計算 Y1 = GeLU(XA1)、Y2 = GeLU(XA2)，這個過程完全不需要通訊。接著第二層採用行切分：把 B 按行切成 B1、B2，兩張卡各自計算 Z1 = Y1B1、Z2 = Y2B2，最後再透過一次 All-Reduce 把 Z1 + Z2 合併。
這種「一列一行」的搭配非常巧妙：它讓整個前饋層只需要兩次通訊（前向一次 All-Reduce、反向一次 All-Reduce），而不是每層都通訊，大幅降低了開銷。這也是為什麼 Megatron 的張量平行設計被廣泛採用。同樣的技巧也應用在注意力層的多頭切分上——每個注意力頭天然就可以分給不同的 GPU。
流水線的氣泡問題與微批次排程
流水線平行的核心挑戰是「如何讓所有階段同時忙碌」。最簡單的做法是 GPipe 的「全前向再全反向」：把所有微批次的前向都跑完，再依序做反向。但這樣會導致大量激活值被快取，記憶體壓力大，而且氣泡依然存在。
更先進的做法是「一前一後」（1F1B）排程，讓每個階段在前向與反向之間交錯，減少記憶體佔用。PipeDream 甚至提出了「非同步流水線」，允許不同階段以不同速度前進，進一步壓縮氣泡。這些排程策略的設計，本質上是在記憶體、氣泡比例、通訊重疊三者之間做權衡。沒有萬靈丹，只有最適合當下硬體拓撲的解法。
四、實務上的挑戰與調優
紙上談兵容易，真正把模型平行跑起來，才會發現處處是坑。以下幾個挑戰，是每一位做過大模型訓練的工程師都曾經頭痛的問題。
通訊開銷與頻寬瓶頸
模型平行最大的敵人，就是通訊。每切一刀，就多一次資料交換。而 GPU 之間的頻寬，遠遠低於 GPU 內部的頻寬。以 H100 為例，HBM 頻寬高達每秒數 TB，但跨機器的 InfiniBand 或乙太網路，往往只有每秒數百 GB，延遲也高出一個數量級。這意味著：切得越細，通訊越頻繁，效率可能越差。
因此，實務上的黃金法則是「把通訊密集的平行放在同一台機器內，把通訊稀疏的放在跨機器」。例如張量平行通常限制在 NVLink 域內，流水線平行與資料平行則可以跨機器。此外，通訊與計算的重疊（Overlap）也是關鍵：好的框架會讓 All-Reduce 在反向傳播計算梯度的同時偷偷進行，把通訊時間藏起來。
記憶體重算與激活重算
即使做了模型平行，記憶體往往還是不夠。這時就得靠「激活重算」（Activation Recomputation，或稱 Gradient Checkpointing）：前向傳播時不保存所有中間激活值，等到反向傳播需要時再重新計算一次。這用額外的計算換取記憶體空間，是大模型訓練的標配技巧。
但重算也有代價：它會增加約 30% 的計算量，而且與流水線排程交互作用時，可能讓氣泡變大。因此，重算策略需要與平行策略一起設計，而不是事後補救。
容錯與斷點續訓
大規模訓練動輒運行數週甚至數月，期間 GPU 故障、網路抖動、節點重啟幾乎是常態。在數千張卡的規模下，平均每天可能都有硬體出問題。因此，高效的 Checkpoint 機制與快速恢復能力至關重要。
問題是，模型平行讓 Checkpoint 變得複雜：不同平行維度下的參數分片方式不同，要還原成完整模型或重新分片，都需要專門的轉換邏輯。近年來，分散式 Checkpoint（如 PyTorch 的 Distributed Checkpoint）開始支援「不改變平行配置也能讀寫」，大幅簡化了這件事。但無論如何，容錯設計仍然是模型平行系統中最容易被低估的一環。
五、未來趨勢與結論
走過記憶體牆、拆解了四大路線、看過通訊機制與實務痛點，我們最後來談談模型平行的未來。這個領域正在快速演進，幾個明顯的趨勢值得關注。
自動平行與編譯器驅動的資源配置
過去，選擇哪種平行策略、怎麼切、切幾刀，往往靠工程師的經驗與反覆試錯。但隨著模型結構越來越複雜、硬體拓撲越來越異質，手工調優已不切實際。因此，自動平行（Auto-Parallelism）成為熱門方向。像是 Alpa、Megatron-LM 的自動配置、以及各種基於編譯器的方案，都試圖把「平行策略搜尋」變成一個優化問題，讓系統自動找出最佳的切分與排程。
這背後的理念是：未來的開發者不應該需要理解 All-Reduce 的細節，就能訓練大模型。就像今天的開發者不需要手寫組合語言一樣。
MoE 與稀疏化：用「不計算」換取規模
專家平行的興起，反映了一個更根本的趨勢：與其讓每個 token 都經過所有參數，不如只啟動其中一小部分。這種稀疏化思維，讓模型容量可以持續膨脹，而計算成本卻不成比例地增加。未來我們很可能會看到更多「極度稀疏」的架構，搭配更智慧的路由機制與更高效的專家平行通訊。
長上下文與序列平行
另一個明顯的趨勢是長上下文。當序列長度從 4K 推進到 128K、甚至百萬 token 時，激活值的記憶體需求會急遽上升。傳統的資料平行與張量平行不足以應付，於是「序列平行」（Sequence Parallelism）應運而生——把序列維度也切開，分給不同的 GPU 處理。這與環形注意力（Ring Attention）等技術結合，成為新一代長上下文模型的關鍵基礎。
異質運算與跨資料中心
最後，硬體的多元化也在改變模型平行的樣貌。未來的訓練叢集可能混合不同型號的 GPU、甚至包含 CPU 與專用加速器。如何在異質環境中做平行，如何處理跨資料中心的低頻寬連結，都是開放中的研究題目。某種程度上，模型平行正在從「單一叢集內的技術」，走向「分散式系統的工程」。
結語：切開跑，是為了跑得更遠
回到最初的問題：為什麼大模型要切開跑？答案其實很簡單——因為單一顆晶片已經裝不下人類對智慧的渴望。模型平行不是妥協，而是必然。它讓我們能把數千顆晶片黏成一台超級電腦，把記憶體、算力、頻寬這三種稀缺資源重新分配，最終訓練出單卡永遠不可能觸及的模型。
當然，切開跑從來不是免費的。每一次切分，都伴隨著通訊成本、排程複雜度與除錯難度。真正的功力，在於知道該在哪裡切、切多深、用什麼通訊模式、如何與硬體拓撲對齊。這是一門融合了系統、網路、數值計算與機器學習的交叉學科，也是當前 AI 基礎設施競爭最激烈的戰場之一。
下次當你看到某個模型發布，宣稱「使用了數萬張 GPU 訓練」時，不妨想想背後那套精密的平行策略。那些看不見的 All-Reduce、那些被藏起來的氣泡、那些深夜裡為了 0.5% 效率提升而調整的排程參數——它們才是大模型時代真正的無名英雄。而理解模型平行，也就等於理解了這個時代的算力究竟是如何被組織起來的。
如果你對這個主題有興趣，建議可以從 Megatron-LM 的論文與開源程式碼入手，搭配 PyTorch 的分散式訓練文件，親手跑一個小規模的張量平行範例。相信我，當你第一次看到兩張 GPU 協同算出一個線性層的結果時，那種「原來如此」的頓悟，會比讀十篇文章都來得深刻。