RunningHub_ZImageI2L_LoraGenerator

This is the node the whole pack exists for. Feed it a few reference images and a pipeline from the Loader, and it produces a real .safetensors LoRA in your models/loras folder. No dataset prep, no captioning, no hours of training on a rented 4090. It's Z-Image's "image-to-LoRA" (i2L) trick, wrapped as a ComfyUI node, and it's genuinely cool - with a caveat you should hear before you get excited.

The mechanism. This isn't training in the traditional sense. The node runs DiffSynth's ZImageUnit_Image2LoRAEncode then Image2LoRADecode on your images: the reference pictures get turned into embeddings, and the pipeline converts those embeddings into LoRA weights in one shot, then saves the result to models/loras under a random name like zimage_i2l_lora_<uuid>.safetensors. That's the trade-off in a nutshell - it's near-instant, but it's an approximation, not a fine-tune. The community assessment of Z-Image-i2L when it launched alongside Z-Image Base was that it copies style loosely rather than replacing proper LoRA training; it's great for a quick one-off style or pose reference, less so for a character you need consistent across forty generations. For that, you still train (Ostris AI Toolkit or OneTrainer on the Base model).

The three inputs that matter. There are only three, and you'll touch two of them:

• pipeline - the ZImageI2LPipeline socket from the Loader. Non-negotiable.
• training_images - an IMAGE tensor. Wire one Load Image, or batch several with ImageBatchMulti; the pack's own example workflow uses four. More images give the i2L encode more to work with, but the LoRA will be rough either way.
• seed (default 42) - a random seed for reproducibility. Bump it if the result feels off; it's the only dial you have.

The outputs. It returns both lora_name and lora_path. The neat part is lora_name is typed to match ComfyUI's normal LoRA dropdown - the node literally builds its return socket from folder_paths.get_filename_list("loras") so it plugs straight into a standard LoraLoader node. (There's a custom socket-type override in the source to keep that dropdown validation stable when the LoRA folder changes at runtime - an obscure corner, but it's why you can wire this to LoraLoader without fighting type errors.) lora_path is the full path for the pack's Saver node.

Where people get burned. First, the same unload-everything behavior as the Loader: this node evicts your currently loaded models from VRAM before it runs. Second, remember the generated LoRA belongs to the Z-Image family - the example workflow applies it to a Z-Image Base checkpoint, not SDXL or Flux. Third, the random filenames mean your models/loras folder accumulates zimage_i2l_lora_* files fast; delete the ones you don't love. And none of this is cheap to run - the whole i2L stack (including the DINOv3-7B encoder) is resident, so the pack's 24GB+ recommendation applies here too.

Install is the pack-wide two-step (ComfyUI Manager, searching "ComfyUI_RH_ZImageI2L", or git clone https://github.com/HM-RunningHub/ComfyUI_RH_ZImageI2L.git into custom_nodes, then pip install -r requirements.txt, then restart). Models auto-download from ModelScope on first use.

The honest take: as an instant "make this look like these four images" button, it's a fun and useful trick. As a production character pipeline, it's a stepping stone to real training. Use it for what it is and you'll be happy.