Fast LoRA inference for Flux with Diffusers and PEFT

🖼️ 인포그래픽

Fast LoRA inference for Flux with Diffusers and PEFT 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Diffusers와 PEFT의 LoRA 핫스와핑, torch.compile, FP8 양자화, Flash Attention 3를 조합해 Flux.1-Dev의 재컴파일 문제를 피하고 고성능 GPU에서 약 2.23배, RTX 4090에서 약 2.04배 빠른 LoRA 추론을 구현한 최적화 방법을 설명한다.

📌 핵심 요약

LoRA 어댑터는 이미지 생성 모델에 스타일과 캐릭터 등을 추가할 수 있지만, 어댑터마다 랭크와 대상 계층이 달라 교체할 때 컴파일된 모델이 재컴파일되는 문제가 발생한다.
핵심 최적화 조합은 Flash Attention 3, torch.compile, TorchAO 기반 FP8 양자화, 그리고 모델 구조를 바꾸지 않고 가중치만 교환하는 Diffusers의 LoRA 핫스와핑이다.
고성능 GPU 환경의 최적화 구성은 기준 추론 시간 7.8910초를 3.5464초로 줄여 2.23배 속도 향상을 기록했으며, FP8을 제외해도 1.81배 향상됐다.
24GB 메모리의 RTX 4090에서는 CPU 오프로딩이나 T5 텍스트 인코더 NF4 양자화를 활용해야 하며, FP8 변환기 양자화와 컴파일을 결합한 LoRA 구성은 23.6060초에서 11.5715초로 약 2.04배 빨라졌다.
재컴파일 없는 핫스와핑을 위해서는 최대 LoRA 랭크를 미리 지정하고 첫 어댑터가 이후 어댑터의 모든 대상 계층을 포괄해야 하며, 현재 텍스트 인코더를 대상으로 하는 LoRA 핫스와핑은 지원되지 않는다.

🧩 주요 포인트

LoRA 어댑터는 이미지 생성 모델에 스타일과 캐릭터 등을 추가할 수 있지만, 어댑터마다 랭크와 대상 계층이 달라 교체할 때 컴파일된 모델이 재컴파일되는 문제가 발생한다.
핵심 최적화 조합은 Flash Attention 3, torch.compile, TorchAO 기반 FP8 양자화, 그리고 모델 구조를 바꾸지 않고 가중치만 교환하는 Diffusers의 LoRA 핫스와핑이다.
고성능 GPU 환경의 최적화 구성은 기준 추론 시간 7.8910초를 3.5464초로 줄여 2.23배 속도 향상을 기록했으며, FP8을 제외해도 1.81배 향상됐다.
24GB 메모리의 RTX 4090에서는 CPU 오프로딩이나 T5 텍스트 인코더 NF4 양자화를 활용해야 하며, FP8 변환기 양자화와 컴파일을 결합한 LoRA 구성은 23.6060초에서 11.5715초로 약 2.04배 빨라졌다.
재컴파일 없는 핫스와핑을 위해서는 최대 LoRA 랭크를 미리 지정하고 첫 어댑터가 이후 어댑터의 모든 대상 계층을 포괄해야 하며, 현재 텍스트 인코더를 대상으로 하는 LoRA 핫스와핑은 지원되지 않는다.

🧠 상세 정리

1. LoRA 추론 최적화의 목표와 Flux.1-Dev

LoRA 어댑터는 모델 전체를 다시 학습하지 않고도 이미지 생성 모델에 새로운 스타일, 캐릭터와 같은 특성을 부여하는 중요한 사용자화 수단이다. 경우에 따라서는 추론 지연 시간을 줄이는 용도로도 활용할 수 있어, 모델 사용자화와 미세 조정 모두에서 의미가 크다. 글은 널리 사용되고 Hugging Face Hub에 3만 개가 넘는 관련 어댑터가 보고된 Flux.1-Dev를 대상으로 LoRA 추론 속도를 높이는 방법을 다룬다. 목표는 단순히 하나의 LoRA를 빠르게 실행하는 것이 아니라, 실제 서빙 환경에서 여러 LoRA를 교체하면서도 최적화 효과를 유지하는 것이다. 실험은 Flux를 중심으로 진행됐지만, 작성자들은 제시한 최적화 방식이 다른 모델에도 적용할 수 있을 만큼 일반적이라고 설명한다.

2. 동적인 LoRA 교체와 재컴파일 문제

LoRA를 서비스할 때는 서로 다른 어댑터를 수시로 불러오고 내리는 핫스와핑이 일반적이지만, 각 LoRA는 기본 모델의 구조에 영향을 줄 수 있다. 어댑터마다 랭크가 다르고 적응 대상으로 삼는 계층도 달라서, 특정 LoRA가 적용된 모델을 torch.compile로 컴파일한 뒤 다른 구성의 LoRA로 바꾸면 재컴파일이 발생할 수 있다. 이 재컴파일은 원래 컴파일을 통해 얻으려던 추론 지연 시간 단축 효과를 훼손한다. LoRA 파라미터를 기본 모델 파라미터에 융합한 뒤 컴파일하고 새 어댑터를 넣을 때 다시 분리하는 방식도 고려할 수 있지만, 잠재적인 아키텍처 변화 때문에 추론 과정에서 같은 문제가 반복된다. 따라서 현실적인 최적화는 서로 다른 LoRA의 동적 특성을 수용하면서 모델 구조를 안정적으로 유지해야 한다.

3. Flash Attention 3·컴파일·FP8의 결합

제안된 기본 최적화 구성은 Flash Attention 3, torch.compile, TorchAO의 FP8 양자화, 그리고 핫스와핑 지원으로 이루어진다. 파이프라인을 불러올 때 Flux 변환기에 float8dq_e4m3_row 방식의 FP8 양자화를 적용하고, 전용 FlashFluxAttnProcessor3_0을 어텐션 처리기로 설정한 뒤 변환기를 fullgraph와 max-autotune 모드로 컴파일한다. torch.compile은 적시 컴파일 방식이므로 첫 번째 파이프라인 호출은 느리지만, 이후 호출부터는 상당한 속도 향상을 기대할 수 있다. FP8 양자화는 손실이 있는 최적화여서 이미지 품질에 영향을 줄 수 있으나, 속도와 메모리 사용량 사이에서 가장 강력한 절충 효과를 제공하는 요소로 소개된다. 실험은 주로 NVIDIA GPU에서 수행됐지만, 글은 이 구성이 AMD GPU에서도 작동할 수 있다고 설명한다.

4. 재컴파일을 피하는 LoRA 핫스와핑 절차

Diffusers에서는 enable_lora_hotswap으로 최대 랭크를 먼저 설정하고 첫 번째 LoRA를 불러온 다음, 그 상태에서 변환기를 컴파일하는 순서가 사용된다. 이후 어댑터는 load_lora_weights 호출에 hotswap을 참으로 지정해 불러오며, 이 방식은 모델 아키텍처를 바꾸지 않고 LoRA 가중치만 교체하므로 재컴파일을 요구하지 않는다. 다만 사용할 어댑터 가운데 가장 큰 랭크를 사전에 알아야 하며, 랭크 16과 32의 어댑터를 함께 사용한다면 최대 랭크를 32로 지정해야 한다. 이후 교체되는 LoRA는 첫 번째 LoRA가 대상으로 삼은 계층과 같거나 그 일부만 대상으로 삼을 수 있고, 현재 텍스트 인코더를 대상으로 하는 LoRA 핫스와핑은 지원되지 않는다. 따라서 어댑터를 불러오는 순서와 첫 LoRA의 대상 계층 범위가 전체 핫스와핑 풀의 호환성을 결정한다.

5. 고성능 GPU에서 확인한 속도 향상

고성능 GPU에서 기준 구성의 추론 시간은 7.8910초였고, 핫스와핑과 컴파일을 재컴파일 없이 결합하며 FP8과 Flash Attention 3를 적용한 최적화 구성은 3.5464초로 2.23배 빨랐다. FP8만 비활성화한 구성은 4.3520초로 1.81배, Flash Attention 3만 비활성화한 구성은 4.3020초로 1.84배 향상됐다. 일반적인 방식으로 컴파일했지만 간헐적인 재컴파일 정지가 발생한 구성은 5.0920초와 1.55배 향상에 그쳤고, Flash Attention 3와 FP8을 모두 끈 구성도 5.0850초로 같은 1.55배 수준이었다. 컴파일과 FP8을 끄면 7.5190초로 개선 폭이 1.05배에 불과했으며, 컴파일을 비활성화한 설정은 10.4340초로 기준보다 느렸다. 이 수치는 컴파일 자체의 최초 소요 시간을 제외한 결과이며, 재컴파일을 제거하는 핫스와핑이 최고 속도 향상의 핵심임을 보여준다.

6. RTX 4090의 메모리 제약과 CPU 오프로딩

Flux.1-Dev를 LoRA 없이 Bfloat16으로 실행해도 약 33GB의 메모리가 필요하므로, 24GB 메모리를 갖춘 RTX 4090에서는 기본 상태로 전체 파이프라인을 실행하기 어렵다. 먼저 현재 연산에 필요하지 않은 구성 요소를 CPU로 옮기는 모델 CPU 오프로딩을 적용하면 약 22GB의 GPU 메모리로 파이프라인을 실행할 수 있으며, 이때 추론 시간은 35.403초였다. 전체 변환기를 한 번에 컴파일하는 대신 반복 블록을 fullgraph 방식으로 지역 컴파일하면 컴파일 시간을 줄이면서 추론 시간을 31.205초로 낮춰 1.12배 속도 향상을 얻었다. 그러나 CPU 오프로딩과 컴파일을 함께 사용하는 구성에서는 FP8 양자화가 지원되지 않았고, Flux 변환기만 FP8로 양자화하는 것으로도 메모리 부족을 해결할 수 없었다. 이 제약 때문에 소비자용 GPU에서는 고성능 GPU와 다른 메모리 절감 전략이 추가로 필요했다.

7. T5 양자화를 포함한 RTX 4090 최적화

CPU 오프로딩 없이 FP8 양자화를 활용하기 위해 글은 Flux 변환기뿐 아니라 T5 텍스트 인코더에도 양자화를 적용한다. T5에는 bitsandbytes의 NF4 양자화를 사용했으며, 비교 결과 이 양자화로 인한 품질 손실은 크지 않은 것으로 제시됐다. LoRA를 적용하지 않은 비교에서는 NF4로 양자화한 T5, FP8로 양자화한 Flux 변환기, torch.compile을 결합해 32.27초를 9.668초로 줄였고 약 3.3배 속도 향상과 눈에 띄지 않는 품질 저하를 보고했다. RTX 4090은 Flash Attention 3를 지원하지 않으므로 LoRA 실험에는 FP8, torch.compile, 핫스와핑, T5 NF4 양자화만 사용됐다. 이 LoRA 구성에서 기준 시간은 23.6060초였고 최적화 후에는 11.5715초로 줄어 약 2.04배 빨라졌으며, 다른 시험 조합들은 오프로딩을 사용해도 메모리 부족 오류를 일으켰다.

8. 핫스와핑의 내부 동작과 실무적 제약

재컴파일 없는 핫스와핑을 구현하려면 먼저 부동소수점 값인 LoRA 스케일링 계수를 torch 텐서로 변환해야 한다. 또한 서로 다른 랭크의 LoRA 가중치를 직접 교환할 수 있도록 가중치 형태를 필요한 최대 크기까지 패딩해야 하며, 이 때문에 최대 랭크 지정이 필수적이다. 빈 영역은 0으로 채우므로 계산 결과 자체는 변하지 않지만, 실제 랭크보다 패딩이 클수록 불필요한 계산이 늘어 실행 속도가 다소 느려질 수 있다. 새 LoRA 속성을 추가하지 않는 방식이므로 이후 어댑터의 대상 계층은 첫 번째 어댑터가 만든 범위를 넘어설 수 없다. 서로 완전히 다른 계층을 대상으로 하는 LoRA들을 함께 사용해야 한다면, 모든 대상 계층의 합집합을 포함하는 더미 LoRA를 먼저 만드는 방법이 제시된다. 구현 세부 사항은 PEFT의 hotswap.py에 있으며, 전체적으로는 재컴파일 방지와 어댑터 호환 범위 사이의 명확한 절충이 존재한다.

🧾 핵심 주장 / 시사점

LoRA 추론에서는 torch.compile 적용 자체보다 어댑터 교체 과정에서 모델 구조를 고정해 재컴파일을 방지하는 것이 전체 지연 시간을 줄이는 데 더 중요하다.
FP8을 제거한 구성도 고성능 GPU에서 1.81배 속도 향상을 기록했으므로, 품질 손실이 우려되는 경우에도 핫스와핑과 컴파일만으로 유의미한 개선을 얻을 수 있다.
소비자용 GPU에서는 연산 최적화만으로는 부족하며, T5 텍스트 인코더와 Flux 변환기를 각각 양자화해 전체 파이프라인을 24GB 메모리 안에 배치하는 구성이 속도 향상의 전제 조건이 된다.

✅ 액션 아이템

Flux.1-Dev에서 Flash Attention 3, torch.compile, TorchAO FP8 양자화, Diffusers LoRA 핫스와핑을 묶어 기준 7.8910초 대비 3.5464초 구간을 재현한다.
재컴파일 회피를 위해 최대 LoRA 랭크를 사전 지정하고, 첫 어댑터가 이후 모든 대상 계층을 포함하는지 교체 전 점검 규칙으로 정한다.
24GB RTX 4090 기준으로 CPU 오프로딩 또는 T5 텍스트 인코더 NF4 중 적합한 경로를 선택하고 FP8 양자화+컴파일 조합 성능(23.6060초→11.5715초)을 반영한다.

❓ 열린 질문

어떤 최대 LoRA 랭크와 대상 계층 조합이 첫 어댑터 후속 교체 시 재컴파일 없이 안정적으로 유지될 것인가?
텍스트 인코더 대상 LoRA 핫스와핑 미지원 제약이 스타일·캐릭터 확대 전략에서 실질적으로 어디까지 제약요인이 될까?
24GB RTX 4090에서 CPU 오프로딩과 T5 텍스트 인코더 NF4 중 어떤 경로가 FP8 양자화 및 torch.compile을 고려했을 때 더 나은 판단 기준이 될까?