DGX SparkでのFLUX 1-dev 12B LoRAファインチューニング実践記

最近サービスで使用するキャラクターモデル生成のために、FLUX 1-dev(12B)モデルをファインチューニングしました。120億パラメータの巨大モデルを低消費電力ARMベースのDGX Sparkでトレーニングし、得られたデータと試行錯誤を共有します。

1. 学習環境と設定

ハードウェア: DGX Spark (120GB Unified Memory)
モデル: FLUX 1-dev (12B Parameters)
データセット: キャラクター画像40枚 (1024px解像度)
学習設定:
- Batch Size: 1
- Gradient Accumulation: 4
- Epochs: 100
- Total Steps: 1000

NVIDIAのリファレンスでは「13枚の画像、1000ステップのトレーニングに約90分」と明記されていました。これをもとに40枚の画像ならば余裕を持って4～5時間、早ければ2～3時間で終わると予想しました。

しかし実際の所要時間は約8時間でした。

分析: > 画像数と解像度: 40枚というデータセットと1024pxの高解像度設定が負荷を増大させました。

ステップあたりの時間: 1エポック(10ステップ)処理に平均28秒がかかりました。つまり、画像1枚の学習に約7秒かかっていたことになります。

120GBの統合メモリを信じて油断したことが最初の失敗でした。

以前にサーバーにアップロードしていたサービスが問題でした。

この状態で学習を始めると、Linuxカーネルがプロセスを強制終了(Kill)しました。約66GBの余裕スペースでは12Bモデルの学習(勾配計算など)を耐えるには不足でした。結局、すべてのバックグラウンドサービスを停止させて初めて安定した学習が可能になりました。

LoRAトレーニング中のGPU状態

x86ベースの高性能GPUであれば電力消費がかなりかかった作業かもしれませんが、DGX Sparkの効率は驚くべきものでした。

12Bモデルをフルロードで学習させても90W程度の電力しか消費しないことは、エッジやオンデバイスAIサーバーとしての可能性を示す励みになる数字です。

学習時間が予想より長くなった決定的な原因の一つを発見しました。

FLUXモデルはCLIP-LとT5-XXLの2つのテキストエンコーダーを使用しており、モニタリングの結果そのうちの1つがCUDAではなくCPUに割り当てられて動作していました。

メモリ不足(OOM)の状況ではなかったにもかかわらず、なぜCPUにオフロードされたのか設定上の原因分析が必要です。次回の学習では2つのエンコーダーをすべてCUDAに強制的に割り当てて速度改善を試みる予定です。

今回のテストを通じて100エポック / 1000ステップは過剰な設定であることを認識しました。

改善方向: 画像数を30枚程度に減らすか、枚数を維持しても300～400ステップ程度に学習量を調整するのが効率的であると思われます。
ハードウェア: 90Wの電力で巨大モデルのファインチューニングが可能である点は非常に魅力的ですが、クーリングソリューション(ミニ扇風機など)は必須です。やはり86～87度で8時間動かすのは少し怖かったです。

Next Step: 現在学習完了まで約2時間30分が残っています。学習が終わり次第生成されたLoRAアダプターをFLUXに装着して実際の性能テスト結果を共有します。次の投稿をお楽しみに。