Illustrious Advanced Training Options

IllustriousTrainingOptions is a widget farm with one output. It's the pack's escape hatch for everything the trainer node didn't want to put on its own face: repeats, alpha, aspect buckets, optimizer, schedule, caption length, loss shaping, and the prompt for the sample image it renders every epoch.

It matters more than its name suggests. IllustriousSDXLLoRATrain has an optional advanced_options input, and if you don't wire this node into it, the trainer silently falls back to bare defaults that look nothing like the pack's documentation: no aspect buckets, no sample images, 75-token captions, constant learning rate, every image used once per epoch. Wire it, and you get the author's actual recommended set. That's the whole reason this node exists as a separate box - one place to configure a run, reusable across graphs.

The knobs that change the result

repeats (default 2) is how many times each image is fed in per epoch; it multiplies your step count (images × repeats × epochs ÷ batch ÷ accumulation). For SDXL, 100–200 steps per image is the traditional ballpark.

alpha (default 16) is independent of the trainer's rank, and effective scale is alpha ÷ rank - rank 16 / alpha 16 gives the 1:1 that modern trainer defaults have converged on, while rank 32 / alpha 16 halves it. The pack writes your alpha into the saved metadata and the Kohya .alpha tensors, because the Diffusers conversion would otherwise reset alpha to rank. If a LoRA feels too strong at weight 1.0, alpha is a cleaner lever than lowering rank.

buckets (on by default) plus bucket_min 256, bucket_max 1536, bucket_step 64: instead of squashing everything into a square, the trainer picks for each image the grid size with the closest log aspect ratio whose area fits under the resolution ceiling - ties go to the larger area - and batches images that landed in the same bucket together. Turn buckets off and everything becomes a plain square at the trainer's resolution. Whatever doesn't fit after resizing is center-cropped with no idea where your subject is, so framing is your problem. That's what the crop node is for.

optimizer is AdamW8bit or AdamW. 8-bit is the community default and cuts optimizer memory; it needs bitsandbytes, and if that import fails the pack raises rather than quietly falling back to full-precision AdamW. scheduler is cosine or constant, with warmup_percent (default 5) applied to the optimizer steps - a warmup is nearly free and prevents the first handful of steps from taking a wild swing at the weights.

Caption handling. max_caption_tokens is a 75 / 150 / 225 choice - one, two or three chunks of 75 content tokens through both frozen CLIPs, with anything beyond truncated. shuffle_caption shuffles the tags each epoch so the model stops treating tag order as a cue, and keep_tags (default 1) pins the first N in place - normally your trigger. Only raise the token limit for genuinely long captions; the pack notes its chunking isn't guaranteed bit-identical to other trainers'.

Loss shaping. min_snr_gamma (default 5) down-weights the noisy-high-timestep steps that otherwise dominate early training, and noise_offset (default 0.03) adds a spatially constant channel-wise offset to the noise, which helps dark and bright batches. Both are standard SDXL-era tricks and both are fine at these defaults; if you're the superstitious type, set them to 0 and compare on a fixed seed.

The sample settings, which are also a VRAM trap

samples (on by default) renders one image after every epoch with the current adapter, using an Euler ancestral sampler and a fixed sample_seed, then writes sample_epoch_###.png plus a JSON of the prompt and settings. sample_prompt defaults to masterpiece, best quality, 1girl, solo - quality tags plus a generic subject, matching the Danbooru-style prompting the Illustrious line expects. Put your trigger in there or the samples tell you nothing. sample_negative, sample_width (768), sample_height (1024), sample_steps (20) and sample_cfg (5) round it out; both dimensions must be multiples of 64.

The trap: sampling costs VRAM and time, and if sample generation fails the job stops. Job fails, you lose the run - which is exactly the wrong trade on a small GPU. Turn samples off, get your adapter, then re-enable it when you know your VRAM headroom.

Outputs are options, which wires to the trainer's advanced_options input, and report - the same values echoed back as JSON. Keep the report next to the adapter; six weeks later it's the only record of what you actually ran.

Install

Manager, searching ComfyUI-IllustriousLoRATools (Illustrious LoRA Tools), or:

cd ComfyUI/custom_nodes
git clone https://github.com/katorikonoe-ai/ComfyUI-IllustriousLoRATools
pip install -r ComfyUI-IllustriousLoRATools/requirements.txt

Requirements into ComfyUI's Python, CUDA PyTorch preserved, native/ + web/ + crop_routes.py kept together, then restart. Find it under Katori/Illustrious Native Training.

Where people get burned

Validation is strict and it's on your side: bucket limits have to be multiples of the bucket step, bucket_min can't exceed bucket_max, the minimum bucket's area can't exceed the training resolution's, sample dimensions must be multiples of 64, and unknown keys are rejected. You get an error, not a silently ignored field.

The real footgun is the unwired case described above - an options node sitting on the canvas, unconnected, doing nothing while the trainer runs defaults you didn't choose. If your run produced no samples and had no aspect bucketing, that's what happened.