ModelMerger for ComfyUI (Chroma/Flux.1/SDXL/SD1.5/Qwen-image)
详情
下载文件
模型描述
Qwen ver.2
Qwen-image 版本的合并器被设计为尽可能轻量，因为原始模型体积庞大，但在前一版本中，加载过程极其沉重，必须通过ckpt加载器将三个巨大的ckpt文件载入工作流。Ver.2 已对此进行了大幅改进。此次我还准备了完整版。
输入时，仅将基础模型作为模型载入工作流；用于合并的模型信息仅接收文件路径，内部仅访问必要的部分。合并后的模型以BF16格式保存在VRAM中，因此无法避免占用大量显存。因此，我在采样器前加入了FP8转换节点。即使包含FP8转换，预览速度也应当更快。请参考上传图片中的工作流。在我的环境中，若保持BF16，VRAM占用约为48GB；转换为FP8后，降至约21GB。若放弃实时预览，则合并本身几乎不占用太多VRAM，此时消耗约为10GB，其中大部分是用于合并后预览的文本编码器。
除非VRAM空间充足，否则请勿使用可选的预加载设置。我的环境（32GB）不足以支持。此外，在ADA生成中，FP16和BF16的速度更快，因此尝试使用它们可能是不错的选择。通常情况下，您无需过于担心。
为连接路径，请使用同时安装的CheckpointPathPicker。
请注意，工作流已压缩以适应单屏截图，因此请勿将其作为参考模板。
Qwen-image 合并器
这是 Qwen-image 版本。
目前我仅上传了简化版。
是否有完整版的需求？
自从HiDream以来，我一直受制于模型体积过大。我曾询问ChatGPT是否可以分段下载模型，对方表示可行，于是我以此为原型开发了分段版本。该版本仍需约10GB VRAM，同时也会占用大量主内存，请注意。
支持FP8，但不支持GGUF。
FluxMerger 分块版（适用于低VRAM）
此版本使用更少的VRAM，但会占用更多主内存。在使用完整尺寸T5时，合并过程中的VRAM使用量约为11GB。然而，当传递至工作流中的KS采样器时，会以BF16大小（约27GB）消耗VRAM。为检查结果，建议在采样器前立即保存模型并重启ComfyUI，重启可通过ComfyUI Manager执行。
为降低内存消耗，各层进一步划分成块进行处理，但这并不会提升效果，反而可能略有负面影响。
注意：此版本以更多主内存换取更少VRAM，导致合并速度变慢。仅当标准版本无法满足您的VRAM需求时，请使用此版本。
SD15 FineMerger
这是专为SD1.5设计的ComfyUI模型合并节点，基于SDXL的经验进行了简化。
功能上与之前模型几乎一致：可为每一层指定权重，支持加权合并、AddDifference 和 TrainDifference 合并方式，并新增以下功能：
- 可为整个模型的attn1和attn2应用全局缩放因子。
- 可同时调整IN和OUT层的缩放因子（据我理解，MID即IN12）。
我个人认为这些功能非常实用。若仅想增强OUT的attn1，请采用多阶段方法。
示例工作流使用了五个模型和三个块合并器。在使用最占内存的TrainDiff时，分四批显示稍大图像，最大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阶段的视觉Transformer被划分为三个阶段，允许您指定权重。
此外，还可连接第二个滑块。第二个滑块专门用于某一层Transformer，允许您指定attn1、attn2和ff/norm的比例。其应用值会乘以第一个滑块的值。通过这些获得的alpha值，可采用三种模式合并：加权（标准合并）、AddDifference 和 TrainDifference。alpha值处理方式和合并模式基于SuperMerger（alpha值与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中按下“释放模型与节点缓存”按钮。
Flux.1 合并器
此前我发布 SimpleFluxMerger 时，仅使用Schnell，不确定其是否与dev版本完全兼容。此后，ComfyUI的内存行为变得不稳定，即便我拥有16GB显卡，生成图像也变得困难。
这一问题延续至今。过去无需深思熟虑即可流畅运行，如今即便精心优化，运行速度仍极慢。您至少需要一块支持Flux.1的GPU和64GB主内存。
合并过程中约消耗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（可被Checkpoint Loader读取）的工具。非必需，但非常有用。
注意：
滑块值基于SuperMerger等设定：α=1 表示将Model B设为100%，这与ComfyUI相反。
不支持GGUF（可能也不支持NF4？）。由于延迟加载，模型加载后无法正确访问文件本身，导致信息无法获取。请提前将其扩展为标准safetensors格式（参见：https://github.com/purinnohito/gguf_to_safetensors）。
作为Chroma发布的模型包含多种不同张量形状的混合。我本欲实现自动调整，但消耗过多内存并引发合并问题，最终放弃。我也上传了一个用于检查张量形状的工具。
该模型会消耗大量主内存和显存。虽然设计上应比Flux.1更紧凑，但Flux.1由于所有内部处理均在BF16下进行，内存占用更低。ChromaMerger虽使用BF16以减少内存消耗，但其显存需求却高于Flux.1，可能是因为采样器及其他程序中存在FP32扩展。内存泄漏警告属于正常现象。总计约占用45GB共享内存，请提前确认可用容量。
指定为模型B的模型会被加载至显存（模型A和C位于主内存）。请检查GPU显存容量及经过BF16转换的模型大小（通常约为11GB）。
从第二次开始，内存消耗会进一步增加。这似乎是ComfyUI的正常行为，但请注意，之前使用的模型会保留在显存中，尤其会显著减慢采样器速度。通常建议重启ComfyUI以提升效率。若使用ComfyUI Manager，请在继续操作前务必点击“释放模型和节点缓存”按钮。
开发环境为64GB主内存 + 32GB显存。在低内存GPU上运行无法保证稳定性。代码主要由ChatGPT 4.1生成。如遇任何问题，请将代码提交至ChatGPT寻求帮助。
与Flux.1相比，本模型出现了多种新问题。因此，尽管使用环境受限、可用性不高，但现已能够实现基本处理。
请注意，若在Flux.1上使用LoRA，该平台的许可协议可能仍然适用。