Flux Train Block Select

This is a power-user node. It lets you restrict LoRA training to specific blocks inside Flux's transformer instead of adapting the whole model - a "train only these layers" instruction. Most people never need it, and that's fine: the default full-network LoRA is what the recipes assume. But if you're deliberately building a tiny, targeted LoRA or experimenting with which parts of Flux carry style versus structure, this is the node that gives you that scalpel.

Fair warning up front: this is the deep end of an already-experimental pack. There's no beginner mode here, no preset that says "single-block style LoRA." You type block names, and you're expected to know what they mean.

Why you'd reach for it

Flux is a transformer with a stack of blocks (the double-stream and single-stream blocks that make up its architecture). A normal LoRA hangs adapters across all of them. Training only a subset does two things: it shrinks the LoRA dramatically, and it concentrates learning in whichever layers you chose. The community interest in "single block" and few-block Flux LoRAs comes from exactly this - people found that some concepts, particularly style, can be captured by adapting a surprisingly small slice of the network, producing featherweight LoRAs. This node is how FluxTrainer exposes that.

It's a technique, not a default. If you don't have a specific reason to limit blocks, don't - you're trading capacity for size, and for most character or subject LoRAs you want the capacity.

The input that matters

There's exactly one input:

• include - a text field naming the block(s) to train. The default shown is lora_unet_single_blocks_20_linear2, which is a concrete example of the naming scheme: it targets one linear projection inside single-block index 20. You edit this to list the blocks you want to include in training. It's a multiline field, so you can specify more than one.

The output is block_args (type ARGS), which plugs into the training-init node alongside the pack's other optional config bundles. Connect it and the run restricts LoRA training to what you named; leave it unconnected and you get the standard full-network behavior.

Installing ComfyUI-FluxTrainer

ComfyUI Manager: search "ComfyUI Flux Trainer", install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-FluxTrainer
cd ComfyUI-FluxTrainer
pip install -r requirements.txt

Restart ComfyUI. Torch 2.4.0 or newer recommended. Example workflow uses ComfyUI-KJNodes.

Common issues

The block names have to be exact. The include string has to match FluxTrainer's internal naming, and a typo doesn't do something friendly - at best it selects nothing useful, at worst the run errors or trains a LoRA that does nothing. Copy the naming pattern from the default (lora_unet_single_blocks_<n>_...) rather than inventing names, and test small.

It's easy to over-restrict. Limit training to one tiny linear layer and you may find the LoRA simply can't learn your subject - there isn't enough capacity in the slice you left it. If a block-selected run refuses to converge, the first fix is to include more blocks, not more steps. This node is a trade: smaller, more surgical LoRAs in exchange for less to learn with.

This is uncharted territory, and the pack says so. Kijai's README is explicit that the whole thing is experimental and the defaults aren't gospel. Block selection especially is where you're expected to poke around and see what happens. Treat it as an experiment with a fixed dataset and seed so you can actually read the results - change the blocks, hold everything else, compare. If you just want a good LoRA and don't have a block hypothesis to test, skip this node entirely and train the full network.