GitHub Repo
Transformers 社群回報 FSDP2 載入記憶體缺陷，多 GPU 啟動可能重複建立完整模型
Transformers 5.12.0 的社群案例指出，啟用節省 CPU 記憶體的載入選項後，其他訓練程序仍可能配置完整模型，導致主機記憶體耗盡。官方文件確認該選項應避免各程序重複載入，但問題根因與修復狀態仍待上游確認。
10 月 4 日，Hugging Face Transformers 社群出現一項 FSDP2 載入問題回報：使用者即使啟用 cpu_ram_efficient_loading=True，非 rank 0 程序仍可能在 CPU 上建立完整模型。案例使用 Transformers 5.12.0、Accelerate 1.15.0 與 PyTorch 2.10，在單一節點啟動 16 個程序，載入約 270 億參數的 BF16 稠密模型，並回報主機記憶體耗盡。問題回報
回報者將問題定位到 from_pretrained() 階段：處理 meta 裝置上的參數時，相關分支對非主程序呼叫 torch.zeros_like(..., device="cpu")，建立實際 CPU 張量。meta 張量原本只保留形狀等資訊，不配置參數儲存空間；若提早實體化，每個程序便可能占用約 54 GB。依案例數字估算，16 份模型約需 864 GB，尚未計入其他載入開銷。這是回報配置的容量估算，不能當作所有部署的固定門檻。程式路徑與重現步驟
這項行為與選項的設計目的存在落差。Accelerate 官方文件說明，啟用 CPU RAM 高效率載入時，應只有第一個程序載入預訓練 checkpoint，其餘程序保留空權重，再透過同步取得參數；文件也要求在 from_pretrained() 前初始化分散式程序群組。FSDP 的參數分片可以降低訓練時的記憶體需求，但若完整副本在分片前就已建立，啟動階段仍可能成為瓶頸。官方 FSDP 文件
對工程團隊而言，這起回報提示容量驗證必須涵蓋模型載入期。可先以較小模型觀察各 rank 在 from_pretrained() 前後的常駐記憶體，再核對程序群組初始化順序與套件版本，確認成本是否隨程序數增加。目前公開證據主要來自單一使用者回報，尚不足以確定其他版本、量化模型或多節點部署的影響。後續應追蹤上游是否確認該分支的 FSDP2 行為，以及修補後能否保留空權重直到同步完成。