為了生成可用於服務的角色模型，我們對FLUX 1-dev（12B）模型進行了微調。在低功耗的ARM基礎上，於DGX Spark上訓練120億參數的巨型模型，並分享所獲得的數據和反覆試驗的經驗。
1. 學習環境及設置
-
硬體： DGX Spark (120GB統一內存)
-
模型： FLUX 1-dev (12B參數)
-
數據集： 40張角色圖片 (1024px解析度)
-
學習設置：
-
Batch Size: 1
-
Gradient Accumulation: 4
-
Epochs: 100
-
Total Steps: 1000
-
2. 預想vs現實：時間管理的失敗
NVIDIA的參考中提到：“用13張圖像進行1000步訓練約需90分鐘。”因此，我預測40張圖像所需的時間大約在4到5小時之間，最快也應該在2到3小時內完成。
但實際所需時間約為8小時。
分析： > 圖像數量和解析度： 40張的數據集及1024px的高解析度設置增加了負擔。
- 每步所需時間：處理1個Epoch（10步）平均需要28秒。因此，對於每張圖像的學習約需7秒。
3. OOM（內存不足）及內存管理
我對120GB的統一內存抱有信心的同時，這也是我第一次犯下的錯誤。
之前在伺服器上運行的服務造成了問題。
-
GPT-OSS (20B)： 預留32GB
-
ComfyUI： 分配16GB
在這種狀況下開始訓練，Linux內核強制終止了進程。約66GB的可用空間對於12B模型的訓練（如Gradient計算等）來說不夠用。最終，關閉所有後台服務後才得以進行穩定的訓練。
- 訓練期間實際內存佔用率： 約71.4GB（持續維持）
4. ARM架構的驚人電力效率
如果是基於x86的高性能GPU，將是相當耗電的工作，但DGX Spark的效率令人驚訝。
-
峰值電力： 89~90W
-
溫度： 84~86°C（使用迷你風扇後穩定在81~83°C）
在全載運行12B模型的同時僅消耗90W的電力，顯示出作為邊緣（Edge）或在設備上的AI伺服器的潛力，是一個令人欣慰的數字。
5. 發現瓶頸：文本編碼器（TE）的CPU偏移
我發現了學習時間比預期更長的關鍵原因之一。
FLUX模型使用了CLIP-L和T5-XXL兩個文本編碼器，但監控結果顯示，這兩者中有一個被分配到了CPU而非CUDA上運行。
-
現象： CUDA上分配了一個TE，CPU上也分配了一個TE
-
影響： CPU與GPU間的數據傳輸及運算速度差異導致了瓶頸出現
儘管並沒有內存不足（OOM）的情況，卻為何被卸載到CPU上進行的設定原因需要進行分析。在下次的訓練中，計劃將兩個編碼器都強制分配到CUDA，以期改善速度。
6. 結論及未來計畫
這次測試讓我意識到100 Epoch / 1000 Step的設定過於苛刻。
-
改善方向：將圖像數量減少到30張左右，或即使保持數量，也建議調整訓練量至300~400 Step。
-
硬體：用90W的電力能進行巨型模型的微調非常吸引人，但冷卻方案（如迷你風扇等）是必須的。畢竟以86~87度運行8小時讓人有點緊張。
下一步：目前距離學習完成還剩約2小時30分鐘。學習結束後會將生成的LoRA適配器安裝到FLUX上，以分享實際性能測試結果。敬請期待下一篇文章。
目前沒有評論。