Diffusers welcomes FLUX-2
Quick Summary
FLUX.2는 처음부터 새로 사전학습한 이미지 생성·편집 모델로, Diffusers는 새로운 구조와 다중 이미지 참조 기능부터 8~80GB급 그래픽 메모리 환경별 추론 방법까지 구체적으로 소개한다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
FLUX.2는 처음부터 새로 사전학습한 이미지 생성·편집 모델로, Diffusers는 새로운 구조와 다중 이미지 참조 기능부터 8~80GB급 그래픽 메모리 환경별 추론 방법까지 구체적으로 소개한다.
📌 핵심 요약
- FLUX.2는 FLUX.1의 단순한 후속 교체판이 아니라 새로운 아키텍처로 처음부터 사전학습한 이미지 생성·편집 모델이며, 텍스트 기반 생성과 이미지 기반 생성을 모두 지원한다.
- 텍스트 인코더는 두 개에서 Mistral Small 3.1 하나로 통합됐고 최대 시퀀스 길이 512를 지원하며, 단일 최종 층 대신 여러 중간 층의 출력을 쌓아 프롬프트 임베딩을 만든다.
- 확산 트랜스포머는 이중 스트림과 단일 스트림 구조를 이어가면서 변조 매개변수 공유, 편향 매개변수 제거, 완전 병렬 블록 도입, 단일 스트림 비중 확대 등의 변화를 적용했다.
- 전체 구성은 오프로딩 없이 80GB가 넘는 그래픽 메모리를 요구하지만, 중앙처리장치 오프로딩, 플래시 어텐션 3, NF4 4비트 양자화, 원격 텍스트 인코더를 조합해 약 18~24GB 환경에서도 실행할 수 있다.
- 그룹 오프로딩과 원격 인코딩을 이용하면 여유 그래픽 메모리 8GB에서도 실행할 수 있으며, FLUX.2는 최대 10개의 참조 이미지를 받아 번호와 자연어로 대상을 지시할 수 있다.
🧩 주요 포인트
- FLUX.2는 FLUX.1의 단순한 후속 교체판이 아니라 새로운 아키텍처로 처음부터 사전학습한 이미지 생성·편집 모델이며, 텍스트 기반 생성과 이미지 기반 생성을 모두 지원한다.
- 텍스트 인코더는 두 개에서 Mistral Small 3.1 하나로 통합됐고 최대 시퀀스 길이 512를 지원하며, 단일 최종 층 대신 여러 중간 층의 출력을 쌓아 프롬프트 임베딩을 만든다.
- 확산 트랜스포머는 이중 스트림과 단일 스트림 구조를 이어가면서 변조 매개변수 공유, 편향 매개변수 제거, 완전 병렬 블록 도입, 단일 스트림 비중 확대 등의 변화를 적용했다.
- 전체 구성은 오프로딩 없이 80GB가 넘는 그래픽 메모리를 요구하지만, 중앙처리장치 오프로딩, 플래시 어텐션 3, NF4 4비트 양자화, 원격 텍스트 인코더를 조합해 약 18~24GB 환경에서도 실행할 수 있다.
- 그룹 오프로딩과 원격 인코딩을 이용하면 여유 그래픽 메모리 8GB에서도 실행할 수 있으며, FLUX.2는 최대 10개의 참조 이미지를 받아 번호와 자연어로 대상을 지시할 수 있다.
🧠 상세 정리
1. 새 모델로 출발한 FLUX.2
FLUX.2는 Black Forest Labs가 공개한 최신 이미지 생성 모델 계열로, 앞선 FLUX.1을 바탕으로 일부만 수정한 모델이 아니다. 본문은 새로운 아키텍처를 채택하고 사전학습도 처음부터 다시 수행한 완전히 새로운 모델이라고 명시한다. 따라서 FLUX.1을 그대로 대체하는 호환형 모델로 간주해서는 안 되며, 이미지 생성과 편집을 위한 별도의 모델로 이해해야 한다. 글은 이러한 구조적 변화와 Diffusers를 이용한 여러 추론 구성, 제한된 자원에서의 실행 방법, 저순위 적응 미세조정을 주요 주제로 제시한다. 다만 제공된 원문 범위에서는 주로 모델 구조와 추론 구성, 다중 참조 이미지 기능이 구체적으로 설명된다.
2. 텍스트·이미지 기반 생성과 새 텍스트 인코더
FLUX.2는 텍스트 지시만으로 이미지를 만드는 방식과 입력 이미지를 바탕으로 결과를 만드는 방식을 모두 지원한다. 하나의 이미지만 받는 데 그치지 않고 여러 이미지를 참조 입력으로 받아 최종 결과에 반영할 수 있다는 점도 핵심 기능으로 소개된다. 텍스트 인코더는 FLUX.1의 두 개 구성에서 Mistral Small 3.1 하나로 통합되어 프롬프트 임베딩 계산 과정이 단순해졌다. 파이프라인의 최대 시퀀스 길이는 512이며, 프롬프트 표현을 만들 때 마지막 단일 층의 출력만 쓰지 않고 여러 중간 층의 출력을 쌓아 사용한다. 본문은 이런 중간 층 결합 방식이 더 유익한 결과를 내는 것으로 알려져 있다고 설명한다.
3. 확산 트랜스포머의 기본 구조
FLUX.2의 확산 트랜스포머는 FLUX.1과 마찬가지로 다중 모달 확산 트랜스포머와 병렬 확산 트랜스포머를 결합한 큰 틀을 유지한다. 이중 스트림 블록에서는 이미지 잠재 표현과 조건 텍스트를 각각 별도의 흐름으로 처리한 뒤 어텐션 연산에서 두 흐름을 결합한다. 이후 단일 스트림으로 불리는 병렬 블록은 이미지와 텍스트 흐름을 연결한 상태에서 함께 연산한다. 시간 및 가이던스 정보에 해당하는 적응형 층 정규화 제로 변조 매개변수는 각 블록마다 따로 두지 않고, 이중 스트림 블록 전체와 단일 스트림 블록 전체에서 각각 공유한다. 이는 FLUX.1이 개별 블록마다 독립적인 변조 매개변수를 사용했던 방식과 구별되는 변화다.
4. 편향 제거와 완전 병렬 블록
FLUX.2는 모델의 어떤 층에서도 편향 매개변수를 사용하지 않으며, 이 원칙은 두 종류의 트랜스포머 블록에 포함된 어텐션과 순방향 신경망 하위 블록에도 적용된다. FLUX.1의 단일 스트림 블록은 어텐션 출력 투영과 순방향 신경망 출력 투영을 결합했는데, FLUX.2는 여기서 병렬화 범위를 더 넓혔다. 어텐션의 질의·키·값 투영과 순방향 신경망의 입력 투영까지 결합해 완전 병렬 트랜스포머 블록을 구성한다. 본문이 비교 대상으로 제시한 ViT-22B 블록과 달리 FLUX.2는 가우시안 오차 선형 유닛이 아니라 스위시 게이트 선형 유닛 방식의 다층 퍼셉트론 활성화를 사용한다. 또한 이 비교에서도 편향 매개변수를 사용하지 않는다는 차이가 다시 강조된다.
5. 단일 스트림 중심의 대형 구조
FLUX.2는 이중 스트림 블록 8개와 단일 스트림 블록 48개로 구성되어, FLUX.1의 19개와 38개 구성보다 단일 스트림 블록의 비중이 커졌다. 이러한 재배치는 단순히 블록 개수뿐 아니라 모델 매개변수의 분포도 크게 바꾼다. 약 120억 매개변수 규모의 FLUX.1 개발 모델에서는 전체 매개변수의 약 54%가 이중 스트림 블록에 있었지만, 약 320억 매개변수 규모의 FLUX.2 개발 모델에서는 그 비중이 약 24%로 줄었다. 반대로 FLUX.2에서는 전체 매개변수의 약 73%가 단일 스트림 블록에 배치된다. 이와 함께 새로운 자동 인코더인 AutoencoderKLFlux2가 도입됐고, 해상도에 따라 달라지는 시간 단계 일정을 반영하는 방법도 개선됐다.
6. 기본 추론의 높은 메모리 요구량
FLUX.2는 더 큰 확산 트랜스포머와 Mistral Small 3.1 텍스트 인코더를 함께 사용하므로, 아무런 오프로딩 없이 추론하면 80GB가 넘는 그래픽 메모리가 필요하다. Diffusers에서 실행하려면 우선 저장소의 최신 주 브랜치 버전을 설치하고 허깅페이스 인증 명령으로 로그인해야 한다. 기본 예시는 FLUX.2 개발 모델을 브레인 플로트 16 자료형으로 불러온 뒤 중앙처리장치 모델 오프로딩을 활성화하고, 1024×1024 이미지를 50단계로 생성한다. 이 구성은 H100에서도 오프로딩 없이는 충분하지 않았으며, 중앙처리장치 오프로딩을 사용한 상태에서도 약 62GB가 필요했다. 호퍼 계열 그래픽처리장치 사용자는 플래시 어텐션 3 백엔드를 적용해 추론 속도를 높일 수 있다.
7. 4비트 양자화와 원격 텍스트 인코딩
자원이 제한된 환경에서는 비트앤바이츠를 이용해 확산 트랜스포머와 텍스트 인코더를 NF4 형식의 4비트 모델로 불러올 수 있다. 본문의 예시는 미리 양자화된 저장소에서 두 구성요소를 중앙처리장치에 적재한 뒤 파이프라인에 연결하고 모델 오프로딩을 활성화하며, 약 20GB의 여유 그래픽 메모리에서 실행할 수 있다고 설명한다. Diffusers의 모듈식 설계를 활용하면 텍스트 인코더를 추론 엔드포인트에 따로 배치하고, 로컬 장치에는 확산 트랜스포머와 변분 자동 인코더만 남길 수도 있다. 이 혼합 구성에서는 인증 토큰을 사용해 원격 서버에서 프롬프트 임베딩을 받은 다음, 로컬의 NF4 양자화 모델에 전달한다. 본문에 따르면 이 조합은 18GB 그래픽 메모리 환경에서 실행할 수 있고 여러 프롬프트의 임베딩을 묶어 복수 이미지를 생성하는 것도 가능하다.
8. 8GB 환경과 다중 참조 이미지
그래픽 메모리가 더 적은 환경에서는 그룹 오프로딩을 사용해 모델의 일부를 필요할 때만 그래픽처리장치로 옮길 수 있다. 원격 텍스트 인코더와 양자화 모델, 잎 수준 그룹 오프로딩을 결합하면 여유 그래픽 메모리가 8GB인 장치에서도 FLUX.2를 사용할 수 있지만, 기본 구성에는 32GB의 여유 시스템 메모리가 필요하다. 속도 저하를 감수하고 낮은 중앙처리장치 메모리 사용 설정을 켜면 시스템 메모리 요구량을 10GB까지 낮출 수 있다고 설명한다. 기능 측면에서 FLUX.2는 최대 10개의 이미지를 참조 입력으로 받을 수 있으나, 이미지를 추가할 때마다 그래픽 메모리 사용량도 늘어난다. 프롬프트에서는 ‘이미지 1’, ‘이미지 2’ 같은 번호나 ‘캥거루’, ‘거북이’ 같은 자연어 명칭으로 참조 대상을 지정할 수 있으며, 본문은 두 방식을 함께 사용하는 접근을 권한다.
🧾 핵심 주장 / 시사점
- FLUX.2의 변화는 모델 크기 증가에만 있지 않고, 텍스트 인코더 통합과 변조 매개변수 공유, 편향 제거, 완전 병렬 블록, 단일 스트림 중심 재배치처럼 계산 구조 전반에 걸쳐 있다.
- 기본 모델의 메모리 요구량은 매우 높지만 Diffusers의 모듈 분리, 4비트 양자화, 중앙처리장치 및 그룹 오프로딩, 원격 프롬프트 인코딩을 단계적으로 조합해 실행 가능한 장치 범위를 넓힌다.
- 다중 이미지 참조는 최대 10개 입력과 번호·자연어 기반 지시를 지원하지만, 참조 이미지를 늘릴수록 그래픽 메모리가 추가로 필요하므로 기능 활용과 자원 사용을 함께 고려해야 한다.
✅ 액션 아이템
- FLUX.2가 FLUX.1의 단순 후속이 아닌 새 아키텍처임을 반영해 교체 판단 기준을 기능·학습 구조 변화 중심으로 재정의한다.
- 텍스트 인코더 단일화와 최대 10개 참조 이미지 지시 방식(번호 지정·자연어)을 반영해 생성·편집 프롬프트 운용 규칙을 점검한다.
- 오프로딩·양자화·원격 인코딩 조건을 80GB 무오프로딩, 18~24GB 하이브리드, 8GB 그룹 오프로딩으로 구분해 환경별 배치 정책을 정한다.
❓ 열린 질문
- Mistral Small 3.1 단일 텍스트 인코더가 중간층 누적 임베딩 방식과 결합될 때 어떤 품질 편차를 가장 우선적으로 점검할 것인가?
- 플래시 어텐션 3와 NF4 4비트 양자화, CPU 오프로딩을 조합한 18~24GB 구성에서 지연시간과 품질 균형의 임계값은 어디인가?
- 그룹 오프로딩과 원격 인코딩으로 8GB 환경을 노릴 때 10개 참조 이미지 입력 시 안정적으로 처리 가능한 최대 프롬프트 복잡도는 무엇인가?