小紅書開源 BigMac：把多模態訓練的顯存與速度，從二選一中解放出來

多模態大語言模型（MLLM）正在成為新一代 AI 應用的核心引擎，但訓練這類模型的工程團隊長期被困在一個兩難境地：如果想讓訓練跑得快，顯存往往率先爆掉；如果想省顯存，計算速度又會大幅下滑。小紅書「dots infra」團隊將這個困境稱為「多模態流水訓練的帕累託前沿」——在傳統設計框架下，顯存與速度幾乎是無法同時兼顧的取捨。然而，這個僵局如今迎來了突破口。7 月 22 日，小紅書 dots infra 團隊正式開源了一套名為 BigMac 的流水並行訓練新範式，並將程式碼上傳至 GitHub 的 Dots-Infra 組織下。這套方案專為原生多模態場景設計，目標是讓顯存與速度不再處於零和賽局，而是能同時達到高效水準。 多模態模型並非一塊規整的 Transformer。一個典型的 MLLM 由三大模組拼合而成：負責將圖像、音訊等原始資料轉換為 embedding 的模態編碼器；在 embedding 之上執行推理的 LLM 主幹；以及將 LLM 的輸出映射回圖像、語音等目標模態的生成器。這三者的計算特性差異極大，要把它們放進同一條流水線並行訓練，挑戰自然接踵而至。 業界過去主要有兩條應對路線。第一條側重計算效率，做法是將編碼器與生成器從 LLM 流水線中獨立出來，各自單獨排程。優點在於模態模組的耗時波動不會傳染到 LLM 流水線，進而避免產生空泡（bubble）；但代價是激活值（activation）的顯存會隨著 micro‑batch 數量直線上升，在生產規模下成本極其高昂。第二條路線則偏向顯存效率，把所有模組全都塞進同一條流水線，讓編碼器和生成器分別佔據頭尾階段。這樣一來激活的生命週期縮短，顯存壓力較低；然而只要某個編碼器或生成器因計算負載波動而慢了一點，整條 LLM 流水線就必須停下來等待，尾部空泡隨之產生。當模型規模持續放大，這兩種設計都會觸及各自的瓶頸，無法兼顧吞吐與記憶體。 BigMac 的出發點既樸素又關鍵：排程的主幹依然應該是那條已經高度優化的 LLM 流水線。大規模 LLM 訓練早已依賴 1F1B 或 interleaved 1F1B 等成熟的排程策略，這些排程與生產級的訓練框架深度綁定。BigMac 不打算取代它們，而是把 LLM 排程當作一條底層時間線，再將編碼器與生成器的計算，精準插入到「輸入已就緒且不會打亂 LLM 執行順序」的位置上。團隊將這種設計稱為「準依賴安全的嵌套流水線」。 這套設計帶來了兩項關鍵性質。其一，編碼器與生成器的耗時波動不再沿著 LLM 流水線一路傳導，LLM 仍然按照自己原本該遵循的節奏推進。其二，模態模組的激活顯存從演算法層被壓縮到 O(1) 等級，編碼器不必為所有的 micro‑batch 保留激活直到流水線結束，生成器也不必拖著長長的激活尾巴。換句話說，BigMac 並不是在顯存與空泡之間做傳統意義上的「交換」，而是直接改寫了排程的結構，讓這兩個目標不再彼此牴觸。 從能設計出新的排程到真正能夠把模型訓練起來，中間還橫亙著系統整合、介面定義與效能排查等一系列工程關卡。BigMac 針對這些環節，提供了三項具體工具。第一是全局排程可視化：運行時的 Scheduler 會生成一張覆蓋所有 pipeline rank、micro‑batch 以及模組類型的全局 operator 表，Executor 再將這張表拆解成每個 rank 上的本地序列，分別派送給 Megatron Core 等 LLM 後端、模態 runtime 以及通信後端。從此排程策略變得可見、可檢查，又對後端保持友好。 第二是對演算法工程師幾乎透明的流水線並行介面。工程師只需要描述每個模組「生產什麼、消費什麼」，其餘的 stage 劃分、activation 與 gradient 的交接、跨設備通信，全部由 BigMac 在底層自動料理。這讓一個原本在單卡上驗證過的多模態實驗，能夠更自然地擴展到流水線並行環境。 第三是一套專門用來理解排程結構的 profiler、simulator 與可視化工具鏈。它能將一次訓練迭代拆回 operator 等級，讓開發者看清楚每個 rank 在每個時間點究竟在算什麼、在哪裡空轉、哪一條依賴卡住了後續計算。simulator 則能在真正啟動昂貴的訓練之前，先嘗試不同的 PP 配置與 micro‑batch 組合，預先評估對空泡與吞吐的影響。 這些設計在兩類代表性的負載上得到了驗證。第一類是 MLLM‑Understanding，主幹採用 Qwen3‑30B‑A3B，並搭配一個 1.3B 的 ViT 編碼器。與計算高效的基線 Optimus 相比，BigMac 獲得 1.08 到 1.1 倍的加速；與顯存高效的基線 Megatron‑DistTrain 相比，加速比更高達 1.6 到 1.9 倍。更關鍵的是顯存表現：隨著每張 GPU 的 batch size 增大，BigMac 的峰值顯保持平穩，而 Optimus 因為必須保留編碼器激活，顯存一路飆升，最終在更大的 batch 下直接記憶體溢出。 第二類負載 MLLM‑Generation 更加複雜，因為它多加了一個 20B 的 MMDiT 生成器。在這種情境下，差異被進一步放大：Optimus 在所有測試的 batch size 上全部 OOM；BigMac 則因為能及時執行 generator backward、快速釋放生成器側的激活，順利躲過記憶體暴增的陷阱，相比 Megatron‑DistTrain 仍取得 1.5 到 1.9 倍加速，且顯存依舊穩定。這正是嵌套流水線最能體現價值的場景——系統必須同時伺候編碼器與生成器的依賴，卻又無法承受大量激活駐留或嚴重空泡所帶來的損失。 目前，BigMac 已經作為 dots 多模態模型訓練的核心組件之一，在小紅書的生產環境中實際運作。團隊同步公開了相關論文《BigMac: Breaking the Pareto Frontier of Compute and Memory in Multimodal LLM Training》，已上傳至 arXiv；同時也在 GitHub 上釋出了互動式 PP Profiler 的 trace 示例。對於正在被多模態訓練的顯存與速度兩頭夾擊的研究者與工程師而言，這份帶有生產驗證的開源專案，或許能省下可觀的「重新造輪子」的時間，也為業界突破多模態訓練效率瓶頸提供了一條值得跟進的新路徑。