經過 8 小時的漫長等待，終於完成了學習。

在 DGX Spark（基於 ARM）的環境中對 FLUX 1-dev 12B 模型進行了微調，究竟在 90W 的低功耗下產生的結果如何呢？

今天我將比較分析 250、500、750、1000 步驟生成的 LoRA 適配器，並分享我發現的 「學習的蜜點（Honey Spot）」。

1. 測試環境與條件

Commandbox 광고

  • 基礎模型： FLUX 1-dev (12B)

  • 數據集： 40 張人物實景圖像 (1024x1024)

  • 採樣器： dpmpp_2m, euler

  • 硬體： DGX Spark (120GB 統一記憶體)

  • LoRA 檢查點： 250, 500, 750, 1000 步

2. 步驟別結果比較 (The Battle of Steps)

生成包含訓練角色的實景圖像以測試一致性。

🥉 步驟 250: "你... 誰？" (Underfitting)

  • 結果： 與學習對象的氛圍相似，但若問 "是同一人物嗎？"，會讓人疑惑。面部特徵的微妙細節不足。

  • 速度： 生成速度最快（不到 100 秒），但並非理想質量。

  • 診斷： 過度擬合（Underfitting）。 模型尚未充分吸收數據特徵。

🥈 步驟 500: "哦！就是你！" (Good Fit)

  • 結果： 確實是訓練過的那個人物。終於感覺到 LoRA 正在正常運作。

  • 特異點： 偶爾變換表情時，會通常看起來像其他人，但整體表現出色。

  • 診斷： 進入適合的學習區間。 根據 40 張數據，可以開始進入實用階段。

🥇 步驟 750: "穩定的美學" (Stable)

  • 結果： 與 500 步驟沒有太大區別，但感覺更穩定。在不同姿勢下角色特徵保持良好。

  • 診斷： 當然也是 500 步驟的延續，若硬要說是 '成熟' 的感覺。

🏅 步驟 1000: "完美但... 太完美反而成為問題" (Overfitting Risk)

  • 結果： 一致性 100%。即使進行盲測也難以辨認與原本的不同。

  • 問題： 要求增添 '生氣的表情'、'性感的表情' 等，會導致人物一致性崩潰。

  • 診斷： 過擬合的邊界。 模型對訓練數據（“這個人的這個表情”）記憶過厚，開始喪失應變能力（Generalization）。

3. 技術性謎團與分析

Commandbox 광고

測試過程中，我發現了兩個有趣（或尷尬）的技術性問題。

1) LoRA 文件大小為 5GB？

生成的 4 個 LoRA 文件大小均為 5GB，這個情況非常異常。通常 LoRA 適配器的大小應該在幾十 MB 至幾百 MB 的範圍內才正常。

分析：

起初我懷疑：“會不會是優化器狀態或文本編碼器整體被一起保存了呢？”
然而，若將FLUX 12B規模的rank 256 LoRA應用於所有層，LoRA 本身的參數數量可能變得幾 GB。
也就是說，依據SD1.5得出的「LoRA的大小應該在幾十到幾百MB」的直覺完全不適用，
在大型模型中，LoRA的 rank 與應用範圍直接相關於其容量這一點得到了充分的實證。
下次我將嘗試將 network_dim 降至 64~128，重新獲得容量與性能的平衡。

2) 生成速度降低 (97~130秒)

應用 LoRA 前的生成時間有所增加。

分析：

  1. 結構性原因： LoRA 是在基本權重 ($W$) 上加上學習權重 ($B \times A$) 進行運算，因此運算量增加。

  2. 瓶頸現象： 在學習腳本的設計中，T5XXL 文本編碼器的結構是將計算結果緩存後轉到 CPU，因此，
    推理管道中可能也出現 CPU↔GPU 來回的情況。
    不過，由於這部分尚未完全在代碼層面確認，因此，在下一次實驗中：

  3. 我將嘗試將 TE 強制放置在所有 CUDA 上。

  4. 並改變緩存策略
    比較生成速度和質量有何不同。

4. 結論：尋找 '蜜點（Honey Spot）'

這次的 8 小時艱苦旅程所得到的結論十分明確。 「並非單純地大量學習就一定是好的。」

  1. 最佳區間： 根據 40 張數據集來看，400~600 步驟 之間似乎能兼顧「性價比」與「質量」，而 1000 步驟不僅是浪費時間，甚至可能影響靈活性。

  2. 數據的重要性： 若只學習特定表情，就會成為只能作出該表情的“表情機器人”。在構建數據集時，加入多樣的角度和表情比單純增加步驟數要重要得多。

  3. DGX Spark 的潛力： 雖然花了 8 小時且遇到了設置問題，但以 90W 的功耗成功微調 12B 模型本身就是一個鼓舞人心的事實。

當然，這個蜜點（400~600 步驟區間）
是基於「40 張數據 / FLUX 1-dev / 此 LoRA 設定」的相當具體條件下得出的結果。
只不過根據這次的經驗，

  • 需要根據數據量先探索一個適合的步驟範圍
  • 然後在這範圍內細調和保存，以尋找最佳點。

5. 下一步

下一次實驗的目標已經變得明確。

  • 優化： 是否將所有文本編碼器 (TE) 強制分配至 CUDA，這是否是 FLUX LoRA 腳本的設計（將大型 T5XXL 緩存後再轉至 CPU，以節省 VRAM） 的意圖，深度研究之。

  • LoRA 減肥： 當 network_dim 從 256 減至 128 再到 64 時，進行容量/質量/一致性比較。

  • 精細打擊： 在未達到 1000 步驟的情況下，將 400~600 步驟區間進行細分（每 50 步驟保存） 以找出最佳模型。

  • 在學習數據集中引入標題：

    • 與現今相同比例的 40 張數據，增加標題與否的比較。
    • 從“表情/姿勢多樣性與過擬合”的角度進行分析。

低功耗高效能 AI 研究將繼續進行。下篇文章會介紹成功減脂的 LoRA！