ModelMerger for ComfyUI (Chroma/Flux.1/SDXL/SD1.5/Qwen-image)
세부 정보
파일 다운로드
모델 설명
Qwen ver.2
Qwen-image 버전의 병합기는 모델이 크기 때문에 가능한 한 가볍게 만들기 위해 제작되었습니다. 그러나 이전 버전에서는 ckpt 로더를 사용하여 워크플로우에 세 개의 거대한 ckpt를 로드해야 할 정도로 매우 무거웠습니다. ver.2는 이 부분이 크게 개선되었습니다. 이번에는 전체 버전도 함께 준비했습니다.
입력 시, 워크플로우에는 기본 모델만 모델로 로드되고, 병합에 사용되는 모델 정보는 파일 경로만 전달받아 내부에서 필요한 부분만 접근합니다. 병합된 모델은 VRAM에 BF16 상태로 배치되므로 무거워지는 것은 어쩔 수 없습니다. 따라서 샘플러 앞에 FP8로 변환하는 노드를 배치했습니다. FP8 변환을 포함하더라도 미리보기 속도가 더 빠를 것이라 생각합니다. 업로드된 이미지에 나와 있는 워크플로우를 참조하세요. 제 환경에서는 BF16 상태로 유지할 때 VRAM 사용량이 약 48GB였고, FP8로 변환한 후에는 약 21GB였습니다. 실시간 미리보기를 포기한다면 병합 자체에 VRAM을 크게 사용하지 않습니다. 이 단계에서는 약 10GB 정도 소비되며, 그 대부분은 병합 후 미리보기용으로 사용되는 텍스트 인코더입니다.
충분한 VRAM 공간이 없는 한 선택적 프리로드 설정을 사용하지 마세요. 제 환경(32GB)에서는 부족했습니다. 또한 FP16 및 BF16은 ADA 생성 시 더 빠르므로 시도해보는 것이 좋습니다. 일반적으로 별다른 걱정은 필요 없습니다.
경로를 연결하려면 동시에 설치된 CheckpointPathPicker를 사용하세요.
워크플로우가 한 화면에 맞춰 압축되어 있으므로 참고용으로 사용하지 마세요.
Qwen-image Merger
이것은 Qwen-image 버전입니다.
현재 간단한 버전만 업로드했습니다.
전체 버전에 수요가 있나요?
HiDream 이후로 모델의 크기에 계속 고민해왔습니다. ChatGPT에 모델을 부분적으로 다운로드할 수 있는지 물어보았고, 가능하다고 답했습니다. 그래서 이 부분 버전을 프로토타입으로 만들었습니다. 여전히 약 10GB의 VRAM을 사용합니다. 메인 메모리도 상당량 사용하므로 주의하세요.
FP8는 지원하지만, GGUF는 지원하지 않습니다.
FluxMerger Chunked (낮은 VRAM용)
이 버전은 VRAM을 덜 사용합니다. 대신 메인 메모리를 더 많이 사용합니다. 전체 크기의 T5를 사용할 때 병합 시 VRAM 사용량은 약 11GB입니다. 그러나 워크플로우에서 KSsampler로 전달되면 BF16 크기(약 27GB)로 VRAM을 소비합니다. 결과를 확인하려면 샘플러 직전에 모델을 저장하고 ComfyUI를 재시작하는 것이 빠릅니다. 재시작은 ComfyUI Manager에서 수행됩니다.
메모리 소비를 줄이기 위해 레이어를 더 작은 청크로 분할하여 처리하지만, 이는 효과를 향상시키지 못합니다. 오히려 약간의 부정적 영향을 줄 수 있습니다.
참고: 이 버전은 VRAM 사용을 줄이기 위해 메인 메모리 사용을 늘리므로 병합 속도가 느립니다. 표준 버전으로 충분한 VRAM이 없는 경우에만 이 버전을 사용하세요.
SD15 FineMerger
이것은 SD1.5용 ComfyUI 모델 병합 노드입니다. SDXL에서 배운 교훈을 바탕으로 간소화되었습니다.
기능적으로 이전 모델들과 거의 동일합니다. 각 레이어에 가중치를 지정하고 가중치 합성, adddiff, traindiff를 사용해 병합할 수 있습니다. 몇 가지 새로운 기능도 포함되었습니다:
모델 전체의 attn1과 attn2에 글로벌 스케일링 계수를 적용할 수 있습니다.
IN 및 OUT 레이어의 스케일링 계수를 동시에 조정할 수 있습니다(제가 이해하기로는 MID는 IN12입니다).
개인적으로 이 기능들이 매우 유용하다고 생각합니다. OUT attn1만 증가시키고 싶다면 여러 단계 접근법을 사용하세요.
예제 워크플로우는 5개의 모델과 3개의 블록 병합기를 사용합니다. 메모리 사용량이 가장 큰 traindiff를 사용하여 4개의 배치로 약간 더 큰 이미지를 표시할 때, 최대 VRAM 사용량은 17GB였습니다. 그러나 모델 및 노드 캐시를 모두 지운 후에도 6GB를 사용했으므로 실제 사용량은 약 11GB입니다.
기능 확인을 위해 만들었지만, 지금 예제 워크플로우를 보면 매우 이상해 보입니다... 이 모델은 다른 예제들보다 더 의미가 있지만, 처음에는 NAI2 출시 이전에 만들어진 Beyond에 NAI2 요소를 추가하고, 그 후 SimpleRetro의 하위 레이어의 음성 traindiff를 혼합하여 Astaroth의 사진적 표현을 강화하려는 실험에서 시작되었습니다. 사용한 값은 극단적으로 크거나 작지만, 실제 사용에는 보다 온건한 값이 안전합니다.
SDXL FineMerger
이것은 SDXL 1.0 버전의 모델 병합기입니다.
사실 저는 SDXL을 거의 사용해보지 않아 핵심 포인트를 잘 모르겠습니다. 모델 구조도 극단적이며, 레이어의 세밀도가 너무 달라, 사람들이 어떻게 제어했는지 의문이었습니다. 이번에 약간 실험해보니, SD1.5에서는 세 개의 레이어로 처리하던 것을 이제는 하나의 레이어로 처리할 수 있다는 점을 느낄 수 있었고, 개선점을 확인했습니다.
SDXL은 SuperMerger를 사용할 수 있으며, ComfyUI에는 이미 SDXL 블록 병합 노드가 있으며, 파라미터 수가 그렇게 많지 않아 단순 버전이 필요하지 않습니다. 이번에는 이전 버전들과 달리, 더 세밀한 제어를 가능하게 하는 기능을 시도했습니다.
아래는 주요 슬라이더의 구성입니다.
time_embed., label_emb.
input_blocks.0.(128)
input_blocks.1.(128)
input_blocks.2.(128)
input_blocks.3.(128)
input_blocks.4.(64)
input_blocks.4.B0.(64)
input_blocks.4.B1.(64)
input_blocks.5.(64)
input_blocks.5.B0.(64)
input_blocks.5.B1.(64)
input_blocks.6.(64)
input_blocks.7.(32)
input_blocks.7.B0-2.(32)
input_blocks.7.B3-5 .(32)
input_blocks.7.B6-9.(32)
input_blocks.8.(32)
input_blocks.8.B0-2.(32)
input_blocks.8.B3-5.(32)
input_blocks.8.B6-9.(32)
middle_block.0.(32)
middle_block.1.(32)
middle_block.1.B0-2.(32)
middle_block.1.B3-5.(32)
middle_block.1.B6-9.(32)
middle_block.2.(32)
middle_block.2.B0-2.(32)
middle_block.2.B3-5.(32)
middle_block .2.B6-9.(32)
output_blocks.0.(32)
output_blocks.0.B0-2.(32)
output_blocks.0.B3-5.(32)
output_blocks.0.B6-9.(32)
output_blocks.1.(32)
output_blocks.1.B0-2.(32)
output_blocks.1.B3-5.(32)
output_blocks.1.B6-9.(32)
output_blocks.2.(32)
output_blocks.2.B0-2.(32)
output_blocks.2.B3-5.(32)
output_blocks.2.B6-9.(32)
output_blocks .3.(64)
output_blocks.3.B0.(64)
output_blocks.3.B1.(64)
output_blocks.4.(64)
output_blocks.4.B0.(64)
output_blocks.4.B1.(64)
output_blocks.5.(64)
output_blocks.5.B0.(64)
output_blocks.5.B1.(64)
output_blocks.6.(128)
output_blocks.7.(128)
output_blocks.8.(128)
out, sampling_sigma, noise_augmentor.
조정할 가치가 없어 보이는 설정들은 그룹화했습니다. 레이어 내 하위 블록마다 가중치를 지정할 수 있습니다. 이 기능만으로도 이전 병합기보다 더 정밀한 제어가 가능합니다. 또한 괄호 안의 숫자는 Unet에서 해당 레이어가 처리하는 이미지 크기입니다. 저는 이 정보가 나머지 내용을 파악하는 데 도움이 될 것이라 생각해 추가했습니다.
하지만 세부 수준이 하나 낮아졌기 때문에, Transformer 레이어로 보완하지 않으면 SD1.5보다 덜 정밀합니다. 여기서 10단계 Vision Transformer를 3단계로 그룹화하여 가중치를 지정할 수 있습니다.
또한 두 번째 슬라이더도 연결할 수 있습니다. 두 번째 슬라이더는 특정 Transformer 레이어에 특화되어 attn1, attn2, ff/norm 비율을 지정할 수 있습니다. 적용된 값은 첫 번째 슬라이더의 값과 곱해집니다. 이 방법으로 얻은 알파 값은 세 가지 모드로 병합할 수 있습니다: Weighted(일반 병합), AddDifference, TrainDifference. 알파 값과 병합 모드의 처리는 SuperMerger에 기반합니다(알파 값은 ComfyUI와 반대로 0과 1로 설정됩니다).
컨트롤러 노드 없이도 병합이 가능하며, 컨트롤러 노드 슬라이더의 기본값은 1(=비활성)이므로, 수정하고 싶은 설정만 조정하면 됩니다.
input_blocks.4.attn1
input_blocks.4.attn2
input_blocks.4.ffnorm
input_blocks.5.attn1
input_blocks.5.attn2
input_blocks.5.ffnorm
input_blocks.7.attn1
input_blocks.7.attn2
input_blocks.7.ffnorm
input_blocks.8.attn1
input_blocks.8.attn2
input_blocks.8.ffnorm
middle_block.1.attn1
middle_block.1.attn2
middle_block.1.ffnorm
middle_block.2.attn1
middle_block.2.attn2
middle_block.2.ffnorm
output_blocks.0.attn1
output_blocks.0.attn2
output_blocks.0.ffnorm
output_blocks.1.attn1
output_blocks.1.attn2
output_blocks.1.ffnorm
output_blocks.2.attn1
output_blocks.2.attn2
output_blocks.2.ffnorm
output_blocks.3.attn1
output_blocks.3.attn2
output_blocks.3.ffnorm
output_blocks.4.attn1
output_blocks.4.attn2
output_blocks.4.ffnorm
output_blocks.5.attn1
output_blocks.5.attn2
output_blocks.5.ffnorm
이를 만들고 나서 너무 세밀한 것 같다는 생각이 들었습니다. 슬라이더 연결 방식을 테스트하기 위해 만들었으며, ComfyUI의 병합 노드에 만족하지 못한다면 사용해보세요.
HiDream DeltaLoRA 도구
HiDream 모델은 ComfyUI에서 병합 도구를 만들기에는 너무 컸습니다.
대신, 두 모델 간의 차이 LoRA를 생성하는 도구를 만들었습니다. 이 도구는 메모리를 많이 요구하지 않습니다. 그러나 전체 1615개 레이어 중 DoubleBlocks와 SingleBlock만 사용하더라도 모든 레이어의 차이를 취하면 LoRA의 크기가 엄청나게 커지므로, 매우 제한된 수의 레이어만 추출하는 데 사용하세요. 이 도구의 MODEL 출력은 차이를 고려하여 생성되므로, 저장하면 부분적으로 병합된 모델과 유사한 결과를 얻을 수 있습니다. 보다 정밀한 조정을 원한다면 LoRA로 사용하고 강도를 설정하세요.
이 도구는 CUDA 전용입니다. FP8(e4m3en 등)도 입력 파일로 사용할 수 있지만, 내부에서는 BF16으로 처리됩니다. GPU가 BF16을 지원하지 않으면 FP32로 변환됩니다.
*지속적으로 처리하려면 ComfyUI Manager에서 “Free model and node cache” 버튼을 누르세요.
Flux.1 Merger
이전에 SimpleFluxMerger를 발표할 때는 Schnell만 사용했기 때문에 dev 버전과의 호환성이 확신이 없었습니다. 이후 ComfyUI의 메모리 관련 동작이 불안정해져, 당시 사용하던 16GB 카드로 이미지 생성조차 어려워졌습니다.
이 문제는 오늘날까지 지속됩니다. 과거에는 별다른 고민 없이 만들어도 원활하게 실행되었지만, 지금은 신경을 많이 써도 느려집니다. Flux.1을 사용할 수 있고, 64GB의 메인 메모리를 갖춘 GPU가 필요합니다.
병합 시 약 30GB의 VRAM이 사용됩니다. RTX 5090과 호환되도록 설계되었지만, 그래도 이 정도를 사용합니다(거의 VRAM을 사용하지 않는 느린 버전도 만들었지만, 매우 느립니다). 많은 환경에서는 30GB의 공유 GPU 메모리로 실행 가능할 것입니다.
Chroma 버전과 마찬가지로 전체 버전과 간단 버전이 있고, 각각 세 개의 다른 초기값을 가진 노드를 제공합니다.
유의할 점은 대부분 Chroma 버전과 동일합니다.
일부 스크린샷은 SamplerCustomAdvanced를 사용하지만, 이는 메모리를 많이 소비하므로 병합에는 KSampler를 사용하는 것이 안전합니다.
*TrainDifference 동작 예시
ChromaMerger
Chroma 관련 도구가 적기 때문에, 이 병합 노드를 ComfyUI용으로 만들었습니다.
Chroma의 모든 레이어를 블록 병합할 수 있습니다. 슬라이더 범위는 -1에서 2이며, AddDifference 및 TrainDifference와 동일한 모드를 제공합니다.
CUDA 전용입니다. ComfyUI를 최신 상태로 유지하세요.
*간단 버전
각 버전에는 정식 버전(66개 슬라이더)과 간단 버전(19개 슬라이더)이 있으며, 초기 슬라이더 값만 다를 뿐 동작 방식은 동일합니다. 슬라이더 값을 수동으로 변경하는 것은 번거로울 수 있으므로, 한 번에 모두 변경하려면 새로운 초기값을 가진 버전을 로드하세요.
추가 도구도 포함되어 있습니다: 모델 구성을 콘솔에 표시하는 도구와, 모델의 Unet 부분을 Checkpoint(ckpt 로더에서 읽을 수 있는 형식)로 저장하는 도구입니다. 필수는 아니지만 유용할 수 있습니다.
참고:
슬라이더 값은 SuperMerger 등에 기반합니다. α=1은 Model B를 100%로 설정합니다. 이는 ComfyUI와 반대입니다.
GGUF는 사용할 수 없습니다(아마 NF4도 불가능?). 지연 로딩으로 인해 모델을 로드한 후 파일 자체에 접근할 수 없어 정보를 정확히 가져올 수 없습니다. 사전에 일반 safetensors 파일로 확장하세요(참조: https://github.com/purinnohito/gguf_to_safetensors).
Chroma로 공개된 모델들은 여러 다른 텐서 형태를 혼합하고 있습니다. 자동 조정을 목표로 했으나 메모리 사용량이 너무 많아 병합에 문제가 생겨 포기했습니다. 텐서 형태를 확인하는 도구도 함께 업로드했습니다.
이 모델은 주 메모리와 VRAM을 모두 많이 소모합니다. Flux.1보다 더 컴팩트해야 하지만, Flux.1은 내부 처리가 모두 BF16으로 이루어져 메모리 사용량이 적습니다. ChromaMerger는 메모리 소비를 줄이기 위해 BF16을 사용하지만, 샘플러 및 기타 프로그램에서 FP32 확장으로 인해 Flux.1보다 더 많은 VRAM을 요구합니다. 메모리 누수 경고는 정상적인 현상입니다. 총 약 45GB의 공유 메모리를 사용하므로 사전에 용량을 확인하세요.
모델 B로 지정된 모델은 VRAM에 로드됩니다(A 및 C는 주 메모리입니다). GPU 메모리 용량과 BF16으로 변환된 모델의 크기(일반적으로 약 11GB)를 확인하세요.
두 번째부터는 더욱 많은 메모리를 소모합니다. 이는 명백히 ComfyUI의 정상적인 동작이며, 이전에 사용된 모델들이 VRAM에 그대로 남아 있어 특히 샘플러의 속도를 저하시킵니다. 일반적으로 ComfyUI를 재시작하는 것이 더 빠릅니다. ComfyUI Manager를 사용 중이라면 진행하기 전에 반드시 "Free model and node cache" 버튼을 누르세요.
개발 환경은 64GB 주 메모리 + 32GB VRAM입니다. 저메모리 GPU에서의 운영은 보장되지 않습니다. 이 코드는 주로 ChatGPT 4.1이 생성했습니다. 문제가 발생하면 코드를 ChatGPT에 제출하여 도움을 요청하세요.
Flux.1에서는 발생하지 않았던 다양한 문제가 발생했습니다. 그 결과, 사용 환경이 제한적이며 사용성이 우수하지는 않지만, 최소한의 처리는 가능해졌습니다.
Flux.1에서 LoRA를 사용할 경우, 해당 플랫폼의 라이선스가 적용될 가능성이 있음을 유의하세요.