KV_Edit_Load_LoRA

KV_Edit_Load_LoRA is the optional middle stop between KV_Edit_Load and the conditioning nodes. Its one job: take the MODEL_KVEDIT you just loaded and merge a Flux LoRA into its weights. It's a thin node, but it's the reason the pack's own example workflow is fast, so it's worth understanding rather than skipping.

The example (kv0930.json) wires in flux-turbo.safetensors at scale 1.0. That's the acceleration LoRA - the README's changelog literally says the update added "加速lora支持" (accelerated LoRA support). Flux Turbo is a distilled/speed fine-tune distilled into LoRA form, the same family of trick the KB's distillation essay covers: fewer steps, same destination, some fine-detail cost. With it loaded, the example runs the sampler at 10 steps instead of 28. If you skip this node you're not broken - you're just slow.

The other thing LoRAs give you is style/character control, since this is Flux dev and the whole LoRA economy applies. One catch from the KB's LoRA panel: LoRAs are architecture-bound. This node merges into a Flux.1 dev transformer, so a Flux LoRA only - an SDXL LoRA will silently do nothing, and no it won't work on your Flux 2 files either.

How it works

This is not ComfyUI's usual LoraLoader, which patches activations on the fly. The source shows a plain weight merge: it loads the safetensors from your loras folder, finds every lora_up/lora_down pair, computes down @ up * scale, and does an in-place copy_ into the model's state dict. By the time the sampler runs, the LoRA is baked into the weights.

Three inputs, one output:

• model (MODEL_KVEDIT) - chain this straight after KV_Edit_Load.
• lora_name - dropdown of your ComfyUI/models/loras folder. "none" passes the model through untouched.
• lora_scale (0–2, default 1) - merge strength. 1 is the sane start; push toward 2 only if the LoRA feels weak, and if a LoRA was trained to be used at 1.0, leaving it there is usually correct.

Output: model (MODEL_KVEDIT), same type it got, ready for KV_Edit_PreData.

Install

Same as the rest of the pack - it ships inside ComfyUI_KV_Edit, so installing the pack (ComfyUI Manager search "ComfyUI_KV_Edit", or git clone https://github.com/smthemex/ComfyUI_KV_Edit into custom_nodes + pip install -r requirements.txt) gives you this node too. The LoRA itself goes in ComfyUI/models/loras.

Two gotchas worth knowing

It fails quietly. If a LoRA's keys don't match the Flux state dict conventions (lora_up/lora_down), the code catches the error, prints "Failed to apply LoRA" to the console, and returns the model unchanged. No red node, no exception - so if your edit looks exactly like the no-LoRA version, check the terminal before you assume the LoRA is weak.

Re-running compounds the merge. Because the delta is added to the current weights, queueing the same workflow twice without reloading the model layers a second dose of the LoRA on top of the first. If your image gets weirdly over-styled after the second run, reload the workflow (or re-run KV_Edit_Load) before touching the scale slider. Not a bug you'll hit in normal use, but it explains a confusing result when you're iterating.

That's the whole node. It merges one Flux LoRA into your KV-Edit model, "none" passes through, and it's where the pack gets its speed from - small, but load the turbo LoRA and suddenly the 12B model edits feel snappy.