SD3Multiply

The category this node lives under is doing a lot of the explaining for me: _for_testing/attention_experiments. That's the author's own filing, not mine, and it's an accurate warning label. SD3Multiply doesn't merge two checkpoints or fix a broken generation - it scales specific weight groups inside a single SD3 model by a scalar you choose, node-graph style. This is a probing tool for understanding what each piece of SD3's architecture actually contributes, not something you'd leave wired into a production workflow.

What it's scaling

SD3 (and SD3.5) use the MMDiT architecture - a Multimodal Diffusion Transformer, built from a stack of blocks that each process two parallel streams: a "context" stream carrying the text conditioning, and an "x" stream carrying the image latent, cross-informing each other at every layer. SD3Multiply exposes ten multipliers, one for each of these building blocks on both streams: attention (attn_qkv, attn_proj) and the feed-forward MLP (mlp_fc1, mlp_fc2) for both context_block and x_block, plus one adaLN_modulation_1 multiplier per stream - the adaptive layer-norm modulation that DiT-style architectures use to let the timestep and conditioning steer how each block behaves. Turn x_block_mlp_fc1 down and you're specifically damping how much the image stream's feed-forward layer contributes, uniformly, across every block in the model. It's a blunt instrument by design - every block gets the same multiplier, there's no per-layer targeting here (that's what its sibling, SD3BlocksMultiply, does instead).

The fields, and what's actually worth touching

All ten fields - context_block_attn_qkv, context_block_attn_proj, context_block_mlp_fc1, context_block_mlp_fc2, context_block_adaLN_modulation_1, x_block_attn_qkv, x_block_attn_proj, x_block_mlp_fc1, x_block_mlp_fc2, x_block_adaLN_modulation_1 - default to 1 (no change), with a 0–10 range. Leave most of them at 1 and change one at a time if you're actually trying to learn something from this - touching all ten simultaneously tells you nothing about which one mattered.

Input: model (a loaded SD3 checkpoint). Output: MODEL, scaled, wire it wherever the unmodified model would have gone.

Installing SP-Nodes

Through ComfyUI Manager: search "SP-Nodes," install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Restart afterward. No model download for this node - it reshapes weights already loaded in your graph, and there's nothing in the README suggesting an extra Python dependency for it.

Worth knowing before you touch it

SD3's own reputation is a factor here, not just the node's. The SD3 family shipped with well-documented anatomy problems at release, and CivitAI dropped the entire lineage from its platform in 2025 over a license change - Stability's own ecosystem never fully recovered community trust, and the going advice these days is to reach for Chroma or newer models for most work SD3 used to cover. That's not a reason to avoid this node specifically, but it does mean the model you're experimenting on is already a niche choice going in, and results from scaling its internals won't necessarily generalize to how other architectures (Flux, SDXL) would respond to the same kind of scaling - different architecture, different sensitivities.

Push any of these multipliers far from 1 and expect visible degradation - garbled composition, broken conditioning adherence, or outright noise, depending on which weight group you hit and how hard. That's the node doing exactly what it says; if you wanted a subtle nudge, use a value close to 1 (0.8–1.2 range) rather than the extremes the slider allows.