LongLive-Plug Apply Adapter Pair

A 50-step, CFG 5 Wan2.1-T2V-14B run at 832×480 and 81 frames takes about 15 minutes on a 5090. The README for this pack measured 932 seconds in the sampler stage alone. That's the number distillation exists to fix, and it's why NVlabs' LongLive-Plug project ships two LoRAs per backbone: one to collapse the step count, one to collapse the guidance.

Here's the part that trips people up. You cannot just drop both into two LoraLoader nodes and set steps=4. The adapters were distilled to run at runtime CFG 1.0 with conditional-only passes, at specific weights (Few-Step 1.0, CFG 0.5), against a specific scheduler. Get any of those wrong and you get the mushy, ghosted output that makes people conclude "4-step video looks bad." LongLive-Plug Apply Adapter Pair handles the apply half of that problem and then hands you a JSON receipt telling you exactly what it did.

What it actually does

This is one of exactly two nodes in hiroki-abe-58/ComfyUI-LongLive-Plug, an unofficial community integration - not NVIDIA, not the Wan team, not Comfy Org. Apache-2.0, no extra Python dependencies, and it wants ComfyUI 0.38.0 or newer.

It patches a clone of your model, so the original stays clean and you can branch. Before it patches anything it checks a lot: that the state dict actually matches the wan2.1-t2v-14b profile (40 blocks, dim 5120, patch size 1×2×2), that each file is one of the pinned releases, that rank and alpha are sane, that you didn't swap the two adapter slots, and that every one of the 400 expected targets per adapter exists at the right shape. Both pinned adapters are rank 128 / alpha 128, so the merge rule in the report collapses to W + weight × B@A, accumulated in float32 and rounded back to the base dtype.

The coverage report is the actual selling point. It reports patches_applied and an application_rate against targets_expected - the README's wording is 400/400 on Wan2.1-T2V-14B. A silently half-applied LoRA is one of the nastier failure modes in ComfyUI, and this node refuses to let it be silent.

Inputs you'll touch

You'll set four things. few_step_lora and cfg_lora are dropdowns pulled from your loras folder. few_step_weight defaults to 1.0 and cfg_weight to 0.5 - note the tooltip on that second one: it's the LoRA weight, not the sampler CFG scale. That distinction is the whole reason this node exists. Leave profile on wan2.1-t2v-14b (it's the only choice) and leave verify_sha256 on unless you're iterating fast - it reads both adapters, about 3.6 GB, once per session.

Two outputs: model, which goes to the sampler path, and report, a string you can park in a PreviewAny or a Note node.

Install

Same steps for both nodes in the pack. ComfyUI Manager, search LongLive-Plug (listed as "LongLive-Plug for ComfyUI"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/hiroki-abe-58/ComfyUI-LongLive-Plug

Or comfy node install longlive-plug. Then restart ComfyUI.

You need the model files too, and the README pins exact revisions:

| Folder | File | | --- | --- | | diffusion_models | wan2.1_t2v_14B_bf16.safetensors | | text_encoders | umt5_xxl_fp16.safetensors | | vae | wan_2.1_vae.safetensors | | loras | LongLive-Plug-Wan2.1-T2V-14B-few-step.safetensors | | loras | LongLive-Plug-Wan2.1-T2V-14B-cfg.safetensors |

Start ComfyUI with --bf16-unet --bf16-text-enc --fp32-vae to match what was tested. Without the flags, ComfyUI 0.38.0 picked fp16 for the DiT and text encoder on the author's machine.

Where people get burned

Quantized bases are refused on purpose. Comfy-Org's wan2.1_t2v_14B_fp8_scaled is rejected, and GGUF/tensor-subclass weights are rejected by class. The patch path for quantized weights isn't verified, so the author refuses rather than guessing. If your whole stack is fp8 or Q8, this pack is not for you yet.

Wrong backbone gives you an error, not a bad video. Wan 1.3B, Wan2.2-5B, Wan2.2 A14B, I2V, VACE - all refused by the shape checks. allow_untested_derivative (default off) lets a derivative through for I2V/VACE-style models, but read that flag's name literally: shape-checked, never actually run.

The renamed-CFG-adapter trap. With verify_sha256 on, alpha comes from the pinned hash and you can rename the file freely. Turn it off and the CFG adapter's alpha has to come from a sibling adapter_config.json - which is only read next to a file literally named adapter_model.safetensors. Rename it and it gets refused rather than applied with a guessed alpha. Good failure, annoying surprise.

Double-apply is refused, and it catches swapped inputs by checking which pinned release landed in which slot.

One last thing: this node only applies the adapters. Pair it with LongLive-Plug Sampling Recipe, which refuses to build a LongLive-Plug recipe unless the marker this node writes is present on the model. That's the intended pair, and the interlock is a feature - it's the difference between a 4-step run and a 4-step run that looks like a bad upscale.