It is debatable whether this warrants being a custom node, but this is a standalone merge node designed for Krea2; no other nodes need to be connected to it.It blends two Krea2 models based on a specified ratio. The result is saved in BF16 format within the <code>output\diffusion_models\krea2</code> folder. You generally do not need to adjust the <code>fp8_scale_mode</code> setting.Merging older FP8 and BF16 models was straightforward because their layer structures were identical. However, with the recent trend toward quantization, Krea2—being a massive model—is often released only in quantized versions. The issue is that layer retention varies during quantization; there are many models with different layer configurations, even among those using the same FP8 scaled (e4m3fn) format. While a standard model has 430 layers, some can have as many as 1,102. This discrepancy arises because different people make different choices regarding which layers to quantize (which adds scaling information and increases the layer count) and which to leave in BF16.This node handles the merge by temporarily converting models—whether FP8, INT8, or NVfp4—back to FP32, performing the merge, and then saving the output in BF16 format. This allows for the merging of quantized models with different formats. If "Model 2" is left blank, the node simply converts "Model 1" to BF16 and saves it. Since processing and saving occur sequentially layer by layer, VRAM capacity is not a limiting factor, though a reasonable amount of system memory is required. The process runs on the CPU; in my environment, converting a single model's format took about 70 seconds, while merging NVfp4 and INT8 models took just under three minutes. While using the GPU to load both Krea2 models into VRAM would allow for blazing-fast speeds, doing so would drastically limit the number of users who could actually run it.・Locationmodel\merging\krea2・NoteGGUF format is not supported.

Files with SHA256: 1b8a89bcd22f55f31c5d188d3a3a9b911c7accb854611a465234f71f2d2667c8