⬡ Polyhedron LoRA Engine

Calling it the "LoRA Engine" is the honest name. This node is the sibling of the big LoRA Stack, and it exists for one reason: engine-class LoRAs - Lightning, Turbo, LCM, FusionX, CausVid, LightX2V and the like - don't depict things, they change how the model computes. They alter the inference trajectory, usually by collapsing the number of steps the model needs. That's a different job from a style or character LoRA, which is why the pack keeps them in a separate, simpler node instead of letting them mingle with your creative stack.

There's a real reason for the separation, and the community has the scars to prove it. On Wan 2.2, speed LoRAs are famous for "killing everything good" about the model when they're slapped on at full strength - washed-out detail, plastic skin, motion that dies. The fix everyone landed on is to keep the acceleration LoRA on the low-noise pass only, at reduced strength, usually around 0.4–0.6, with CFG 1.0. The Engine is where you park those acceleration LoRAs so you can reason about them separately from the fifteen style and character LoRAs in the Stack.

How it works

Where the Stack organizes its rows into semantic groups (acc → style → scene → motion → subject → detail → custom), the Engine is deliberately flat: one list, one global merge mode, no groups to think about. Behind the scenes it's the same universal merge machinery as the Stack - sequential, combined, or DARE-based merging, all model-agnostic, so it works on WAN 2.1/2.2, FLUX, SDXL and SD 1.5 alike.

You wire your loaded model into model (and optionally a clip), the node applies the engine LoRAs in order, and hands the patched MODEL out the other side. In a dual-noise Wan 2.2 workflow you run two of them side by side, one per expert:

[UNet HIGH] → [Engine HIGH] → [Stack HIGH] → [Sampler HIGH]
[UNet LOW]  → [Engine LOW]  → [Stack LOW]  → [Sampler LOW]

That's the whole point of the dual-HIGH/LOW pattern this pack is built around: your Lightning or LightX2V LoRA goes on the LOW lane where it belongs, and the HIGH lane keeps the full-quality model for structure and motion.

The inputs that matter

There are only three, and two of them are the same pins as any LoRA loader:

• model - the MODEL to patch. Required.
• clip - optional CLIP, patched alongside for models whose LoRAs carry text-encoder keys (SDXL, SD 1.5).
• engine_config - the JSON string the node's UI manages for you (rows + merge mode, default SEQ). You don't hand-edit this; the row list and mode dropdown on the node write it.

Outputs are MODEL, CLIP, and a debug_info string if you want to see what got applied.

Installing it

This is one node in the Polyhedron Suite pack - install once, get all of them. ComfyUI Manager: search "Polyhedron Suite". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack.git
# restart ComfyUI

No hard Python dependencies; the nodes run on what ComfyUI already ships. The one gotcha that bites: the Engine's UI is hand-drawn on the classic LiteGraph canvas, so under ComfyUI's new "Modern Node Design" (Nodes 2.0) renderer it can appear empty. Disable that renderer in Settings and it's fine - your rows and settings survive either way.

Where people get burned

The most common mistake is treating the Engine as a second Stack and stacking a dozen rows in it. It's a flat list by design - engine LoRAs are few and fiddly, and stacking them multiplies their quirks. And remember the distilled-model rule: if your Engine row is a Lightning-style LoRA, the sampler downstream needs the matching low step count and CFG near 1.0, not your usual 20-step/CFG-6 recipe. The LoRA gets you speed; the sampler has to actually honor it.