多模態模型的下一場競賽：不只堆 GPU，更要重新安排等待時間

生成式 AI 的算力競賽，常被簡化成「誰擁有更多 GPU」。但在真正的大規模訓練裡，昂貴硬體不一定時時都在工作：只要模型元件的執行時間不一致，流水線便可能出現空檔；為了提高吞吐而提前計算，又可能讓大量中間結果長時間占用 GPU 記憶體。

小紅書 dots infra 團隊近期開源的 BigMac，正是從這個排程問題下手。這套系統針對同時處理文字、影像或音訊的多模態大語言模型，嘗試在不改變大型語言模型主幹執行順序的前提下，把編碼器與生成器的工作嵌入既有流水線。

多模態訓練為何更難排

典型的多模態模型不只有一個大型語言模型。編碼器先把影像或音訊轉成模型可處理的表示，語言模型負責推理，生成器再將輸出轉回影像、音訊等目標形式。這些元件的規模、運算型態與適合的平行化方式不同；不同批次包含的影像或音訊資訊量也不一致，因此各階段很難保持相同速度。

現有做法往往必須在兩種成本之間取捨。把編碼器、語言模型與生成器分開執行，可以減少彼此干擾，卻要保存更多供後續反向傳播使用的 activation；把它們直接串進同一條流水線，雖能限制記憶體占用，卻可能因較慢的元件而讓其他 GPU 等待。

BigMac 論文提出「依賴安全的嵌套流水線」：以原有的語言模型排程為主幹，在資料依賴允許的最早時點插入編碼器與生成器工作，並及早執行反向運算、釋放 activation。系統也把全域排程與各節點的執行器拆開，讓工程師能先檢查、模擬與視覺化整條訓練時間線，再交由底層框架執行。

數字亮眼，但仍是特定環境下的結果

研究團隊在 16 台伺服器、共 128 張 Nvidia H800 GPU 的測試環境中，比較多種多模態訓練工作負載。論文報告顯示，BigMac 相較所選基準系統取得約 1.08 倍至 1.9 倍的訓練加速，並在每張 GPU 的批次大小增加時維持較穩定的峰值記憶體用量。

這些數據不能直接推論所有模型都能獲得同等提升。加速幅度取決於模型元件、資料分布、批次設定、網路與既有訓練框架；論文中的結果也主要證明研究團隊選定配置下的系統效果，而不是跨平台的通用保證。開源的價值，在於其他團隊可以檢查實作並用自己的工作負載重現測試。

真正稀缺的資源，是有效運算時間

BigMac 帶來的啟示不只是一項訓練框架更新。當多模態模型把語言、視覺與生成元件接在一起，基礎設施的核心問題會從「如何啟動更多 GPU」，逐漸轉向「如何讓不同元件少等待、少保存不必要的中間狀態」。

對模型團隊而言，這也改變了成本優化的順序。擴充叢集以前，先看清楚每個 microbatch 在各節點間如何流動，可能比單純加購硬體更有價值。未來的算力優勢，未必只屬於擁有最多晶片的公司，也可能屬於最能把每一段等待時間重新排好的人。