为了创建服务用的角色模型，我对FLUX 1-dev(12B)模型进行了微调。在低功耗ARM架构的 DGX Spark上训练120亿参数的巨大模型，分享获得的数据和反复试验的经验。
1. 学习环境与设置
-
硬件： DGX Spark (120GB统一内存)
-
模型： FLUX 1-dev (12B参数)
-
数据集： 40张角色图像 (1024px分辨率)
-
学习设置：
-
Batch Size: 1
-
梯度累积: 4
-
Epochs: 100
-
总步骤: 1000
-
2. 预想 vs 现实: 时间管理的失败
在NVIDIA的参考中提到，“训练13张图像，需要约90分钟的时间。”根据这个推算，40张图像的话，预估需要4~5小时，快的话可在2~3小时内完成。
但实际消耗时间约为8小时。
分析： > 图像数量和分辨率： 40张的数据集和1024px的高分辨率设置增加了负担。
- 每步所需时间：处理1个Epoch(10步)平均需要28秒。也就是说，训练1张图像大约需要7秒。
3. OOM（内存不足）和内存管理
我第一步的错误是过于信任120GB的统一内存。
之前在服务器上运行的服务是问题所在。
-
GPT-OSS (20B): 32GB预留分配
-
ComfyUI: 16GB分配
在这种状态下开始训练时，Linux内核强制结束了进程。约66GB的剩余空间对于12B模型的训练（如梯度计算等）显得不够。最终，关闭所有后台服务之后，才得以稳定训练。
- 训练时实际内存占用率： 约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。
-
现象： 分配一个TE到CUDA，一个TE到CPU
-
影响： 由于CPU与GPU之间的数据传输及运算速度差异造成的瓶颈
尽管没有内存不足(OOM)的状况，但仍需分析为何会转移到CPU的设置原因。下次训练时，我计划强制将两个编码器均分配到CUDA，以提升速度。
6. 结论与未来计划
通过这次测试，我意识到100 Epoch / 1000 Step是一个过于苛刻的设置。
-
改进方向： 减少图像数量至30张左右，或者保持数量的情况下，将学习步数调整到300~400 Step将更为高效。
-
硬件： 90W的功率能够进行巨大模型的微调是非常吸引的，但冷却方案（如迷你风扇等）是必不可少的。毕竟以86~87度运行8小时让我感到略有担忧。
下一步： 当前距离训练完成还有约2小时30分钟。培训结束后，将使用生成的LoRA适配器的FLUX进行实际性能测试结果的共享。期待下篇文章。
目前没有评论。