FLUX.2 [klein] 4B Style LoRA Training

If you've ever tried to train a LoRA on FLUX locally, you know the drill: one more VRAM math session, one more pip install of a trainer that fights your Python environment, one more overnight run that dies at step 800 because you misread the learning rate. This node deletes that whole category of pain. You give Runware a ZIP of images and a trigger word, it trains a style LoRA on FLUX.2 Klein 4B in its own cloud, and it hands you back a file path.

The trade is the same as every node in this pack: you're paying per run and sending your dataset somewhere else. What you get in return is genuinely useful - FLUX.2 Klein is BFL's size-distilled consumer line, and the 4B is the one with the good news for you commercially: it's Apache 2.0, so LoRAs you train on it don't inherit the non-commercial restrictions of the 9B or the Dev tiers. That makes this the safe default for style work you might actually ship.

How it works

This is a training node, not an inference node - it lives under Runware/Training/runware. You drop in a dataset and parameters, Runware runs the optimization steps remotely, and when it finishes the finished LoRA is downloaded to your ComfyUI output folder with the path returned as the file_path output (STRING). That path is what you feed to whatever loads the LoRA at inference time (or, more likely on Runware, you register it via the Runware Import Model flow and pull it into a Runware LoRA builder).

Two inputs are required:

• dataset - a ZIP file, given as a UUID or URL, containing your training images. Each image can be paired with a .txt caption file of the same filename; that's optional, but it's how you teach the model what to leave variable.
• importModel - a RUNWARE_IMPORTMODEL socket, fed by the Runware Import Model builder node (Runware/Params). You give the model a name, an AIR, and a visibility/private setting; this is how your freshly trained LoRA becomes a first-class model in your Runware library that the LoRA builder nodes can reference.

The knobs that actually change your result:

• trainingSteps - default 1000, up to 4000. Style LoRAs from small-ish datasets land in this range; more steps isn't automatically better.
• learningRate - default 5e-05. That's squarely in the sane zone for modern architectures; the old "big LR, small batch" SDXL instinct is exactly backwards here.
• triggerWord - the word you'll use at inference to summon the style. Worth choosing something rare.
• checkpoint - an AIR of a LoRA you previously trained on Runware, to resume training from its final state. Note the constraint baked into the tooltip: only Runware-trained LoRAs work here, not ones you trained elsewhere.

Dataset reality check

The LoRA-training playbook that still holds: for a style, you want 30–100 images, diverse subjects, one consistent aesthetic - and caption what you want to stay variable while leaving the fixed parts undescribed. A 1000-step run on a decently curated set is a reasonable starting point; save early epochs, because the last one is rarely the best.

Installing and gotchas

Same story as every node in this pack: install Runware/ComfyUI-Runware via ComfyUI Manager (search "Runware") or clone it into custom_nodes and pip install -r requirements.txt, then restart. There are no heavy model downloads - the training happens remotely.

The real gotchas are the account ones: you need a Runware API key (Settings → Runware API key, RUNWARE_API_KEY, or runware auth login), and training is a billed service with real compute, so the cost shows up on the node title bar after each run. And remember the resume constraint - if you trained a LoRA locally and want to continue it here, you can't; the checkpoint must have been trained on Runware.