Stable Diffusion 체크포인트 위주로 ComfyUI를 사용했다면 FLUX 워크플로우를 처음 열었을 때 VAE 연결부터 낯설 수 있다. CheckpointLoaderSimple 하나에서 MODEL·CLIP·VAE가 모두 나오는 대신 diffusion model, text encoder, VAE가 각각 따로 로드되는 구성이 자주 등장하기 때문이다.
FLUX.1 Dev 계열의 공식 ComfyUI 워크플로우에서도 VAE는 VAELoader를 통해 별도로 불러오며 ae.safetensors를 사용한다. 이번 글에서는 외부 VAE의 일반적인 설치법이 아니라 FLUX에서 이 VAE가 어디에 들어가고 무엇과 연결되는지만 좁혀서 본다.
comfyui vae 사용법에서 가장 먼저 볼 변화
FLUX에서는 VAE를 별도 파일로 불러온다
ComfyUI의 기본 FLUX.1 Dev 워크플로우를 보면 모델 구성 요소가 나뉘어 있다.
diffusion model은 Load Diffusion Model 또는 UNETLoader 계열에서 불러오고, 텍스트 인코더는 DualCLIPLoader에서 불러온다. VAE는 별도의 VAELoader에서 ae.safetensors를 선택하는 구조다.
CheckpointLoaderSimple 방식과 다르게 보이는 이유
일반적인 통합 체크포인트 워크플로우에서는 하나의 checkpoint loader에서 MODEL, CLIP, VAE가 함께 출력될 수 있다.
반면 FLUX 분리형 워크플로우에서는 각각 필요한 파일을 따로 불러온다.
diffusion model → MODEL
text encoders → CLIP
ae.safetensors → VAE
따라서 FLUX에서 VAELoader가 따로 보이는 것은 VAE가 중복으로 로드된다는 의미가 아니다. 워크플로우 구성 요소가 처음부터 분리돼 있는 것이다.
이 차이를 이해하면 FLUX 워크플로우에서 CheckpointLoaderSimple의 VAE 출력을 찾다가 막히는 일을 줄일 수 있다.
ae.safetensors는 models/vae에서 불러온다
comfyui vae 사용법가 ComfyUI 워크플로우에 미치는 영향
공식 FLUX 관련 ComfyUI 워크플로우에서는 ae.safetensors를 VAE로 사용하며 파일 위치는 ComfyUI/models/vae다.
기존 방식과 비교해야 할 부분
구조를 단순화하면 다음과 같다.
ComfyUI/models/vae/ae.safetensors
파일이 정상적으로 인식되면 VAELoader의 vae_name에서 ae.safetensors를 선택할 수 있다.
diffusion model 폴더와 혼동하지 않는다
FLUX 모델 파일과 VAE 파일은 같은 위치에 넣는 것이 아니다.
diffusion model은 별도의 diffusion_models 경로에서 관리되는 구성이 사용되고, ae.safetensors는 VAE 폴더에 들어간다. 텍스트 인코더 역시 text_encoders 경로로 분리된다.
이 때문에 FLUX를 처음 설치할 때 모든 safetensors 파일을 한 폴더에 넣으면 워크플로우의 각 loader에서 필요한 파일이 나타나지 않을 수 있다.
즉 파일 확장자가 같다는 것보다 각 파일이 어떤 역할을 맡는지를 기준으로 폴더를 나누는 것이 중요하다.
VAELoader 출력은 VAEDecode로 연결한다
text-to-image 기준으로 FLUX가 샘플링을 마쳤다고 해서 바로 저장 가능한 RGB 이미지가 나오는 것은 아니다. KSampler 계열에서 나온 결과는 latent이므로 마지막에 VAE Decode가 필요하다.
성능과 결과 품질에서 확인할 차이
연결은 다음처럼 보면 된다.
워크플로우 구성에서 놓치기 쉬운 부분
KSampler LATENT → VAEDecode samples
VAELoader VAE → VAEDecode vae
VAEDecode IMAGE → Save Image
VAELoader에서 선택한 ae.safetensors는 이때 VAEDecode의 vae 입력으로 들어간다.
MODEL이나 CLIP에 연결하는 파일이 아니다
ae.safetensors는 diffusion model을 대체하지 않는다. DualCLIPLoader에서 사용하는 텍스트 인코더 파일도 아니다.
따라서 VAELoader의 VAE 출력을 MODEL이나 CLIP 타입 입력에 연결하려고 할 필요가 없다. FLUX의 생성 모델, 텍스트 인코더, VAE는 서로 역할이 나뉘어 있고 각각 자신의 입력 타입을 가진다.
워크플로우를 점검할 때는 선의 시작점과 끝점에 표시된 타입을 보면 어느 구성 요소가 어디로 가는지 파악하기 쉽다.
FLUX 이미지 편집에서는 VAE가 입력에도 쓰인다
FLUX 기반 이미지 편집이나 inpainting 계열 워크플로우로 넘어가면 VAE의 역할이 마지막 Decode에만 머물지 않는다.
실제로 적용할 때 체크할 점
공식 FLUX Fill 계열 워크플로우에서도 VAELoader에서 불러온 ae.safetensors가 여러 VAE 처리 단계로 연결된다. 입력 이미지를 latent로 바꾸는 과정이 있기 때문이다.
이 구조는 일반 img2img와 같은 원리다. 픽셀 이미지를 latent로 변환할 때 VAE가 필요하고, 생성이 끝난 latent를 다시 이미지로 복원할 때도 VAE가 사용된다.
따라서 FLUX text-to-image에서는 우선 VAEDecode 연결을 보고, 이미지 편집 워크플로우라면 VAE 출력이 입력 이미지 처리 쪽에도 연결되는지 함께 확인하면 된다.
다른 모델의 VAE와 혼용하지 않는다
FLUX 공식 워크플로우에서 ae.safetensors가 사용된다고 해서 모든 생성 모델에서 이 파일을 공통 VAE처럼 사용하는 것은 아니다.
ComfyUI는 모델 계열마다 서로 다른 VAE 파일을 사용하는 워크플로우를 제공한다. 따라서 vae.safetensors, ae.safetensors처럼 이름이 비슷하다는 이유만으로 서로 바꿔 연결하면 안 된다.
공식 워크플로우의 VAE 구성을 먼저 맞춘다
특히 모델을 새로 설치했을 때는 배포 페이지나 공식 워크플로우가 어떤 VAE 파일을 요구하는지 먼저 보는 편이 안전하다.
FLUX라면 공식 예제에서 지정된 ae.safetensors와 현재 사용 중인 diffusion model 구성을 먼저 맞춘 뒤 다른 VAE를 실험하는 순서가 원인을 구분하기 쉽다.
FLUX VAE 사용법은 세 연결만 보면 된다
FLUX 분리형 ComfyUI 워크플로우에서는 VAE가 체크포인트 내부에서 자동으로 따라오는 구조라고 생각하지 않는 편이 이해하기 쉽다. ae.safetensors를 models/vae에 준비하고 VAELoader에서 선택한 뒤 VAEDecode에 연결하면 된다.
동시에 diffusion model과 text encoder는 각각 별도의 loader에서 관리한다. FLUX 워크플로우를 열었는데 VAE 연결이 헷갈린다면 먼저 VAELoader → VAEDecode → Save Image 흐름부터 확인하자. 그다음 이미지 편집 작업이라면 Encode 쪽 VAE 연결까지 확장해서 보면 된다.