comfyUI-Realtime-Lora claims 33 nodes, lists 34, and bundles none of its three trainers

Training is handled by external tools in their own venvs

The pitch is that this trains LoRAs on the fly from your images without leaving ComfyUI, and the whole toolkit is presented as one unified interface across three training backends. The dependency file says something narrower. It contains no packages at all, three comment lines explaining that the node uses only standard ComfyUI dependencies, torch, PIL and numpy, and then the sentence that matters: training is handled by external tools, AI-Toolkit and sd-scripts, in their own venvs. So the backends are not vendored, not installed and not version-pinned by this pack. The three named trainers are Kohya sd-scripts for SDXL and SD 1.5, Musubi Tuner for Z-Image, Z-Image Base, FLUX Klein 4B and 9B, Qwen Image, Qwen Image Edit and Wan 2.2, and AI-Toolkit as the alternative path for FLUX.1-dev, Z-Image and Wan 2.2. Each needs its own environment before any trainer node will do anything.

The node inventory says 33 and its own parts sum to 34

The headline count and the breakdown under it do not agree. The README states 33 nodes total, then lists 10 trainer nodes, 15 selective loaders described as 6 V1 plus 9 V2 combined, 2 analyzers as V1 and V2, 6 model layer editors and 1 utility node. Those five numbers add to 34, one more than the total printed above them. The gap is not only arithmetic. The repository root contains node files the inventory never mentions at all: a FLUX VAE debiaser and inspector, a FLUX Klein debiaser, a Z-Image deep debiaser, and four Qwen3 text-encoder debiaser and inspector pairs split across 4B and 8B variants, which is eight files on their own. The packaging description does mention text-encoder debiasing and inspection tools, so the capability is acknowledged elsewhere, just not counted where the node total is stated.

The Wan example workflows load both noise models even when you trained one

Wan 2.2 uses a two-stage noise model, with the High variant handling early denoising steps and Low handling later ones, and the toolkit lets you train a separate LoRA for each or use Combo mode to train one LoRA across all noise steps that works with both. The technical note attached to that feature describes an inefficiency in the shipped workflows. When you use High or Low mode, the example workflows still pass the LoRA to both models, at zero strength for the one you did not train, because that is what prevents ComfyUI from loading the base model into memory first. So a single-noise-mode setup carries the weight of two models, and the zero-strength entry is a loading guard rather than a no-op. The README states the mechanism but does not quantify the memory cost of the workaround.

batch_size is pinned to 1 for every SDXL VRAM preset

Two SDXL changes are listed together under training improvements, and they pull in opposite directions. One adds a `--no_half_vae` option to work around NaN errors with some SDXL checkpoints, which is a fix. The other fixes `batch_size` to 1 for all VRAM presets for stability, which is a constraint. A fixed batch of one means every SDXL training run through this toolkit processes one image per optimiser step regardless of how much VRAM the preset assumes is free, so the throughput ceiling is a property of the code rather than of your hardware. The two figures given elsewhere, a few minutes for SDXL and roughly two minutes for 500 steps of SD 1.5 on a 5090, are therefore best read as single-image timings. Nothing in the visible documentation offers a flag to raise the batch size back.

Strength scheduling is keyframed, and Save Refined LoRA writes the filtered result out

The V2 combined nodes merge analysis and selective loading into one node and add the scheduling layer. Strength scheduling applies a LoRA at different strengths during generation using keyframes, with more than 40 schedule presets covering fades, bell curves, pulses, step functions and inverted versions of the same. Save Refined LoRA exports the block-filtered result as a new file, which turns an in-graph experiment into a reusable artefact. Krea 2 block loading exposes 28 main SingleStreamBlocks and groups the non-main Linear layers under a single `other_weights` bucket, so Krea 2 is finer-grained than the other architectures in one respect and coarser in another. The loader also detects decompressed formats properly, covering standard LoRA with `lora_up` and `lora_down`, LoKR, LoHa and GLoRA, plus the AI-Toolkit, Kohya sd-scripts and Musubi Tuner formats, and the V2 nodes print the detected type in the analysis, for example `ZIMAGE (LoKR)`. Alongside the selective loaders sit six model layer editors, which scale individual blocks of the base model before any LoRA is applied, cover the six architecture families the pack supports, ship presets for common adjustments, add a user preset system you can save into and delete from, and write the modified base model out to disk. So the pack edits models as well as adapters, in both directions.

Block counts scale with model size, and Z-Image adds four more

Block-level loading is the part of the toolkit that is genuinely model-specific, and the counts are given per architecture. The FLUX Klein 4B analyzer and selective loader V2 see 25 blocks, split as 5 double and 20 single, while the 9B variant sees 32, split as 8 double and 24 single. The two doubles-and-singles splits are internally consistent, which is a small sign the numbers were measured rather than estimated. Z-Image adds four blocks outside the main sequence, giving control over `context_refiner`, `noise_refiner`, `final_layer` and `x_embedder`. The VRAM figures attached to the Klein models are roughly 13GB for the 4B and roughly 29GB for the 9B, with the 4B carrying an Apache 2.0 licence, and both use the Qwen3 text encoder and the FLUX.2 VAE. Training is on the base, undistilled versions of these models rather than the distilled releases. Block swapping is exposed as an independent control, separate from the resolution and fp8 settings, so VRAM can be tuned without touching image size. Z-Image follows the same pattern: training needs the de-distilled model, while the resulting LoRA works with the ordinary distilled Z-Image Turbo at inference, and a base-trained LoRA is readable by the existing V2 analyzer because the architecture is the same.

Forty files at the repository root, and no src directory

The layout is flat and it is the clearest sign of how the toolkit grew. Forty top-level entries include roughly thirty Python files, and the pattern is a matched pair per backend: a `*_config_template.py` and a `*_lora_trainer.py` for musubi_zimage, musubi_zimage_base, musubi_qwen_image, musubi_qwen_image_edit, musubi_wan and musubi_flux_klein, plus sd15 and sdxl pairs and a standalone `realtime_lora_trainer.py`. There is also a bare `config_template.py` at the root whose role beside six backend-specific ones is not explained. The Qwen3 text encoder tools are duplicated per size, four files for 4B and 8B, so a change to that logic has to be made twice. `web/` and `workflows/` hold the assets and the example workflows the technical note refers to. The packaging metadata declares version 2.1.9 under MIT with Python 3.10 or higher, registers the pack with ComfyUI through a PublisherId and the display name Realtime LoRA Toolkit, and leaves the registry icon field as an empty string. Its three project URLs all point at a repository path with a differently capitalised owner than the one this repository is served from, and no GitHub release exists for any version, so 2.1.9 is a manifest string with no tag behind it.

Editorial conclusion

Use this pack when you already have a working LoRA trainer installed and want its analysis, block-level selective loading and model layer editing inside ComfyUI, because those are the parts that need ComfyUI and nothing else. Do not expect the training half to work out of the box: `requirements.txt` states that training is handled by external tools in their own venvs, so sd-scripts, Musubi Tuner and AI-Toolkit are prerequisites you set up yourself, and the pack pins no version of any of them. Before you plan a schedule around it, check two constraints the README states plainly, that batch size is fixed at 1 across every VRAM preset for SDXL, and that the example Wan workflows still load both noise models even when you trained only one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. shootthesound/comfyUI-Realtime-Lora on GitHub