huggingface.co의 「Exploring Quantization Backends in Diffusers」는 Diffusers 안에서 바로 쓰는 양자화 백엔드를 FLUX-dev로 비교합니다.
BF16 전체 모델은 31.447 GB가 들었고, 4-bit는 12.584 GB, 8-bit는 19.273 GB였습니다.
실무에서는 transformer와 text_encoder_2를 먼저 줄이고, 장비별로 다시 재는 편이 안전합니다.
Diffusers는 FLUX-dev로 여러 양자화 백엔드를 직접 비교했습니다
huggingface.co의 「Exploring Quantization Backends in Diffusers」는 큰 이미지 생성 모델을 더 가볍게 다루는 방법을 보여줍니다.
이 글은 FluxPipeline을 기준으로 설명합니다. 사용한 체크포인트는 black-forest-labs/FLUX.1-dev입니다.
원문은 bitsandbytes, GGUF, torchao, Quanto, 네이티브 FP8 지원을 함께 살핍니다. 즉, 한 가지 압축법이 아니라 여러 백엔드의 차이를 나란히 보여줍니다.
또한 원문은 간단한 체감 실험도 넣습니다. 사용자가 프롬프트를 보고, 어떤 결과가 양자화 모델에서 나왔는지 맞히는 방식입니다.
원문이 밝힌 핵심은 단순합니다. 양자화는 메모리를 줄이면서도, 결과 차이가 생각보다 작을 수 있습니다. 특히 8-bit에서는 차이가 미세할 수 있고, 4-bit도 충분히 쓸 만할 수 있습니다.
FLUX-dev에서 부담이 큰 부분도 분명히 드러납니다. 원문은 변환기와 text_encoder_2, 즉 T5를 중심으로 메모리를 줄이는 예시를 보여줍니다.
- 텍스트 인코더 CLIP과 T5는 입력 문장을 해석합니다.
- 변환기 MMDiT는 실제 이미지를 만드는 핵심 부분입니다.
- VAE는 잠재 표현과 픽셀 이미지를 오갑니다.
원문에서 확인된 메모리와 시간 값은 다음과 같습니다
아래 표는 원문에서 확인된 값만 정리한 것입니다.
| 항목 | 원문 수치 | 무엇을 재는 값인지 |
|---|---|---|
| FLUX.1-dev 전체 BF16 로딩 | 31.447 GB | 전체 모델을 BF16으로 올릴 때 필요한 메모리입니다. |
| T5 텍스트 인코더 | 9.52 GB | BF16에서 T5가 차지하는 메모리입니다. |
| CLIP 텍스트 인코더 | 246 MB | BF16에서 CLIP이 차지하는 메모리입니다. |
| 변환기 MMDiT | 23.8 GB | BF16에서 핵심 생성부가 차지하는 메모리입니다. |
| VAE | 168 MB | BF16에서 VAE가 차지하는 메모리입니다. |
| BF16 벤치마크 | 31.447 GB / 36.166 GB / 12 seconds | 로딩 후 메모리, 최대 메모리, 추론 시간입니다. |
| 4-bit 벤치마크 | 12.584 GB / 17.281 GB / 12 seconds | 로딩 후 메모리, 최대 메모리, 추론 시간입니다. |
| 8-bit 벤치마크 | 19.273 GB / 24.432 GB / 27 seconds | 로딩 후 메모리, 최대 메모리, 추론 시간입니다. |
원문은 다음 문장을 그대로 적습니다.
"Loading the full FLUX.1-dev model in BF16 precision requires approximately 31.447 GB of memory."
"All benchmarks performed on 1x NVIDIA H100 80GB GPU"
이 두 문장은 수치 해석의 기준점이 됩니다. 전체 모델이 얼마나 무거운지와, 어떤 장비에서 측정했는지를 함께 알려주기 때문입니다.
양자화는 화질을 무너뜨린다는 통념과 원문은 다르게 봅니다
원문은 양자화를 곧바로 화질 붕괴로 보지 않습니다. 오히려 8-bit에서는 차이가 미세해, 자세히 보지 않으면 구분이 어려울 수 있다고 말합니다.
4-bit나 그보다 더 공격적인 양자화는 차이가 더 보일 수 있습니다. 그런데도 결과가 충분히 좋을 수 있다고 원문은 적습니다.
이 지점이 통념과 갈리는 부분입니다. 많은 사람은 메모리를 줄이면 곧 품질도 크게 깎인다고 생각합니다. 원문은 적어도 FLUX-dev 실험에서는 그 관계가 그렇게 단순하지 않다고 보여줍니다.
NF4가 자주 언급되는 이유도 여기에서 보입니다. 원문은 NF4가 균형이 좋은 경우가 많다고 적습니다. 즉, 같은 압축이라도 표현 방식에 따라 체감 결과가 달라질 수 있습니다.
내 시스템에서는 transformer와 text_encoder_2를 먼저 건드려야 합니다
원문은 메모리 절감의 초점을 transformer와 text_encoder_2에 맞춥니다. 이 둘이 가장 큰 절감 효과를 내기 쉽기 때문입니다.
실무에서는 다음 순서로 보면 됩니다.
- 전체 모델이 아니라 가장 무거운 모듈부터 확인합니다.
- transformer와 T5를 우선 양자화 대상으로 둡니다.
- 로딩 후 메모리와 최대 메모리, 추론 시간을 함께 기록합니다.
- 장비가 바뀌면 같은 설정도 다시 측정합니다.
원문 예시는 bitsandbytes를 기준으로 보여줍니다. 이때 DiffusersBitsAndBytesConfig는 diffusers에서, TransformersBitsAndBytesConfig는 transformers에서 따로 가져와야 합니다. 원문이 이 부분을 따로 강조한 이유는, 구성요소가 서로 다른 라이브러리에서 오기 때문입니다.
또한 벤치마크 해석에도 주의가 필요합니다. 원문 수치는 1x NVIDIA H100 80GB GPU에서 측정됐습니다. 따라서 같은 비율의 절감이 다른 장비에서 그대로 재현된다고 보면 안 됩니다.
실무에서는 우선 비교 기준을 고정하는 편이 좋습니다. 같은 프롬프트, 같은 추론 단계 수, 같은 출력 크기에서 BF16과 4-bit, 8-bit를 나란히 봐야 합니다. 그렇게 해야 메모리와 시간의 차이를 같은 선상에서 판단할 수 있습니다.
자주 묻는 질문
FLUX-dev에서 가장 무거운 구성요소는 무엇입니까?
원문 기준으로 변환기 MMDiT가 가장 무겁습니다. BF16에서 23.8 GB를 차지하므로, 먼저 줄여 볼 후보가 됩니다.
4-bit와 8-bit 중 어느 쪽이 더 가볍습니까?
4-bit가 더 가볍습니다. 원문 벤치마크에서 4-bit는 12.584 GB였고, 8-bit는 19.273 GB였습니다. 최대 메모리와 추론 시간도 4-bit가 더 낮았습니다.
이 수치를 다른 GPU에도 그대로 적용할 수 있습니까?
아닙니다. 원문 벤치마크는 1x NVIDIA H100 80GB GPU에서 측정됐습니다. 다른 GPU에서는 메모리와 속도를 다시 재야 합니다.