🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

NVIDIA NeMo Automodel과 Hugging Face Diffusers의 통합은 체크포인트 변환 없이 이미지·비디오 확산 모델을 단일 GPU부터 다중 노드 환경까지 미세 조정하고 다시 Diffusers 생태계에서 활용할 수 있게 한다.

📌 핵심 요약

• NeMo Automodel은 Diffusers 모델 클래스와 파이프라인을 그대로 사용하는 오픈소스 PyTorch DTensor 기반 학습 라이브러리로, 학습 전후의 별도 체크포인트 변환을 요구하지 않는다.
• 현재 flow matching 모델을 대상으로 FSDP2, 텐서·전문가·컨텍스트·파이프라인 병렬화, 잠재 표현 캐싱, 다중 해상도 버킷 데이터 로딩을 지원한다.
• 제공되는 미세 조정 레시피는 Wan 2.1·2.2, FLUX.1-dev·FLUX.2-dev, HunyuanVideo 1.5, Qwen-Image를 포함하며 대부분 전체 미세 조정과 LoRA를 지원한다.
• 78장의 Rider–Waite 타로 데이터로 FLUX.1-dev를 200스텝 전체 미세 조정한 예제에서는 trtcrd 토큰을 포함할 때 타로 카드 양식이 나타나고, 토큰을 제외하면 사진풍 결과가 유지됐다.
• 8대의 H100 80GB GPU에서 측정한 성능표는 이미지·비디오 모델별 스텝 시간, 처리량, GPU당 처리량과 최대 할당 메모리를 전체 미세 조정 및 LoRA 구성별로 제시한다.

🧩 주요 포인트

1. Diffusers 형식의 가중치를 그대로 학습하고 다시 로드할 수 있어 체크포인트 변환 부담을 없애고 기존 추론·양자화·컴파일·어댑터 도구와의 연결을 유지한다.
2. 모델 코드를 규모별로 다시 작성하는 대신 YAML 설정으로 병렬화 방식을 선택하므로 동일한 학습 구조를 단일 GPU부터 대규모 분산 환경까지 확장할 수 있다.
3. 타로 스타일 학습 사례와 H100 벤치마크를 함께 제시해 조건 토큰에 연결된 학습 효과뿐 아니라 전체 미세 조정과 LoRA의 처리량·메모리 차이도 구체적인 수치로 확인하게 한다.

🧠 상세 정리

1. 협업의 배경과 목표

이 글은 2026년 7월 17일 공개된 NVIDIA와 Hugging Face의 공동 게시물로, Diffusers 형식의 이미지·비디오 모델을 대규모로 학습하는 통합 방식을 소개한다. FLUX.1-dev, Wan 2.1, HunyuanVideo 같은 공개 확산 모델이 등장하면서 Diffusers는 추론, 적응, 파이프라인 구성을 위한 일관된 인터페이스로 자리 잡았다. 반면 학습과 미세 조정에는 메모리 효율적인 샤딩, 잠재 표현 캐싱, 다중 해상도 버킷, 단일 GPU부터 수백 GPU까지 확장 가능한 설정 체계가 추가로 필요했다. 두 조직의 협업은 Hugging Face Hub에 있는 Diffusers 형식 모델을 별도 체크포인트 변환이나 모델 재작성 없이 분산 학습할 수 있도록 하는 데 초점을 둔다. 해당 통합은 Diffusers 학습 안내서에 문서화됐으며 Apache 2.0 라이선스의 오픈소스로 제공된다.

2. NeMo Automodel의 설계와 현재 범위

NeMo Automodel은 NVIDIA NeMo 프레임워크에 속한 오픈소스 PyTorch DTensor 기반 학습 라이브러리이며, Hugging Face 네이티브 방식과 규모 독립적인 단일 프로그램이라는 두 원칙을 중심으로 설계됐다. 사용자는 pretrained_model_name_or_path에 Hub의 Diffusers 모델 식별자를 지정해 학습을 시작할 수 있고, 로딩에는 WanTransformer3DModel 같은 Diffusers 모델 클래스를, 생성에는 WanPipeline 같은 Diffusers 파이프라인을 사용한다. 학습된 체크포인트는 Diffusers 생태계로 다시 정상적으로 돌아가므로 별도의 전용 학습 형식에 종속되지 않는다. FSDP2, 텐서 병렬, 전문가 병렬, 컨텍스트 병렬, 파이프라인 병렬은 모델 코드를 다시 쓰는 대신 설정으로 선택할 수 있다. 현재 지원 범위는 flow matching 모델로 제한되며, 학습 목표에도 flow matching을 사용하고 사전 인코딩한 VAE 잠재 표현과 다중 해상도 버킷 데이터 로딩으로 처리량을 높인다.

3. 지원되는 이미지·비디오 모델

현재 examples/diffusion/finetune에 준비된 레시피는 텍스트-비디오와 텍스트-이미지 모델을 함께 다룬다. Wan 2.1 T2V는 1.3B와 14B 모델을 지원하고 LoRA 레시피도 제공하며, 1.3B 모델은 40GB A100 한 대에 들어가는 것으로 명시돼 있다. Wan 2.2 T2V A14B는 전체 27B 규모의 혼합 전문가 모델로 스텝당 14B가 활성화되지만, 목록상 LoRA 레시피는 제공되지 않는다. 이미지 모델로는 12B FLUX.1-dev, 32B FLUX.2-dev, 20B MMDiT 구조의 Qwen-Image가 포함되며 모두 LoRA 레시피를 제공한다. 비디오 모델인 13B HunyuanVideo 1.5도 전체 미세 조정과 LoRA 대상에 포함돼, 지원 범위가 소형 비디오 모델부터 수십억 매개변수 규모의 이미지·비디오 모델까지 이어진다.

4. Diffusers 통합이 제공하는 기능

가장 직접적인 이점은 Hub의 사전 학습 가중치를 변환 없이 불러오고, 학습 결과를 DiffusionPipeline에서 바로 추론하거나 Hub에 공유할 수 있다는 점이다. 중간에 별도의 학습 전용 형식이 생기지 않으므로 양자화, 컴파일, LoRA 어댑터, 사용자 정의 샘플러 같은 후속 도구도 계속 활용할 수 있다. 새로운 확산 모델이 Diffusers에 추가되면 NeMo Automodel에서는 데이터 전처리 처리기와 모델 어댑터를 추가하고, FSDP2·버킷 데이터 로딩·체크포인트·생성 등 기존 레시피 체계는 그대로 재사용한다. 전체 미세 조정과 LoRA 방식의 매개변수 효율적 미세 조정을 동일한 레시피 구조에서 선택할 수 있어, 대규모 클러스터의 전체 학습과 단일 노드 중심의 효율적 학습을 모두 다룬다. 분산 기능에는 FSDP2와 텐서·컨텍스트·파이프라인 병렬화, 다중 노드 오케스트레이션, 다중 해상도 버킷이 포함되며 오케스트레이션은 현재 SLURM을 지원하고 Kubernetes 지원이 예정돼 있다.

5. 설치와 데이터 사전 인코딩

권장 설치 방식은 PyTorch, TransformerEngine 및 CUDA로 컴파일된 의존성을 포함한 nvcr.io/nvidia/nemo-automodel:26.06 컨테이너이며, pip 패키지나 GitHub 소스에서 직접 설치하는 방법도 제시된다. 예제는 공개된 78장의 Rider–Waite 타로 카드 데이터로 FLUX.1-dev의 전체 트랜스포머를 미세 조정하고, 새 설정 파일을 만들지 않은 채 기존 YAML과 명령행 재정의를 사용한다. 학습 때마다 원본 이미지를 인코딩하지 않도록 먼저 VAE 잠재 표현과 텍스트 임베딩을 캐시하며, Hugging Face에서 데이터를 스트리밍하고 전처리를 보이는 모든 GPU에 분배한다. 캡션에는 이미 trtcrd 트리거 토큰이 포함돼 있고, 지정된 픽셀 예산과 세로형 종횡비에 따라 샘플은 시연에 사용된 384×640 버킷으로 배정된다. 전처리 결과는 해상도별 디렉터리의 .pt 캐시 파일, 샤딩된 메타데이터, 통합 metadata.json과 내려받은 데이터셋 이미지 구조로 저장된다.

6. FLUX 학습·생성 절차와 결과

학습에는 기존 flux_t2i_flow.yaml을 그대로 사용하며, 이 설정은 FLUX.1-dev, 전체 트랜스포머 미세 조정, FLUX용 flow matching 어댑터, 유효 배치 크기 32와 8방향 FSDP2를 선택한다. 실행 시 캐시 경로, 384×640 기본 해상도, 20스텝 워밍업, 최대 200스텝, 50스텝 간격 체크포인트 저장, 통합 체크포인트 저장 여부와 시드를 명령행에서 덮어쓴다. 체크포인트는 50·100·150·200번째 스텝에 생성되며, 최종 파일 이름 epoch_66_step_199는 0부터 시작하는 표기라서 실제로는 200번째 옵티마이저 스텝 완료 상태를 뜻한다. 생성 단계에서는 기존 FLUX 생성 YAML에 이 체크포인트를 지정하고 640×384 출력과 동일한 시드를 사용해 trtcrd가 포함된 프롬프트와 제외된 대조 프롬프트를 비교한다. 200스텝 결과에서 트리거가 있는 이미지는 요청한 우주비행사 장면을 유지하면서 크림·빨강·검정의 빈티지 색상, 굵은 잉크 윤곽, 평면 색면, 낡은 종이 느낌과 우화적 카드 구도를 보였고, 트리거가 없는 결과는 사진풍을 유지해 학습 효과가 주로 해당 토큰과 연결됐음을 보여줬다.

7. 텍스트-이미지 성능 측정

이미지 성능은 NVLink로 완전히 연결된 H100 80GB GPU 8대의 단일 노드에서 512×512 해상도로 측정됐고, 수치는 정상 상태의 10스텝 구간 세 개에서 구한 평균과 표본 표준편차다. FLUX.1-dev 전체 미세 조정은 FSDP2와 전역·로컬 배치 32·4에서 스텝당 0.902초, 초당 35.51장, GPU당 초당 4.44장, GPU당 최대 63.88GiB를 기록했다. 같은 모델의 LoRA r64는 DDP와 배치 48·6에서 0.894초, 초당 53.73장, GPU당 초당 6.72장, 최대 67.43GiB였다. Qwen-Image 전체 미세 조정은 FSDP2와 배치 40·5에서 0.974초, 초당 41.21장, GPU당 초당 5.15장, 최대 53.55GiB였고, LoRA r64는 DDP와 배치 24·3에서 0.515초, 초당 46.63장, GPU당 초당 5.83장, 최대 66.33GiB를 기록했다. 따라서 이 표의 이미지 구성에서는 두 모델 모두 LoRA가 더 높은 처리량을 보였지만, 측정된 최대 할당 메모리는 각 전체 미세 조정 구성보다 높았으며 배치 크기와 병렬화 방식도 서로 달랐다.

8. 텍스트-비디오 성능과 측정 조건

비디오 벤치마크는 512×512 크기의 49프레임 클립을 샘플 단위로 사용했으며, Wan 2.1 1.3B 전체 미세 조정은 활성화 체크포인팅 없이 0.942초, 초당 8.50클립, GPU당 초당 1.06클립, 최대 6.09GiB를 기록했다. Wan 2.1 14B 전체 미세 조정은 활성화 체크포인팅을 켠 상태에서 3.798초와 초당 2.107클립, 최대 33.35GiB였고, LoRA r64는 전역 배치를 16으로 늘려 7.585초와 초당 2.110클립, 최대 24.07GiB를 기록했다. Wan 2.2 A14B의 고노이즈 전체 미세 조정 결과는 4.628초, 초당 1.730클립, 최대 23.57GiB였다. HunyuanVideo 1.5 전체 미세 조정은 5.926초, 초당 1.350클립, 최대 15.90GiB였으며, LoRA r64는 5.575초, 초당 1.433클립, 최대 10.58GiB였다. 측정에는 캐시된 이미지 샘플 256개와 비디오 샘플 112개가 사용됐고, 완전한 배치를 유지하기 위해 drop_last가 활성화됐으며 체크포인트 쓰기는 비활성화됐다. 보고된 스텝 시간은 데이터 로딩, 순전파, 역전파, 그래디언트 클리핑과 옵티마이저 처리를 포함하므로 모델 계산만을 분리한 수치가 아니라 전체 학습 스텝 기준의 결과다.

🧾 핵심 주장 / 시사점

• 통합의 핵심은 새로운 독자 형식을 만드는 것이 아니라 Diffusers 모델·파이프라인·체크포인트의 왕복 호환성을 유지하는 데 있으며, 그 결과 기존 후속 도구를 학습 뒤에도 계속 사용할 수 있다.
• VAE 잠재 표현과 텍스트 임베딩을 사전에 캐시하고 해상도별로 버킷화하는 구조는 매 학습 스텝의 반복 인코딩을 피하면서 다양한 종횡비의 데이터를 처리하도록 설계됐다.
• 동일한 장면과 시드를 유지한 채 trtcrd 토큰만 바꾼 대조 결과는 미세 조정된 타로 표현이 기본 모델 전체를 일괄적으로 대체한 것이 아니라 특정 트리거와 상당 부분 연계됐음을 보여준다.

✅ 액션 아이템

• NeMo Automodel로 Diffusers 가중치를 체크포인트 변환 없이 학습·재로드하는 경로를 점검한다.
• flow matching 대상 FSDP2·파이프라인 병렬화를 YAML 설정으로 단일 GPU부터 확장하는 기준을 정의한다.
• FLUX.1-dev 전체 미세 조정과 LoRA의 H100 처리량·메모리 차이를 구성별로 비교한다.

❓ 열린 질문

• Wan 2.1·2.2, HunyuanVideo 1.5, Qwen-Image 레시피에서 전체 미세 조정과 LoRA 지원 범위는 무엇인가?
• 78장 Rider–Waite 데이터로 200스텝 학습한 FLUX.1-dev에서 trtcrd 토큰 분리는 얼마나 안정적인가?
• 8대 H100 80GB 벤치마크에서 잠재 표현 캐싱과 다중 해상도 버킷 로딩의 기여를 어떻게 판단할 것인가?